Hacking Referring Urls
Wikipedia : The referer, or HTTP referer, identifies, from the point of view of an internet webpage or resource, the address of the webpage (commonly the URL, the more generic URI or the i18n updated IRI) of the resource which links to it. By checking the referer, the new page can see where the request came from. Referer logging is used to allow websites and web servers to identify where people are visiting them from, for promotional or security purposes. Since the referer can easily be spoofed (faked), however, it is of limited use in this regard except on a casual basis.
Gli HTTP Referer furono creati come strumento per aiutare il tracciamento e l'analisi delle fonti di traffico in ingresso nelle applicazioni Internet. Indifferentemente dal loro scopo, il loro utilizzo è proporzionalmente mutato nel tempo. Da strumento per operazioni di marketing /partnership, fino a sistema di sicurezza.
Questo sistema è decisamente popolare su siti di qualità e contenuto discutibile, il ragionamento si riproduce in 3 step.
- Utente effettua il login
- Nel caso in cui la login e la password siano corretti viene eseguito il redirect ad una pagina temporanea (es loginOK.aspx)
- loginOK.aspx al suo caricamento reindirizza l'utente alla pagina members.aspx, la quale verifica HTTP referer. Se è uguale a loginOK.aspx l'accesso viene effettuato.
Ma oltre a strumento di sicurezza, HTTP Referer viene utilizzato come tool di debug. Può capitare spesso di dover rintracciare richieste errate che hanno portato ad errori 404 (not found). Grazie a HTTP Referer sarà possibile individuare tutte le richieste che hanno effettivamente scatenato l'errore.
Gli HTTP Referer vengono anche utilizzati da sistemi di tracciamento ed analisi. Google Analytics (vedi immagine), per esempio, fornisce i risultati contenuti nella pagina Refering Sites grazie all'analisi delle intestazioni HTTP ricevute.
Il problema di queste interessanti funzionalità è dovuto dal fatto che sono facilmente alterabili. Live HTTP Headers, per esempio, permette la modifica di tutti gli header precedentemente al loro invio. In questo modo sarà possibile avere delle intestazioni HTTP con valori alterati a dovere(notate la riga 11).
1: GET /cyphersecurity HTTP/1.1
2: Host: feeds.feedburner.com
3: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.9pre) Gecko/20071102 Firefox/2.0.0.9 Navigator/9.0.0.3
4: Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
5: Accept-Language: en-us,en;q=0.5
6: Accept-Encoding: gzip,deflate
7: Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
8: Keep-Alive: 300
9: Proxy-Connection: keep-alive
10: X-Moz: livebookmarks
11: Referer: hospoffatoquestarichiesta.it
12: If-Modified-Since: Sun, 18 Nov 2007 22:57:45 GMT
13: If-None-Match: gCsTB2NQlIQNEO+S4vAbCyjw97g
14: Cache-Control: max-age=0, max-age=0, max-age=0
Spesso, nell'analisi dei log, i più esperti, presteranno attenzione a chiamate con Refer nulli o comunque non logicamente validi. Questo è dovuto al fatto che alcune forme di attacco alle web applications vengono portati a termine proprio grazie alla modifiche delle intestazioni HTTP. Naturalmente HTTP Referer non può solo essere nullo o non valido, ma può contenere codice xss.
Esempio (notate riga #11)
1: GET /cyphersecurity HTTP/1.1
2: Host: feeds.feedburner.com
3: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.9pre) Gecko/20071102 Firefox/2.0.0.9 Navigator/9.0.0.3
4: Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
5: Accept-Language: en-us,en;q=0.5
6: Accept-Encoding: gzip,deflate
7: Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
8: Keep-Alive: 300
9: Proxy-Connection: keep-alive
10: X-Moz: livebookmarks
11: Referer : http://www.mylamesite.com/myEvilJavaScriptThatPownzTheWorld.js
12: If-Modified-Since: Sun, 18 Nov 2007 22:57:45 GMT
13: If-None-Match: gCsTB2NQlIQNEO+S4vAbCyjw97g
14: Cache-Control: max-age=0, max-age=0, max-age=0
Decisamente interessante; Da ricordare che HTTP Referer non è l'unica intestazione HTTP che può creare dei problemi alle applicazioni web. In molti casi, User Agent (ovvero la voce che indica il browser in utilizzo) può contenere valori XSS i quali possono portare (in alcuni casi) al crash del server web stesso.
Nel caso di un controllo applicativo, è importante andare a verificare tutte le possibili varianti di attacchi XSS attraverso intenstazione HTTP. Tenendo a mente quanto spiegato nell'articolo Come Violare Filtri XSS e solo dopo aver effettuato tutti i test necessari, sarà possibile certificare lo stato di sicurezza dell'applicazione in esame.
Per evitare questo ed altri attacchi XSS il consiglio è sempre lo stesso. Verificare e validare TUTTO (read: files,intestazione http,cookies,etc) quello che viene letto/visualizzato dall'applicativo.
