Чому 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 Контакти, здається, починаються з while(1); &&&START&&&.

Що тут відбувається?

Це запобігає викрадженню JSON - головного питання безпеки JSON, який офіційно фіксується у всіх основних браузерах з 2011 року за допомогою ECMAScript 5.

Надуманий приклад: скажімо, у Google є така URL-адреса, mail.google.com/json?action=inboxяка повертає перші 50 повідомлень вашої вхідної пошти у форматі JSON. Веб-сайти в інших доменах не можуть надсилати запити AJAX отримати ці дані через політику того самого джерела, але вони можуть включати URL-адресу через <script>тег. URL-адресу відвідують ваші файли cookie, і, заміняючи глобальний конструктор масиву або методи аксесуара, вони можуть мати метод, який називається, коли встановлюється атрибут об'єкта (масиву чи хеша), що дозволяє їм читати вміст JSON.

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

Це не стосується питання підробки міжміських запитів .

Це запобігає розкриттю реакції через викрадення 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.

Це потрібно для того, щоб якийсь інший сайт не міг робити неприємні хитрощі, щоб спробувати вкрасти ваші дані. Наприклад, замінивши конструктор масиву , а потім включивши цю 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 додає (1) до своїх даних JSON, так що якщо якийсь шкідливий скрипт оцінює його, шкідливий сценарій потрапляє у нескінченний цикл.

Довідка: Посібник з тестування веб-безпеки: Систематичні методи швидкого пошуку проблем