PDA

View Full Version : http only cookies, XST (Cross site tracing), varie :D


Sisupoika
22-05-2009, 20:38
Visto che
- e' stato tirato in ballo (riferimenti a http only cookies nelle "regole d'oro" per gli sviluppatori nell'altro thread, assieme all'intervento di riazzituoi)
- e' venerdi'
- adesso sono a casa e ho una mezz'ora libera prima di preparare una cenetta per la mia mogliettina che presto tornera' dal suo turno in ospedale

:D

parliamo un po' di questi benedetti cookies "http only" (brevemente perche' ho non molto tempo, poi magari possiamo approfondire in seguito o linkare qualche doc etc).


Immagini di repertorio: ( :asd: )

http://blog.calgarypubliclibrary.com/blogs/food/great_chocolatechip_cookies%20photo%20Laura.jpg http://ajax.theoffside.com/files/2008/08/306px-ajax_amsterdam_svg.pnghttp://www.scottkleper.com/blog/ajax.jpg




Premessa: come si e' visto nell'altro thread (http://www.hwupgrade.it/forum/showthread.php?t=1987141), e in svariate altre occasioni, i cookies (http://en.wikipedia.org/wiki/HTTP_cookie), quando non ci si riferisce ai biscotti, sono qualcosa spesso frainteso (molti utenti inesperti, ancora oggi, pensano che cookie sia sinonimo di spyware, virus, o quant'altro).
E molto spesso i cookie finiscono al centro dell'attenzione per l'una o l'altra vulnerabilita' di questo o quell'altro sito.

Il motivo e' semplice: i cookies sono - tristemente, come si vedra' in seguito - alla base, in un certo senso il "cuore", dei sistemi di autenticazione utilizzati dalla stragrande maggioranza dei siti Internet e, purtroppo per gli utenti della rete, la stragrande maggioranza degli sviluppatori web ignora o non conosce in maniera adeguata, i rischi indirettamente legati all'uso dei cookies, qualora non vegano prese le dovute misure di precauzione.

Questi due fattori fanno si' che i cookies, appunto, siano spesso il soggetto, il target di molte vulnerabilita' di un tipo o dell'altro che di solito mirano a compromettere l'account dell'utente X sul sito (non idealmente progettato) Y.

Tornando in topic... (se la prendiamo alla larga non la finiamo piu' :D)

Tutti, anche i meno esperti, avranno almeno una volta sentito il termine "AJAX", che quando non e' usato per riferirsi alla squadra di calcio o al detersivo, sta per asynchronous JavaScript and XML (http://en.wikipedia.org/wiki/Ajax_(programming)).
Al giorno d'oggi si usano spesso parole nuove per riferirsi a technologia vecchia (o a nuovi modi di utilizzare tecnologia esistente), e il termine AJAX non fa eccezione (mi viene in mente "cloud computing", in proposito).

Inutile ripetere qui descrizioni ed esempi che potete trovare su Wikipedia all'articolo linkato, o googlando.
Ci interessa qui fare il punto sul perche' i cookies sono cosi' importanti quando si parla di tecniche di programmazione AJAX che sono alla base del "web 2.0" e di tanta roba figa che si vede oggi giorno su Internet.

Anzi...per essere piu' precisi, avrei forse dovuto cominciare col dire: "Ci interessa qui fare il punto sul perche' i cookies sono cosi' importanti quando si parla di JavaScript", prima che di AJAX che vedremo nello specifico in un attimo.

Nel precedente post ho illustrato un paio tra le piu' comuni tecniche (ci sono diverse varianti) usate per appropriarsi di cookies che altrimenti dovrebbero essere inacessibili se non dal sito stesso che li crea. Ho fatto cenno sulla restrizione che riguarda il nome a dominio (in breve: una pagina nel dominio microsoft.com, per esempio, non puo' accedere ai cookies scritti dal dominio google.com, per esempio) e ad un trucchetto, quello dell'IMG tag (o SCRIPT tag... il concetto e' lo stesso), che sfrutta l'inaccortezza di chi ha progettato un sito per inviarne i cookies, di nascosto, accedendo mediante JavaScript alla proprieta' cookie dell'oggetto document.

Fin qui, penso sia chiaro, ed e' qui che entra in gioco il flag "http only".
HttpOnly e' una sorta di meccanismo di difesa introdotto nei browsers (chi prima, chi dopo), per rendere questi tipi di attacco molto piu' difficili, a vantaggio dell'utente, poiche' esso rende un cookie inaccessibile (almeno in teoria) a codice client.

Ad es. il cookie:

Set-Cookie: SessId=...; HttpOnly;

contenente un token di autenticazione della sessione, non potra' essere accessibile mediante document.cookie perche' "document.cookie" restituira' semplicemente una stringa vuota.
Cio' significa, almeno in teoria, che le tecniche di XSS citate, cosi' come altre varianti che comunque hanno lo stesso scopo (quello di fare "session hijacking" per potersi autenticare impersonando altri), fallirebbero.

Cool, no? :stordita:

Il problema e' che non tutti i browsers, o non tutte le versioni ancora in uso dei vari browsers, supportano questo flag.

Prima di chiudere questo riferimento, una parentesi (onde evitare di dimenticarlo in seguito). Aggiungo pertanto una importante nota a proposito del fatto che HttpOnly non protegge da altri tipi di azioni maligne che e' possibile compiere attraverso tecniche basate su XSS molto simili. Vi ricordate del MySpace worm (http://namb.la/popular/tech.html)?
O, anche meglio: sempre attraverso il trucchetto di un IMG o SCRIPT tag, e' possibile effettuare HTTP requests verso il sito vittima, e compiere azioni maligne, senza che l'utente se ne accorga, e spesso anche senza dover
far ricorso a tecniche di cross site scripting.
Questo, a causa ancora una volta del fatto che un buon (mia stima :D) 90% degli sviluppatori web lavora in maniera molto amatoriale, tutt'altro che professionale, per ignoranza o disinteresse.

Le specifiche (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html) che descrivono il protocollo HTTP, infatti, dettano la seguente legge, in due chiare regole:

1) tutte le HTTP requests che hanno lo scopo di leggere dati ritornati da un server, andrebbero normalmente eseguite col verb/method GET.

Richieste di tipo GET sono per esempio quelle che voi stessi fate effettuare al browser nel momento in cui digitate un indirizzo e premete invio.

Altri esempi di richieste GET:

- normali links che semplicemente redirezionano l'utente all'indirizzo specificato nell'attribute href, o - similarmente - i rif. a stylesheets, che anche usano href

- redirezioni fatte attraverso la manipolazione dell'oggetto location mediante JavaScript

- l'attribute src di frames/iframes/images

2) tutte le azioni che comportano la creazione, la modifica, o la cancellazione di dati, andrebbero effettuate col verb/method POST.

Le richieste di tipo POST sono quelle effettuate

- attraverso l'invio di forms

- attraverso richieste AJAX / XMLHttp specificando il method POST


Purtroppo *TROPPI* siti, invece, consentono azioni "distruttive" (di cui al punto 2) attraverso richieste GET.
Facciamo un esempio (quello classico dell'home banking :D): supponiamo che bancafiga.com consenta erroneamente il compimento di azioni, attraverso l'invio di richieste GET del tipo:

bancafiga . com /transfer-money/?to_account_id=...&amount=1000000


bene: in un caso di questo tipo sarebbe sufficiente che un malintenzionato aggiungesse un tag IMG su un sito qualunque (il suo blog, un forum, ecc) che invece di visualizzare una immagine, effettui una richiesta come quella dell'esempio (che naturalmente e' soltanto un fantasioso esempio par illustrare il concetto), verso il sito bancafiga.com.

Utenti che giungano al sito dell'attaccante, e che in quel momento risultino autenticati sul sito vittima (bancafiga.com nell'esempio), puff... :D

Purtroppo anche questo tipo di vulnerabilita' e' fin troppo diffusa.
Sarebbe sufficiente, per evitarla,

1) seguire le direttive RFC ed usare POST per evitare le varianti piu' banali di questo tipo di attacco; banali... perche' il solo uso di POST non protegge da questo tipo di vulnerabilita' nell'insieme, perche' un sito maligno potrebbe avere del JavaScript che comunque effettui richieste POST...

2) usare, come gia' suggerito, nonce (http://en.wikipedia.org/wiki/Cryptographic_nonce) con validita' di singola pagina/richiesta (meglio) o almeno di sessione.

Un valore nonce dovrebbe essere generato dalla parte di applicazione invisibile all'utente, quella che opera sul lato puramente server della comunicazione, e dovrebbe essere reso disponibile nella pagina inviata al browser attraverso un campo form nascosto, una variabile JavaScript settata dinamicamente, o quello che vi pare.
L'importante e' che questo "nonce" venga passato ad ogni richiesta, e che venga confrontato col valore che l'applicazione server si aspetta di vedere.
Una richiesta effettuata malignamente nel modo illustrato nell'esempio, non avrebbe modo -se eseguita attraverso un altro sito- di conoscere il valore nonce che verrebbe accettato dal server (qui ho volutamente semplificato il discorso.... c'e' molto altro da dire, ma non la finiamo piu' altrimenti :D)

Chiudo questa parentesi che si e' protratta molto piu' a lungo di quanto immaginavo tornare in topic :D

E' possibile, in determinate circostanze, bypassare la restrizione che ho illustrato in merito al flag HttpOnly che e' possibile usare quando si scrivono cookies. In questo caso parliamo di cross site tracing o XST (ho linkato un white paper nell'altro post).
Questa tecnica si basa su un altro verb/method previsto da HTTP: trace. Normalmente non viene usato per le normali richieste ma per diagnostica, controllo, ecc. E' utile per esempio per sapere se una richiesta e' stata modificata tra server e client a causa di un proxy o MITM ecc.

Dunque? il problema e' che

- i browsers inviano tutti i cookies assieme a tutte le richieste, anche quelle che vengono effettuate col method trace, anche quelli segnati come httponly :fagiano:

- in diverse precedenti versioni di IE, Safari, Firefox, ecc ancora in uso (soprattutto di IE e Safari), e' ancora possibile effettuare richieste trace, e quindi leggere i cookies, anche con AJAX, dunque JavaScript, dunque client code, anche se document.cookie ritorna una stringa vuota.

Per es. con in IE:

var xst_req = new ActiveXObject("Microsoft.XMLHTTP"); // o altra versione
with (xst_req) {
open("TRACE", "http://sito vittima", false);
send();
var testo_contenente_il_cookie = responseText;
}



Fortunatamente i browsers piu' recenti, chi prima, chi dopo, si stanno adeguando bloccando le richieste trace effettuate con JavaScript / AJAX.
Questo e' il motivo per cui nelle "5 regole d'oro" mi sono limitato a suggerire cookies http only. Se utilizzati assieme agli altri suggerimenti, sono un'ottimo meccanismo di difesa e prestissimo tutti i browsers in circolazione saranno - si spera - immuni a XST.

spero che anche quest'altro mattoncino vi sia piaciuto :ciapet:
adesso stacco, tocca a me cucinare stasera :fagiano:




ps: ho parlato di "mezz'ora libera", ma scrivere m'ha portato via un'altra ora :help:

riazzituoi
22-05-2009, 22:13
.

Sisupoika
22-05-2009, 23:27
Ti sei dato da fare :D
ricomplimenti, ottimo POST :sofico:

Per onestÓ intellettuale bisogna dare a Cesare quel che Ŕ di Cesare, vale a dire IE Ŕ stato il primo browser a risolvere questo problema (nonchŔ ad implementare l'httponly).

Hai ragione, per una volta tanto avrei dovuto menzionare un primato di IE :D
Ho dimenticato di scriverlo

juninho85
23-05-2009, 18:25
ogni volta che ti leggo mi viene mal di testa,per limiti miei purtroppo :D

Sisupoika
25-05-2009, 15:49
ogni volta che ti leggo mi viene mal di testa,per limiti miei purtroppo :D

ho del paracetamol, se vuoi... :stordita: :D

medus@
04-08-2009, 06:41
un uomo ke cucina da solo e conosce tutte queste cose sui...."biscottini". ke uomo di altri tempi :rolleyes: :D
(...e ke favola sono i forum...riesco a prendermi certe confidenze ke d persona posso solo sognarmele...)

xcdegasp
04-08-2009, 10:52
io pure cucino e mi diverto molto a farlo :D :O
sono questi i tempi, in altri tempi la donna era legata alla stufa a legna come i cookies all'utente :asd:

Sisupoika
04-08-2009, 12:10
:D

xcdegasp
05-08-2009, 14:57
spostato in tutorial/faq :)

Sisupoika
05-08-2009, 14:59
spostato in tutorial/faq :)

Cominciavo a pensare di aver perso molto tempo inutilmente nello scrivere questi threads :D

xcdegasp
05-08-2009, 15:06
assolutamente no non Ŕ stato tempo perso semplicemente attendevamo che producessi ogni venerdý :O
:asd:

ps: sono stati linkati in thread importanti con un paragrafo dedicato :)

Sisupoika
05-08-2009, 15:32
assolutamente no non Ŕ stato tempo perso semplicemente attendevamo che producessi ogni venerdý :O
:asd:

ps: sono stati linkati in thread importanti con un paragrafo dedicato :)

Ogni venerdi'? :eek:

xcdegasp
06-08-2009, 00:00
dai 2 visto che Ŕ estate, due venerdý al mese? :D

medus@
13-08-2009, 06:53
io pure cucino e mi diverto molto a farlo :D :O
sono questi i tempi, in altri tempi la donna era legata alla stufa a legna come i cookies all'utente :asd:

:D :D :D