#javascript #security #cross-domain #csrf
#javascript #Безопасность #междоменный #csrf
Вопрос:
Мне нужно получить некоторые данные со стороны сервера Site B into Site A . Для того, чтобы сделать запрос на Site B извлечение данных, существуют файлы cookie, связанные с Site B доменом, которые должны присутствовать. Я предполагаю, что поэтому мне нужно сделать это в javascript с помощью JSONP?
Мои идеи состояли в том, чтобы использовать JavaScript для отправки запроса на B , а затем зафиксировать результат и поместить его в файл cookie в A домене A таким образом, чтобы последующие запросы к A передавали файл cookie с возвращенными данными (не имеет значения, что для получения информации на сервер A требуется два запроса к). Это работало бы нормально, за исключением того, что его можно полностью взломать.
Сами данные не являются секретными, но мне нужно предотвратить подделку запроса или людей, которые Site A вручную вызывают функцию обратного вызова JSONP или вручную устанавливают A cookie с украденными или иным образом подделанными данными. Кроме того, есть ли какая-либо другая лазейка для взлома? Это также необходимо было бы предотвратить!
Единственный способ, которым я могу придумать, как это сделать, это:
Site A генерирует случайный токен и сохраняет его в сеансе. Затем он добавляет этот токен к строке запроса JSONP в Site B . Site B затем отвечает, но шифрует обычные данные вместе с токеном, используя цифровую подпись. Site A затем помещает это значение в cookie на A . В следующем запросе к A , A серверная сторона может перехватить cookie, получить значение, расшифровать его, проверить токен и, если он соответствует значению в сеансе, доверять остальным данным.
Звучит ли это разумно? Есть ли более простой способ? Моя цель — уменьшить сложность в A конце.
Спасибо
Комментарии:
1. Контролируете ли вы оба сайта? т.Е. можете ли вы вносить изменения в код в обоих доменах?
2. Похоже, вы только что заново изобрели криптографию с открытым ключом! Смотрите здесь: en.wikipedia.org/wiki/Public-key_cryptography#A_postal_analogy
3. @bdares нет, я этого не делал, потому что это все равно не предотвращает подделку. что помешает мне украсть чужой зашифрованный repsonse и использовать его самому?
4. @steve
Site A— сайт клиента, желающего воспользоваться моим сервисомSite B. Да, их код можно изменить, но мне нужно, чтобы они выполняли как можно меньше работы5. Любой запрос javascript ajax, который вы отправляете от клиента, может быть подделан, поскольку исходный код javascript может быть прочитан / скопирован / изменен
Ответ №1:
Способ избежать его взлома — заставить сайты взаимодействовать друг с другом напрямую, а не использовать JavaScript на стороне клиента. Напишите небольшой облегченный REST API, который позволяет передавать данные за кулисами, с сервера на сервер.
При ссылке на сайт A включите в URL-адрес токен аутентификации, который затем можно проверить с помощью скрытого вызова сайта B. Этот вызов может передавать любую дополнительную требуемую информацию. Токен, вероятно, должен быть привязан к IP-адресу и истекать после использования. После успешного выполнения вы можете настроить информацию о своих файлах cookie на сайте A, чтобы избежать необходимости дальнейших обходов.
Комментарии:
1. это было бы идеально, но как насчет файлов cookie для
Site B, хранящихся в браузере пользователя?2. Добавлено больше. Вы не можете получить доступ к файлам cookie разных доменов по соображениям безопасности.
3. что вы имеете в виду «при ссылке на сайт A»? кроме того, запросы JSONP будут передавать файлы cookie
4. У вас есть ссылка на пример передачи файлов cookie в формате JSONP? Используете ли вы iFrame? Я предполагаю, что в какой-то момент вы переходите по ссылке с сайта B на сайт A — или ваши пользователи просто переходят на сайт A независимо?
5. ну, он использует тег script, поэтому он будет отправлять файлы cookie так же, как и любой другой запрос, это не ajax / xhr. Сайт A будет использоваться независимо
Ответ №2:
Вы могли бы использовать easyXDM для обмена данными между доменами. С ним у вас есть две программы на javascript, одна в домене потребителей, а другая у поставщиков, которые могут утверждать домен потребителя. Обе эти программы могут взаимодействовать с пользователем, и пользователь может аутентифицироваться перед обеими сторонами. Благодаря тому, что программа providers знает, кто такой пользователь, и кто такой потребитель, поставщик может передавать потребителю любые данные, которые он хочет.
Это то, что крупные компании, такие как Twitter, Disqus и LinkedIn, используют для своих API.