L’uso dei “biscottini” (Parte II) – Web Security

Proseguendo sulla scia di quanto detto la scorsa volta, l’estrema semplicità dei cookie rappresenta contemporaneamente il più grande vantaggio, e la più grave debolezza. Essi sono stati concepiti come piccoli file di testo, e come tali sono facilmente accessibili e modificabili. I vari attacchi esistenti fanno tutti leva su quest’aspetto.

A questo proposito la prima minaccia da considerare è nota col nome di Cookie Hijacking o più semplicemente “furto di cookie”. Per chiarezza bisogna ricordare, dall’articolo precedente, che i cookie vengono trasmessi in chiaro nell’header HTTP, e pertanto sono facilmente sottraibili.
Un qualsiasi attacker potrebbe entrare in possesso dei cookie altrui mediante lo sniffing della rete, oppure sfruttando una nota vulnerabilità che affligge alcuni siti web dinamici, ovvero le XSS (Cross Site Scripting).
Nel primo caso si tratta di intercettare i pacchetti che transitano in rete e che trasportano le informazioni tra cui le richieste HTTP. Nel secondo caso, senza entrare nel dettaglio, è possibile sottrarre i cookie di un sito vulnerabile (cookie grabbing) mediante una stringa Javascript adeguamente formata che invia i dati rubati ad una destinazione prestabilita. La gravità di un attacco di tipo Cookie Hijacking risulta ovvia ricordando che nei cookie sono spesso contenute informazioni relative all’autenticazione di un utente (user e password). Tuttavia la soluzione è dietro l’angolo: basta fare in modo che il trasferimento del cookie avvenga in modalità protetta tramite SSL/TLS, sfruttando HTTPS. Per far ciò bisognerebbe semplicemente settare il flag SECURE al momento della creazione del cookie. Purtroppo la maggior parte dei siti web adottano una connessione protetta soltanto al momento del login, ma utilizzano una normale connessione HTTP per tutto il resto della comunicazione.

Essendo i cookie semplici file di testo risultano anche di facile modifica. Un attacco che si focalizza su quest’aspetto è noto col nome di Cookie Manipulation o Cookie Poisoning (Tampering). Specialmente in passato, dove i controlli server-side erano più blandi, era possibile ingannare una web application semplicemente modificando i valori contenuti nel cookie manualmente o editando direttamente la richiesta HTTP prima dell’invio. Ad esempio un attaccante avrebbe potuto cambiare il valore del prezzo contenuto nel cookie di un sito di e-commerce, oppure qualora fosse in possesso di un cookie contenente i dati di accesso di un altro utente avrebbe potuto iniettarli nel proprio. Tale attacco risulta ultimamente più difficile da realizzare perchè i controlli nei siti dinamici sono stati fortemente migliorati.

Molte sono d’altronde le varianti delle minacce descritte, e altre ancora quelle esistenti. Un esempio: un particolare bug nel controllo di compatibilità del dominio di appartenenza tra cookie e web server, che ha afflitto tutti i browser più noti, consente un attacco noto come Cross Site Cooking. Come il nome stesso lascia intuire, un attaccante potrebbe far sì che un cookie falsificato creato da lui, e quindi proveniente da un dominio diverso, sovrascriva un cookie originale dell’utente vittima.

In conclusione, ogni attacco qui citato potrebbe essere ampiamente descritto, ma lo spazio a mia disposizione è limitato.
Lo scopo è stato principalmente quello di suggerirvi interessanti spunti di approfondimento. I cookie nonostante tutto sono rimasti per adesso una parte integrante del web, e rimarranno tali finchè non sarà trovata una valida alternativa, o finchè non sarà lo stesso protocollo HTTP a cambiare.Proseguendo sulla scia di quanto detto la scorsa volta, l’estrema semplicità dei cookie rappresenta contemporaneamente il più grande vantaggio, e la più grave debolezza. Essi sono stati concepiti come piccoli file di testo, e come tali sono facilmente accessibili e modificabili. I vari attacchi esistenti fanno tutti leva su quest’aspetto.

A questo proposito la prima minaccia da considerare è nota col nome di Cookie Hijacking o più semplicemente “furto di cookie”. Per chiarezza bisogna ricordare, dall’articolo precedente, che i cookie vengono trasmessi in chiaro nell’header HTTP, e pertanto sono facilmente sottraibili.
Un qualsiasi attacker potrebbe entrare in possesso dei cookie altrui mediante lo sniffing della rete, oppure sfruttando una nota vulnerabilità che affligge alcuni siti web dinamici, ovvero le XSS (Cross Site Scripting).
Nel primo caso si tratta di intercettare i pacchetti che transitano in rete e che trasportano le informazioni tra cui le richieste HTTP. Nel secondo caso, senza entrare nel dettaglio, è possibile sottrarre i cookie di un sito vulnerabile (cookie grabbing) mediante una stringa Javascript adeguamente formata che invia i dati rubati ad una destinazione prestabilita. La gravità di un attacco di tipo Cookie Hijacking risulta ovvia ricordando che nei cookie sono spesso contenute informazioni relative all’autenticazione di un utente (user e password). Tuttavia la soluzione è dietro l’angolo: basta fare in modo che il trasferimento del cookie avvenga in modalità protetta tramite SSL/TLS, sfruttando HTTPS. Per far ciò bisognerebbe semplicemente settare il flag SECURE al momento della creazione del cookie. Purtroppo la maggior parte dei siti web adottano una connessione protetta soltanto al momento del login, ma utilizzano una normale connessione HTTP per tutto il resto della comunicazione.

Essendo i cookie semplici file di testo risultano anche di facile modifica. Un attacco che si focalizza su quest’aspetto è noto col nome di Cookie Manipulation o Cookie Poisoning (Tampering). Specialmente in passato, dove i controlli server-side erano più blandi, era possibile ingannare una web application semplicemente modificando i valori contenuti nel cookie manualmente o editando direttamente la richiesta HTTP prima dell’invio. Ad esempio un attaccante avrebbe potuto cambiare il valore del prezzo contenuto nel cookie di un sito di e-commerce, oppure qualora fosse in possesso di un cookie contenente i dati di accesso di un altro utente avrebbe potuto iniettarli nel proprio. Tale attacco risulta ultimamente più difficile da realizzare perchè i controlli nei siti dinamici sono stati fortemente migliorati.

Molte sono d’altronde le varianti delle minacce descritte, e altre ancora quelle esistenti. Un esempio: un particolare bug nel controllo di compatibilità del dominio di appartenenza tra cookie e web server, che ha afflitto tutti i browser più noti, consente un attacco noto come Cross Site Cooking. Come il nome stesso lascia intuire, un attaccante potrebbe far sì che un cookie falsificato creato da lui, e quindi proveniente da un dominio diverso, sovrascriva un cookie originale dell’utente vittima.

In conclusione, ogni attacco qui citato potrebbe essere ampiamente descritto, ma lo spazio a mia disposizione è limitato.
Lo scopo è stato principalmente quello di suggerirvi interessanti spunti di approfondimento. I cookie nonostante tutto sono rimasti per adesso una parte integrante del web, e rimarranno tali finchè non sarà trovata una valida alternativa, o finchè non sarà lo stesso protocollo HTTP a cambiare.