Devo usare AntiForgeryToken in tutti i moduli, anche login e registrazione?

78

Gestisco un sito piuttosto grande con migliaia di visite al giorno e una base utenti piuttosto ampia. Da quando ho iniziato la migrazione a MVC 3, ho inserito AntiForgeryToken in un certo numero di moduli, che modificano i dati protetti ecc.

Alcune altre forme, come il login e la registrazione, usano anche AntiForgeryToken ora, ma mi sto chiedendo in quali condizioni non ci sia bisogno, in primo luogo, per un paio di motivi ...

Il modulo di accesso richiede che il poster conosca le credenziali corrette. Non riesco davvero a pensare a nessun attacco CSRF, specialmente se controllo che la richiesta provenga dallo stesso host (controllando l'intestazione Referer).

Il token AntiForgeryToken genera valori diversi ogni volta che viene caricata la pagina. Se sono aperte due schede con la pagina di accesso, quindi proviamo a pubblicarle, la prima verrà caricata correttamente. Il secondo fallirà con una AntiForgeryTokenException (prima carica entrambe le pagine, poi prova a postarle). Con pagine più sicure - questo è ovviamente un male necessario, con le pagine di accesso - sembra eccessivo, e solo per chiedere guai.

Ci sono probabilmente altre ragioni per cui si dovrebbe usare o non usare il token in quelle forme. Ho ragione nel ritenere che l'uso del token in ogni forma di post sia eccessivo e, in tal caso, che tipo di forme ne trarrebbero beneficio, e quali sarebbero sicuramente non benefici?

P.S. Questa domanda viene anche richiesta su StackOverflow, ma non sono del tutto convinto. Ho pensato di chiederlo qui, per più copertura sicurezza

    
posta Artiom Chilaru 11.02.2011 - 22:08
fonte

2 risposte

68

Sì, è importante includere i token anti-contraffazione per le pagine di accesso.

Perché? A causa del potenziale per attacchi "login CSRF". In un attacco CSRF di accesso, l'utente malintenzionato registra la vittima nel sito di destinazione con l'account dell'aggressore. Prendi in considerazione, ad esempio, un attacco a Alice, che è un utente di Paypal, da un malvagio attaccante Evelyn. Se Paypal non ha protetto le sue pagine di accesso dagli attacchi CSRF (ad es. Con un token anti-contraffazione), l'utente malintenzionato può registrare silenziosamente il browser di Alice nell'account di Evelyn su Paypal. Alice viene portata sul sito web di Paypal e Alice ha effettuato l'accesso, ma ha effettuato l'accesso come Evelyn. Supponiamo che Alice faccia clic sulla pagina per collegare la sua carta di credito al suo account Paypal e inserisca il suo numero di carta di credito. Alice pensa che stia collegando la sua carta di credito al suo account Paypal, ma in realtà l'ha collegata all'account di Evelyn. Adesso Evelyn può acquistare materiale e farlo addebitare sulla carta di credito di Alice. Ops. Questo è sottile e un po 'oscuro, ma abbastanza serio da includere i token anti-contraffazione per il target di azione del modulo utilizzato per accedere. Vedere questo documento per ulteriori dettagli e alcuni esempi reali di tali vulnerabilità.

Quando è OK lasciare il gettone anti-contraffazione? In generale, se il target è un URL e l'accesso a quell'URL non ha effetti collaterali, non è necessario includere token anti-contraffazione in quell'URL.

La regola approssimativa è: includere un token anti-contraffazione in tutte le richieste POST, ma non è necessario per le richieste GET. Tuttavia, questa approssimativa regola empirica è un'approssimazione molto approssimativa. Presuppone che le richieste GET saranno tutte prive di effetti collaterali. In un'applicazione Web ben progettata, dovrebbe essere auspicabile, ma in pratica a volte i progettisti di applicazioni Web non seguono questa linea guida e implementano gestori GET che hanno un effetto collaterale (questa è una cattiva idea, ma non è raro) . Ecco perché suggerisco una linea guida basata sul fatto che la richiesta abbia o meno un effetto collaterale sullo stato dell'applicazione web, invece che basata su GET vs POST.

    
risposta data 12.02.2011 - 03:32
fonte
2

Dove potrebbe essere necessario avere il token su una pagina di accesso è quando è necessario impedire a qualcuno di accedere in modo malevolo al sito con credenziali particolari. Posso vedere questo nel caso in cui qualcuno viene incorniciato per qualcosa che richiede l'accesso con un utente di particelle. Detto questo, è un esempio un po 'forzato.

    
risposta data 12.02.2011 - 02:59
fonte

Leggi altre domande sui tag