Ho iniziato di recente a creare applicazioni Web utilizzando .NET MVC e mi sono imbattuto in questo post sul blog di Phil Haack: JSON Hijacking. Per quelli di voi che non sono a conoscenza di questa vulnerabilità quando si usa JSON per trasferire dati sensibili, è davvero una lettura obbligata.Preferisci racchiudere gli array JSON in un altro oggetto JSON o richiedere sempre il POST per impedire JSON Hijacking?
Sembra che ci siano tre modi per gestire questa vulnerabilità.
- Richiedere un POST al posto di GET nel servizio JSON.
- Includi le risposte dell'array JSON in un oggetto JSON.
- Non esporre dati sensibili in ogni servizio che non è protetto da 1 o 2.
La terza alternativa non è realmente un'opzione in quanto limita in realtà l'uso di JSON.
Quindi quale degli altri due preferisci?
L'anteprima di .NET MVC 2 richiede un POST per le risposte JSON per impostazione predefinita, penso che questo sia un ottimo modo per proteggere qualsiasi sviluppatore che non conosce ancora questo problema. Ma a me sembra un po '"hacky" interrompere REST in questo modo. A meno che qualcuno non me ne parli, mi sto impegnando per avvolgere i miei array in un altro oggetto e scartarlo dal lato client.
l'articolo E4X si parla parla di rischi per la sicurezza nella direzione opposta: che i consumatori * * di dati E4X devono stare attenti a eseguirla w/o analisi. Se produci * dati e4x, qual è la preoccupazione? –
La pagina indirizza l'iniezione in entrambe le direzioni. Precedentemente (e ancora in Firefoxen precedente) è possibile modificare il prototipo XML per ottenere l'accesso agli oggetti E4X appena creati per script esterni e sussistono ancora potenziali pericoli per il contenuto JavaScript nidificato in E4X per richiamare i callback degli hacker.Questo vale in particolare per le pagine che includono contenuti forniti dagli utenti malintenzionati, anche se opportunamente sfuggiti. – bobince