it-swarm.it

Dovrei usare AntiForgeryToken in tutti i moduli, anche il login e la registrazione?

Sto gestendo un sito piuttosto grande con migliaia di visite ogni giorno e una base utenti piuttosto grande. Da quando ho iniziato la migrazione a MVC 3, ho messo AntiForgeryToken in una serie di moduli, che modificano i dati protetti ecc.

Alcuni altri moduli, come il login e la registrazione, usano anche AntiForgeryToken ora, ma sto diventando dubbioso sulla loro necessità lì in primo luogo, per un paio di motivi ...

Il modulo di accesso richiede al poster di conoscere le credenziali corrette. Non riesco davvero a pensare a un vantaggio che un attacco CSRF trarrebbe beneficio qui, soprattutto se controllo che la richiesta provenga dallo stesso Host (controllando l'intestazione del Referer).

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

Probabilmente ci sono altri motivi per cui si dovrebbe usare o meno il token in quei moduli. Sono corretto nel dare per scontato che l'utilizzo del token in ogni forma di post sia eccessivo e, in caso affermativo, che tipo di moduli ne trarrebbe beneficio e quali sicuramente ne trarrebbero vantaggio no?

Post scriptum Questa domanda viene anche posta su StackOverflow, ma non sono del tutto convinto. Ho pensato di chiedere qui, per più sicurezza copertura

82
Artiom Chilaru

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

Perché? A causa del potenziale attacco "login CSRF". In un attacco CSRF di accesso, l'attaccante accede la vittima nel sito di destinazione con l'account dell'attaccante. Considera, ad esempio, un attacco ad Alice, che è un utente di Paypal, da parte di 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ò accedere silenziosamente al browser di Alice nell'account Evelyn su Paypal. Alice viene indirizzata al sito Web Paypal e Alice è loggata, ma ha effettuato il login 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. Ora Evelyn può acquistare roba e caricarla sulla carta di credito di Alice. Ops. Questo è sottile e un po 'oscuro, ma abbastanza serio da includere token anti-contraffazione per l'obiettivo di azione del modulo utilizzato per accedere. Vedi questo documento per maggiori dettagli e alcuni esempi reali di tali vulnerabilità.

Quando è corretto interrompere il token anti-contraffazione? In generale, se la destinazione è un URL e l'accesso a tale URL non ha effetti collaterali, non è necessario includere il token anti-contraffazione in tale URL.

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

72
D.W.

Dove potrebbe essere necessario avere il token in una pagina di accesso è quando è necessario impedire a qualcuno di accedere in modo dannoso al sito con credenziali particolari. Vedo che questo è il caso se qualcuno viene incastrato per qualcosa che richiede il login con un utente particlar. Detto questo, è un po 'un esempio inventato.

2
Steve