Безопасность JSONP, о которой также необходимо знать внешним интерфейсам

внешний интерфейс JSON Безопасность
Безопасность JSONP, о которой также необходимо знать внешним интерфейсам

Что такое JSONP (JSON с дополнением)?

Что? Вы до сих пор не знаете, что такое JSONP? Поторопитесь и помиритесь, я не буду больше говорить об этом. Сначала создайте ссылку на энциклопедию Baidu,Encyclopedia.Baidu.com/item/JSON P/…

Какие риски безопасности будут? Как предотвратить?

Мы предполагаем, что есть такой сценарий
я вошел в системуwww.qq.com, QQ может иметь такой интерфейс jsonp для предоставления услуг третьим лицам,www.qq.com/getUserInfo?callback=action, то я могу сам создать вредоносную страницу, запросить этот интерфейс jsonp, разместить его в сети и собрать информацию о пользователях qq. Если интерфейс jsonp также включает в себя некоторые конфиденциальные операции или информацию, это будет еще более увлекательно, например, вход в систему, удаление и другие операции. Однако многие back-end разработчики в Китае не обращают внимания на эту проблему.Я вдруг вспомнил, что back-end разработка старой компании написала общую функцию для того, чтобы ускорить разработку.Пока интерфейс, который может получить доступ с помощью GET, можно получить с помощью jsonp. Эммм...

В первом случае сначала необходимо проверить источник (Referer) вызова JSONP.Эта схема использует функцию, согласно которой Referer будет отправлен при загрузке js-ресурса, и сервер может определить, является ли Referer белым списком.
Легко сказать, но на самом деле он будет обойден, потому что регулярность фильтрации не является строгой, например, только проверка того, существует она или нет.www.qq.comключевое слово, то я могу построитьwww.qq.com.domain.comнападать. Другой пример: многие разработчики разрешают пустой Referer, но вызов js через протоколы не отправляет Referer.<iframe src="javascript:'<script src=http://attack.com/jsonp></script>'"></iframe>Код использует iframe для вызова псевдопротокола javascript для отправки запроса js с пустым реферером.
Так что пустой реферер все равно придется банить.
Кроме того, для защиты используется случайный токен. Каждый запрос сопровождается значением токена. Значение токена должно быть длиннее с буквами и цифрами, иначе его можно взломать методом грубой силы.

Далее вторая сцена
Уязвимость XSS, вызванная неточным типом контента Представьте, что вы запрашиваете jsonphttp://youdomain.com?callback=douniwan, затем вернутьсяdouniwan({ data }), то если запросhttp://youdomain.com?callback=<script>alert(1)</script>не возвращайся<script>alert(1)</script>({ data }), если не строго определеноContent-Type( Content-Type: application/json ), плюс нет фильтрации параметра callback, при прямом парсинге html это голый XSS. Content-Type установлен наapplication/javascriptВ браузерах, таких как IE, он может быть преобразован в HTML, чтобы вызвать XSS-уязвимости. Поэтому он должен быть строго определен какapplication/json. Но даже в этом случае перед различными браузерами будут специальные, например, в IE6/7 добавление /x.html после того, как запрошенный файл URL может быть преобразован в html.

Защита от этой ситуации начинается со строгого определенияContent-Type: application/json, а затем строго фильтровать параметры после обратного вызова и ограничивать длину.
Иногда мы увидим это начало в возвращаемом содержимом встроенной функции jsonp некоторых фреймворков: /**/, например, встроенная функция jsonp фреймворка Express будет возвращаться так:

/**/ typeof func === 'function' && func({"data":"hello"});

Почему это? На самом деле тому есть исторические причины: в 2011 году была обнаружена уязвимость в междоменном парсинге через протокол mhtml: MHTML Mime-Formatted Request Vulnerability (CVE-2011-0096), которая также затронула кучу международных производителей на то время. Чтобы узнать больше, нажмите здесь,техническая сеть.Microsoft.com/library/color…
Защита заключается в добавлении /**/ или нескольких символов новой строки впереди, чтобы в определенной степени предотвратить вывод файлов других форматов.

Далее третья сцена
Если мой веб-сайт использует сторонний сервис, а другая сторона предоставляет только интерфейс jsonp, если сервер другой стороны взломан и возвращается строка вредоносных кодов, разве городские ворота не горят, и он принести бедствие в Чию?
Помните слово, всем третьим лицам нельзя полностью доверять.
С точки зрения защиты, прежде всего, рассмотрим, какие защитные меры может выполнить передняя часть?
фреймы? Вроде можно, искал, кто-то пробовал в интернете, подробности можно посмотреть здесьGitHub.com/A UI/JSON P - это...
Как иначе? Похоже, что во внешнем интерфейсе нет функции для обнаружения возвращаемого js-контента, и, кажется, не с чем играть.
Другой способ мышления, переадресация сервера, поскольку внешний интерфейс не может обнаружить сторонний jsonp-контент, я использую свой собственный сервер, чтобы определить, является ли сторонний jsonp-контент законным, а затем возвращаю результат.

наконец

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