Session Management - ISWATlab · Session Management Corrado Aaron Visaggio Sicurezza delle Reti e...

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.”

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.


client server Prima richiesta Pagina web

Pagina + Token Token di sessione memorizzato

Richiesta successiva + token Utente Riconosciuto

Pagina Session Management 3

COOKIE

Richiesta HTTP dell’utente di una pagina: GET http://www.jobonline.it/ HTTP/1.1 Host: www.jobonline.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

Risposta HTTP (Solo header) del server: HTTP/1.1 200 OK Date: Sat, 23 Aug 2008 15:11:02 GMT Server: Apache X-Powered-By: PHP/5.2.0-8+etch11 Set-Cookie: PHPSESSID=8fda85921fd31588485b9f27189afce7; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Content-Type: text/html; charset=ISO-8859-1

Richiesta HTTP successiva dell’utente: GET http://www.jobonline.it/aziende/aziende.php?id=servizi HTTP/1.1 Host: HUwww.jobonline.itUH 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: PHPSESSID=8fda85921fd31588485b9f27189afce7


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/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/cgi-bin/webmail.cgiUH Cookie: webmail_lang=Italiano; webmail_tpl=surge _none_; webmail_cookie=works Content-Type: application/x-www-form-urlencoded Content-Length: 182 cmd=login&tcode=62379693705&frames=true&email=&on_error=show&err_page=login.tpl&gmt_mins=120&user=test%40drmita.com&pass=test&selected_tpl=surge+_none_&_tpl_lang=Italiano&login=Login

1


Hidden Field 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/cgi-bin/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_connection=true&gmt_mins=120&msg_new=Nuovo+Messaggio+

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">

2

3


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=1219403037108&sessionid=1219403024328344019

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/SystemCheck/LaunchSystemCheck.jhtml?in=0&sessionid=1219403024328344019','SystemCheck','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/SiteRoots/main/Public/Events.jsp?domain=/&sessionid=1219403024328344019" class='leftnav' onmouseover="window.status='Public Events';return true" onmouseout="window.status=''">Public Events</a>

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

1

2


Parametro URL

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

3


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.


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.

757365723d6c6f7279733b6170703d61646d696e3b646174653d30392f30392f3038

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



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

--Õ$ .ÍÀŽ Æ’«ø ^W-b ö‚Ì ?án6 %¦Y

9708D524 2ECDC08E C692ABF8 5E579762 F61C82CC 8DE16E36 25A659A0

FF97C4EB6A 97C4EB6A FF97C4EB6A 97C4EB6A FF97C4EB6A FF97C4EB6A

base64 hex Bi-bi-1

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.



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

344 219 453 312 110 140 125 391 78

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.

Bi-bi-1 new



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.” 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.

Server Jetty synchronized protected int next(int bits) { seed = (seed * 0x5DEECE66DL + 0xBL) & ((1L << 48) - 1); return (int)(seed >>> (48 - bits)); }


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


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.


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.



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.



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»



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.



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.



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.


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.


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 utente-applicazione 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


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


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.


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.


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.


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


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 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.


http://www.anonymbox.com/

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 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 Fixation

victim

Online.worldbank.com attacker

1

3

4 5


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 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.


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.


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.


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,%20System%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=advancedContent-Length: 0 HTTP/1.1 200 OKContent-Type: text/htmlContent-Length: 35 <html>Sorry,%20System%20Down</html><other data>


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


Countermeasures


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).



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.



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.


Fine?


Session Management - ISWATlab · Session Management Corrado Aaron Visaggio Sicurezza delle Reti e...

Documents

Transcript of Session Management - ISWATlab · Session Management Corrado Aaron Visaggio Sicurezza delle Reti e...