Dichiarazione di non responsabilità : non ho trovato alcun riferimento sull'argomento, quindi userò uno strumento discutibile chiamato "logica". Se qualcuno trova qualche buon riferimento, per favore aggiungili.
CSRF è pericoloso
Non ci sono dubbi e OAuth2 non fa eccezione. In realtà, ci sono molti modi in cui puoi sfruttare l'attacco CSRF mentre usi OAuth2. Il motivo è che ci sono più messaggi inviati che potrebbero essere utilizzati per attivare un attacco CSRF. La sezione Spec. OAuth2 sezione 10.12 offre una buona panoramica di cosa potresti fare con CSRF
Ma diamo un'occhiata a cosa succede nei dettagli quando un utente vuole accedere usando OAuth2. Nel nostro esempio, avremo i seguenti attori:
- L'utente (tu e il tuo browser)
- L'autore dell'attacco (solitamente un sito Web dannoso)
- Il client (applicazione Web in uso)
- Il provider (server oauth2 che autentica l'utente)
Quindi, esaminiamo cosa succede dal punto di vista dell'utente quando tenta di autenticare con il provider.
- L'utente fa clic su un collegamento sul sito Web del cliente e viene reindirizzato al modulo di autenticazione del provider
- L'utente si autentica con il provider e viene reindirizzato al sito Web del cliente dove viene autenticato anche automaticamente
Dove possiamo attaccare?
Dal punto di vista dell'utente, sono solo 2 semplici passaggi, ma ci sono più punti in cui puoi attaccarlo. Uno dei problemi principali qui è che spesso il provider OAuth2 ti reindirizzerà automaticamente, se hai già effettuato l'accesso. Un buon esempio è lo stackoverflow. Vedi questa risposta per i dettagli:
OAuth2 Cross Site Request Forgery e parametro di stato
Quindi i diversi attacchi sono:
-
Un utente malintenzionato può sostituire il codice di autorizzazione con il proprio per farti accedere al suo account anziché al tuo. Potrebbe sembrare un'idea pazzesca, ma se decidi di inserire alcune informazioni riservate nel suo account, ora può accedervi. Es .: informazioni bancarie
-
Un utente malintenzionato può generare un link di provider valido sulla sua macchina e poi lo serve a te, se il provider sta reindirizzando automaticamente, allora sarai loggato al servizio che l'attaccante vuole attaccare.
-
L'attaccante ti fa generare un link valido dal sito web del client (funziona solo se il link viene generato tramite un post / ottieni su un URL statico), quindi se il provider sta reindirizzando automaticamente ti verrà registrato al servizio dell'attaccante desidera attaccare.
Come proteggersi da loro?
Semplice, devi solo passare il tuo token CSRF anti-contraffazione nel parametro di stato di OAuth2 per proteggerti da # 1 e # 2. Quindi, per proteggersi dal punto # 3, è necessario assicurarsi che il collegamento non possa essere generato senza l'interazione dell'utente, ovvero proteggere il collegamento con la protezione CSRF. Ma torniamo al # 1 e al # 2 ...
Includendo un token CSRF come stato, sconfiggerete quegli attacchi in quanto sarà impossibile per l'attaccante servirvi collegamenti che non avete generato voi stessi. Una semplice implementazione di un token CSRF è un numero casuale che viene archiviato nella sessione e quindi incluso in ogni modulo inviato da tale utente. Se il modulo contiene il token, il client lo considera valido. Se non lo contiene, il client presume che la richiesta non sia valida.
Di solito, quel token CSRF è accessibile solo all'utente / browser e al client, ma nel caso di OAuth2, più parti accedono ad esso. Per capire cosa fare, dobbiamo sapere quali sono queste parti aggiuntive.
La risposta: invia il token
Quindi, in quel caso, il token sarà noto per
- Il client (colui che lo ha creato)
- L'utente
- Il provider
È un semplice round trip su HTTPS. Un utente malintenzionato non può inserirsi in quella conversazione, quindi non devi preoccuparti di questo.
Hai bisogno di proteggere il token contro il provider?
No. Se il provider OAuth2 è malevolo, hai già perso. Non ha bisogno del tuo token CSRF per prendere in consegna tutti i tuoi account, se lo desidera. Quando hai scelto di usare OAuth2, in pratica sei diventato un dio di tutti i tuoi account utente.
Conclusione
Non preoccuparti troppo di come invii il token CSRF; assicurati di inviarlo. Inoltre, il fatto che sia inviato come parametro url sarebbe un altro punto di cui preoccuparsi per una password permanente, ma dato che quei token sono temporanei non dovrebbe essere un grosso problema.