Domanda Perché Google si antepone mentre (1); alle loro risposte JSON?


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

Ad esempio, ecco una risposta mentre si attiva e disattiva un calendario 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 ciò impedisca alle persone di fare un eval() su di esso, ma tutto quello che dovresti fare è sostituire il while e poi saresti impostato. Assumerei che la prevenzione della valutazione evitasse che le persone scrivessero un codice di analisi JSON sicuro.

Ho visto questo anche in un paio di altri posti, ma molto di più con Google (Mail, Calendar, Contatti, ecc.). Stranamente, documenti Google inizia con &&&START&&& invece, e i contatti Google sembra iniziare while(1); &&&START&&&.

Cosa sta succedendo qui?


3481
2018-04-19 18:00


origine


risposte:


Previene Dirottamento JSON.

Esempio forzato: per esempio, Google ha un URL simile mail.google.com/json?action=inbox che restituisce i primi 50 messaggi della tua casella di posta in formato JSON. I siti Web malvagi su altri domini non possono effettuare richieste AJAX per ottenere questi dati a causa della politica dell'origine stessa, ma possono includere l'URL tramite un <script> etichetta. L'URL è visitato con il tuo biscotti e da sovrascrittura dei metodi globali di costruzione o accesso dell'array possono avere un metodo chiamato ogni volta che viene impostato un attributo object (array o hash), che consente loro di leggere il contenuto JSON.

Il while(1); o &&&BLAH&&& impedisce questo: una richiesta AJAX a mail.google.com avrà pieno accesso al contenuto del testo e potrà eliminarlo. Ma a <script> l'inserimento del tag esegue ciecamente il codice JavaScript senza alcuna elaborazione, risultando in un loop infinito o un errore di sintassi.

Questo non affronta il problema di falsificazione di richieste cross-site.


3760
2018-04-19 18:11



Previene 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 informazioni da pagine su un altro dominio (se non esplicitamente consentito).

Un utente malintenzionato può richiedere pagine su altri domini per suo conto, ad es. usando a <script src=...> o <img>tag, ma non può ottenere alcuna informazione sul risultato (intestazioni, contenuti).

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

Tranne che quando si utilizza un tag script per richiedere il contenuto JSON, il JSON viene eseguito come Javascript nell'ambiente controllato di un utente malintenzionato. Se l'utente malintenzionato può sostituire il costruttore Array o Object o qualche altro metodo utilizzato durante la costruzione di un oggetto, qualsiasi cosa nel JSON dovrebbe passare attraverso il codice dell'aggressore e essere divulgata.

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

Ci sono più contromisure:

Assicurarsi che il JSON non venga mai eseguito

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

Solo una pagina legittima potrebbe effettivamente ottenere l'intero contenuto, rimuovere il while(1);e analizza il resto come JSON.

Cose come for(;;); sono stati visti su Facebook, ad esempio, con gli stessi risultati.

Assicurarsi che il JSON non sia Javascript valido

Allo stesso modo, aggiungere token non validi prima del JSON, come &&&START&&&, si assicura che non venga mai eseguito.

Restituisci sempre JSON con un oggetto all'esterno

Questo è OWASP modo consigliato per proteggersi dal dirottamento JSON, ed è quello meno intrusivo.

Analogamente alle precedenti contromisure, assicura che il JSON non venga mai eseguito come Javascript.

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

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

Questo è comunque valido JSON:

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

Quindi, assicurandoti di restituire sempre un oggetto al livello più alto della risposta, assicurati che JSON non sia Javascript valido, mentre è ancora valido JSON.

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

Confronto dei metodi di cui sopra

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

Il modo in cui Google richiede la libreria client per supportare la de-serializzazione automatica e può essere considerato più sicuro per quanto riguarda i bug del browser.

Entrambi i metodi richiedono modifiche laterali del server per evitare che gli sviluppatori inviino involontariamente JSON vulnerabili.


441
2018-02-02 12:09



Questo per garantire che un altro sito non possa fare brutti scherzi per cercare di rubare i tuoi dati. Ad esempio, da sostituzione del costruttore di array, quindi includendo questo URL JSON tramite a <script> tag, un sito di terze parti malintenzionato potrebbe rubare i dati dalla risposta JSON. Mettendo a while(1); all'inizio, lo script si bloccherà invece.

D'altra parte, una richiesta con lo stesso sito che utilizza XHR e un parser JSON separato, può facilmente ignorare il while(1); prefisso.


343
2018-05-16 02:08



Ciò renderebbe difficile a una terza parte inserire la risposta JSON in un documento HTML con <script> etichetta. Ricorda che il <script> il tag è esente dal La stessa politica di origine.


97
2018-04-19 18:04



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

modificare - annotare il commento (e altre risposte). Il problema ha a che fare con servizi integrati sovvertiti, in particolare con il Object e Array costruttori. Questi possono essere modificati in modo che JSON altrimenti innocuo, se analizzato, possa attivare il codice dell'attaccante.


65
2018-04-19 18:02



Dal momento che il <script> tag è esentato dalla stessa politica di origine che è una necessità di sicurezza nel mondo web, mentre (1) quando aggiunto alla risposta JSON impedisce l'uso improprio di esso nel <script>etichetta.


3
2017-08-18 04:14