Безопасный кроссдоменный обмен данными между AJAX и PHP?

Question

[Robotex]

На одном сервере лежит PHP скрипт, на другом есть сайт, использующий AJAX. Как передавать между ними данные, чтобы гарантировать конфеденциальность и невозможность подделывания (вместо AJAX может быть и Flash, и обычные GET/POST запросы — на сокетах то просто, а нужно вот так вот)?



Единственное, что приходит в голову, это дополнительный скрипт ПХП и сокеты + SSL. Но это не очень удобно (т.к. может использоваться флеш без ПХП). Использование секретных ключей не кажется мне безопасным — флеш или яваскрипт легко стянуть и подстмотреть всю информацию. RSA — в одну сторону отправлю, но в обратную опять же — можно подсмотреть секретный ключ.



Какие есть варианты?

Answer 1

[Искандер Гиниятуллин]

Очевидно что вы плохо понимаете как работает openApi раз пытаетесь все время сравнивать то, что вам нужно, с этой технологией.

Там структура такая: есть браузер клиента, с яваскриптом.
Есть сервер сайта.
Есть сервер вконтакте.

Когда человек хочет авторизоваться на сайте он жмет кнопку «авторизоваться через в контакте». Открывается всплывающее окно со страницей с домена вконтакте, там пользоватлеь вводит email/пароль, данные его (логин и пароль) отправляются серверу контакта. Сервер контакта их проверяет и если все ОК отправляет данные серверу сайта, на котором человек авторизуется. Сервер сайта, приняв эти данные, проверяет их и если все ок авторизует человека.

Т.е. проверка подлинности данных происходит на стороне сервера, а не на стороне яваскрипт.

Хранить ключи в яваскрипте/флеше не вариант и так никто не делает. В любом случае нужен дополнительный скрипт на стороне сервера-клиента, который будет проверять подлинность пришедших от сервера-поставщика услуги данных и уже потом передавать их в браузер (аяксом или еще как то)

Ответ на вопрос выше: как определить что посетитель уже залогинен на сайте-поставщике услуги?
Очень просто, сайт-поставщик услуги ставит клиенту свою куку. сайт-клиент ставит на своей странице iframe в котором грузится спецстраница сайта-поставщика со спец параметром типа from=site-client. Сайт-поставщик услуги получив запрос этой страницы смотрит есть ли у человека его кука и если есть то шлет серверу сайта-клиента необходимые данные, а сайт-клиент уже аяксом шлет данные в браузер пользователя.

Весь обмен данными с точки зрения JS происходит в пределах одного домена: через iframe с сайтом-поставщиком и аяксом с сайтом-клиентом.

Весь кроссдоменный обмен данными (между сайтом-поставщиком и сайтом-клиентом) происходит уже на стороне серверов без участия браузеров клиентов и эти данные невозможно перехватить.

Comments

[Nyarlathotep]

Если я все-таки правильно в итоге понял вопрос, то как раз сторону сервера можно убрать.
Что мешает открыть ифрейм с сайтом поставщиком услуги? Залогинен: все хорошо, все работает.
Не залогинен: форма логина. Даже если злоумышленник скажет своей локальной версии страницы каким-то обрзом, что он залогинен это не даст ему ровным счетом ничего, т.к. любой следующий запрос будет не обработан с предложением залогиниться. А к примеру получив сессионный ключ, яваскрипт на странице может уже работать и с сервером поставщиком услуги. И вроде именно так происходит логин на тот же вконтакт со сторонних сайтов. Там вроде ничего не надо ставить именно на сервер (именно относящегося к процедуре логина, понятно, что обрабатывать данные пользователя все равно надо).

[Искандер Гиниятуллин]

по сути да, если автору просто нужно внедрять какую то фигню на сайты-клиенты (типа информеров или каких то форм) то это можно делать просто создавая iframe

[Искандер Гиниятуллин]

Если выпосмотрите пример авторизации через вконтакте:

vkontakte.ru/developers.php?o=-1&p=Auth

то вы увидите что для проверки авторизации сервер вконтакте кроме данных пользователя возвращает также hash от конкатенированной строки app_id+user_id+secret_key, при этом secret_key как ни крути мы должны хранить на сервере, и если мы хотим быть уверены что это именно тот юзер у нас авторизовался, на стороне сервера придется делать проверку этого хеша, и это относится к процедуре логина

[Nyarlathotep]

ВКонтакте, как я писал выше, два ключа: secret_key и private_key. Secret_key нужен всего лишь для усложнения жизни взломщикам (отсеивает 99% script kiddie).

Answer 2

[Nyarlathotep]

Все зависит от того, можно ли что-либо сделать не client-side, а server-side с сайтом человека, которому представляется услуга. ВКонтакт именно так и работает, если мне не изменяет память.
(Ну если быть полностью точным, то там два набора ключей, один для усложнения жизни тем, кто будет ломать, второй действительно секретный, который знает только серверные части).

Т.е. ситуация меняется, AJAX спрашивает не у вашего сайта, а у сайта, который потом спрашивает ваш (причем делает это либо много раз, либо после первого успеха ставит правильную сессионную куку и т.д.).

Т.е. если человек изменит что-либо на клиентской части, да что угодно, то серверная часть все равно откажется обрабатывать его запросы.

Взаимодействие между сайтом клиента и вашим сайтом может быть по любому протоколу, ведь его пользователь не может подделать.

На примере авторизации:

A — AJAX, S — сайт клиента, U — ваш сайт.

A -> S: авторизируй меня, вот мои данные (хоть сколько раз подделанные)
S -> U: тут кто-то хочет авторизоваться, вот его данные
U -> S: окей, данные нормальные
S -> A: вот тебе сессионная кука, работай дальше

Поскольку в такой схеме у злоумышленника нет контроля над данными между S и U он ничего критичного сделать не сможет.

Comments

[Макс Кузнецов]

опять Аякс превращается в какого-то таинственного активного участника. Лучше вместо AJAX написать USER, так понятнее.
Вопрос автора, мне кажется, глубже — он как раз и интересуется, как обезопасить соединение между S и U? Как сделать так, чтобы S не использовал данные USER'а?

[Robotex]

Вообще-то, я спрашивал как обойтись без S, и безопасно реализовать схему:
A -> U: авторизируй меня, вот мои данные (хоть сколько раз подделанные)
U -> A: ты авторизован (или данные поддельные, пошел вон), хочешь, поставь себе куку.

[Nyarlathotep]

Просто логин и пароль? Вообще просто… Что там можно подделать?
(простите запутался с системой комментариев хабра, развернуто ниже отписался)

Answer 3

[Макс Кузнецов]

Заинтересовался вашим вопросом и решил разобраться.
Как оказалось, авторизация вконтакте организована с помощью своего Open API и напоминает openID. Здесь написано о нём.
Собственно, на данный момент могу только помочь советом (почитайте про openID и Open API). В ближайшее время постараюсь сам в этом разобраться и отпишусь сюда, если вопрос будет актуален.

Comments

[Robotex]

Вот этот openAPI как-то ведь шифруется от подделок.

Answer 4

[Макс Кузнецов]

если уж вы смотрели в сторону RSA, то можно сделать шифрование с открытом ключом. Как я понимаю, вы хотите передавать данные с одного своего домена на другой свой же? Тогда этот тип шифрования подойдет. Но это лишь предположение, как можно решить задачу, наверняка есть и более лёгкие способы.

Comments

[Robotex]

PHP мой домен, AJAX — не мой. Я могу прописать открытый ключ в яваскрипте и безопасно слать на свой PHP. Но чтобы безопасно отсылать с PHP на AJAX (в ответ на GET), нужно чтобы в яваскрипте был прописан секретный ключ. А тогда можно стянуть этот скрипт и подсмотреть ключ.

[Макс Кузнецов]

так если домен чужой, то вы с него не сможете запросы на свой слать. Да и что-то непонятно, как вы на чужом домене хотите яваскрипт изменить. XSS?

[Robotex]

Я не понимаю о чем вы. Я даю человеку JavaScript, он встраивает его в свой сайт. Я получаю за это деньги, он предоставляемую услугу. Но я еще хочу, чтобы услуга была качественной и безопасной.

Вот как аутентификация на сайте от вконтакте работает? Как они защищаются от подделки ответа?

[Robotex]

Как они скрывают секретный ключ в яваскрипте?

Answer 5

[Nyarlathotep]

Так похоже все гораздо проще, чем я думал.
Что мешает просто авторизоваться по логину и паролю, стандартными методами?

Ну делается скрипт, который открывает окошко с нашего сайта, дает там авторизоваться, после чего выставляет сесию/куку? А дальше все скрипты уже работают с нашим сайтом имея там нормальную авторизацию…

Или надо обезопасится от кривых запросов на наш сайт? Ну так если запросы посылает клиент, то злоумышленник в итоге сможет послать что угодно, как ты не защищайся, т.е. в этом случае без сервера не обойстись.

Comments

[Макс Кузнецов]

А что делать (и как определить), если пользователь уже залогинен на Сайт-сервер? По идее, нужно отсылать на него запрос с какой-то инфой о пользователе, по которой тот его мог бы однозначно определить, проверить и вернуть «Уже авторизован» или «Нет, он у нас не авторизован». Вопрос, как мне кажется, именно в том, какую инфу о пользователе отправлять. Она должна быть доступной Сайту-клиенту и в тоже время известна Сайту-серверу — и этим мы возвращаемся к началу, где автор спрашивает, как можно вшить какую-то секретную информацию в яваскрипт, который передается Сайту-клиенту.

[Nyarlathotep]

Шифрованная кука? Можно ставить на свой домен, а к сайту-поставщику услуги ее передавать другим методом. Вариантов уйма.

Answer 6

[Алекс Белов]

Кратко:
curl и fscopen
С ключами можно заморочится, но через те же curl и fscopen как дополнительная мера.
А ваш флеш или скрипт могут получать данные от скриптов которые выполняют данные функции.