Безопасно ли использовать JSONP? - PullRequest
65 голосов
/ 05 марта 2009

Есть ли какие-либо проблемы безопасности, которые следует учитывать при использовании JSONP?

Ответы [ 4 ]

65 голосов
/ 05 марта 2009

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

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

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

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

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

21 голосов
/ 08 сентября 2009

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

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

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

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

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

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

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

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

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

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

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

3 голосов
/ 16 июня 2011

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.

...