In più occasioni è capitato che parlassimo, su questo blog, 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. Per comprendere al meglio i contenuti di questo articolo, vi suggeriamo di leggere anche l’approfondimento sui tipi di vulnerabilità e sicurezza informatica che abbiamo proposto qualche giorno fa.
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 footprinting. 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);
a caratterizzare tre tra i più comuni casi di attacchi informatici cross-side scripting.
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:
# protezione base SecFilter "<( |\n)*script" # protezione attacchi con JS/HTML SecFilter "<(.|\n)+>"
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 XSSer o Zaproxy.
Si ricorda inoltre che il cross-side scripting, pur avendo a che fare con il lato client del server, può introdurre malware e virus così come codice arbitrario JS proveniente da sorgenti esterni, e per questa ragione non dovrebbe essere sottovalutato. Segue una tabella riassuntiva dei principali tipi di attacchi, con alcuni esempi di URL pericolosi che andrebbero analizzati e che possono richiedere, probabilmente, interventi sul codice.
[table id=3 /](fonte script: owasp.org)
