Nella moderna società digitale, le applicazioni e i siti web costituiscono la nuova “appendice” dell’individuo, lo strumento attraverso il quale egli realizza ogni azione e interazione quotidiana: per questo motivo, due tra le più importanti strategie di hardening (rafforzamento) delle applicazioni web riguardano la gestione della sessione (session management) tra la piattaforma e l’utente e il conseguente controllo degli accessi.
Indice degli argomenti
Tecniche di hardening delle applicazioni Web: il contesto tecnologico
Le piattaforme online sono frequentate con sempre maggiore fiducia da parte degli utenti e dei consumatori, le funzionalità si espandono, coprono ogni aspetto della vita sociale, contatti, bisogni, urgenze, soddisfano ogni tipo di necessità; ad uno sguardo sociologico attento, tuttavia, non può sfuggire un dettaglio importante e sostanziale: le applicazioni web si innestano in uno spazio cyber, dematerializzato, invisibile, incontrollabile e intrinsecamente esposto a malintenzionati.
La presa d’atto dell’evoluzione dell’ecosistema sociale, dall’interazione faccia a faccia alla cyber società, comporta quindi la messa in campo di metodologie e tecniche di rafforzamento (hardening) dei siti e delle web application, al fine di realizzare una barriera robusta tra l’utilizzo lecito della piattaforma e qualsiasi altro uso improprio o illecito.
I siti web comunicano attraverso il protocollo HTTP che si basa su una logica di tipo request-response: il client dell’utente (browser) chiede una risorsa dell’applicazione e il server risponde nel modo opportuno, concedendo l’accesso alla risorsa o meno, a seconda delle caratteristiche del client.
Il punto cruciale è che il protocollo HTTP è stateless, cioè senza memoria, dunque tecnicamente le varie richieste dell’utente pervengono al backend come “monadi” singole, non integrabili in un contesto organico che consenta al server il riconoscimento dell’identità del client stesso.
Questa caratteristica, che poteva essere “tollerata” nell’era “arcaica” del web, in cui le pagine statiche non facevano altro che mettere a disposizione contenuti testuali, è inadeguata al giorno d’oggi, quando e nella misura in cui le applicazioni consentono funzionalità avanzate, dinamiche, multimediali, in cui prevale la dimensione della personalizzazione, del mantenimento di uno “storico” del comportamento di navigazione e, non ultima, la necessità di monitoraggio dei log anche ai fini probatori.
Tecniche di hardening delle applicazioni Web: il session management
Il meccanismo della sessione consiste quindi nel creare un gruppo unitario di interazioni tra il client e il server, in un certo intervallo temporale di riferimento, all’interno del quale siano valide le scelte, le preferenze, i comportamenti (tracciati dall’applicazione attraverso variabili) espresse dall’utente e non sia necessario ripeterle.
Da un punto di vista rilevante per la cyber security, la sessione è lo “scope”, l’ambito di validità dei parametri sottoposti al server dal client, dunque una corretta politica di gestione della sessione, il cosiddetto session management, è un requisito da cui non si può prescindere, specie se l’accesso ai dati del sito richiede autenticazione.
Ad un livello generale e prima di prendere in considerazione le modalità tecniche di gestione della sessione, il tipico errore che viene commesso è di estendere l’intervallo temporale di validità della sessione in maniera non necessaria e incontrollata: in assenza di una decisione esplicita di logout, se l’utente utilizza il browser per accedere ad altri siti, l’account dell’utente diventa vulnerabile, durante tutto questo intervallo di tempo non necessario, ad attacchi Cross Site Request Forgery, che sfruttano proprio la “fiducia” che il server ripone sui parametri (manipolati dall’attaccante) e dunque su quanto gli viene proposto da un client che, dal suo punto di vista, risulta dotato di sessione valida.
Le vulnerabilità del session management
Più nel dettaglio, le vulnerabilità connesse al session management sono sostanzialmente classificabili in due grandi categorie:
- la debolezza nella generazione dei token di sessione, spesso veicolati attraverso cookie;
- la debolezza dei meccanismi di mantenimento della sicurezza di questi token (pensiamoli come delle stringhe), durante il loro ciclo di vita.
Con riguardo al primo punto, non è raro imbattersi in token che sono generati semplicemente trasformando, codificando, o mescolando parametri trasmessi dal client durante il login e dunque, una volta individuato il tipo di “camuffamento” implementato dalla logica applicativa, facilmente individuabili e riproducibili con attacchi brute force, ad esempio:
- lo username
- l’ID numerico dell’utente
- nome e cognome dell’utente proprietario dell’account
- l’indirizzo mail
- il timestamp del login
- la pagina richiesta
In questo modo, un token apparentemente sicuro:
dXNlcj1tYW51ZWxhO3VybD0vYWRtaW4vdG9vbHMvdXBsb2FkcztkYXRlPXRvZGF5
decodificato in base64, potrebbe rivelare le seguenti informazioni:
user=manuela;url=/admin/tools/uploads;date=today
utilissime per un attaccante che voglia sniffare un token di una sessione, magari privilegiata, con un semplice attacco brute force automatizzato.
Una volta individuato il cookie di sessione e sostituito il token, sarà possibile sostituirsi all’utente legittimo ed operare con le funzionalità back end previste per quel profilo utente.
Spesso poi gli amministratori godono di funzionalità di upload e di esecuzione di script direttamente sul server: il passo dall’hacking dell’applicazione alla shell su server e poi all’escalation dei privilegi può essere un gioco da ragazzi.
Un’altra vulnerabilità connessa ai meccanismi di generazione dei token riguarda la loro prevedibilità: se nell’algoritmo di “assemblaggio” della stringa si utilizzano funzioni random standard e conosciute, oppure sequenze di caratteri sottoposte a particolari pattern, disponibili in librerie dei comuni linguaggi di programmazione, regolarità e dipendenze correlate agli intervalli temporali, la sicurezza della sessione sarà seriamente esposta ad attacchi automatizzati finalizzati al riconoscimento e all’identificazione di questi schemi standard.
Se il sistema implementa tecniche di cifratura o di hashing della stringa ottenuta, sarà inoltre necessario ricorrere ad algoritmi robusti, considerando che un hash MD5 su una stringa di 47 caratteri è invertibile nel giro di qualche secondo.
Con riferimento invece alla seconda categoria di vulnerabilità, cioè la debolezza nella gestione del ciclo di vita del token, un grande errore è quello di pensare che trasmettere il token “in chiaro” sia tollerabile, qualora si abbia cifratura del canale di trasmissione (TLS e HTTPS). In effetti, è possibile intercettare i token anche in presenza di canale di trasmissione criptato se:
- il sito mantiene alcune pagine (la home, ad esempio, prima del login e quelle ritenute erroneamente meno “sensibili”) in HTTP;
- se il cookie HTTP che trasmette il token non ha l’attributo “secure”, che previene la trasmissione su connessioni con criptate;
- se il token di sessione viene generato prima del form di login in HTTPS (quindi del cookie di autenticazione) e la home è in HTTP;
- se il token è registrato in file di log, a qualsiasi livello: browser, server, proxy;
- se il token viene replicato sul campo Referer dell’header HTTP.
Applicazioni Web e session management: le sessioni multiple
Un’altra fonte di criticità emerge quando la logica dell’applicazione consente la coesistenza di sessioni multiple dello stesso utente: in presenza di un desiderabile meccanismo di tracciatura e monitoraggio di eventi anomali sul back end, questo comportamento facilita enormemente la vita dell’eventuale attaccante che può impadronirsi di una delle sessioni senza essere rilevato dai sistemi antintrusione.
Correlata alla precedente è la vulnerabilità legata all’utilizzo di token di sessione statici, uniti alla funzione “Ricordami”: se il token che identifica il client non cambia e viene memorizzato in cookie persistenti all’interno del browser dell’utente si aumenta considerevolmente il perimetro di rischio perché la superficie di attacco si estende al dispositivo client, al browser e agli altri siti visitati.
Conclusioni
Concludendo la rassegna sulle principali criticità dei meccanismi di gestione della sessione, la sicurezza dell’intera infrastruttura dipende da pochi necessari accorgimenti:
- utilizzare algoritmi forti di generazione dei token, che costruiscano la stringa utilizzando un certo grado “di entropia” e parametri non usuali (ad esempio numeri pseudo-random uniti a liste di dati in ordine non sequenziale, combinati con timestamp in millisecondi);
- circoscrivere l’intervallo temporale di validità della sessione al minimo indispensabile e generare nuovi token davanti a richiese di accesso a risorse sensibili (la cosiddetta politica del “per page token”);
- prestare la massima attenzione alla sicurezza di tutto il ciclo di vita del token analizzando nel dettaglio la risposta dell’applicazione ad ogni specifica funzionalità prevista, anche sottoponendo input non prevedibili (fuzzing) per isolare eventuali comportamenti anomali da cui derivi esfiltrazione non voluta del token di sessione;
- evitare l’utilizzo di token statici, non consentire la funzione “Ricordami” e prevedere un pulsante di logout sempre visibile;
- evitare sessioni multiple;
- effettuare test di vulnerabilità sull’applicazione, specie con riguardo alla minacci del Cross Site Scripting (e al CSRF).
