Ответ 1

Он предотвращает захват JSON, серьезную проблему безопасности JSON, которая официально исправлена во всех основных браузерах с 2011 года с помощью ECMAScript 5.

Придуманный пример: скажем, у Google есть URL-адрес, например mail.google.com/json?action=inbox, который возвращает первые 50 сообщений из вашего почтового ящика в формате JSON. Злые сайты в других доменах не могут отправлять запросы AJAX на получение этих данных из-за политики того же происхождения, но они могут включать URL-адрес через тег <script>. URL посещают ваши куки, и переопределяя конструктор глобального массива или методы доступа, они могут иметь метод, вызываемый всякий раз, когда установлен атрибут объекта (массива или хеша), позволяющий им читать содержимое JSON.

while(1); или &&&BLAH&&& предотвращают это: запрос AJAX на mail.google.com будет иметь полный доступ к текстовому содержимому и может его убрать. Но вставка тега <script> слепо выполняет JavaScript без какой-либо обработки, что приводит либо к бесконечному циклу, либо к синтаксической ошибке.

Это не решает проблему подделки межсайтовых запросов.

Ответ 2

Это предотвращает разглашение ответа через угон JSON.

Теоретически содержимое HTTP-ответов защищено одной и той же политикой происхождения: страницы из одного домена не могут получать какие-либо фрагменты информации со страниц из другого домена (если это явно не разрешено).

Злоумышленник может запрашивать страницы в других доменах от вашего имени, например, с помощью тега <script src=...> или <img>, но он не может получить никакой информации о результате (заголовки, содержимое).

Таким образом, если вы посетите страницу злоумышленника, он не сможет прочитать вашу электронную почту с gmail.com.

За исключением того, что при использовании тега сценария для запроса содержимого JSON JSON выполняется как Javascript в среде, контролируемой злоумышленником. Если злоумышленник может заменить конструктор Array или Object или какой-либо другой метод, используемый во время создания объекта, все, что в JSON, пройдет через код злоумышленника и будет раскрыто.

Обратите внимание, что это происходит во время выполнения JSON как Javascript, а не во время его анализа.

Существует несколько контрмер:

Убедитесь, что JSON никогда не выполняется

Поместив оператор while(1); перед данными JSON, Google гарантирует, что данные JSON никогда не выполняются как Javascript.

Только легитимная страница может фактически получить весь контент, убрать while(1); и проанализировать остаток как JSON.

Такие вещи, как for(;;); были замечены на Facebook, например, с такими же результатами.

Убедитесь, что JSON не является допустимым Javascript

Аналогично, добавление недопустимых токенов перед JSON, например, &&&START&&&, гарантирует, что он никогда не будет выполнен.

Всегда возвращайте JSON с Объектом снаружи

Это OWASP рекомендуемый способ защиты от угона JSON и менее навязчивый.

Подобно предыдущим контрмерам, он гарантирует, что JSON никогда не выполняется как Javascript.

Допустимый объект JSON, если он ничем не заключен, недопустим в Javascript:

eval('{"foo":"bar"}')
// SyntaxError: Unexpected token :

Это, однако, допустимый JSON:

JSON.parse('{"foo":"bar"}')
// Object {foo: "bar"}

Итак, убедитесь, что вы всегда возвращаете Object на верхнем уровне ответа, убедитесь, что JSON не является допустимым Javascript, но при этом остается действительным JSON.

Как отмечает @hvd в комментариях, пустой объект {} является допустимым Javascript, и знание того, что объект пуст, само по себе может быть ценной информацией.

Сравнение вышеуказанных методов

Способ OWASP менее навязчив, так как не требует изменений клиентской библиотеки и передает действительный JSON. Однако неизвестно, могут ли прошлые или будущие ошибки браузера победить это. Как отмечает @oriadam, неясно, могут ли данные быть пропущены в результате ошибки синтаксического анализа посредством обработки ошибок или нет (например, window.onerror).

В способе Google требуется клиентская библиотека, чтобы она поддерживала автоматическую десериализацию, и ее можно считать более безопасной в отношении ошибок браузера.

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

Ответ 3

Это делается для того, чтобы какой-то другой сайт не смог сделать неприятные трюки, чтобы попытаться украсть ваши данные. Например, заменив конструктор array, затем включив этот URL JSON с помощью тега <script>, сайт-сайт вредоносного third- мог бы украсть данные из ответа JSON. Помещая while(1); в начале, вместо этого будет script.

A same- запрос сайта с использованием XHR, а отдельный анализатор JSON, с другой стороны, может легко игнорировать префикс while(1);.

Ответ 4

Это было бы затруднительно для сторон third- вставить ответ JSON в HTML-документ с тегом <script>. Помните, что тег <script> освобожден от Политика одинакового происхождения.

Ответ 5

Примечание: с 2019 года многие из старых уязвимостей, которые приводят к профилактическим мерам, обсуждаемым в этом вопросе, больше не являются проблемой в современных браузерах. Я оставлю ответ ниже как историческое любопытство, но на самом деле вся тема радикально изменилась с 2010 года (!!), когда об этом спросили.

Он не позволяет использовать его в качестве цели простого тега <script>. (Ну, это не мешает этому, но делает его неприятным.) Таким образом, злоумышленники не могут просто разместить этот тег сценария на своем собственном сайте и полагаться на активный сеанс, чтобы сделать возможным получение вашего контента.

изменить &— обратите внимание на комментарий (и другие ответы). Проблема связана с извращенными встроенными средствами, в частности с конструкторами Object и Array. Они могут быть изменены таким образом, чтобы в противном случае безобидный JSON при анализе мог вызвать код злоумышленника.

Ответ 6

Поскольку <script> освобожден от той же политики происхождения, что является необходимостью безопасности в веб-мире, while(1) при добавлении в ответ JSON предотвращает его неправильное использование в <script>.