I moduli di accesso hanno bisogno di token contro gli attacchi CSRF?

161

Da quello che ho imparato finora, lo scopo dei token è impedire a un utente malintenzionato di creare un modulo.

Ad esempio, se un sito Web avesse un modulo che immetteva articoli aggiunti al carrello e un utente malintenzionato potrebbe inviare spam al carrello con articoli che non desideri.

Questo ha senso perché potrebbero esserci più input validi per il modulo del carrello, tutto ciò che l'attaccante dovrebbe fare è conoscere un oggetto che il sito Web sta vendendo.

Capisco come funzionano i token e aggiungo sicurezza in questo caso, perché assicurano che l'utente abbia effettivamente compilato e premuto il pulsante "Invia" del modulo per ogni articolo aggiunto al carrello.

Tuttavia, i token aggiungono sicurezza al modulo di accesso dell'utente, che richiede un nome utente e una password?

Poiché il nome utente e la password sono molto singolari, l'aggressore dovrebbe conoscerli entrambi affinché la falsificazione dell'accesso funzioni (anche se non hai impostato i token) e se un attaccante lo sapesse già, potrebbe semplicemente accedere al sito Web lui stesso. Per non parlare del fatto che un attacco CSRF che fa in modo che l'utente esegua l'accesso non avrebbe comunque alcuno scopo pratico.

La mia comprensione degli attacchi e dei token CSRF è corretta? E sono inutili per i moduli di accesso degli utenti come sospetto?

php token csrf

— php_learner
fonte

Possono dirottare il tuo router, perché probabilmente usi la password predefinita e non è protetta da CSRF per l'accesso.

— AbiusX,

Sì, quindi altri siti Web non possono imitare il modulo di accesso. Che cosa possono raggiungere facendolo? Per prima cosa non vuoi permetterlo. Secondo: casi di errore molto semplici come il blocco dell'utente a causa della password errata n. di volte, può essere evitato.

— Mayankcpdixit,

126

Sì. In generale, è necessario proteggere i moduli di accesso dagli attacchi CSRF come qualsiasi altro.

Altrimenti il tuo sito è vulnerabile a una sorta di attacco di "phishing del dominio di fiducia". In breve, una pagina di accesso vulnerabile CSRF consente a un utente malintenzionato di condividere un account utente con la vittima.

La vulnerabilità si presenta così:

L'attaccante crea un account host sul dominio trusted
L'attaccante forgia una richiesta di accesso nel browser della vittima con le credenziali di questo account host
L'aggressore induce la vittima a utilizzare il sito attendibile, dove potrebbe non notare che è stato effettuato l'accesso tramite l'account host
L'aggressore ora ha accesso a tutti i dati o metadati che la vittima ha "creato" (intenzionalmente o non intenzionalmente) mentre il suo browser era connesso con l'account host

Come esempio pertinente, considera YouTube . YouTube ha permesso agli utenti di vedere un record della "loro" cronologia di visualizzazione e il loro modulo di accesso era vulnerabile CSRF! Di conseguenza, un utente malintenzionato potrebbe creare un account con una password che conosceva, accedere alla vittima su YouTube utilizzando tale account, cercando i video che la vittima stava guardando.

C'è qualche discussione in questo thread di commenti che implica che potrebbe "solo" essere usato per violazioni della privacy del genere. Forse, ma per citare la sezione dell'articolo CSRF di Wikipedia :

Login CSRF rende possibili vari nuovi attacchi; ad esempio, un utente malintenzionato può successivamente accedere al sito con le sue credenziali legittime e visualizzare informazioni private come la cronologia delle attività salvate nell'account.

Enfasi su "nuovi attacchi". Immagina l'impatto di un attacco di phishing contro i tuoi utenti, quindi immagina che detto attacco di phishing funzioni tramite il segnalibro di fiducia dell'utente sul tuo sito! Il documento collegato nel suddetto thread di commenti fornisce numerosi esempi che vanno oltre i semplici attacchi alla privacy.

— natevw
fonte

6

In che modo aiuta la protezione CSRF? C'è qualcosa che impedisce all'aggressore di chiedere il proprio token CSRF e di inviarlo? Poiché non esiste alcuna sessione autenticata, il server Web non ha motivo di preferire un token rispetto a un altro.

— A. Wilson,

2

"C'è qualcosa che impedisce all'aggressore di chiedere il proprio token CSRF e di sottometterlo?" - Sì! Questo è il presupposto alla base della logica di prevenzione CSRF. I browser consentivano / inoltrano un modulo di targeting per un'altra origine, ma non hanno mai [intenzionalmente] consentito a JS di leggere i dati attraverso i siti, tranne ora tramite opt-in CORS. A meno che non imposti CORS in modo errato, l'utente malintenzionato può attivare l'invio di un modulo (che può includere un token CSRF esistente nei cookie ) ma non ha modo di conoscere il token per inviare la seconda copia richiesta (ad esempio nel corpo / intestazioni). Quindi il codice CSRF verrà rifiutato.

— natevw,

7

Penso che il tuo ultimo commento sia sbagliato (hai frainteso quello che stava dicendo A. Wilson). Stiamo dicendo che un utente malintenzionato può caricare http://good.com/login.htmlin un client, analizzare il token CSRF nidificato e quindi pubblicare http://bad.com/login.htmlche contiene un modulo modificato che invia il suo nome utente, password e token indipendentemente da ciò che la vittima digita. CORS non si applica perché tu ' ho due clienti separati: l'attaccante e la vittima. Quindi, per ribadire la domanda: la protezione CSRF funziona davvero per i moduli di accesso?

— Gili,

8

Sì, CSRF proteggerà un modulo di accesso da falsificazioni di richieste tra siti . Un token CSRF corretto è crittograficamente unico ogni volta che viene generato. Certo, l'attaccante può ottenere un token da solo, ma NON CORRISPONDERÀ il cookie [potenzialmente non impostato] che la vittima ha nel proprio browser e l'attaccante non ha modo di impostare detto cookie senza compromettere una pagina sul dominio valido. (Il tuo esempio sembra un po 'confuso tra CSRF e una sorta di strano attacco di phishing, quindi, quindi non sono sicuro di rispondere alla tua vera domanda ...)

— Natevw,

3

Potrei sbagliarmi, ma sembra che ci sia una minaccia significativa se l'utente fa accidentalmente qualcosa relativo all'acquisto di articoli. Ad esempio, un utente malintenzionato inganna l'utente per accedere a un sito Web e l'utente procede all'acquisto di articoli senza rendersi conto di trovarsi in un altro account (pensa ad Amazon o simili). Ora l'attaccante ha accesso alle informazioni di pagamento salvate, può reindirizzare gli acquisti, ecc.

— tu786

14

La tua comprensione è corretta - il punto centrale di CSRF è che l'attaccante può creare una richiesta dall'aspetto legittimo in anticipo. Ma questo non può essere fatto con un modulo di accesso a meno che l'attaccante non conosca il nome utente e la password della vittima, nel qual caso ci sono modi più efficienti per attaccare (accedi tu stesso).

In definitiva, l'unica cosa che un utente malintenzionato può fare è l'inconveniente dei tuoi utenti tramite spamming di accessi non riusciti, quando il sistema di sicurezza potrebbe bloccare l'utente per un periodo di tempo.

— Jon
fonte

2

Wow, risposta super veloce! Molte grazie! Ora posso continuare a costruire il mio sito Web con fiducia.

— php_learner,

21

Login CSRF può ancora essere utilizzato per attacchi alla privacy dell'utente seclab.stanford.edu/websec/csrf/csrf.pdf

— squiddle

6

@squiddle: Questo è un documento piuttosto interessante, grazie per il link. Ma dipende dall'accesso dell'utente con un account sotto il controllo dell'aggressore e presuppone che l'utente non realizzerà che qualcosa non è giusto e presuppone che l'utente produrrà informazioni sensibili che verranno poi archiviate sul server. Quindi IMHO è molto meno serio del CSRF "classico".

— Jon,

6

@Jon Sì, può essere meno grave, ma alla fine può essere più di un semplice inconveniente, vale a dire l'invasione della privacy. Ogni servizio deve definire autonomamente il proprio modello di minaccia e gestirlo di conseguenza. Per fare ciò è necessario almeno essere consapevoli delle possibili minacce. Ecco perché ho aggiunto i miei 2 centesimi.

— Squiddle

1

Per favore, potresti ampliare il modo in cui "Alla fine l'unica cosa che un utente malintenzionato può fare è scomodare i tuoi utenti inviando spam con accessi non riusciti, quando il sistema di sicurezza potrebbe bloccare l'utente per un certo periodo di tempo".

— Samthebest,

0

Sì , quindi altri siti web non possono imitare il tuo modulo di accesso! Così semplice.

Che cosa possono raggiungere facendolo?

Primo: non vuoi permetterlo.
Secondo: anche casi di fallimento molto semplici come:
- blocco utente a causa di password errata nn. di volte, può essere evitato.
- Gli avvisi di hacking flase possono essere prevenuti. ecc ecc.

— mayankcpdixit
fonte

La maggior parte di questi punti non sono corretti. L'attaccante può creare un modulo di accesso, ottenere le credenziali dell'utente caricare il modulo di accesso (con token csrf) e pubblicare le tre informazioni sulla destinazione. CSRF non impedisce questo.

— Snapey,

I browser @Snapey generalmente non consentono a JS di leggere i dati CSRF. Utilizzando JS non è possibile imitare la richiesta di invio del modulo originale.

— Mayankcpdixit,

Il token csrf viene spesso passato al client per l'utilizzo da parte di JavaScript. Non sto parlando di cors che sto prendendo per l'attaccante, sto solo richiedendo il modulo di login e riempiendo le credenziali. @mayankcpdxit. Sembrerebbe implicare che CSRF previene il riempimento delle credenziali, cosa che non accade.

— Snapey,

Teoricamente, sì, non può impedirlo. Ma non è possibile automatizzare il riempimento delle credenziali dopo CSRF se si interrompe il caricamento dei moduli CSRF negli iframe e si impedisce il req tra origini.

— Mayankcpdixit

-1

Il pre-login di convalida CSRF non ha molto senso IMHO.

Grazie a @squiddle per il link: seclab.stanford.edu/websec/csrf/csrf.pdf , possiamo leggere nella prima pagina:

The most popular CSRF defense is to include a secret
token with each request and to validate that the received
token is correctly bound to the user’s session,
preventing CSRF by forcing the attacker to guess the
session’s token.

Se provi il pre-login di convalida CSRF, dai a un potenziale attaccante la possibilità di grattare un codice valido del tuo sito web! Sarebbe quindi in grado di ripubblicare il token sconfiggendo lo scopo.

Forse un utente malintenzionato può quindi provare a indovinare un nome utente del tuo sito. Quello che ho fatto, se l'indirizzo IP tenta di indovinare dire 10 nomi utente senza successo, lo metto semplicemente nella lista nera.

— Patrice Gagnon
fonte