Session Management Corrado Aaron Visaggio Sicurezza delle Reti e dei Sistemi Software A.A. 2012/2013 Session Management 1
intro Il protocollo http è stateless Modello request-response: transazione indipendente Non si può ricordare la storia delle interazioni Sessione: Sequenza di pagine, visitata sullo stesso sito dallo stesso utente con lo stesso browser nella stessa seduta di navigazione, che presentino una consequenzialità logica. Uso delle sessioni: log.-in Carrello della spesa Wish list La sessione si gestisce attraverso i TOKEN / SESSION ID: Token memorizzato in cookies. Token memorizzato in hidden fields (Campi nascosti) nelle Form HTML. Token veicolati come Parametri URL. Session Management: the process of keeping track of a user's activity across sessions of interaction with the web site. Session Management 2
client Prima richiesta Pagina web server Token di sessione memorizzato Pagina + Token Richiesta successiva + token Utente Riconosciuto Pagina Session Management 3
COOKIE Risposta Richiesta HTTP (Solo dell utente successiva header) dell utente: di una server: pagina: HTTP/1.1 GET http://www.jobonline.it/aziende/aziende.php?id=servizi 200 OK HTTP/1.1 HTTP/1.1 Date: Host: HUwww.jobonline.itUH Sat, 23 Aug 2008 15:11:02 GMT User-Agent: Server: Apache Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.0.1) X-Powered-By: Gecko/2008070208 Firefox/3.0.1 Paros/3.2.13 PHP/5.2.0-8+etch11 Firefox/3.0.1 Paros/3.2.13 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Set-Cookie: PHPSESSID=8fda85921fd31588485b9f27189afce7; path=/ Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Expires: Thu, 19 Nov 1981 08:52:00 GMT Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Cache-Control: Keep-Alive: 300 no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: Proxy-Connection: no-cache keep-alive Content-Type: text/html; charset=iso-8859-1 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.0.1) Gecko/2008070208 Cookie: PHPSESSID=8fda85921fd31588485b9f27189afce7 Session Management 4
Hidden Field il token di sessione viene continuamente inviato e ricevuto dal server sotto forma di campi nascosti presenti all interno delle FORM. il metodo di invio dei dati di tipo POST, così che le informazioni di sessione risultano veicolate nel corpo dei messaggi HTTP 1 Messaggio di Richiesta HTTP per il login alla posta elettronica di aruba: POST HUhttp://webmaildomini.aruba.it/cgibin/webmail.cgi HTTP/1.1UH Host: webmaildomini.aruba.it User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Paros/3.2.13 Accept: text/html,application/xhtml+xml,application/ xml;q=0.9,*/*;q=0.8 Accept-Language: it-it,it;q=0.8,enus;q=0.5,en;q=0.3 Accept-Charset: ISO-8859-1,utf- 8;q=0.7,*;q=0.7 Keep-Alive: 300 Proxy-Connection: keep-alive Referer: HUhttp://webmaildomini.aruba.it/cgibin/webmail.cgiUH Cookie: webmail_lang=italiano; webmail_tpl=surge _none_; webmail_cookie=works Content-Type: application/x-www-formurlencoded Content-Length: 182 cmd=login&tcode=62379693705&frames=true&emai l=&on_error=show&err_page=login.tpl&gmt_mins =120&user=test%40drmita.com&pass=test&select ed_tpl=surge+_none_&_tpl_lang=italiano&login =Login Session Management 5
2 Messaggio di Risposta HTTP per il login alla posta elettronica di aruba: HTTP/1.1 200 OK Date: Sun, 17 Aug 2008 14:51:32 GMT Server: Apache/2.2.3 (CentOS) Set-Cookie: webmail_lang=italiano; expires="wed, 17-Sep-2008 14:51:32 GMT"; domain=webmaildomini.aruba.it Set-Cookie: webmail_tpl=surge _none_; expires="wed, 17-Sep-2008 14:51:32 GMT"; domain=webmaildomini.aruba.it Set-Cookie: webmail_key=; expires="thu, 1-Jan-1970 01:00:00 GMT"; domain=webmaildomini.aruba.it Set-Cookie: webmail_rnd=; expires="thu, 1-Jan-1970 01:00:00 GMT"; domain=webmaildomini.aruba.it Set-Cookie: webmail_tpl=surge _none_; expires="wed, 17-Sep-2008 14:51:35 GMT"; domain=webmaildomini.aruba.it Set-Cookie: webmail_user=; expires="thu, 1-Jan-1970 01:00:00 GMT"; domain=webmaildomini.aruba.it Set-Cookie: webmail_code=; expires="thu, 1-Jan-1970 01:00:00 GMT"; domain=webmaildomini.aruba.it Connection: close Content-Type: text/html Nel codice della pagina è presente questo frammento: <form name="leftnav" method="post" action="/cgi-bin/webmail.cgi"> <input type="hidden" name="utoken" value="test!40drmita.com!40localhost!3a143_!7e2-89d473cb5278ad210ee400_0"> <input type="hidden" name="get_attach_id" value="true"> <input type="hidden" name="force_connection" value="true"> Hidden Field 3 Messaggio di Richiesta HTTP successiva: POST HUhttp://webmaildomini.aruba.it/cgi-bin/webmail.cgi HTTP/1.1UH Host: webmaildomini.aruba.it User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Paros/3.2.13 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q= 0.8 Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Proxy-Connection: keep-alive Referer: HUhttp://webmaildomini.aruba.it/cgibin/webmail.cgiUH Cookie: webmail_lang=italiano; webmail_tpl=surge _none_; webmail_cookie=works Content-Type: application/x-www-form-urlencoded Content-Length: 159 utoken=test%2140drmita.com%2140localhost%213a143_%217e2-89d473cb5278ad210ee400_0&get_attach_id=true&force_connecti on=true&gmt_mins=120&msg_new=nuovo+messaggio+ Session Management 6
1 Parametro URL Con questo metodo il token di sessione viene veicolato attraverso uno o più parametri URL. http://elearning.moe.gov.eg/siteroots /main/user/homepage.jhtml?dmy=1219403 037108&sessionid=1219403024328344019 Messaggio di Richiesta HTTP della pagina principale del sito: GET http://elearning.moe.gov.eg/siteroots/main/index.jhtml HTTP/1.1 Host: elearning.moe.gov.eg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Paros/3.2.13 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Proxy-Connection: keep-alive Cookie: DisplayLocale=en_US 2 Messaggio di Risposta HTTP della pagina principale del sito: HTTP/1.1 200 OK Connection: close Expires: -1 Date: Fri, 22 Aug 2008 11:03:44 GMT Content-Type: text/html;charset=utf-8 Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET Pragma: no-cache Cache-control: max-age=0,must-revalidate,no-store <a href="javascript:openwindow('http://elearning.moe.gov.eg/main/sys temcheck/launchsystemcheck.jhtml?in=0&sessionid=1219403024328 344019','SystemCheck','toolbar=yes,location=no,directories=no,menu bar=no,scrollbars=yes,resizable=yes,width=800,height=600')" name=syscheck class='topnav' onmouseover="window.status='';return true" onmouseout="window.status=''">system Check</a> <a href="http://elearning.moe.gov.eg/siteroots/main/public/events.jsp?d omain=/&sessionid=1219403024328344019" class='leftnav' onmouseover="window.status='public Events';return true" onmouseout="window.status=''">public Events</a> Session Management 7
Parametro URL 3 Messaggio di Richiesta HTTP successiva: GET HUhttp://elearning.moe.gov.eg/SiteRoots/main/eMeeting/AttendMeeting.jsp?sessionid=1219403024328344019UH HTTP/1.1 Host: elearning.moe.gov.eg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Paros/3.2.13 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Proxy-Connection: keep-alive Referer: HUhttp://elearning.moe.gov.eg/SiteRoots/main/User/Homepage.jhtml?dmy=1219403041092&sessionid=1219403024328344019UH Cookie: DisplayLocale=en_US Session Management 8
Alternative Autenticazione HTTP Con l autenticazione HTTP, il client interagisce con il meccanismo di autenticazione direttamente via browser, usando header HTTP, e non attraverso il codice delle pagine dell applicazione web. Meccanismi SessionLess trasmettono tutti i dati richiesti per gestire lo stato attraverso il client, spesso in un cookie oppure in un campo nascosto. E una pratica abbastanza pericolosa dato che ad ogni richiesta non viene trasmesso solo un token di sessione privo di informazioni riconoscibili (spesso un numero o una sequenza di caratteri incomprensibili), ma tutta una serie di informazioni che possono spaziare dalle credenziali dell utente, agli oggetti nel carrello per un applicazione di e- commerce, fino ai dati delle carte di credito. Session Management 9
Punti di debolezza nella generazione Token con informazioni Alcuni token di sessione sono creati usando una trasformazione di informazioni dell utente al quale il token è assegnato, come la username oppure l indirizzo email. 757365723d6c6f7279733b6170703d61646d696e 3b646174653d30392f30392f3038 Ipotizzando che la stringa sia la codifica in esadecimale di una stringa ASCII, è possibile decodificarla per ottenere: user=lorys;app=admin;date=09/09/08 Schemi di codifica XOR Base64 Rappresentazioni esadecimale di caratteri ASCII Username dell account Identificatore numerico usato dall applicazione per distinguere gli account Il nome/cognome dell utente L email dell utente Il gruppo dell utente o il ruolo nell applicazione Data/Ora Numero incrementale o predicibile L indirizzo IP dell utente Session Management 10
Punti di debolezza nella generazione Token predicibili Randomness : an event is random if one couldn't predict that the event would occur. Nel caso più semplice di vulnerabilità, un applicazione può usare un numero sequenziale come token di sessione. Sequenze nascoste Dipendenze dal tempo Generazione dei numeri random debole lwjvja Ls3Ajg xpkr+a XleXYg 9hyCzA jefung JaZZoA --Õ$ 9708D524.ÍÀŽ 2ECDC08E Æ «ø C692ABF8 base64 ^W-b hex 5E579762 Bi-bi-1 ö Ì F61C82CC?án6 8DE16E36 % Y 25A659A0 FF97C4EB6A 97C4EB6A FF97C4EB6A 97C4EB6A FF97C4EB6A FF97C4EB6A il token viene generato aggiungendo 0x97C4EB6A al valore precedente, troncando il risultato ad un numero di 32 bit, e codificando in Base64 questo dato binario, in modo da essere trasmesso usando il protocollo HTTP. Session Management 11
Punti di debolezza nella generazione Dipendenze dal tempo token=f(tempo_generazione) 3124538-1172764258718 3124539-1172764259062 3124540-1172764259281 3124541-1172764259734 3124542-1172764260046 3124543-1172764260156 3124544-1172764260296 3124545-1172764260421 3124546-1172764260812 3124547-1172764260890 Bi-bi-1 344 219 453 312 110 140 125 391 78 new 3124553-1172764800468 3124554-1172764800609 3124555-1172764801109 3124556-1172764801406 3124557-1172764801703 3124558-1172764802125 3124559-1172764802500 3124560-1172764802656 3124561-1172764803125 3124562-1172764803562 La prima sequenza numerica continua ad essere incrementale. La seconda sequenza numerica continua ad incrementarsi con più o meno gli stessi intervalli della sequenza precedente. Il primo valore della seconda sequenza differisce però dall ultimo della prima sequenza di 539.578. il tempo di delay di 10 minuti tra la cattura della prima e della seconda sequenza ha portato allo scarto di 539.578 tra i valori. Ciò fa pensare che il secondo numero sia semplicemente il valore in millisecondi del tempo di generazione. Session Management 12
Punti di debolezza nella generazione Pseudo-Random Number Generator (PRNG). Entropy : a measure of randomness. In information theory, entropy is a direct measurement of the amount of information in a signal in other words, the minimum number of bits that can possibly be used to encode it. Server Jetty synchronized protected int next(int bits) { seed = (seed * 0x5DEECE66DL + 0xBL) & ((1L << 48) - 1); return (int)(seed >>> (48 - bits)); } l output della scheda audio (che presenta sempre variazioni anche minime), il numero di click del mouse, e altre fonti che usate insieme aumentano l entropia del numero finale generato. Session Management 13
Punti di debolezza nella gestione Token intercettabili sulla rete: L attacker per poter ascoltare la comunicazione deve posizionarsi in determinati sistemi, e tali sistemi includono: la rete locale dell utente da attaccare, ISP dell utente, Internet backbone, interno dell ISP dell applicazione e interno del dipartimento IT dell organizzazione che ospita (host) l applicazione. Nel caso più semplice, quando un applicazione usa una connessione HTTP non criptata Session Management 14
Punti di debolezza nella gestione Alcune applicazioni usano connessioni criptate (HTTPS) per proteggere le credenziali utente durante la fase di autenticazione, ritornando poi al protocollo non criptato HTTP per tutte le operazioni normali dell applicazione. In questa situazione, l attacker non può intercettare le credenziali dell utente ma può comunque catturare il token di sessione. Alcune applicazioni usano HTTP per aree del sito in cui non è necessaria l autenticazione, come ad esempio, la homepage, per poi usare HTTPS dalla pagina di autenticazione in poi. In molti casi, all utente è assegnato un token di sessione già dalla prima pagina del sito, prima dell autenticazione, e tale token non è modificato quando l utente si autentica. Anche se l applicazione genera un nuovo token dopo il login, e il protocollo HTTPS viene usato solo in area protetta, è possibile lo stesso intercettare il token di sessione, nel caso in cui l utente visita, dopo l autenticazione, una pagina al di fuori dell area protetta, dove viene usato solo il protocollo HTTP. L applicazione può usare il protocollo HTTPS per tutto il sito oppure solo per la parte di area protetta. Però alcune applicazioni rendono possibile ancora accettare connessioni su HTTP, se l utente modifica l URL. Se un attacker induce un utente ad effettuare una richiesta su HTTP, allora il token può essere intercettato. L attacker può spedire all utente un URL in un email, o in un messaggio di un programma di instant messaging, piazzando dei link che si attivano automaticamente, o banner pubblicitari. Alcune applicazioni usano HTTP per tutti i contenuti statici come immagini, script, CSS. Se ciò avviene, l attacker può catturare il token di sessione attraverso queste richieste non criptate. Session Management 15
Punti di debolezza nella gestione Token Intercettabili nei file di log Molte applicazioni forniscono ad amministratori e altro personale di supporto, funzionalità di monitoraggio e di controllo dello stato dell applicazione, inclusi le sessioni dell utente. Spesso i file di log contengono le URL delle pagine visitate dall utente. In più, anche se sono usate richieste POST per trasmettere il token di sessione (Hidden Field), è possibile che l applicazione accetti il metodo GET anche per richieste di tipo POST, e quindi inviare il token come parametro URL. Log del browser Log del server web Log nei server proxy di ISP o dell azienda Log in ogni server proxy usato nella rete del fornitore del servizio di hosting sul quale è collocata l applicazione Referer Log di ogni server che l utente visita seguendo un link che porta fuori dal sito dove è situata l applicazione web. Session Management 16
Punti di debolezza nella gestione Token intercettabili dalla cache Nelle cache è possibile memorizzare l intera pagina e l header di risposta, e un attacker che ha accesso a queste informazioni, può intercettare i token di sessione. In alcune applicazioni web non sono utilizzate direttive di caching restrittive nelle risposte HTTP, come ad esempio l header Cache-Control: no cache, permettendo dunque il caching delle pagine. Spesso viene usato l header Cache- Control: private che non permette il caching sui sistemi esterni (es. proxy esterni), ma abilita comunque la cache sul computer dell utente, e, nel caso di computer condivisi da più utenti (ad esempio, un internet point), è possibile per un attacker leggere i token di sessione dalla cache. Session Management 17
Punti di debolezza nella gestione Mapping vunerabile dei token con le sessioni La vulnerabilità più semplice è quella di permettere che vengano assegnati token validi multipli allo stesso utente. uso da parte dell applicazione di token statici. Applicazioni che usano la funzione «remeber me» Session Management 18
Punti di debolezza nella gestione Terminazione di sessione vulnerabile Garantire che la durata di vita di una sessione sia la più breve possibile Alcune applicazioni non implementano nessuna tecnica per far scadere la sessione. attacchi di Guessing del token di sessione, dove per indovinare un token valido è necessario provare un numero elevato di valori ma comunque realistico (nell ordine dei 100.000 tentativi per ogni token valido). 1) la funzionalità non è implementata. 2) la funzionalità di logout non fa invalidare la sessione al server. Il server rimuove il token dal browser dell utente ma se l utente continua a inviare il token precedente, viene ancora accettato dal server. 3) Quando un utente usa la funzionalità di logout, non è effettuata alcuna richiesta al server, e quindi il server non esegue nessuna azione per invalidare la sessione. Uno script client-side è usato per rimuovere il cookie di sessione. Se un attacker ottiene questo cookie può usare la sessione come se l utente non si è mai disconnesso. Session Management 19
Punti di debolezza nella gestione Cookie Vulnerabile Flag: Ci sono due flag che è possibile impostare in un cookie e sono Secure e HTTPOnly. Se un cookie non ha il flag Secure esso verrà inviato su tutti i tipi di connessioni, criptate e non, quindi, se l applicazione web utilizza HTTPS ma il cookie non ha il flag secure, il cookie può essere trasmesso non criptato nel caso in cui magari l applicazione permette l uso di HTTP al posto di HTTPS. Se un cookie non ha il flag HTTPOnly è possibile leggerlo attraverso attacchi di cross-site scripting. Tuttavia, non tutti i browser supportano tale flag. Session Management 20
Punti di debolezza nella gestione Cookie Vulnerabile Quando un applicazione installata, ad esempio, sul dominio exp.testsite.com invia un cookie, il browser per default invierà il cookie per tutte le richieste seguenti al dominio exp.testsite.com e anche ad ogni sottodominio, ad esempio user.exp.testsite.com. Non invierà invece il cookie per ogni altro sottodominio del parente testsite.com, come beg.testite.com. Un server può aggirare questo comportamento includendo un attributo domain nell header Set-Cookie. Ad esempio, supponiamo che l applicazione a exp.testsite.com ritorna il seguente header http: Set-Cookie: sessionid=12363437; domain=testsite.com; Il browser rispedirà questo cookie per tutti i sottodomini di testsite.com, anche beg.testsite.com. Session Management 21
Punti di debolezza nella gestione Cookie vulnerabile: Restrizioni di Path Quando un applicazione risiede in /app/testapp/index.jsp e imposta un cookie, il browser invierà il cookie per tutte le richieste nel path /app/testapp/, e anche nelle sottodirectory. Non invierà il cookie per la directory progenitrice o ogni altra directory che esiste sul server. Così come accade per il dominio del cookie, un server può aggirare il comportamento standard, includendo l attributo path nell header Set-Cookie. Per esempio se l applicazione ritorna il seguente header HTTP: Set-Cookie: sessionid=12363437; path=/app/; il browser restituirà il cookie per tutte le richieste nelle sottodirectory di /apps/. E molto comune incontrare delle applicazioni che impostano lo scope del path dei loro cookie al root del server web. In questa situazione se sul server ci sono diverse applicazioni, il cookie verrà inviato per ogni applicazione presente sul server. Si andrà incontro agli stessi problemi di vulnerabilità incontrati nel caso del dominio del cookie. Session Management 22
Attacchi: Session Sniffing Il Session Sniffing è l attività di intercettamento delle informazioni di sessione degli utenti collegati ad una applicazione web. L intercettazione si può effettuare sfruttando: vulnerabilità dell applicazione web (trasmissione non criptata, direttive di caching non restrittive, uso di token come parametri URL, ecc.) falle di sicurezza nelle infrastrutture attraverso la quali transita l interazione utenteapplicazione web (proxy, gateway, ecc.) Posizionamento strategico nella rete (rete locale dell utente, rete dell applicazione web) Le tecniche di attacco più diffuse sono: HTTP Packet Sniffing Log Sniffing Cache Sniffing XSS Cookie Sniffing Session Management 23
Attacchi: Session Sniffing Packet Sniffing Questa tecnica di attacco mira ad intercettare i pacchetti HTTP che transitano sulla rete nell interazione tra un utente e il server web allo scopo di intercettare i token di sessione all interno dei pacchetti HTTP. Le funzioni tipiche degli sniffer : filtraggio e conversione dei dati e dei pacchetti in una forma leggibile dall'utente analisi dei difetti di rete analisi di qualità e portata della rete (performance analisys) setacciamento automatizzato di password e nomi di utenti (in chiaro o, più spesso, cifrati) per successiva analisi creazione di log, lunghi elenchi che contengono la traccia, in questo caso, del traffico sulla rete scoperta di intrusioni in rete attraverso analisi dei log del traffico Session Management 24
Attacchi: Session Sniffing Analizzare le varie pagine dell applicazione web per vedere quali usano protocolli non criptati (HTTP) e quali protocolli criptati (HTTPS). Ovviamente se tutto il sito usa HTTP lo sniffing è possibile sempre. Se sono usati cookie HTTP per trasmettere i token di sessione, si verifica se il flag secure è utilizzato. Se non viene utilizzato il token può essere trasmesso su connessioni non criptate e quindi può essere catturato dallo sniffer. Se l applicazione usa HTTP per la pagina principale e poi usa HTTPS per il login e la parte protetta, si verifica se un nuovo token è creato dopo l autenticazione, altrimenti il token creato prima dell autenticazione può essere intercettato dato che il sito usa HTTP per la parte non protetta. Controllare se l applicazione accetta richieste usando HTTP per le pagine protette da HTTPS. Se ciò avviene si può intercettare il token di sessione. L attacker, infine, conduce l attacco seguendo questi passi: 1)Analizza l applicazione web alla ricerca di vulnerabilità tali da abilitare l attacco. 2) Ottiene l accesso alla rete locale dell utente o dell organizzazione. 3) Installa lo sniffer su una macchina e sfrutta tutte le possibili vulnerabilità per ascoltare il traffico dell intera rete con la sua macchina. 4) Analizza il traffico alla ricerca di token di sessione degli utenti. 5) Effettua una richiesta HTTP all applicazione web con il token di sessione catturato ed ottiene l accesso alla sessione dell utente. Session Management 25
Attacchi: Log sniffing intercettare i token di sessione attraverso l analisi dei file di log di vari sistemi presenti nella comunicazione tra client e server. Identificare il modo in cui viene trasmesso il token di sessione. Se viene trasmesso come parametro URL c è la possibilità che venga registrato nei file di log di diversi sistemi. Verificare, nel caso in cui il token viene trasmesso tramite campo nascosto, se c è la possibilità di far accettare al server richieste col metodo GET per quelle pagine che utilizzano il metodo POST. Tramite uno script client-side, è possibile effettuare questo cambio di metodo e così il token di sessione verrà inviato come parametro URL e sarà possibile leggerlo tramite i file di log. 1)Analizzare l applicazione web alla ricerca di vulnerabilità tali da abilitare l attacco. 2)Sfruttare tutte le possibili vulnerabilità per accedere ai file di log dei sistemi presenti nella comunicazione client/server. 3) Analizzare il file di log alla ricerca di token di sessione degli utenti. 4) Effettuare una richiesta HTTP all applicazione web con il token di sessione catturato ed ottenere l accesso alla sessione dell utente. Session Management 26
Attacchi: Cache Sniffing I più comuni sistemi che implementano la cache web sono i browser e i proxy. Se non sono presenti direttive come: Expires:0 Cache-control: max-age=0 oppure Cache-Control: no-cache Allora il caching delle pagine è abilitato e quindi l attacco è possibile. Nel caso in cui c è la direttiva Cache- Control: private la cache è abilitata solo sulla macchina dove è presente l utente e quindi ci possono essere dei rischi nel caso di macchine condivise (internet cafè). Anche nel caso di una macchina usata da un singolo utente, ci possono essere dei rischi, se l attacker riesce ad ottenere l accesso al file-system dove la cache è situata. 1)Analizzare l applicazione web alla ricerca di vulnerabilità tali da abilitare l attacco. 2)Sfruttare tutte le possibili vulnerabilità per accedere alla cache dei sistemi presenti nella comunicazione client/server. 3)Analizzare il contenuto della cache alla ricerca di token di sessione degli utenti. 4) Effettuare una richiesta HTTP all applicazione web con il token di sessione catturato ed ottenere l accesso alla sessione dell utente. Session Management 27
Attacchi: XSS Cookie Sniffing Cross-Site Scripting: Cross-Site Scripting (XSS) is an attack technique that forces a Web site to echo attacker-supplied executable malicious code, which loads in a user s browser. Cattura dei token di sessione Session Management 28
Attacchi: L attacker controlla la presenza delle seguenti vulnerabilità: attraverso software di analisi automatica, oppure mediante sperimentazione manuale, la presenza della vulnerabilità XSS. la presenza del flag HTTPOnly. Se non è presente, è possibile leggere il cookie tramite XSS. XSS Cookie Sniffing 1)Analizzare l applicazione web alla ricerca di vulnerabilità tali da abilitare l attacco. 2)Inserire uno script sfruttando l XSS Injection nell applicazione web, in maniera persistente se è possibile, oppure costringendo l utente a cliccare su un link appositamente modificato ed inviato all utente in vari modi (email, instant messanger). Lo script invierà il cookie all attacker. 3)Effettuare una richiesta HTTP all applicazione web con il token di sessione catturato ed ottenere l accesso alla sessione dell utente. Session Management 29
Session Prediction: Manipolazione del token se il token di sessione contiene una serie di informazioni sull utente autenticato o sulla natura della sessione, sequenze nascoste, dipendenze del tempo o algoritmi di PRNG deboli, è più facile per un attacker capire la struttura del token e manipolarlo per ottenere non solo l accesso all utente corrente autenticato, ma anche agli altri utenti autenticati. I passi che un attacker deve compiere per poter effettuare questo attacco sono i seguenti: 1) Creare un account presso l applicazione web da attaccare (è possibile farlo usando dati falsi e e- mail anonime temporanee come http://www.anonymbox.com) 2) Collezionare un numero considerevole di token di sessione. 3) Analizzare i token di sessione alla ricerca di informazioni note o pattern predicibili, e usare dei tool statistici per verificare la randomness. 4) Provare a manipolare il token per ottenere l accesso ad altri account. 5) Effettuare una richiesta HTTP all applicazione web con il token di sessione manipolato per ottenere l accesso alla sessione dell utente. Session Management 30
Session Prediction: brute force Questo tipo di attacco mira ad indovinare il token di sessione di un utente attivo, semplicemente provando molteplici valori di token di sessione in un lasso di tempo breve. Riescono ad individuare una serie di informazioni sui token di sessione: 1) Alfabeto utilizzato per ogni carattere del token di sessione 2) Individuazione dei caratteri che sono troppo rari e quelli che sono troppo comuni in ogni posizione, che potrebbero far pensare ad un certo di tipo di pattern e quindi una certa predicibilità. 3) Frequenza di transizioni tra caratteri della stessa posizione 4) Test statistici per individuare il livello di randomness dei token di sessione Tempo di idle troppo elevato: in questo modo la sessione non scade subito, dando più tempo e quindi più possibilità all attacker di provare combinazioni di token di sessione. Terminazione di sessione vulnerabile: anche qui se la terminazione di sessione non è implementata o è implementata non correttamente, l attacker ha più tempo a disposizione per effettuare l attacco. 1)Creare un account presso l applicazione web da attaccare (è possibile farlo usando dati falsi e e- mail anonime temporanee come http://www.anonymbox.com) 2)Analizzare l applicazione web alla ricerca di vulnerabilità tali da facilitare l attacco. 3)Usare un tool per l analisi dei token di sessione per collezionare un numero considerevole di token di sessione. 4)Usare il suddetto tool per effettuare l analisi di randomness e verificare che si possa condurre un attacco di brute force. 5)Usare dei tool automatici che inviano delle richieste HTTP all applicazione web da attaccare con valori diversi di token di sessione. 6)Aspettare fino a che una risposta sia corretta e si possa entrare nella sessione di un utente collegato. Session Management 31
Session Fixation In un attacco di tipo Session Fixation, l attacker fissa il token di sessione per l utente da attaccare, prima che egli si autentichi all applicazione web, eliminando così il bisogno di ottenere il token di sessione con le tecniche descritte in precedenza Session Management 32
Session Fixation 1 attacker 3 Online.worldbank.com 4 5 victim Session Management 33
Session Fixation Session Setup: L attacker deve creare una sessione sul server ( trap session ) e ricevere un token di sessione, oppure creare un token di sessione arbitrario. In alcuni casi la sessione deve essere mantenuta in vita (Session Maintenance) inviando richieste ad intervalli regolari per far sì che essa non scadi. Session Fixation: L attacker introduce il suo token di sessione nel browser dell utente, fissando la sessione. Session entrance: L attacker aspetta che l utente si autentichi all applicazione web e poi entra nella sessione dell utente Permissive : accetta dei token di sessione arbitrari, e crea una nuova sessione con il token proposto se non esiste ancora (Macromedia JRun server, PHP) L attacker sceglie un token a caso Strict : accetta solo token di sessione conosciuti, che sono stati generati in precedenza (Microsoft IIS). L attacker deve invece stabilire una sessione e mantenerla in vita per tutta la durata dell attacco (Session Maintenance). Session Management 34
Session Fixation Se è usato un parametro URL allora l attacker deve costringere l utente a cliccare su un link creato su misura. Se il token è trasmesso in un hidden field, l attacker deve cercare di sfruttare la vulnerabilità XSS (se è presente) per costruire un form di login che abbia il token di sessione scelto. Se il token è trasmesso in un cookie: Usare un script client-side che imposta il cookie nel browser. Usare il tag HTML <META> con l attributo Set-Cookie. Usare l header di risposta HTTP Set- Cookie. Per far sì che si possa utilizzare questo attacco è necessario controllare la presenza di alcune vulnerabilità dell applicazione web: 1)Controllare se, al momento dell autenticazione, viene creato un nuovo token di sessione. In caso contrario è possibile effettuare attacchi di session fixation. 2)Controllare se è possibile creare una sessione utilizzando un token di sessione arbitrario. Se è possibile il sistema è più facilmente attaccabile usando session fixation. Session Management 35
Cross Site Il Cross-Site Request Forgery (CSRF) è un attacco che consiste nel costringere l utente ad eseguire azioni non volute su una applicazione web nella quale è autenticato Request Forgery Con questo scenario un attacker che riesce a scoprire il modo in cui funziona l applicazione web, potrebbe creare un email con il link di cui sopra e costringere l utente a cliccare sul link. Oppure ancora l attacker potrebbe creare un sito trappola inducendo l utente a visitarlo e tramite un redirect effettuare la richiesta. Session Management 36
Cross Site Comportamento del browser riguardante la gestione delle informazioni di sessione come cookie e informazioni di autenticazione HTTP Conoscenza delle URL dell applicazione web da attaccare da parte dell attacker. Session management che si basa solo su informazioni conosciute dal browser. Esistenza di tag HTML la cui presenza causa un immediato accesso ad una risorsa HTTP(S), ad esempio il tag di immagine img. Request Forgery Per il primo punto, l attacco è possibile grazie al comportamento del browser che invia automaticamente le informazioni della sessione al server. In questo modo basta che l utente visiti un link normale, e il browser automaticamente invia il token di sessione e quindi l operazione eseguita da un link è autenticata. Per quanto riguarda il secondo punto, l attacco è possibile se l applicazione non usa informazioni di sessione nell URL, in questo modo è possibile scoprire facilmente parametri e valori legittimi delle URL. Per quanto riguarda il terzo punto, per informazioni conosciute dal browser, si intende informazioni come cookie o autenticazione HTTP (non basata su form), che sono memorizzate nel browser e rispedite ad ogni richiesta delle pagine protette da autenticazione. Session Management 37
HTTP Response Splitting Alcune applicazioni web usano parte dell input dell utente per generare i valori di alcuni header della risposta HTTP. L esempio più significativo è rappresentato dal redirect, che spesso è utilizzato a seconda dell input dell utente. Più in dettaglio, se il parametro interface ha il valore advanced, l applicazione risponderà con la seguente risposta HTTP: HTTP/1.1 302 Moved Temporarily Date: Sun, 03 Dec 2005 16:22:19 GMT Location: http://victim.com/main.jsp?interface=advanced <snip> Quando si riceve questo messaggio, il browser porta l utente alla pagina indicata nell header Location. Se l applicazione non controlla l input dell utente, è possibile inserire nel valore del parametro interface la sequenza %0d%0a, che rappresenta la sequenza CRLF che è usata per separare linee differenti. A questo punto, si può generare una risposta che sarà interpretata come due risposte differenti da qualsiasi sistema possa processarla, come ad esempio una cache web posta tra l utente e l applicazione. Questa vulnerabilità può essere sfruttata da un attacker per fornire contenuti falsi in tutte le richieste successive. Ad esempio, supponiamo che per l esempio precedente, un potenziale attacker inserisce nel parametro interface il valore: advanced%0d%0acontent- Length:%200%0d%0a%0d%0aHTTP/1.1%20200% 20OK%0d%0aContent- Type:%20text/html%0d%0aContent- Length:%2035%0d%0a%0d%0a<html>Sorry,%2 0System%20Down</html> La risposta HTTP dell applicazione che presenta questa vulnerabilità è la seguente: HTTP/1.1 302 Moved TemporarilyDate: Sun, 03 Dec 2005 16:22:19 GMTLocation: http://victim.com/main.jsp?interface=a dvancedcontent-length: 0 HTTP/1.1 200 OKContent-Type: text/htmlcontent- Length: 35 <html>sorry,%20system%20down</html> <other data> Session Management 38
HTTP Response Splitting La cache web vedrà due risposte differenti, così se l attacker spedisce, immediatamente dopo la prima richiesta una seconda chiedendo ad esempio /index.html, la cache web effettuerò il match tra questa richiesta e la seconda risposta e memorizzerà il contenuto, in modo che tutte le richieste successive dirette a http://applicazioneweb.test/index.html che passano per la cache riceveranno il messaggio System Down. Ovviamente il contenuto della seconda risposta è a discrezione dell attacker, può ad esempio creare una risposta con uno script javascript che ruba i cookie dell utente, similmente a quanto accade con l XSS Injection. Gli header candidati a questo tipo di attaccon sono: Location Set-Cookie Session Management 39
Countermeasures Session Management 40
Countermeasures: Generazione dei Token Usare nella generazione dei token una forte sorgente pseudo-random, con algoritmi noti per essere crittograficamente sicuri, assicurando una distribuzione di token ampia e non predicibile lungo tutto il range di valori. Spesso è utile usare più fonti pseudo-random e unirli con un algoritmo di hashing come SHA- 256 per generare un token di lunghezza fissa. Generare token di sessione con un alto range di valori (caratteri alfanumerici, simboli, ecc). Generare dei token con un numero elevato di bit di entropia, in modo da rendere troppo onerosa la conduzione di attacchi di tipo brute force. Non inserire informazioni sull utente in chiaro o codificate con tecniche di offuscamento reversibili (Base64, Hex). Session Management 41
Countermeasures: Generazione dei Token Il token dovrebbe essere trasmesso solo usando HTTPS. Se il token trasmesso in chiaro è possibile condurre attacchi di sniffing. Se i token sono trasmessi usando i cookie, dovrebbero usare il flag secure, impedendo ai cookie stessi di essere trasmessi su HTTP. HTTPS dovrebbe essere utilizzato in tutte le pagine dell applicazione web, anche per contenuti statici come pagine, immagini, ecc. Per le pagine protette da HTTPS non deve essere possibile utilizzare HTTP. I token non dovrebbero mai essere trasmessi esclusivamente come parametri URL, (session fixtion & log sniffing). Se non è possibile usare cookie, meglio usare gli hidden field. Se l applicazione web usa i cookie come mezzo di trasmissione del token di sessione, il dominio e il path del cookie devono essere il più possibile restrittivi per impedire che il token venga inviato per richieste che non riguardino l area protetta dell applicazione web. Può essere necessario delle volte riorganizzare la posizione delle varie applicazioni nei vari domini e nei vari path. La funzionalità di logout dovrebbe essere implementata. Dovrebbe eliminare tutte le risorse di sessione create sul server e invalidare il token di sessione sul client. La sessione dovrebbe avere un tempo di idle timeout abbastanza basso (30 minuti o meno). La scadenza della sessione dovrebbe produrre gli stessi effetti della funzionalità di logout. Non dovrebbe essere possibile effettuare connessioni autenticate da diverse macchine nello stesso momento. Ogni volta che l utente si autentica, la sessione precedente dovrebbe essere invalidata. Dovrebbe essere notificato alla macchina che ha effettuato il login per primo che c è stato un nuovo accesso e che la sessione è invalidata. Session Management 42
Countermeasures: Generazione dei Token I token di sessione non dovrebbero essere trasmessi usando esclusivamente i cookie (attacchi Cross-Site Request Forgery). Sarebbe opportuno usare token di sessione misti, usando cookie e parametri URL (con valori diversi). E opportuno creare ed assegnare il token di sessione solo dopo l autenticazione all applicazione web (session fixation). Se il token viene assegnato prima dell autenticazione, al momento dell autenticazione, un nuovo token dovrebbe essere creato ed assegnato. (session fixation). 1)Eliminare la vulnerabilità Cross Site Scripting Injection, che può essere usata per intercettare i token di sessione. 2)Impedire, se possibile, la possibilità di collegarsi da un altro computer con lo stesso token di sessione assegnato ad un altro utente. Si potrebbe legare l indirizzo IP al token, al momento della creazione, impedendo ad un altro computer con un differente indirizzo IP di usare il token per accedere alla sessione dell utente da attaccare. 3)Evitare di fornire la funzionalità remember me, per evitare che venga di fatto implementato un token statico che permetterebbe ad un attacker di ottenere accesso per lungo termine alla sessione dell utente. Session Management 43
Fine? Session Management 44