Web Security
| Author | Roberto Bifulco |
|---|---|
| Date | 12-10-2007 |
Introduction
Questo documento analizza velocemente i piu' diffusi pericoli alla sicurezza delle applicazioni web. Oltre ai rischi ed alle tipologie di attacco, vengono presentate le best pratices per la risoluzione di tali problemi.
Types of attack
Nel seguito sono presentate le piu' diffuse tecniche di attacco adoperate nel web e le possibili contromisure.
Cross site scripting (XSS)
Il XSS e' un attacco eseguito inserendo codice malevolo in una
pagina web. L'attacco consiste nello sfruttare la possibilita' di
inserire contenuti in una pagina (wikipedia e' un esempio di siti del
genere, ma anche un qualunque forum, guestbook, blog in cui si
lasciano commenti, sono sito che possono ricevere attacchi), per
inserire del codice attivo con lo scopo di rubare informazioni
sensibili dell'utente.
L'attacco sfrutta quindi un sito benevolo per ottenere informazioni
sui suoi utenti. Le informazioni sono recuperate inserendo una
richiesta ad un server malevolo come codice "intruso" nella pagina.
Solution
Controllo degli input utente, con sostituzione dei caratteri pericolosi
quali quelli di < e > con le corrispondenti sequenze di
escape.
E' possibile anche definire white list oppure
black list per i caratteri che sono
rispettivamente accettati e non accettati dal controllo sull'input.
Dal lato del server e' sempre bene usare funzioni di sanitarizzazione
dell'input, ad esempio in php si puo' adoperare
htmlspecialchars.
Cross site request forgeries (CSRF)
Nel CSRF l'attacco viene eseguito da una pagina creata
appositamente. Si sfruttano le caratteristiche dei browser che
attaccano ad una richiesta HTTP tutti i cookie impostati
precedentemente dal sito cui la richiesta e' fatta.
Se l'utente visista due siti in contemporanea: il sito benigno
e quello malevolo, e' possibile procedere come segue:
- il sito malevolo aggiunge un tag del tipo:
< script language="javascript" src="www.good.com">in questo modo effettua una richiesta dalla sua pagina, al sito benevolo.
</script> - Il browser attacca i cookie a questa richiesta.
- Il sito malevolo ottiene gli stessi privilegi che ha in quel momento l'utente, ma con una sua richiesta opportunamente costruita.
Se la richiesta del sito malevolo e' ben congeniata, chi realizza l'attacco puo' arrivare a fare richieste per operazioni privilegiate dell'utente, sfruttando l'autenticazione da lui stesso eseguita
Solution
La soluzione piu' consigliata in questi casi e' quella
di aggiungere un'informazione alla richiesta effettuata che
sia anch'essa utilizzata per individuare la sessione, oltre
al cookie stesso.
Generalmente si mette fra i parametri della richiesta proprio
il cookie stesso, che non puo' essere acceduto da un'altra
pagina. Con questa soluzione, verificando il valore del cookie
passato come parametro della richiesta, il server puo' eseguire
un'autenticazione sicura.
Un'ulteriore pratica e' generalmente consigliata per una
maggiore sicurezza: accettare solo richieste fatte con POST.
Le richieste che permettono ad una pagina malevola di
ottenere informazioni da un sito web bypassando la
Same Origin Policy sfruttano infatti il solo metodo GET,
poiche' adoperano i tag del tipo <IMG> e <SCRIPT>.
JSON hijacking
Il JSON hijacking (talvolta indicato anche come Javascript
hijacking) e' una tecnica di attacco che si basa sul CSRF.
Vengono sfruttate le debolezze dei servizi che utilizzano JSON come
formato di scambio dati. Questo formato infatti e' lo stesso usato
da Javascript per descrivere i suoi oggetti, e puo' dunque direttamente
essere interpretato all'interno dei tag SCRIPT. Utilizzando CSRF
e' dunque possibile ottenere ed interpretare informazioni codificate
in JSON. In particolare, si effettua la richiesta tramite un
tag SCRIPT che punta al servizio JSON, la risposta viene interpretata
come codice javascript e, quindi, l'oggetto puo' essere acceduto dal
rimanente codice della pagina.
Solution
L'attacco, essendo basato su CSRF, puo' essere prevenuto
semplicemente prevenendo il CSRF.
Visto che non sempre e' possibile attuare queste protezioni, o
se si desidera un grado superiore di sicurezza, e' possibile
adottare ulteriori strategie.
Fra queste la piu' comune consiste nell'inserire del codice,
prima del testo JSON, che ne impedisca l'esecuzione diretta.
Infatti, la richiesta malevola, per superare il vincolo di
Same Origin Policy usa il tag SCRIPT
facendolo puntare ad una risorsa esterna, e, quindi, non puo'
fare elaborazioni sui dati in arrivo.
La soluzione consiste quindi nel far precedere la stringa JSON da
una stringa del tipo while(1); che va eliminata da chi usufruisce
del servizio "legalmente" prima di eseguire il codice JSON.
Alternativa altrettanto valida e' inserire la stringa JSON nei
caratteri di commento "/* */", anch'essi da eliminare prima di
elaborarla.