In ogni applicazione web che implementa un meccanismo di login è necessario avere una gestione delle sessioni. Come sappiamo infatti il protocollo http è stateless e abbiamo quindi bisogno di una struttura logica che mi permetta di tener traccia dell'utente autenticato in modo da riconoscerlo durante la navigazione e non obbligarlo a inserire continuamente i propri dati di accesso.
In pratica quando un utente si autentica nell'applicazione, gli viene fornito (in maniera a lui trasparente) un "tesserino di riconoscimento" (un token) valido per tutta la durata della navigazione nell'area protetta.
Problemi del token
Il termine token è qui usato volutamente in senso generico: un token può essere un cookie, un parametro di sessione, un campo hidden in una form e altro.
Facilità nella predizione della sequenza di generazione
L'importanza della gestione delle sessioni utente obbliga l'applicazione e generare token univoci per ogni utente connesso in un dato momento. Accadrà quindi che l'utente1 ha il suo token e l'utente2 connessosi immediatamente dopo avrà un token+1 dove con +1 intendiamo il token successivo secondo l'algoritmo di generazione.
L'algoritmo di generazione del token mi permette di ottenere un token differente per ogni utente. Questo algoritmo è estremamente importante per tutelare le sessioni utente e non generare furti di identità! Se il token diventa prevedibile possono iniziare i problemi.
Facciamo un esempio: il nostro token (di esempio) viene generato tramite una formula matematica elaborando "data", "ora" e le vocali del nome utente connesso.
Mentre svolgo il mio test su un sito che fornisce l'accesso a un forum, creo un certo numero di utenti di test (ovviamente più di uno: più alto è il loro numero più probabilità ho di ottenere un'efficace reverse engineering sull'algoritmo). Per visualizzare la progressione del valore dei token mi connetto in rapida successione con tutti gli utenti di test fino ad avere un elenco di token sufficiente per una analisi.
Con un po' di pazienza (e un po' di fortuna) riesco a determinare l'algoritmo e a capire come vengono generati i token. Vado sul forum..leggo l'elenco degli utenti autenticati connessi..e a che ora si sono connessi.. Poi che faccio?
Disponibilità del token trasmesso
Altro problema nell'utilizzo dei token è il loro trasporto. Il token per essere riconosciuto dall'applicazione deve essere trasmesso al server. Per essere trasmesso al server deve transitare attraverso la rete.
Cosa succede: Un utente si autentica, il server lo riconosce e gli invia il token di sessione. Il token passa per il web server e viene inviato in rete.
Cosa succede se mi metto a sniffare il traffico di rete proprio nel momento in cui il server invia il token? Potrei trovarmi tra le mani il token dell'utente autenticato e "impersonarlo" nell'applicazione per avere accesso al suo account e alle sue funzionalità.
Attenzione: Ricordiamo inoltre per precisione che nel caso di una trasmissione di un token tramite querystring (quindi all'interno dell'url), questo viene salvato un po' dappertutto...log del browser, log del web server, log del proxy (se usato), log del proprio isp, viene registrato come referrer se si passa da una pagina a un'altra e così via.
In conclusione: per lo sviluppatore il consiglio è di utilizzare la gestione delle sessioni nel modo più pignolo possibile, creando token robusti, integrandoli con altri sistemi, e verificandoli sempre (quando è possibile) durante il loro ciclo di vita che DEVE essere limitato a un periodo ben definito.
