Безопасно ли использовать JSONP?

Обновление. JSONP - это распространенный способ взлома для выполнения междоменных запросов. Современные браузеры теперь имеют совместное использование ресурсов Cross Origin, а IE8 + имеет аналогичный XDomainRequest. См. http://enable-cors.org/ для получения дополнительной информации.

JSONP - это просто сценарий, который позволяет использовать обратный вызов. Однако вам следует знать о подделке межсайтовых запросов (CSRF).

Пока вы управляете сценарием и сервером, JSONP не более небезопасен, чем сценарий, включенный в него. Если у вас нет JSONP-сервиса, который возвращает конфиденциальные данные авторизованным пользователям. Вредоносный сайт может отправить запрос в службу (надеясь, что пользователь вошел в систему на вашем сайте) и получить данные. Сервис может проверить реферер запроса, но можно подделать реферер с помощью flash (спасибо Крису Москини).

Представьте себе этот сценарий: - Пользователь входит в свою учетную запись интернет-банка. Сохранение файла cookie сеанса в браузере пользователя. На этом сайте есть служба jsonp с конфиденциальной информацией о пользователе и его учетных записях. - Другие сайты не будут знать, что пользователь вошел в систему, но они могут сделать безумную догадку и попытаться получить доступ к службе jsonp. Поскольку у пользователя есть файл cookie сеанса, браузер получит ответ, и ничто не помешает сайту выполнить публикацию ajax для сохранения конфиденциальных данных на своем сервере.

Обновление от 28 июня 2012 г.. Если вы хотите защитить себя от CSRF-атак, прочитайте подробное сообщение в блоге эксперта по безопасности: http://erlend.oftedal.no/blog/?blogid=130

Да, вам нужно быть осторожным, но при правильном использовании с доверенными службами это относительно безопасно.

Вот краткое изложение проблем безопасности с JSONP, насколько я понимаю:

С точки зрения потребителя:

• Вы должны быть уверены, что провайдер не вернет вредоносный код JavaScript вместо ожидаемого JSON, заключенного в указанный вами обратный вызов JSONP.
• То же самое можно сказать и о любых сторонних встроенных надстройках JavaScript, таких как Google Analytics.
• Это похоже на XSS-атаки только в том смысле, что позволяет третьей стороне выполнять произвольный JavaScript в вашем приложении, однако вы должны сначала выбрать доверие этой третьей стороне, сделав запрос в первую очередь.

С точки зрения провайдера:

• Вы не должны предполагать, что даже если клиентские файлы cookie присутствуют в запросе, потребитель является веб-страницей, находящейся под вашим контролем. Сравните заголовок Referer с белым списком авторизованных URL-адресов и / или не полагайтесь на аутентификацию на основе файлов cookie.
• Аналогично атаке CSRF / сбитого с толку депутата.

Есть проблемы с безопасностью для обеих сторон. Самый серьезный - для сайта, включающего JSONP.

Если вы включаете домен из другого (который вы не контролируете), этот домен может изменить скрипт в любое время. Они могут заставить javascript делать в контексте вашей веб-страницы все, что может делать ваш собственный javascript. Если вы используете JSONP, этого не избежать. Вы должны изучить междоменное общение с помощью iframe, что лучше всего сделать с помощью отличной библиотеки EasyDXM.

Если вы предлагаете веб-сервис, обрабатывающий JSONP, вам необходимо защитить себя от подделки межсайтовых запросов (CSRF). Здесь ваш веб-сервис возвращает конфиденциальную информацию зарегистрированным пользователям. Если пользователь вошел на ваш сайт, любой другой сайт может сгенерировать запрос GET к службе JSONP, и файлы cookie ВАШЕГО домена отправляются с запросом - по сути, аутентифицируя вошедшего в систему пользователя - за исключением того, что теперь удаленный домен получает ответ и может читать конфиденциальные данные!

Лучший способ защиты от CSRF - создать одноразовый номер (трудно угадываемое, случайно сгенерированное число) и сохранить его в сеансе. Выведите этот одноразовый номер во все формы на ВАШИХ веб-страницах и включите его во все запросы JSONP на ВАШИХ страницах. На сервере убедитесь, что одноразовый номер присутствует и исправен в запросе (будь то GET, POST и т. Д.). Другие домены не смогут угадать этот одноразовый номер и, следовательно, не смогут получить конфиденциальную информацию, несмотря на файлы cookie. послан.

Наконец, существует проблема безопасности другого типа: JSONP просто не поддерживает аутентификацию пользователя в браузере, которая возможна с помощью OAuth. Конечно, вы можете попросить сервер получить какой-то токен доступа (например, с OAuth) и использовать его. Однако, если вы хотите выполнить аутентификацию полностью в браузере, вам необходимо использовать междоменное взаимодействие с iFrames. Думаю, именно так это делает OAuth 2.0. Вот как вы это настраиваете: страницы, размещенные на вашем сайте, имеют полный доступ к вашему серверу. Имейте библиотеку javascript, которая загружает EasyDXM и использует ее для настройки скрытого iframe на вашем сайте, и разговаривайте с ним, используя это.

JSONP определенно небезопасен, поскольку он просто запускает все, что получает кросс-домен, как JavaScript.

решение! решение!

Создайте iframe, желательно изолированный, и загрузите туда JSONP. Получите результат и передайте его через window.postMessage

И да, как всегда, кому-то пришла в голову эта идея первым :)

Публикации в блоге больше нет, но я сохраняю ссылку здесь в качестве кредита: http://beebole.com/blog/general/sandbox-your-cross-domain-jsonp-to-improve-mashup-security/
изменить : ссылка на машину обратного пути

Он использовал хак window.name для связи iframe, но это было для IE6 и 7.