Session Management Corrado Aaron Visaggio Sicurezza delle Reti

Session Management Corrado Aaron Visaggio Sicurezza delle Reti e dei Sistemi Software A. A. 2012/2013 Session Management 1

Session Management 2

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. ” § Session Management: “the process of keeping track of a user's activity across sessions of interaction with the web site. ” 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. https: //www. owasp. org/index. php/Top_10_2013 -Top_10 Session Management 3

client Token di sessione memorizzato Prima richiesta Pagina web server Pagina + Token Richiesta successiva + token Utente Riconosciuto Pagina Session Management 4

COOKIE Richiesta HTTP(Solo successiva dell’utente: dell’utente didel unaserver pagina: Risposta HTTP header) : GET http: //www. jobonline. it/aziende. php? id=servizi HTTP/1. 1 GET http: //www. jobonline. it/ HTTP/1. 1 200 OK Host: HUwww. jobonline. it. UH Host: www. jobonline. it Date: Sat, 23 Aug 2008 15: 11: 02 GMT User-Agent: Mozilla/5. 0 (Windows; U; Windows NT 5. 1; it; rv: 1. 9. 0. 1) Gecko/2008070208 User-Agent: Mozilla/5. 0 (Windows; U; Windows NT 5. 1; it; rv: 1. 9. 0. 1) Server: Apache Firefox/3. 0. 1 Paros/3. 2. 13 Gecko/2008070208 Firefox/3. 0. 1 Paros/3. 2. 13 X-Powered-By: PHP/5. 2. 0 -8+etch 11 Accept: text/html, application/xhtml+xml, application/xml; q=0. 9, */*; q=0. 8 Set-Cookie: PHPSESSID=8 fda 85921 fd 31588485 b 9 f 27189 afce 7 ; 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: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Keep-Alive: 300 Pragma: no-cache Proxy-Connection: keep-alive Content-Type: text/html; charset=ISO-8859 -1 Cookie: PHPSESSID=8 fda 85921 fd 31588485 b 9 f 27189 afce 7 http: //hexillion. com/asp/samples/Asp. Tcp. Query. asp Session Management 5

1 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 Messaggio di Richiesta HTTP per il login alla posta elettronica di aruba: POST HUhttp: //webmaildomini. aruba. it/cgibin/webmail. cgi HTTP/1. 1 UH 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. cgi. UH 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%40 drmita. com&pass=test&select ed_tpl=surge+_none_&_tpl_lang=Italiano&login =Login Session Management 6

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 (Cent. OS) 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 GMT"; domain=webmaildomini. aruba. it Set-Cookie: webmail_rnd=; expires="Thu, 1 -Jan-1970 01: 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 GMT"; domain=webmaildomini. aruba. it Set-Cookie: webmail_code=; expires="Thu, 1 -Jan-1970 01: 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!40 drmita. com!40 localhost!3 A 143_!7 E 289 d 473 cb 5278 ad 210 ee 400_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. 1 UH 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. cgi. UH Cookie: webmail_lang=Italiano; webmail_tpl=surge _none_; webmail_cookie=works Content-Type: application/x-www-form-urlencoded Content-Length: 159 utoken=test%2140 drmita. com%2140 localhost%213 A 143_%217 E 289 d 473 cb 5278 ad 210 ee 400_0&get_attach_id=true&force_connecti on=true&gmt_mins=120&msg_new=Nuovo+Messaggio+ Session Management 7

Parametro URL § Con questo metodo il token di sessione viene veicolato attraverso uno o più parametri URL. http: //elearning. moe. gov. eg/Site. Roots /main/User/Homepage. jhtml? dmy=1219403 037108&sessionid=1219403024328344019 1 Messaggio di Richiesta HTTP della pagina principale del sito: GET http: //elearning. moe. gov. eg/Site. Roots/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: Display. Locale=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: open. Window('http: //elearning. moe. gov. eg/main/Syste m. Check/Launch. System. Check. jhtml? in=0&sessionid=121940302432834 4019', 'System. Check', 'toolbar=yes, location=no, directories=no, menubar= 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/Site. Roots/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 8

Parametro URL 3 Messaggio di Richiesta HTTP successiva: GET HUhttp: //elearning. moe. gov. eg/Site. Roots/main/e. Meeting/Attend. Meeting. jsp? sessionid=1219403024328344019 UH 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/Site. Roots/main/User/Homepage. jhtml? dmy=1219403041092&sessionid=1219403024328344019 UH Cookie: Display. Locale=en_US Session Management 9

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 Session. Less § 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 § Non usa token di sessione § ad ogni richiesta vengono trasmesse tutte le informazioni. Credenziali Carrello Dati acquisto Session Management 10

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. 757365723 d 6 c 6 f 7279733 b 6170703 d 61646 d 696 e 3 b 646174653 d 30392 f 3038 § 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 § • • 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 Schemi di codifica § XOR § Base 64 § Rappresentazioni esadecimale di caratteri ASCII Session Management 11

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. lwj. VJA Ls 3 Ajg xp. Kr+A Xle. XYg 9 hy. Cz. A je. Fu. Ng Ja. ZZo. A § Sequenze nascoste § Dipendenze dal tempo § Generazione dei numeri random debole base 64 --Õ$. ÍÀŽ Æ’ «ø ^W-b ö‚Ì ? án 6 %¦Y hex 9708 D 524 2 ECDC 08 E C 692 ABF 8 5 E 579762 F 61 C 82 CC 8 DE 16 E 36 25 A 659 A 0 Bi-bi-1 FF 97 C 4 EB 6 A FF 97 C 4 EB 6 A il token viene generato aggiungendo 0 x 97 C 4 EB 6 A al valore precedente, troncando il risultato ad un numero di 32 bit, e codificando in Base 64 questo dato binario, in modo da essere trasmesso usando il protocollo HTTP. Session Management 12

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 13

Punti di debolezza nella generazione § Pseudo-Random Number Generator (PRNG). Server Jetty 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. ” § 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. synchronized protected int next(int bits) { seed = (seed * 0 x 5 DEECE 66 DL + 0 x. BL) & ((1 L << 48) - 1); return (int)(seed >>> (48 - bits)); } Session Management 14

Punti di debolezza nella gestione Token intercettabili sulla rete: § § L’attacker 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 15

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. STESSO TOKEN - Autenticazione in https il resto in http § 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. STESSO TOKEN- Aree in https ma stesso token già prima dell’autenticazione § 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. NUOVO TOKEN dopo autenticazione ma utente ritorna in aree http Forzare ad http aree https http per contenuti statici Session Management 16

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 17

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 18

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 «remember me» Session Management 19

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. § 1) 2) la funzionalità non è implementata. 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. 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). Session Management 20

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 21

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: session. ID=12363437; domain=testsite. com; § Il browser rispedirà questo cookie per tutti i sottodomini di testsite. com, anche beg. testsite. com. Session Management 22

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: session. ID=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 23

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 24

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 25

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 26

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. § 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. 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. Session Management 27

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 28

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 29

Attacchi: XSS Cookie Sniffing § 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. 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 30

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 email 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 31

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 email 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 32

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 33

Session Fixation 1 login session. Id=1234 attacker 6 3 2 GET/account. jsp? session. Id=1234 http =12 : //onli ne. w 34 Online. worldbank. com ork b ank . com /log in. js 4 23 1 = Id p? s s p? essi on. Id a T/ GE 4 js nt. u cco & me pa rd o ssw a rn e Us n sio es 5 victim Session Management 34

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 35

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 36

Cross Site Request Forgery § 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 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 37

Cross Site Request Forgery § 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. 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 38

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 %0 d%0 a, 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%0 d%0 a. Content. Length: %200%0 d%0 a. HTTP/1. 1%20200% 20 OK%0 d%0 a. Content. Type: %20 text/html%0 d%0 a. Content. Length: %2035%0 d%0 a<html>Sorry, %2 0 System%20 Down</html> La risposta HTTP dell’applicazione che presenta questa vulnerabilità è la seguente: HTTP/1. 1 302 Moved Temporarily. Date: Sun, 03 Dec 2005 16: 22: 19 GMTLocation: http: //victim. com/main. jsp? interface=a dvanced. Content-Length: 0 HTTP/1. 1 200 OKContent-Type: text/html. Content. Length: 35 <html>Sorry, %20 System%20 Down</html> <other data> Session Management 39

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 40

Countermeasures Session Management 41

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 (Base 64, Hex). Session Management 42

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. § 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. Può essere necessario delle volte riorganizzare la posizione delle varie applicazioni nei vari domini e nei vari path. Session Management 43

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 44

Fine? Session Management 45