Devo utilizzare la protezione CSRF per le richieste GET?

La protezione CSRF è necessaria solo per le operazioni di cambio di stato a causa della politica della stessa origine . Questa politica afferma che:

a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin.

Quindi l'attacco CSRF non sarà in grado di accedere ai dati richiesti perché è un cross-site (è la richiesta CS in CSRF ) e proibito dal politica della stessa origine. Quindi l'accesso illecito ai dati non è un problema con CSRF.

Poiché un attacco CSRF può eseguire comandi ma non può vedere i loro risultati, è costretto ad agire ciecamente. Ad esempio, un attacco CSRF può dire al tuo browser di richiedere il saldo del tuo conto bancario, ma non può vedere quel saldo. Questo è ovviamente un attacco inutile (a meno che tu non stia provando a DDoS il server della banca o qualcosa del genere). Ma non è inutile se, ad esempio, l'attacco CSRF dice al tuo browser di chiedere alla tua banca di trasferire denaro dal tuo account al conto dell'attaccante. La pagina di successo o di fallimento per il trasferimento è inaccessibile allo script di attacco. Fortunatamente per l'aggressore, non hanno bisogno di vedere la risposta della banca, vogliono solo i soldi nel loro account.

Poiché solo le operazioni che cambiano lo stato possono essere bersaglio di attacchi CSRF, solo loro hanno bisogno di difese CSRF.

Normalmente metodi sicuri non devono essere protetti contro CSRF perché non apportano modifiche al applicazione, e anche se restituiscono informazioni sensibili questo sarà protetto dalla Stessa politica di origine nel browser.

Se il tuo sito è implementato secondo gli standard, le tue richieste GET dovrebbero essere sicure e quindi non necessitano di protezione.

Tuttavia, esiste un caso specifico in cui è possibile eseguire un attacco "Cross-Site DoS" ^* . Supponiamo che la tua pagina di report impieghi 10 secondi, con il 100% di utilizzo della CPU sul server di database e l'80% di utilizzo della CPU sul tuo server web.

Gli utenti del tuo sito web sanno di non andare mai a https://yoursite.example.org/Analysis/GetReport durante l'orario di ufficio perché uccide il server e dà ad altri usi un'esperienza utente negativa.

Tuttavia, Chuck vuole bussare alla tua yoursite.example.org sito web offline perché non gli piacciono te o la tua azienda.

Nel forum occupato che pubblica spesso, http://forum.walkertexasranger.example.com , imposta la sua firma su quanto segue:

<img src="https://yoursite.example.org/Analysis/GetReport"width=0height=0/>

Inoltre,sacheidipendentidellatuaaziendafrequentanoilforum,spessoanchequandosonoregistratiinyoursite.example.org.

OgnivoltacheunodeipostdiChuckvienelettodaidipendenti,icookiediautenticazionevengonoinviatiahttps://yoursite.example.org/Analysis/GetReport,quindiiltuositoelaboralarichiestaegenerailreporteiltuosistemavaofflineperchélaCPUvienemangiatadaquesterichiestecostanti.

Quindi,ancheselarichiestaèunarichiestaGETenonapportamodifichepermanentialsistema(ovvero"sicure"), è infatti che abbatte il sistema ogni volta che viene eseguito. Pertanto, sarebbe meglio proteggerlo con un metodo di prevenzione CSRF.

^{* XSDoS, o Diniego tra siti se Servizio, è una frase coniata da me, quindi non usare Google su Google.}

La protezione CSRF non viene utilizzata per proteggere i dati. Viene utilizzato per proteggere un utente dallo stato di modifica inconsapevole, come il trasferimento di denaro o la disconnessione da un account.

Quindi, se la tua richiesta GET sta cambiando uno stato (che non dovrebbe essere), allora dovresti avere una protezione CSRF. Ma se restituisce solo i dati, non ha bisogno della protezione CSRF, perché la protezione CSRF non proteggerebbe nulla in questo caso.

Potrebbe essere utile tornare su questa pagina: link

CSRF, o contraffazione di richieste tra siti, non riguarda la protezione dei dati da recuperare, ma la protezione dei dati da modificare. Si parla anche di cambiamenti di stato. In un'applicazione, le modifiche dello stato possono includere i dati del profilo, come l'indirizzo e-mail, la password utente, la biografia o il trasferimento di fondi.

Le richieste GET devono essere utilizzate per richieste identienti o richieste che non cambiano stato. Queste richieste non necessitano di token anti-CSRF.

Le richieste POST devono essere utilizzate per richieste non identi che, o richieste che cambiano stato.

In generale, le richieste POST dovrebbero essere utilizzate per modificare lo stato di qualcosa. Se hai impostato le richieste GET in modo che possano cambiare lo stato (ad esempio www.example.com/settings?delete_account=True), devi utilizzare la protezione CSRF come correzione di Band-Aid.

Prova a usare i POST per cambiare lo stato, non i GET.