javascript - php protect ajax calls




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

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

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

Ad esempio, ecco una risposta mentre attivi e disattivi 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 di fare eval() su di esso, ma tutto quello che dovresti fare è sostituire il while e poi verrai 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, Google Docs inizia con &&&START&&& , e Google Contacts sembra iniziare con while(1); &&&START&&& while(1); &&&START&&& .

Cosa sta succedendo qui?


Impedisce che venga utilizzato come destinazione di un semplice tag <script> . (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.

modifica - annota il commento (e altre risposte). Il problema ha a che fare con strutture built-in sovvertite, in particolare con i costruttori Object e Array . Questi possono essere modificati in modo che JSON altrimenti innocuo, se analizzato, possa attivare il codice dell'attaccante.


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


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 parti di informazioni dalle pagine dell'altro dominio (se non esplicitamente consentito).

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

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

Posizionando 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 può effettivamente ottenere l'intero contenuto, spogliatosi 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&&& , fa in modo che non venga mai eseguito.

Restituisci sempre JSON con un oggetto all'esterno

Questo è il modo consigliato da OWASP per proteggere dal dirottamento JSON ed è quello meno intrusivo.

Analogamente alle contromisure precedenti, si 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 {} è Javascript valido e sapere che l'oggetto è vuoto può essere di per sé informazioni preziose.

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 potrebbero 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 in relazione ai bug del browser.

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





security