Почему Google добавляет «while (1);» к своим (частным) ответам JSON?
Например, вот ответ при включении и выключении календаря в Google Calendar:
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 & & &
.
Что здесь происходит?
Он предотвращает угон JSON, серьезную проблему безопасности JSON, которая формально фиксируется во всех основных браузерах с 2011 с ECMAScript 5.
Приведенный пример: скажем, у Google есть URL-адрес типа mail.google.com/json?action = inbox
, который возвращает первые 50 сообщений вашего inbox в формате JSON. Злые сайты на других доменах не могут отправлять запросы AJAX на получение этих данных из-за политики того же происхождения, но они могут включать URL-адрес через тег < script >
. URL-адрес посещается с помощью файлов cookie your , и переопределение методов конструктора или доступа глобального массива они могут иметь метод, вызываемый всякий раз, когда объект ( массив или хэш) атрибут установлен, что позволяет им читать содержимое JSON.
We (1);
или& & & BLAH & & & &
предотвращает это: запрос AJAX на mail.google.com
будет иметь полный доступ к текстовому контенту и может удалить его. Но вставка тега < script >
слепо выполняет JavaScript без какой-либо обработки, что приводит к бесконечной петле или синтаксической ошибке.
Это не решает проблему продола межсайтового запроса.
Это предотвращает раскрытие ответа через угон JSON.
Теоретически, содержание ответов HTTP защищено Политикой одного и того же происхождения: страницы из одного домена не могут получать какую-либо информацию со страниц другого домена (если это явно не разрешено).
Злоумышленник может запрашивать страницы на других доменах от вашего имени, например,. с помощью < script src =...>
или< img >
тег, но он не может получить никакой информации о результате (заголовки, содержимое).
Таким образом, если вы посещаете страницу злоумышленника, он не сможет прочитать вашу электронную почту с gmail.com.
За исключением того, что при использовании тега сценария для запроса содержимого JSON JSON выполняется как Javascript в контролируемой среде злоумышленника. Если злоумышленник может заменить конструктор массива или объекта или какой-либо другой метод, используемый во время создания объекта, все, что находится в JSON, пройдет через код злоумышленника и будет раскрыто.
Обратите внимание, что это происходит во время выполнения JSON в виде Javascript, а не во время его анализа.
Есть несколько контрмер:
Размещая оператор while (1); `перед данными JSON, Google следит за тем, чтобы данные JSON никогда не выполнялись как Javascript.
Только законная страница может фактически получить весь контент, удалить while (1);
и проанализировать остаток как JSON .
Такие вещи, как for (;;);
, были замечены, например, в Facebook, с теми же результатами.
Точно так же добавление недопустимых токенов перед JSON, таких как & & & START & & &
, гарантирует, что он никогда не будет выполнен.
Это 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
Это сделано для того, чтобы какой-то другой сайт не мог делать неприятные трюки, пытаясь украсть ваши данные. Например, заменив конструктор массива, затем включив этот URL-адрес JSON с помощью тега < script >
, вредоносный сторонний сайт может украсть данные из ответа JSON. Поставив while (1);
в начале, сценарий будет зависать вместо этого.
Запрос на том же сайте с использованием XHR и отдельного анализатора JSON, с другой стороны, может легко игнорировать префикс while (1); `.
Это затруднит стороннему объекту вставку ответа JSON в документ HTML с тегом < script >
. Помните, что тег < script >
освобождается от Политика того же происхождения.
Примечание : по состоянию на 2019 год многие из старых уязвимостей, которые приводят к превентивным мерам, обсуждаемым в этом вопросе, больше не являются проблемой в современных браузерах. Я оставлю ответ ниже как историческое любопытство, но на самом деле вся тема радикально изменилась с 2010 года (!!) когда это спросили.
& Лт; hr >
Он предотвращает его использование в качестве цели простого тега < script >
. (Ну, это не мешает, но делает это неприятным.Таким образом, плохие парни не могут просто поместить этот тег сценария на свой собственный сайт и полагаться на активный сеанс, чтобы сделать возможным получение вашего контента.
Поскольку тег < script >
освобождается от Политики того же происхождения, что является необходимостью безопасности в веб-мире, , тогда как (1)
при добавлении в ответ JSON предотвращает неправильное использование его в < script >
тег.