Perché l'attacco JSON Hijacking non funziona nei browser moderni? Come è stato risolto?

9

Capisco che le vulnerabilità di JSON Hijacking siano state corrette in tutti i browser moderni, ma in che modo esattamente?

Ci sono molti articoli che parlano di tecniche per prevenire attacchi di JSON Hijacking (cioè prepending while(1); come fa Google), ma nessuno ha spiegato se devono ancora essere implementati in un'applicazione web al giorno d'oggi (ovviamente supponendo che gli utenti abbiano vinto " t utilizzare l'app con browser molto vecchi).

Nel caso in cui restituire dati JSON come valori letterali di array è considerato un rischio per la sicurezza al giorno d'oggi?

    
posta fbid 02.04.2017 - 18:23
fonte

1 risposta

2

Il problema JSON che ha indotto google a anteporre while era una suddivisione della stessa origine nelle prime versioni di firefox (in particolare 1.5 e 2b) in cui il file JSON poteva essere caricato come un normale tag di script da fuori sito e avere i suoi dati sono raggiungibili.

Normalmente i file JSON non "dicono" al motore JS di fare nulla se caricati come uno script, quindi non hanno / non lasciano riferimenti alle loro strutture di dati. La sicurezza di JS è basata sul riferimento, quindi l'assunzione è soddisfacente. I valori letterali dell'oggetto JSON ( {} ) sono in realtà un'ambiguità rispetto al motore di JS poiché assomigliano a parentesi di codice, causando errori di sintassi. Il problema con il vecchio FF era che si potevano usare oscure modifiche al runtime che facevano sì che i letterali di Array eseguissero qualche altro codice quando analizzati / creati. Questo altro codice potrebbe raggiungere in modo introspettivo il contenuto dell'array, che era un bug.

Ci sono stati problemi correlati con XML, dato che Firefox considerava alcune forme XML come JavaScript (tm) valido usando l'estensione E4X di FF (Ecmascript4XML). IE ha riscontrato alcuni problemi con il caricamento di contenuti non js come script, l'errore, ma la rivelazione del contenuto a un gestore di errori globale pre-applicato, che riportava l'origine del "codice" che causava il problema.

Dal momento che ora sono disponibili metodi sicuri per l'acquisizione di contenuti JSON remoti, le vulnerabilità dei browser obsoleti e gli exploit JSONp / eval() non si applicano più al caricamento del contenuto. Se provi a caricare una risorsa JSON valida come script, non puoi raggiungere il contenuto da altri JS.

Infine, non penso che questo abbia davvero molto a che fare con la sicurezza; php, curl, python, ecc. non danno un grido sulle regole del browser; se i dati sono là fuori è là fuori. L'unica cosa che la politica di origine identica fa in questo senso è impedire l'esecuzione del "deep-linking" delle risorse per il furto di dati non segreti.

    
risposta data 02.04.2017 - 20:45
fonte

Leggi altre domande sui tag