Perché Google aggiunge while(1);
alle sue risposte JSON (private)?
Per esempio, ecco una risposta mentre accende e spegne 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']]]]
Presumo che questo sia per impedire alle persone di fare un eval()
su di esso, ma tutto quello che dovreste fare è sostituire il while
e poi sareste a posto. Presumo che la prevenzione dell'eval sia per assicurarsi che le persone scrivano un codice di analisi JSON sicuro.
Ho visto questo usato in un paio di altri posti, anche, ma molto di più con Google (Mail, Calendario, Contatti, ecc.) Stranamente, Google Docs inizia con &&&START&&&
invece, e Google Contatti sembra iniziare con while(1); &&&START&&
.
Cosa sta succedendo qui?
Questo è per assicurarsi che qualche altro sito non possa fare brutti scherzi per cercare di rubare i vostri dati. Per esempio, sostituendo il costruttore dell'array, poi includendo questo URL JSON tramite un tag <script>
, un sito maligno di terze parti potrebbe rubare i dati dalla risposta JSON. Mettendo un while(1);
all'inizio, lo script invece si bloccherà.
Una richiesta dello stesso sito che usa XHR e un parser JSON separato, d'altra parte, può facilmente ignorare il prefisso while(1);
.
Questo sarebbe per rendere difficile ad una terza parte di inserire la risposta JSON in un documento HTML con il tag <script>
. Ricordate che il tag <script>
è esente dalla Same Origin Policy.
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 qui sotto come curiosità storica, ma in realtà l'intero argomento è cambiato radicalmente dal 2010 (!!) quando questo è stato chiesto.
hr>
Impedisce di essere usato come target di un semplice tag <script>
. (Beh, non lo impedisce, ma lo rende sgradevole.) In questo modo i cattivi non possono semplicemente mettere quel tag script nel loro sito e contare su una sessione attiva per rendere possibile il recupero del tuo contenuto.
edit — nota il commento (e altre risposte). Il problema ha a che fare con strutture integrate sovvertite, in particolare i costruttori Object
e Array
. Questi possono essere alterati in modo tale che un JSON altrimenti innocuo, quando analizzato, potrebbe innescare il codice dell'attaccante.