Modulo di accesso HTML senza protezione CSRF

32

Recentemente abbiamo ricevuto un rapporto sulle vulnerabilità che afferma che uno dei nostri moduli HTML in una delle applicazioni interne non è protetto da CSRF. Inizialmente, non è stato possibile riprodurlo immediatamente manualmente utilizzando gli strumenti di sviluppo guardando le intestazioni e i cookie per trovare il XSRF-TOKEN presente nelle intestazioni.

Tuttavia, abbiamo riprodotto il problema nella scheda di navigazione in incognito o in un browser "pulito". Il problema era solo nel primo tentativo di accesso. Sembra che al momento viene pubblicata la prima richiesta di accesso, il client non ha ancora il token XSRF poiché questa è la prima interazione tra il client e il server.

È ancora una vulnerabilità e dovrebbe essere affrontata se riprodotta solo alla prima richiesta di accesso? In che modo viene generalmente affrontato questo tipo di problema? Probabilmente ci deve essere una sorta di interazione client-server prima dell'invio del modulo di login in modo che il client possa ricevere in anticipo il token XSRF.

    
posta alecxe 13.12.2017 - 18:50
fonte

2 risposte

39

Si chiama "Login CSRF" ed è davvero un problema reale che dovresti affrontare.

Mentre un utente malintenzionato non può ingannare una vittima per accedere al proprio account poiché l'utente malintenzionato non conosce le credenziali dell'utente, un utente malintenzionato potrebbe ingannare la vittima per accedere all'account dell'utente malintenzionato. Questo può essere usato per ingannare una vittima nel rinunciare alle informazioni all'attaccante poiché la vittima crede di aver effettuato l'accesso come se stessi.

Questo è davvero qualcosa che è stato usato per fini maligni. Da Detecifica :

PayPal was once vulnerable to login CSRF and the attacker could make a user log in to the attacker’s PayPal account. When the user later on paid for something online, they unknowingly added their credit card to the attacker's account.

Another, less obvious, example is a login CSRF that once existed in Google, which made it possible for the attacker to make the user log in to the attacker’s account and later retrieve all the searches the user had made while logged in.

Anche se non riesci a pensare in alcun modo che questo possa essere sfruttato sul tuo sito, potrebbe essere un abile aggressore. Non c'è motivo di permetterlo.

Quindi come lo blocchi? Anche se la prima azione che l'utente fa è di accedere, la prima interazione che hanno con il server è di recuperare la pagina di accesso. Questa è l'opportunità di assegnare un token CSRF. Quindi controllalo per tutte le richieste che cambiano lo stato del server, incluso il login.

(Una vulnerabilità legata alla tangenza è la fissazione della sessione. Avere dei token CSRF che persistono il login passato può esporvi a questo, quindi leggi su quello prima di iniziare a implementare una soluzione.)

    
risposta data 13.12.2017 - 19:19
fonte
7

Come spiegato da Anders , la mancanza di csrf nel modulo di accesso è una grave vulnerabilità. Probabilmente c'è un gran numero di attacchi, ma ecco un'altra possibilità che mi viene in mente. Nel peggiore dei casi, potrebbe portare al furto delle credenziali della vittima.

Se l'autore dell'attacco ha un self-xss persistente sul suo account, l'accesso al proprio account potrebbe essere sufficiente per attivarlo, consentendogli così di cambiare l'intera pagina di origine e visualizzare una registrazione o un accesso modulo.

Ecco un exploit su AirBnb sfruttando il self-xss più la mancanza di token csrf sul modulo di login.

    
risposta data 13.12.2017 - 22:27
fonte

Leggi altre domande sui tag