In più occasioni è capitato di sentir parlare di XSS come uno dei più diffusi problemi di sicurezza dei siti: l’inserimento/esecuzione di codice arbitrario da parte di attaccanti esterni. Come si può risolvere un problema di questo tipo? La risposta è in parte legata alla tecnica di programmazione utilizzata, e d’altro canto si lega all’utilizzo di misure di sicurezza lato server del sito.
Come funziona XSS?
La dinamica di XSS è ben nota: si sfrutta una mancanza di controllo all’interno del codice, che l’attaccante in qualche modo sospetta o indovina facendo una serie di ipotesi sensate, e dopo aver effettuato eventuale [dt_tooltip title=”footprinting”]Il footprinting è l’attività di monitoraggio delle informazioni disponibili su un server, in particolare in ambito web, allo scopo di mettere in evidenza eventuali debolezze del sistema e sfruttarle per effettuare operazioni di defacing, SQL o code injection e così via.[/dt_tooltip]. A quel punto tutto diventa più semplice, e basta un qualsiasi input proposto all’utente, come ad esempio:- una schermata / finestra di login:
- un form di ricerca interna nel sito;
- un URL passato via GET (in certi casi anche POST);
Cosa può fare Apache 2 in merito?
È vero che Apache 2 propone il modulo mod_security con una direttiva apposita, da inserire nel file /etc/httpd/conf.d/mod_security.conf, che filtra qualsiasi tentativo di XSS (leggi qui per saperne di più). Se lavorate su un VPS, ad esempio, potete editare il file appena citato ed adottare qualcosa su questa falsariga:[dt_quote type="blockquote" font_size="normal" animation="fade" background="fancy"]# protezione base SecFilter "<( |\n)*script" # protezione attacchi con JS/HTML SecFilter "<(.|\n)+>"[/dt_quote]
Come faccio a scrivere codice “safe“?
Le protezioni anti-XSS sono inoltre effettuabili anche lato codice ASP/PHP/…, comunque: ad esempio si può verificare se sia possibile fare in modo di eseguire script in remoto sul sito mediante Javascript, mettendo così a rischio le variabili interne del sito come cookie e sessioni, che non dovrebbero mai contenere informazioni riservate come password ed username in chiaro, specie se si tratta di operazioni lato client (il codice JS ad esempio è visibile all’interno della pagina HTML), relegando piuttosto le operazioni di login al server ed alle sue logiche interne.Proteggersi da XSS: alcune linee guida
In linea di massima, è bene premettere le contromisure che gli sviluppatori dei siti web dovrebbero attuare per proteggersi da questo tipo di attacchi:- filtrare dagli input del sito tutti i caratteri speciali come ad esempio <, >, (, ), # e &;
- filtrate gli output delle variabili in modo che i caratteri suddetti non possano provocare alterazioni o modifiche al comportamento del codice;
- per il browser Internet Explorer (nelle versioni più vecchie, ovvero fino alla 6) conviene sfruttare la feature HttpOnly che limita l’accesso ai cookie da determinati tipi di browser;
- analizzate le eventuali debolezze del sito in fase di produzione del codice, sfruttando appositi tool gratuiti come XSS Me (Firefox), XSSer o Zaproxy.
| [dt_highlight color=””]Tipologia[/dt_highlight] | [dt_highlight color=””]Esempio[/dt_highlight] |
|---|---|
| Injection di uno script in una variabile |
http://sito.com/pagina.php?v=<script>...</script> |
| Visualizzazione del cookie del sito |
http://sito.com/pagina.asp?v=<script>...(document.cookie)</script> |
| Injection di un tag HTML al fine di reperire il contenuto del cookie |
http://sito.com/cgi-bin/cookie.cgi?'%20+document.cookie<script>...</script> |
| Injection dell’attributo onload |
http://sito.com/pagina.asp?v=%20onload=script(document.domain)<script>...</script> |
| Injection di Javascript arbitrario mediante tag di tipo img |
http://sito.com/cgi-bin/script.pl?name=>"'><IMG src="javascript:alert('XSS test')"><script>...</script>
|
(fonte script: owasp.org)
