Ho posto una domanda riguardante un'implementazione WebAPI di ASP.NET della protezione CSRF:
Anche se c'è una risposta che dice che, con le politiche CORS predefinite, quel tipo di convalida del token XSRF con le chiamate AJAX è inutile. È vero, e se è così, perché?
Sì, molto probabilmente è necessario eseguire alcuni controlli per garantire l'autenticità della richiesta.
In sostanza, che cosa è possibile da un sito Web di terzi?
GET o POST . Non è possibile impostare intestazioni personalizzate tramite moduli html. Non è possibile utilizzare altri metodi come PUT o DELETE . Vedi questa domanda o RFC . Access-Control-Allow-Origin e Access-Control-Allow-Methods di intestazioni inviate dal tuo server) e imposta intestazioni personalizzate. Tieni presente che GET e POST richiesta non sono possibili con ajax senza quelle intestazioni mentre sono in formato html! I diversi scenari sono i seguenti:
Si utilizza l'oggetto base javascript XMLHttpRequest per fare GET o POST richiesta. Sei vulnerabile poiché è possibile fare la richiesta equivalente da un sito trasversale usando il modulo html! Puoi proteggere il tuo sito da csrf aggiungendo un'intestazione extra come X-CSRF-HEADER e controllandone il lato server.
Utilizzi $.ajax dalla libreria jQuery per una richiesta GET o POST . Sei vulnerabile se non esegui alcun controllo sul lato server! jQuery aggiunge automaticamente un'intestazione, X-REQUESTED-WITH , mentre esegue la richiesta di $.ajax , che puoi controllare lato server.
Usi un metodo diverso da GET o POST , non sei vulnerabile dato che non puoi inviare una richiesta cross-site con un altro metodo senza ulteriore autorizzazione dal tuo sito web. Tuttavia, questo è davvero il tuo ghiaccio (un bug nel browser o HTTP sepcs potrebbe cambiare) quindi dovresti proteggerlo anche da csrf.
Il valore dell'intestazione X-XSRF-TOKEN nel tuo esempio è nel momento in cui scrivo inutile. La cosa più importante è la presenza dell'intestazione stessa perché è possibile aggiungere solo un'intestazione cutstom con ajax che a sua volta non è il cross-site nativamente possibile. In ogni caso, si noti che questo potrebbe cambiare in futuro a seconda di come si evolvono le specifiche di HTTP in modo che consiglierei di verificare il valore del token.
Questa risposta non è del tutto corretta. CORS non si applica se l'attaccante non sta usando Ajax. Ad esempio, se il tuo sito web non blocca l'utilizzo di IFrame con l'intestazione X-FRAME-OPTIONS, un utente malintenzionato potrebbe semplicemente nascondere un iframe nella sua pagina dannosa e utilizzare javascript per form.submit ().
Come CodesInChaos ha menzionato nel suo commento, lo scenario che ho appena menzionato funzionerà solo se la richiesta non ha alcuna autorizzazione (l'azione del controller ha un attributo [AllowAnonymous], nel caso di ASP.net), o il token di autenticazione viene passato automaticamente dal browser (come avviene con i cookie).
Si noti che se si memorizza il token di sessione in javascript, cosa che si deve fare se si utilizza un'intestazione di richiesta, gli attacchi XSS possono diventare molto più devastanti, poiché un utente malintenzionato sarà quindi in grado di accedere al token di sessione e impersonare il sessione delle vittime. È possibile prendere in considerazione l'utilizzo di cookie tradizionali con il flag HTTPOnly impostato per la memorizzazione del token di autorizzazione e l'aggiunta di un token anti-CSRF tramite javascript.