Broken Authentication

L’impatto delle vulnerabilità di tipo Broken Authentication è particolarmente elevato, poiché l’attaccante, sfruttando questo tipo di falla, potrebbe riuscire ad ottenere un accesso all’interno dell’applicativo ed elevare i propri privilegi. I principali impatti potrebbero essere:

• Esfiltrazione e/o manipolazione di dati
• Acquisizione di persistenza nella piattaforma
• Acquisizione di privilegi elevati
• Disservizi
• Furti d’identità

Inoltre, è prassi comune – una volta ottenuto un accesso ad un applicativo/servizio – sfruttare tali privilegi per aumentare indebitamente il proprio potere sullo/a stesso/a tramite vulnerabilità di tipo SQLi o RCE.

Non esistono delle vere e proprie “Tipologie D’Attacco” per questa problematica, però ci sono vari attacchi che possono causare l’emergere di questa vulnerabilità, come per esempio:

1. Cookie Stealing: se l’applicativo non dispone delle misure di sicurezza giuste come per esempio i flag HttpOnly e Secure, l’attaccante potrebbe rubare la sessione dell’utente attraverso attacchi di tipo XSS.
2. Manipolazione dei cookies: se la gestione dei cookie non è stata implementata correttamente, sarà possibile manipolare i cookie in modo da poter accedere in modo parziale o completo all’applicativo.
3. Attacchi di tipo Brute Force: se la piattaforma non possiede un blocco dopo un certo numero di richieste permette ad un aggressore di eseguire attacchi di tipo Brute Force in modo indiscriminato e senza blocchi.
4. Attachi di tipo Credential Stuffing: la piattaforma dovrebbe rilevare e bloccare un attacco di questo tipo (in cui l’attaccante utilizza una lista di nomi utenti e password associati presi da possibili databreaches). Questa tipologia d’attacco dovrebbe far scattare un allarme data la facilità con cui dovrebbe essere rilevata.
5. Attacchi con tentativi di autenticazione con credenziali stock/deboli: infatti è inteso (da standard OWASP: A07:2021 – Identification and Authentication Failures) come Broken Authentication anche quando l’applicativo permette di settare password di default o molto deboli come “password1”, o combinazione come “utente/utente”.
6. Bypass dell’autenticazione approfittando di un’errata configurazione nella gestione dei redirect: attraverso l’enumerazione delle pagine, potrebbe essere possibile visualizzare il contenuto e/o eseguire richieste senza effettuare il login, riuscendo così a bypassare l’autenticazione e poter interagire con l’applicativo senza effettuare il login.

1. Un esempio “banale” d’attacco di questa tipologia di vulnerabilità è la quella rappresentata nella GIF sottostante:
   
   
   


Come si può vedere, abbiamo aggiunto un parametro conosciuto all’interno dei cookie della richiesta, nello specifico “uid=1” (solitamente il primo id è riferito all’utente root). Questo ci ha permesso di accedere come utente admin, infatti, aggiornando la pagina si può vedere l’utente cambiato.




2. Questa tipologia di vulnerabilità potrebbe manifestarsi nel momento in cui i redirect al login non sono stati eseguiti correttamente (es. se il redirect dell’utente viene effettuato client-side e non server side). Se un attaccante, attraverso l’enumerazione delle directory, trova una pagina con la gestione errata del redirect, potrebbe visualizzare il contenuto reale della pagina e magari, eseguire richieste HTTP bypassando difatti il format di login dell’applicativo.




3. Un altro esempio d’attacco per ottenere l’accesso all’applicativo è quello di trovare una vulnerabilità di tipo XSS in modo tale da poter fare una session hijacking e prendere il cookie di un altro utente, questa vulnerabilità sarà applicabile solamente se i flag HttpOnly e Secure non sono presenti.




4. Se la piattaforma non ha nessun blocco per le richieste di autenticazione e non esiste nessun metodo di impedimento per fare delle richieste automatizzate, sarà possibile creare uno script per testare il login della web application con cui poter fare degli attacchi di Brute Force, Credentials stuffing e/o Password Spraying.

Alcune tecniche di difesa per questa tipologia di attacco potrebbero essere le seguenti:

• Buona gestione dei cookie, cancellazione, generazione, etc
  • È importante revocare la validità dei cookies di sessione dopo un determinato periodo di tempo, dopo una sessione inattiva e chiaramente dopo il logout dell’utente.
  • Se possibile, non includere cookie o tokens/id di sessione negli URL.

• Implementazione dei token in modo da mitigare, almeno parzialmente, gli attacchi automatizzati
  • Implementazione di token come per esempio l’anti-CSRF per limitare gli attacchi automatizzati
  • Implementazione di Captcha (possibilmente v3) in modo da ridurre gli attacchi di tipo Brute Force, Password Spraying o Credential Stuffing fruibili (anche mediante l’ausilio di servizi di bypass di terze parti).

• Implementazione di ban temporanei dopo un ragguardevole numero di tentativi di accesso ad un account
  • Dopo un considerevole numero di accessi falliti in successione, l’applicativo dovrebbe allarmarsi segnalando la questione e bloccando temporanemente l’IP del criminale
  •  Evitare il ban dell’utente in quanto si rischia di proibire l’ingresso di molti utenti creando così un possibile disservizio agli utenti legittimi del servizio.

• Implementazione di ban temporanei ai tentativi di accesso con utenti diversi e/o non esistenti
  • È possibile che l’attaccante abbia a disposizioni qualche lista di username/password della società avendo fatto qualche analisi OSINT, quindi proverà ad accedere con diversi nomi utenti e qualche credenziale di questi, ciò sta a significare che genererà molti tentativi di autenticazione con diversi username, alcuni non esistenti.

• Gestione corretta dei redirect
  • Come abbiamo visto anche negli esempi d’attacco, gestire correttamente i redirect è molto importante poichè si evita di esporre dati ad utenti non autenticati

• Implementazione dei giusti flag di sicurezza come per esempio HttpOnly e Secure
  • Esistono diversi flag di sicurezza per difendersi da alcuni attacchi. I principali sono i flag succitati (HttpOnly e Secure): questi infatti non consentono l’acquisizione dei cookie di sessione tramite codice Javascript limitando, di conseguenza, il rischio del verificarsi di attacchi di tipo Session Hijacking (comunque possibili nel caso di compromissione del browser della vittima per esempio attraverso vulnerabilità XSS).