Возможно ли в XSS использовать ответы JSON с надлежащим экранированием строки JavaScript? - PullRequest
Новая
       2

Возможно ли в XSS использовать ответы JSON с надлежащим экранированием строки JavaScript?

37 голосов
/ 30 июня 2010

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

Предположим, что оба этих вектора адресованы обычным способом. Google классно перехватывает прямые источники ответов JSON, добавляя к префиксу JSON что-то вроде: 

throw 1; < don't be evil' >

А затем следует остальная часть JSON. Таким образом, доктор Зло не может, используя вид эксплойта, обсужденный здесь http://sla.ckers.org/forum/read.php?2,25788, получить ваш файл cookie (если вы вошли в систему), разместив на своем сайте следующее: 

<script src="http://yourbank.com/accountStatus.json">

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

Но мой вопрос: а что, если вы все это делаете?

Burpsuite (автоматизированное средство безопасности) обнаруживает встроенные попытки XSS, которые возвращаются без экранирования HTML в ответе JSON, и сообщает об этом как об уязвимости XSS. У меня есть сообщение, что мое приложение содержит уязвимости такого рода, но я не уверен. Я пробовал это, и я не могу заставить эксплойт работать.

Так что я не думаю, что это правильно, но я прошу вас принять участие в сообществе StackOverflow.

Есть один конкретный случай, например, при прослушивании IE MIME-типа, который, я думаю, может привести к эксплойту. В конце концов, в IE 7 все еще была «особенность», заключающаяся в том, что теги скрипта, встроенные в комментарии к изображению, выполнялись независимо от заголовка Content-Type. Давайте сначала оставим в стороне такое явно глупое поведение.

Конечно, JSON будет анализироваться либо собственным синтаксическим анализатором JavaScript (Window.JSON в Firefox), либо eval () в соответствии со старым поведением jQuery по умолчанию. Ни в том, ни в другом случае следующее выражение не приведет к выполнению предупреждения: 

{"myJSON": "legit", "someParam": "12345<script>alert(1)</script>"}

Я прав или я не прав?

Ответы [ 4 ]

26 голосов
/ 30 июня 2010

Этой потенциальной xss-уязвимости можно избежать, используя правильный Content-Type. На основе RFC-4627 все ответы JSON должны использовать тип application/json. Следующий код не уязвим для xss, протестируйте его: 

<?php
header('Content-type: application/json'); 
header("x-content-type-options: nosniff");
print $_GET['json'];
?>

Заголовок nosniff используется для отключения перехвата содержимого в старых версиях Internet Explorer. Другой вариант выглядит следующим образом: 

<?php
header("Content-Type: application/json");
header("x-content-type-options: nosniff");
print('{"someKey":"<body onload=alert(\'alert(/ThisIsNotXSS/)\')>"}');
?>

когда вышеуказанный код просматривается браузером, пользователю было предложено загрузить файл JSON, JavaScript не выполнялся в современных версиях Chrome, FireFox и Internet Explorer. Это будет нарушением RFC .

Если вы используете JavaScript для eval() JSON выше или напишите ответ на страницу, тогда он станет DOM Based XSS . XSS на основе DOM исправляется на клиенте путем очистки JSON перед обработкой этих данных.

7 голосов
/ 19 января 2014

Burpsuite (автоматизированный инструмент безопасности) обнаруживает встроенные попытки XSS, которые возвращаются без экранирования HTML в ответе JSON, и сообщает об этом как об уязвимости XSS.

Возможно, он пытается предотвратитьуязвимость, описанная в правиле 3.1 шпаргалки OWASP XSS .

Они приводят следующий пример уязвимого кода: 

<script>
    var initData = <%= data.to_json %>;
</script>

Даже если двойные кавычки, косая черта исимволы перевода строки правильно экранированы, вы можете выйти из JSON, если он встроен в HTML: 

<script>
    var initData = {"foo":"</script><script>alert('XSS')</script>"};
</script>

jsFiddle .

to_json() Функция может предотвратить эту проблему с помощью префиксакаждая косая черта с обратной косой чертой.Если в атрибуте HTML используется JSON, вся строка JSON должна быть экранирована HTML.Если он используется в атрибуте href="javascript:", он должен быть экранирован.

0 голосов
/ 21 сентября 2018

Для записи, хотя я принял ответ, для точного буквального вопроса, который я задаю, я был прав, и не было никакой уязвимости из-за присутствия не-HTML-экранированного, но корректно экранированного JSON HTML внутри значений JSON. Там может быть ошибка, если это значение было вставлено в DOM без побега клиента, но у Burpsuite мало шансов узнать, произойдет ли это, просто посмотрев на сетевой трафик.

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

0 голосов
/ 29 марта 2012

Если мы ограничим нашу область применения IE (все версии), предположим, что вы работаете с сайтом на основе PHP или ASP.NET и игнорируете фильтр IE анти-xss, то вы ошибаетесь: ваши пользователи уязвимы. Настройка Content-type: application / json также не поможет.

Это связано с (как вы упомянули) поведением IE по обнаружению контента, которое выходит за рамки отслеживания тегов HTML в теле ответа и включает анализ URI.

Это сообщение в блоге объясняет это очень хорошо:

http://blog.watchfire.com/wfblog/2011/10/json-based-xss-exploitation.html

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.

Нет похожих вопросов

...