L'azione di login e disconnessione dovrebbe avere la protezione CSRF?

Forse dovresti proteggerti da CSRF di accesso . Senza questa protezione, un utente malintenzionato può effettivamente neutralizzare un attacco CSRF. Piuttosto che la vittima che ha effettuato l'accesso al proprio account e l'utente malintenzionato tenta di utilizzare la sessione effettuando richieste al sito utilizzando i cookie della vittima, accederà al sito con le credenziali dell'utente malintenzionato consentendo all'autore dell'attacco di dirottare le richieste in modo efficace dominio che la vittima pensava fossero anonimi o che fossero sotto il proprio account e quindi li inviava all'account dell'attaccante. Naturalmente, se questo è rilevante per il tuo sito particolare o no dipende dalla natura del tuo sito e se qualcosa di simile è vantaggioso per un utente malintenzionato. Un esempio è un attacco CSRF di accesso su un motore di ricerca in modo che l'utente malintenzionato possa vedere i termini ricercati mentre vengono registrati con l'account dell'attaccante anziché con quelli della vittima.

Gli obiettivi principali per questo tipo di attacco sono dove le azioni autenticate possono avvenire al di fuori dell'applicazione principale stessa. per esempio. da un plug-in del browser o widget incorporato in un altro sito. Questo perché tali azioni verranno autenticate tramite l'uso di cookie e, se un utente malintenzionato ha effettuato l'accesso come tali, ciascuna azione verrà registrata nel proprio account.

Dovresti inoltre proteggere il tuo meccanismo di disconnessione contro CSRF. All'inizio sembra che tutto ciò che un utente malintenzionato può fare è disconnettersi dall'utente, il che sarebbe alquanto fastidioso. Tuttavia, se si combina questo con un attacco di phishing, l'aggressore potrebbe essere in grado di invogliare la vittima a riconnettersi utilizzando il proprio modulo e quindi acquisire le credenziali. Vedi qui per un esempio recente - LostPass .

Login? Sì. Disconnettersi? No.

Perché accedere? Esiste questo divertente attacco di accesso CSRF, in cui l'utente malintenzionato accede alla vittima sotto un account controllato da un utente malintenzionato e quindi può "ottenere il controllo sul contenuto creato dalla vittima mentre si è connessi con quell'account". L'impatto è abbastanza debole, ma hanno iniziato a vedere questo come un problema ora che i vettori di attacco più succosi sono spariti. ; -)

Perché non uscire? Non c'è alcun impatto sulla sicurezza. La cosa migliore da fare è registrare qualcuno dal sistema, il che causa al massimo fastidi.

EDIT : non c'è alcun impatto sulla sicurezza nel logout. Attacco CSRF di per sé . Potrebbero esserci casi in cui questo può essere usato in un attacco a più stadi per registrare prima qualcuno, quindi chiedere loro di accedere a una pagina falsificata.

La protezione CSRF al logout è indispensabile!

Perché? Assumi il seguente scenario:

1. Sei su una pagina di trading e prepari un ordine di acquisto per es. 1000 Daimler su uno scambio XETRA.
2. Finché non si sta preparando l'ordine, qualcuno, che sa di aver effettuato l'accesso al collegamento , invia un link di phishing a te. per esempio. link
3. Facendo clic sul collegamento, si è disconnessi e l'ordine potrebbe non essere completato.
4. Dopo aver effettuato di nuovo l'accesso, riconosci il fatto che il prezzo dei 1000 Daimler è più alto di un minuto prima di uscire da questo link di phishing.
5. Ora devi ordinare un prezzo più alto.

Un token CSRF sul logout avrebbe impedito questo pasticcio.

Esci e accedi CSRF è in realtà molto sfruttabile.

Se trovi un modo per ottenere un XSS privato / auto permanente (come un campo privato non protetto come nelle preferenze dell'utente) puoi forzare la disconnessione della vittima, accedere con il tuo account che ha l'auto XSS applicato, e poi esegui del codice per effettuare un attacco di phishing eccetto che si trova sul dominio corretto con un certificato SSL valido . Se l'utente effettua l'accesso (o ha un riempimento automatico che ti consente di rubare le credenziali prima ancora di inviare INVIO e quindi di effettuare automaticamente il login per loro in modo che possano vedere la loro pagina bianca in bianco e poi si troveranno dove si aspettano) tu ora hanno la loro password e una stessa esecuzione di origine. Ora esegui alcuni exploit di persistenza nelle loro impostazioni private e ora hai un'esecuzione JS remota permanente sull'account degli utenti.

Ciò consente attacchi molto importanti, soprattutto perché molti sviluppatori non utilizzano entrambi gli exploit di injection HTML su campi privati perché solo l'utente dovrebbe essere in grado di vederlo e non hanno motivo di eseguire codice contro se stessi. Un logout CSRF di logout di accesso consente di eseguire lo stesso phishing di origine e, se hanno gli stessi iframe di origine abilitati, puoi anche incorporare la pagina di accesso a schermo intero e quindi eseguire qualsiasi codice all'interno dell'iframe apparentemente legittimo.

Qualcuno dei bug varia da inutile a fastidioso, ma se hai questi due (ed è meglio presumere che tu lo faccia) un utente malintenzionato può dirottare un account utente con un solo brutto annuncio.

CSRF per il login generalmente sì ma dipende dalla tua applicazione. un utente malintenzionato può accedere a un account dannoso, ad esempio in Google, e quindi monitorare tutte le visite al sito.

CSRF per il logout - sì assolutamente possibile impedire DOS