In un'applicazione web l'autenticazione è il sistema fondamentale di protezione dei dati, è la linea di frontiera che separa la parte esposta da quella protetta. Se un sistema di autenticazione non funziona o funziona male o non è abbastanza sicuro, tutti gli sforzi per ottenere un'applicazione affidabile risulteranno prima o poi vani. In questa lezione vedremo alcuni metodi per prevedere i comportamenti di un meccanismo di autenticazione per forzarlo o aggirarlo.
Tecnologie per l'autenticazione
Ci sono diversi metodi per creare un meccanismo di autenticazione in una applicazione web, ne ricordiamo alcuni:
- Html form-based authentication: un modulo html è predisposto per accettare in input dall'utente una coppia di valore (username/password) e inviarla all'applicazione. Il sistema è utilizzato per un gran numero di applicazioni di bassa/media criticità.
- Autenticazione multi fattore: dove oltre allo username ed a un eventuale password vengono richiesti altri parametri (un token, un indirizzo ip , un mac address o altro). Sistema utilizzato in ambito aziendale per accesso ad applicativi contenenti dati sensibili (siti di gestione flotte, anagrafiche clienti, gestione ordini)
- Token: in applicazioni particolarmente critiche possono essere richieste anche chiavi generate da dispositivi elettronici (token rsa), chiavi utilizzabili una volta sola (crittografia quantistica). Sono usate in sistemi per applicazioni estremamente critiche che gestiscono dati sensibili (banche, organizzazioni militari e di intelligence ecc).
Fatte queste premesse, vediamo come analizzare efficacemente la tipologia di autenticazione di un applicazione web.
Abbiamo di fronte un box che ci richiede username e password, la prima cosa da fare è..sbagliarle. Testiamo infatti il comportamento dell'applicazione in risposta a un inserimento errato intercettando l'header della risposta del server all'errore che abbiamo generato. Il server può non dare informazioni sull'esito del nostro tentativo, ma dall'analisi della response http possiamo capire molte cose sul meccanismo di autenticazione e sulla dislocazione delle risorse dell'applicativo.
Password di default o deboli
La funzione di autenticazione, per la sua natura e per la sua importanza, è particolarmente esposta a errori di progettazione/implementazione e comunque è tra i primi baluardi a venire attaccato. Il nostro obiettivo (come tester) è determinare se l'applicazione rispetta le seguenti proprietà:
- La password deve avere una lunghezza minima e il campo di testo non può essere vuoto (da controllare sia lato client sia lato server).
- La password "hashata" o crittografata, dovrebbe essere confrontata con un elenco di password deboli e non dovrebbe essere permesso l'utilizzo di password troppo semplici (pippo, password, pippopluto).
- Il nome utente (e sarebbe meglio anche la password) non devono essere duplicabili: diversi utenti devono avere nomi utente diversi e password diverse (vedremo poi il perché).
- Non deve essere possibile utilizzare un nome utente uguale alla password.
Se durante il test della form di autenticazione riusciamo a individuare uno o più di questi errori abbiamo già del materiale per un eventuale penetration test!
Vediamo altri controlli e test da fare.
