Почему Google готовит while(1);к их ответам на JSON

javascript json ajax security


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

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




Answer 1 rjh


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

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




Answer 2 Arnaud Le Blanc


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




Answer 3 bdonlan


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

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




Answer 4 Daniel Vassallo


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




Answer 5 Pointy


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


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

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