Problemi nell'evitare il dirottamento di JSON con la convalida AntiForgeryToken di MVC3 o con un token simile

Sono titubante nell'implementare le proposte di dirottamento anti-JSON dal momento che

1. Le soluzioni consigliate per mitigare il dirottamento JSON coinvolgono POST JSON non REST completi per ottenere dati

2. La soluzione alternativa (object wrapping) causa problemi con i controlli di terze parti. Non ho accesso al codice sorgente.

3. Non riesco a trovare un'implementazione controllata dalla comunità che implementa la soluzione alternativa (elencata di seguito) su come comporre il token di sicurezza o consegnarlo in modo sicuro all'interno della pagina web. Inoltre non pretendo di essere abbastanza esperto per implementare la mia implementazione.

4. Le intestazioni dei referrer non possono essere considerate

Sfondo

Questo blog descrive un problema CSRF relativo a JSON Hijacking e raccomanda l'uso di JSON POST per Ottieni dati. Poiché l'utilizzo di un POST HTTP per i dati GET non è pieno di REST, cerco una soluzione RESTfull che consenta azioni REST per sessione o per pagina.

Un'altra tecnica di mitigazione consiste nel racchiudere i dati JSON in un oggetto come descritto qui . Temo che questo possa solo ritardare il problema, fino a quando non verrà trovata un'altra tecnica.

Implementazione alternativa

Per me, sembra naturale estendere l'uso AntiForgeryToken di ASP.NET MVC con GET HTTP jQuery per il mio JSON.

Ad esempio, se OTTENGO dei dati sensibili, secondo il link Haacked sopra, il seguente codice è vulnerabile:

$.getJSON('[url]', { [parameters] }, function(json) {
    // callback function code
});

Sono d'accordo che non è RESTfull per ottenere dati utilizzando la soluzione POST consigliata. Il mio pensiero è di inviare un token di convalida nell'URL. In questo modo l'attaccante in stile CSRF non conoscerà l'URL completo. Memorizzati nella cache o non memorizzati nella cache, non saranno in grado di ottenere i dati.

Di seguito sono riportati due esempi di come è possibile eseguire una query JET GET. Non sono sicuro di quale sia l'implementazione più efficace, ma posso immaginare che il primo sia più sicuro da proxy errati che memorizzano nella cache questi dati, rendendolo quindi vulnerabile a un utente malintenzionato.

link

o

link

... che potrebbe anche essere l'AntiForgeryToken di MVC3, o una variante ( see swt ) di ciò. Questo token verrebbe impostato come valore in linea su qualsiasi formato di URL selezionato sopra.

Domande di esempio che mi impediscono di aprire la mia soluzione

1. Quale formato URL (sopra) vuoi utilizzare per convalidare il JSON GET (barra, punto interrogativo, ecc.) Un proxy risponderà a link con link dati?

2. Come faresti a consegnare quel token codificato alla pagina web? In linea o come variabile di pagina?

3. Come si comporterà il token? Costruito in AntiforgeryToken, o con altri mezzi?

4. AntiForgeryToken utilizza un cookie. In questo caso, un cookie di supporto potrebbe essere utilizzato / necessario? Solo HTTP? Che dire di SSL in combinazione con solo HTTP?

5. Come impostare le intestazioni della cache? Qualcosa di speciale per Google Web Accelerator (ad esempio)

6. Quali sono le implicazioni della semplice richiesta SSL di JSON?

7. L'array JSON restituito dovrebbe ancora essere avvolto in un oggetto solo per motivi di sicurezza?

8. In che modo questa soluzione si sovrapporrà a quanto proposto da Microsoft templating e databinding caratteristiche

Le domande di cui sopra sono le ragioni per cui non sto andando avanti e sto facendo questo da solo. Per non parlare di probabilmente altre domande a cui non ho pensato, eppure rappresentano un rischio.