Perché Google antepone while(1);alle loro risposte (private) JSON?

Ad esempio, ecco una risposta durante l'attivazione e la disattivazione di un calendario in Google Calendar :

while (1);
[
  ['u', [
    ['smsSentFlag', 'false'],
    ['hideInvitations', 'false'],
    ['remindOnRespondedEventsOnly', 'true'],
    ['hideInvitations_remindOnRespondedEventsOnly', 'false_true'],
    ['Calendar ID stripped for privacy', 'false'],
    ['smsVerifiedFlag', 'true']
  ]]
]

Suppongo che questo sia per impedire alle persone eval()di farne uno , ma tutto ciò che dovresti fare è sostituire il whilee poi verrai impostato. Suppongo che la prevenzione eval sia quella di assicurarsi che le persone scrivano un codice di analisi JSON sicuro.

L'ho visto usato anche in un paio di altri posti, ma molto di più con Google (Mail, Calendar, Contacts, ecc.) Stranamente, Google Docs inizia &&&START&&&invece e Google Contacts sembra iniziare while(1); &&&START&&&.

Cosa sta succedendo qui?

Previene il dirottamento JSON , un grave problema di sicurezza JSON che è stato risolto formalmente in tutti i principali browser dal 2011 con ECMAScript 5.

Esempio contrastato: supponiamo che Google abbia un URL simile a quello mail.google.com/json?action=inboxche restituisce i primi 50 messaggi della posta in arrivo in formato JSON. I siti Web malvagi su altri domini non possono effettuare richieste AJAX per ottenere questi dati a causa della stessa politica di origine, ma possono includere l'URL tramite un <script>tag. L'URL viene visitato con i tuoi cookie e sovrascrivendo il costruttore globale dell'array o i metodi di accesso possono avere un metodo chiamato ogni volta che viene impostato un attributo oggetto (array o hash), che consente loro di leggere il contenuto JSON.

Il while(1);o &&&BLAH&&&impedisce questo: una richiesta AJAX a mail.google.comavrà pieno accesso al contenuto del testo e può eliminarlo. Ma un <script>inserimento di tag esegue ciecamente JavaScript senza alcuna elaborazione, causando un ciclo infinito o un errore di sintassi.

Ciò non risolve il problema della falsificazione delle richieste tra siti .

Impedisce la divulgazione della risposta tramite il dirottamento JSON.

In teoria, il contenuto delle risposte HTTP è protetto dalla stessa politica di origine: le pagine di un dominio non possono ottenere alcuna informazione dalle pagine dell'altro dominio (se non esplicitamente consentito).

Un utente malintenzionato può richiedere pagine su altri domini per conto dell'utente, ad esempio utilizzando un tag <script src=...>o <img>, ma non può ottenere alcuna informazione sul risultato (intestazioni, contenuti).

Pertanto, se visiti la pagina di un utente malintenzionato, non è in grado di leggere la tua email da gmail.com.

Tranne il fatto che quando si utilizza un tag di script per richiedere il contenuto JSON, il JSON viene eseguito come Javascript nell'ambiente controllato di un utente malintenzionato. Se l'attaccante può sostituire il costruttore di array o oggetti o qualche altro metodo utilizzato durante la costruzione di oggetti, qualsiasi cosa nel JSON passerebbe attraverso il codice dell'attaccante e verrebbe divulgata.

Si noti che ciò accade nel momento in cui JSON viene eseguito come Javascript, non nel momento in cui viene analizzato.

Esistono diverse contromisure:

Assicurarsi che JSON non venga mai eseguito

Inserendo una while(1);dichiarazione prima dei dati JSON, Google si assicura che i dati JSON non vengano mai eseguiti come Javascript.

Solo una pagina legittima può ottenere l'intero contenuto, eliminare il file while(1);e analizzare il resto come JSON.

Cose come for(;;);sono state viste su Facebook per esempio, con gli stessi risultati.

Assicurarsi che JSON non sia Javascript valido

Allo stesso modo, l'aggiunta di token non validi prima del JSON, come &&&START&&&, assicura che non venga mai eseguito.

Restituisce sempre JSON con un oggetto all'esterno

Questo è il OWASPmodo consigliato per proteggere dal dirottamento JSON ed è quello meno invadente.

Simile alle precedenti contromisure, si assicura che JSON non venga mai eseguito come Javascript.

Un oggetto JSON valido, quando non è racchiuso tra nulla, non è valido in Javascript:

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

Questo è comunque valido JSON:

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

Quindi, assicurati di restituire sempre un oggetto al livello più alto della risposta assicurandoti che JSON non sia Javascript valido, pur essendo comunque JSON valido.

Come notato da @hvd nei commenti, l'oggetto vuoto {}è Javascript valido e sapere che l'oggetto è vuoto può essere essa stessa un'informazione preziosa.

Confronto dei metodi sopra indicati

Il modo OWASP è meno invadente, in quanto non necessita di modifiche alla libreria client e trasferisce JSON valido. Non è sicuro, tuttavia, se i bug passati o futuri del browser potrebbero sconfiggere questo. Come notato da @oriadam, non è chiaro se i dati potrebbero essere trapelati in un errore di analisi attraverso una gestione degli errori o meno (ad esempio window.onerror).

Per Google è necessario che la libreria client supporti la deserializzazione automatica e può essere considerata più sicura riguardo ai bug del browser.

Entrambi i metodi richiedono modifiche sul lato server per evitare agli sviluppatori di inviare accidentalmente JSON vulnerabile.

Questo per garantire che altri siti non possano fare brutti scherzi per tentare di rubare i tuoi dati. Ad esempio, sostituendo il costruttore di array , quindi includendo questo URL JSON tramite un <script>tag, un sito di terze parti dannoso potrebbe rubare i dati dalla risposta JSON. Mettendo while(1);a all'inizio, lo script si bloccherà invece.

Una richiesta dello stesso sito che utilizza XHR e un parser JSON separato, d'altra parte, può facilmente ignorare il while(1);prefisso.

Ciò significherebbe rendere difficile per una terza parte inserire la risposta JSON in un documento HTML con il <script>tag. Ricorda che il <script>tag è esente dalla stessa politica di origine .

Nota : a partire dal 2019, molte delle vecchie vulnerabilità che portano alle misure preventive discusse in questa domanda non sono più un problema nei browser moderni. Lascerò la risposta di seguito come una curiosità storica, ma in realtà l'intero argomento è cambiato radicalmente dal 2010 (!!) quando è stato chiesto.

Impedisce che venga utilizzato come target di un semplice <script>tag. (Beh, non lo impedisce, ma lo rende spiacevole.) In questo modo i cattivi non possono semplicemente mettere quel tag di script nel proprio sito e fare affidamento su una sessione attiva per consentire di recuperare i tuoi contenuti.

modifica - annota il commento (e altre risposte). Il problema riguarda le strutture integrate sovvertite, in particolare i costruttori Objecte Array. Questi possono essere modificati in modo tale che JSON altrimenti innocuo, una volta analizzato, possa innescare il codice dell'attaccante.

Poiché il <script>tag è esentato dalla stessa politica di origine che è una necessità di sicurezza nel mondo web, while(1)quando aggiunto alla risposta JSON ne impedisce l'uso improprio nel <script>tag.

Una volta effettuata l'autenticazione, la protezione dal dirottamento JSON può assumere varie forme. Google aggiunge mentre (1) ai propri dati JSON, in modo che se uno script dannoso lo valuta, lo script dannoso entra in un ciclo infinito.

Riferimento: ricettario per i test sulla sicurezza Web: tecniche sistematiche per trovare rapidamente i problemi