Come dovrebbero difendersi gli sviluppatori di app Web contro il dirottamento JSON?

La prima difesa è attenersi alle specifiche utilizzando JSON valido che richiede un oggetto come entità di primo livello . Tutti gli attacchi noti si basano sul fatto che se l'oggetto di livello superiore è un array, la risposta è un codice Java Script valido che può essere analizzato utilizzando uno script < script > tag.

If the JSON response contains any confidential/non-public data, only serve the response if the request is authenticated (e.g., comes with cookies that indicate an authenticated session).

Questo è il pre requisito per l'attacco , non una mitigazione. Se il browser ha un cookie per il sito A, lo includerà in tutte le richieste al sito A. Ciò è vero anche se la richiesta è stata attivata da uno script < > tag sul sito B.

If the JSON data contains anything confidential or non-public, host it at a secret unguessable URL (e.g., a URL containing a 128-bit crypto-quality random number), and only share this secret URL with users/clients authorized to see the data.

Gli URL non sono considerati una funzione di sicurezza . Tutti i motori di ricerca comuni hanno addons / barre degli strumenti del browser che riportano qualsiasi URL visitato al fornitore del motore di ricerca. Anche se potrebbero segnalare solo URL visitati esplicitamente, non rischierei nemmeno questo per gli URL JSON.

Have the client send requests for JSON data as a POST (not a GET), and have the server ignore GET requests for JSON data.

Ciò impedirà lo script < > includere.

Put while(1); at the start of the JSON response, and have the client strip it off before parsing the JSON.

Suggerisco una versione modificata di questo approccio: Aggiungi </* all'inizio . while(1) è problematico per due motivi: in primo luogo è probabile che si inneschi lo scanner maleware (su client, proxy e motori di ricerca). In secondo luogo può essere utilizzato per attacchi DoS contro la CPU di navigatori del web. Questi attacchi hanno ovviamente origine dal tuo server.

Google utilizza " unparseable cruft " per difendersi da questo tipo di attacco. Questa vulnerabilità era risolta in firefox 3 . La vulnerabilità deriva dal modo in cui i browser implementano la specifica JSON.

1) If the JSON response contains any confidential/non-public data, only serve the response if the request is authenticated (e.g., comes with cookies that indicate an authenticated session). 2) If the JSON data contains anything confidential or non-public, host it at a secret unguessable URL (e.g., a URL containing a 128-bit crypto-quality random number), and only share this secret URL with users/clients authorized to see the data.

Non c'è una buona ragione per fare entrambi (1) e (2).

Il primo è ABAC e il secondo è ZBAC. Cercare di ottenere la difesa in profondità utilizzando più schemi di controllo degli accessi è complicare troppo le cose.

3) Put while(1); at the start of the JSON response, and have the client strip it off before parsing the JSON.

4) Have the client send requests for JSON data as a POST (not a GET), and have the server ignore GET requests for JSON data.

Questi sembrano idee eccellenti e aggiungono profondità di difesa poiché aiutano a garantire che le credenziali non possano essere appropriate in modo improprio.

Inoltre,

5) Servono solo JSON con dati sensibili su SSL o altri canali sicuri.

per evitare perdite di dati tramite MITM.