Почему Google добавляет while(1); к своим (частным) ответам JSON?

Например, вот ответ при включении и выключении календаря в Календаре Google:

while (1);
[
  ['u', [
    ['smsSentFlag', 'false'],
    ['hideInvitations', 'false'],
    ['remindOnRespondedEventsOnly', 'true'],
    ['hideInvitations_remindOnRespondedEventsOnly', 'false_true'],
    ['Calendar ID stripped for privacy', 'false'],
    ['smsVerifiedFlag', 'true']
  ]]
]

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

Я видел, что это использовалось и в нескольких других местах, но гораздо больше с Google (почта, календарь, контакты и т. Д.) Как ни странно, Документы Google начинаются с &&&START&&&, а контакты Google, похоже, начинаются с while(1); &&&START&&&.

Что тут происходит?

4199
Jess 19 Апр 2010 в 22:00

7 ответов

Лучший ответ

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

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

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

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

4260
PaulMest 10 Мар 2019 в 18:30

Это предотвращает раскрытие ответа через угон 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.

561
Moustaf EL-Saghier 5 Мар 2020 в 13:30

Это сделано для того, чтобы какой-то другой сайт не мог делать неприятные трюки, пытаясь украсть ваши данные. Например, заменив конструктор массива, а затем включив этот URL-адрес JSON через {{ X0}}, злонамеренный сторонний сайт может украсть данные из ответа JSON. Поместив while(1); в начало, скрипт будет зависать.

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

367
hippietrail 31 Янв 2014 в 23:43

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


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

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

80
Pointy 18 Мар 2019 в 02:52

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

110
George Stocker 30 Дек 2013 в 03:10

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

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

0
JSON C11 2 Мар 2020 в 01:24

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

11
Pang 28 Авг 2018 в 09:45