Почему 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 (Mail, Calendar, Contacts и т. Д.) Как ни странно, Google Docs начинается с &&&START&&&этого, а Google Contacts, кажется, начинается с while(1); &&&START&&&.

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

Он предотвращает угон 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 без какой-либо обработки, что приводит либо к бесконечному циклу, либо к синтаксической ошибке.

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

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

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

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

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

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

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

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

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

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

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