Сведения о вопросе

NOTtoday

02:07, 22nd August, 2020

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

Просмотров: 423   Ответов: 6

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

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

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



  Сведения об ответе

PHPH

07:20, 18th August, 2020

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

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

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

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

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

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

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

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


  Сведения об ответе

padenie

21:58, 15th August, 2020

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

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

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

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

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

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

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

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


  Сведения об ответе

FAriza

20:39, 25th August, 2020

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


  Сведения об ответе

ASER

11:10, 28th August, 2020

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


  Сведения об ответе

DO__IT

21:36, 22nd August, 2020

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

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

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


  Сведения об ответе

lats

11:37, 21st August, 2020

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


Ответить на вопрос

Чтобы ответить на вопрос вам нужно войти в систему или зарегистрироваться