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

Почему 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 начинается с &&&START&&&, а Google Contacts начинается с while(1); &&&START&&&.

Что здесь происходит?

3202
задан Jess 19 апр. '10 в 21:00
источник поделиться
6 ответов

Это предотвращает JSON hijacking.

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

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

Это не затрагивает проблему cross- подделку запроса сайта.

3518
ответ дан rjh 19 апр. '10 в 21:11
источник поделиться

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

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

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

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

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

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

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

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

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

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

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

Убедитесь, что JSON недействителен Javascript

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

Всегда возвращайте JSON с Object снаружи

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

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

Действительный JSON object,, если он не заключен никем, недействителен в Javascript:

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

Однако это справедливо JSON:

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

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

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

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

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

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

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

373
ответ дан arnaud576875 02 февр. '14 в 15:09
источник поделиться

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

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

332
ответ дан bdonlan 16 мая '09 в 5:08
источник поделиться

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

91
ответ дан Daniel Vassallo 19 апр. '10 в 21:04
источник поделиться

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

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

59
ответ дан Pointy 19 апр. '10 в 21:02
источник поделиться

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

-1
ответ дан kg11 18 авг. '17 в 7:14
источник поделиться

Другие вопросы по меткам