Почему Google работает в то время как (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 (Почта, Календарь, Контакты и т. Д.) Как ни странно, Документы Google начинаются с &&&START&&& вместо этого, и Google Contacts, кажется, начинается с while(1); &&&START&&&,
Что тут происходит?
10 ответов
Он предотвращает угон JSON, серьезную проблему безопасности JSON, которая официально исправлена во всех основных браузерах с 2011 года с помощью EMCA5.
Придуманный пример: скажем, у 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> тег освобождается от той же политики происхождения.
Это предотвращает его использование в качестве цели простого <script> тег. (Ну, это не мешает этому, но делает его неприятным.) Таким образом, плохие парни не могут просто разместить этот тег сценария на своем собственном сайте и полагаться на активный сеанс, чтобы сделать возможным получение вашего контента.
изменить - отметить комментарий (и другие ответы). Проблема связана с разрушенными встроенными средствами, в частности Object а также Array Конструкторы. Они могут быть изменены таким образом, чтобы в противном случае безобидный JSON при анализе мог вызвать код злоумышленника.
Так как <script> тег освобождается от той же политики происхождения, которая является необходимостью безопасности в веб-мире, while(1) при добавлении в ответ JSON предотвращает его неправильное использование в <script> тег.
Поскольку это сообщение с высоким трафиком, я надеюсь дать здесь немного более неопределенный ответ на исходный вопрос и, таким образом, предоставить дополнительную информацию об атаке JSON Hijacking и ее последствиях.
JSON Hijacking, как следует из названия, представляет собой атаку, похожую на подделку межсайтовых запросов, при которой злоумышленник может получить доступ к конфиденциальным данным JSON из приложений, которые возвращают конфиденциальные данные в виде литералов массива для запросов GET. Пример вызова JSON, возвращающего литерал массива, показан ниже:
[{"id":"1001","ccnum":"4111111111111111","balance":"2345.15"},
{"id":"1002","ccnum":"5555555555554444","balance":"10345.00"},
{"id":"1003","ccnum":"5105105105105100","balance":"6250.50"}]
Эта атака может быть достигнута за 3 основных шага:
Шаг 1. Заставьте аутентифицированного пользователя посетить вредоносную страницу. Шаг 2. Вредоносная страница будет пытаться получить доступ к конфиденциальным данным из приложения, в которое вошел пользователь. Это можно сделать путем встраивания тега сценария в страницу HTML, поскольку политика одного и того же происхождения не применяется к тегам сценария.
<script src="http://<jsonsite>/json_server.php"></script>
Браузер отправит запрос GET на
json_server.phpи любые файлы cookie аутентификации пользователя будут отправлены вместе с запросом. Шаг 3. На этом этапе, пока вредоносный сайт выполнил сценарий, у него нет доступа к каким-либо конфиденциальным данным. Доступ к данным можно получить с помощью установщика прототипа объекта. В приведенном ниже коде свойство прототипов объекта привязывается к определенной функции, когда делается попытка установить "
ccnum" имущество.
Object.prototype.__defineSetter__('ccnum',function(obj){
secrets =secrets.concat(" ", obj);
});
На данный момент вредоносный сайт успешно захватил конфиденциальные финансовые данные.
(ccnum) вернулся
byjson_server.php JSON
Следует отметить, что не все браузеры поддерживают этот метод; Доказательство концепции было выполнено в Firefox 3.x. Этот метод устарел и заменен на
useObject.defineProperty Существует также вариант этой атаки, который должен работать во всех браузерах, в которых используется полностью именованный JavaScript (например,
pi=3.14159) возвращается вместо массива JSON.
Есть несколько способов предотвратить захват JSON:
Поскольку теги SCRIPT могут генерировать только запросы HTTP GET, они возвращают только объекты JSON в запросы POST.
Запретить веб-браузеру интерпретировать объект JSON как допустимый код JavaScript.
Реализуйте защиту от подделки межсайтовых запросов, требуя, чтобы для всех запросов JSON требовалось предварительно определенное случайное значение.
так как вы можете видеть
While(1)подпадает под последний вариант. Проще говоря, это бесконечный цикл, который будет выполняться до тех пор, пока явно не будет выдан оператор break. И, таким образом, то, что можно было бы описать как блокировку для применяемого ключа (инструкция google break). Поэтому угон JSON, при котором у хакера нет ключа, будет последовательно отклоняться. Увы, если вы читаете блок JSON с помощью парсера, цикл while (1) игнорируется.
Итак, в заключение
while(1)Цикл проще представить как простой шифр оператора прерывания, который Google может использовать для управления потоком данных.
Однако ключевое слово в этом утверждении - слово « простой ». Использование аутентифицированных бесконечных циклов, к счастью, было исключено из основной практики с 2010 года из-за абсолютного уменьшения использования ЦП при изоляции (и того факта, что Интернет отошел от принуждения к грубым «быстрым исправлениям»). Сегодня вместо этого в кодовую базу встроены превентивные меры, и система больше не имеет решающего значения и не эффективна. (частично это переход от JSON Hijacking к более продуктивным методам сбора данных, которые я сейчас не буду вдаваться в подробности)
После аутентификации защита от перехвата JSON может принимать различные формы. Google добавляет while(1) в свои данные JSON, так что, если какой-либо вредоносный сценарий оценивает его, вредоносный сценарий входит в бесконечный цикл.
Ссылка: Поваренная книга по тестированию веб-безопасности: систематические методы быстрого поиска проблем
Дополнительная информация о взломе JSON:
In mordern browsers loading content-type "application/json" or "plain/text" etc. isn\'t possible with <script> tag. You will get MIME error in console.
Это исправление старой атаки. 95,2% интернет-пользователей теперь исправлены
while(1), for(;;) Все инъекции были предназначены для предотвращения атак JSON Hijack, где переопределение внутренних компонентов Javascript позволило бы злоумышленнику запрашивать данные, например, google.com, загружая ответ JSON как Javascript. С этими исправлениями бесконечный цикл приведет к тому, что JSON никогда не выполнится и не повесит браузер.
Важно отметить, что это было исправлено начиная с ECMA5 (2009), в котором указывалось, что при синтаксическом анализе массивов и объектов будет использоваться только встроенный конструктор, предотвращающий эту атаку. Facebook, Google и другие крупные игроки иногда по-прежнему имеют их по многим причинам, в том числе из-за устаревших API, из-за того, что у них есть зрелые библиотеки, которые обрабатывают этот унаследованный аспект анализа JSON, и что в некоторых случаях они поддерживают очень нишевые, устаревшие браузеры.
Последним основным браузером, который внедрил ECMA5, был IE 9 в 2011 году [см. Compat. таблица ], и теперь он поддерживается 95,57% всего интернет-трафика (95,52% на настольных компьютерах, 100% на мобильных устройствах).
Если вы сейчас создаете API, вам не о чем беспокоиться. В 2018 году его гораздо эффективнее использовать Access-Control-Allow-Origin: * (что довольно чертовски безопасно по умолчанию) и ожидать Authorization основанная на заголовке аутентификация (обычно Authorization: oauth [token]), что в большинстве приложений предотвращает такого рода кражу из разных источников и CSRF (поскольку злоумышленник может повлиять только на учетную запись, на которую он авторизован).
Это НЕ, так как некоторые опубликовали исправление CSRF. Запрос по-прежнему разрешен куки-файлами жертвы, даже если они не видят ответ.