Поскольку это сообщение с высоким трафиком, я надеюсь дать здесь несколько более неопределенный ответ на исходный вопрос и, таким образом, предоставить дополнительную информацию об атаке JSON Hijacking и ее последствиях

JSON Hijacking, как следует из названия, представляет собой атаку, аналогичную подделке межсайтовых запросов, когда злоумышленник может получить доступ к междоменным конфиденциальным данным JSON из приложений, которые возвращают конфиденциальные данные в виде литералов массива для запросов GET. Пример вызова JSON, возвращающего литерал массива, показан ниже:

[{"id":"1001","ccnum":"4111111111111111","balance":"2345.15"}, 
{"id":"1002","ccnum":"5555555555554444","balance":"10345.00"}, 
{"id":"1003","ccnum":"5105105105105100","balance":"6250.50"}]

Эту атаку можно выполнить за 3 основных этапа:

Шаг 1. Заставьте аутентифицированного пользователя посетить вредоносную страницу. Шаг 2. Вредоносная страница попытается получить доступ к конфиденциальным данным из приложения, в которое вошел пользователь. Это можно сделать путем встраивания тега сценария в HTML-страницу, поскольку политика одного и того же происхождения не применяется к тегам сценария.

<script src="http://<jsonsite>/json_server.php"></script>

Браузер сделает запрос GET на json_server.php, и любые файлы cookie аутентификации пользователя будут отправлены вместе с запросом. Шаг 3. На этом этапе, пока вредоносный сайт выполнил сценарий, у него нет доступа к каким-либо конфиденциальным данным. Доступ к данным можно получить с помощью установщика прототипа объекта. В приведенном ниже коде свойство прототипов объекта привязывается к определенной функции при попытке установить свойство «ccnum».

Object.prototype.__defineSetter__('ccnum',function(obj){
    secrets =secrets.concat(" ", obj);
});

На этом этапе вредоносный сайт успешно захватил конфиденциальные финансовые данные (ccnum), вернул byjson_server.php JSON

Следует отметить, что не все браузеры поддерживают этот метод; Доказательство концепции было выполнено в Firefox 3.x. Этот метод устарел и заменен на useObject.defineProperty. Также существует вариант этой атаки, который должен работать во всех браузерах, где используется JavaScript с полным именем (например, pi=3.14159). возвращается вместо массива JSON.

Есть несколько способов предотвратить захват JSON:

• Поскольку теги SCRIPT могут генерировать только HTTP-запросы GET, в POST возвращаются только объекты JSON. запросы.

• Запретить веб-браузеру интерпретировать объект JSON как допустимый код JavaScript.

• Реализуйте защиту от подделки межсайтовых запросов, требуя, чтобы для всех запросов JSON требовалось предварительно определенное случайное значение.

, как вы видите, While(1) относится к последнему варианту. Проще говоря, while(1) - это бесконечный цикл, который будет выполняться до тех пор, пока явно не будет выдан оператор break. И, таким образом, то, что можно было бы описать как блокировку для применяемого ключа (инструкция google break). Поэтому захват JSON, при котором у хакера нет ключа, будет последовательно отклоняться. Увы, если вы читаете блок JSON с помощью парсера, цикл while (1) игнорируется.

Итак, в заключение, цикл while(1) проще представить как простой шифр оператора прерывания, который Google может использовать для управления потоком данных.

Однако ключевым словом в этом операторе является слово « простой ». Использование аутентифицированных бесконечных циклов, к счастью, было исключено из основной практики в с 2010 из-за абсолютного уменьшения использования ЦП, когда изолировал (и тот факт, что Интернет ушел от продвигаясь через грубые «быстрые решения»). Сегодня вместо этого в кодовую базу встроены превентивные меры, и система больше не имеет решающего значения и не эффективна. (отчасти это связано с переходом от JSON Hijacking к более продуктивным методам сбора данных, которые я сейчас не буду вдаваться в подробности)

После аутентификации защита от перехвата JSON может разнообразие форм. Google добавляет в то время как (1) в свои данные JSON, поэтому что если какой-либо вредоносный сценарий оценивает его, вредоносный сценарий входит бесконечный цикл.

Ссылка: Поваренная книга по тестированию веб-безопасности: систематические методы быстрого поиска проблем

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

Он предотвращает раскрытие ответа через захват JSON.

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

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

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

За исключением того, что при использовании тега сценария для запроса содержимого JSON JSON выполняется как JavaScript в контролируемой злоумышленником среде. Если злоумышленник может заменить конструктор массива или объекта или какой-либо другой метод, используемый во время создания объекта, все, что есть в 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"}

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

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

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

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

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

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

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

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

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

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

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

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