XSS e PHP: teoria e pratica
Lunedì 20 Giugno 2011 - 09:17
di Kiko
Controllare l’input di un form è una delle prime mosse in ottica sicurezza che un buon programmatore deve mettere in pratica. L’attacco XSS mira, tramite inserimento di codice all’interno dei campi di un form, ad alterare i contenuti di una pagina Web.
Un minimo di protezione è garantita dal filtering dei dati in ingresso di un form. PHP in tal senso mette a disposizione dello sviluppatore numerose funzioni.
In How To Protect Your Site From XSS With PHP vengono raccolte alcune riflessioni sulla pericolosità degli attacchi XSS e vengono illustrati due semplici metodi per un basilare filtering dei dati e cioè htmlentities() e strip_tags().
Categoria: Sicurezza, PHP e Open Source | Permalink
Commenti
1
Ma una domanda mi sorge spontanea:
Visto che la validazione dei campi è la base, ma proprio l’ABC della base c’è ancora chi non lo fa?# - postato da lordmax - 20 Giugno 2011 - 09:59
2
@lordmax non sono riuscito a trovare il link, ma oltre il 60% dei casi di problema-di-sicurezza deriva proprio da XSS e da una mancanza di filtering dei dati in ingresso ai form!
3
che tristezza però. ^__^
# - postato da lordmax - 20 Giugno 2011 - 11:44
4
Sì @lordmax sì, e non lo fanno tutti gli esempi che trovi in giro, non lo fanno nei libri che insegnano il PHP, magari perché la “sicurezza” è una tematica sviluppata in un altro capitolo e quindi decisamente svincolata dal controllo dei form.
Una volta che hai letto come si prende un dato da un form non vai a leggere il capitolo sulla sicurezza, hai trovato ciò che ti serve e via.
Ho anche litigato su questa tematica sul forum del php, a nessuno interessa perché dopotutto il form funziona comunque e il progetto l’ho venduto e amen.
@kiko quello che poco vedo in giro invece sono analoghi progetti utilizzando i filtri.M.
# - postato da Marco Grazia - 20 Giugno 2011 - 12:29
5
.Net 1 php 0
:)
# - postato da nessuno - 20 Giugno 2011 - 14:10
6
@nessuno: .Net è un framework, PHP no. Quindi non puoi paragonare il primo con il secondo.
7
@Diego infatti non capivo @nessuno. Vabbuò!
8
@marco
Sì, quello che dici è vero però non è quello che dovrebbe accadere (vabbè, sì, lo so, fra il dire e il mare… ^___^).
La cosa grave è che queste cose non accadono nei sitarelli personali degli studenti di informatica ma in grossi portali aziendali.
Dove sono finiti i test?
Che ci stà a fare il problem solver?# - postato da lordmax - 20 Giugno 2011 - 17:29
9
@Kiko: è semplicemente un paragone che non sta in piedi :-)
@Lordmax: il Web 2.0 ha stravolto un po’ la modalità di produzione di un applicativo: adesso essite ed è ampiamente applicato (anche dove potrebbe essere controproducente) il concetto di “eternal beta” dove è l’utente finale che fa da tester per le web applications. Quindi il problem solver interviene SOLO dopo che il problema è emerso. Magari la risoluzione del bug costerà il doppio rispetto ad averlo previsto in precedenza, ma si è risparmiato i costi dei test che sono svolti dall’utente in modo gratuito (per l’azienda di turno).
10
@tutti! Beh.. forse voi più di altri “dovreste sapere” che molte aziende pretendono un applicativo al minor costo possibile e finito in una settimana.
Quindi e possibile che allo sviluppatore di turno non passi minimamente per la mente di perdere altro tempo/lavoro da dedicare alla sicurezza. Che sia quella dei form o di altro.
# - postato da @rchie - 21 Giugno 2011 - 00:23
11
Non sarò un esperto come Jason Stiles (a proposito, ma chi è Jason Stiles?!), comunque l’articolo citato non mi pare una gran risorsa.
Si dice che htmlentities non è sicura per ie6, sarà anche vero, ma non si capisce perché.
Non si capisce perché non si possa usare htmspecialchars, funzione neppure citata, che dovrebbe essere fatta apposta per questo.
Per concludere si arriva addirittura a proporre come soluzione per filtrare gli URL uno str_replace di “script”, quando basta un tab per aggirarlo
javascr ipt:alert(String.fromCharCode(88,83,83)).Il tutto senza nemmeno un approfondimento, come il cheat sheet http://ha.ckers.org/xss.html o un articolo che tratti seriamente l’argomento.
Una precisazione invece sull’articolo di Edit, gli attacchi XSS non riguardano solamente i form :P
12
@Fra_T concordo con te, l’esempio riportato non è il massimo ma almeno ha il pregio di aver sollevato il coperchio.
@rchie quello che dici è vero solo in parte, ci sono molti modi per aggirare il problema, uno di questi sono le best practice, non è che scrivere che so $a = $_POST[’pippo’]; o $a = htmlentities($_POST[’pippo’], ENT_QUOTES); porti via molto più tempo, è una questione di abitudine, ci sono pure gli editor con gli snipset di codice a posta per questo.
@Diego questi sono problemi che vengono da prima dell’introduzione del cosiddetto Web 2.0 sono cose che ci si porta dietro dalla nascita.
Inoltre tieni presente che se è vero come dice @lordmax che ci sono fior di siti così, ci sono milioni di siti non aziendali ma personali che scopiazzati qua e la non hanno il minimo sindacale per la sicurezza dei dati riportati.
Poi c’è la questione mai affrontata della gestione del software installato, per esempio due a caso Wordpress e Joomla! o per i forum di discussione che nessuno aggiorna mai, va bè quasi mai nessuno, ma per la maggior parte è così.
@lordmax il problem solver costa e come giustamente fanno presente alcuni, ai costi si frappone la fretta.
@nessuno a parte che spero vivamente per te che la Microsoft ti paghi per dire ciò che dici, a parte che la Microsoft non pagherebbe un troll, a parte tutto ciò, qui si sta parlando dell’uomo e non della macchina, anche se Microsoft ha per mira quello di sostituirci cone le macchine, per ora non è accaduto e non può accadere perché comunque anche alla Microsoft hanno bisogno di persone.M.
# - postato da Marco Grazia - 21 Giugno 2011 - 07:37
13
In tema di iniezioni di HTML, cito anche CSRF, che permette di far compiere azioni ad un utente loggato: http://en.wikipedia.org/wiki/C.....st_forgery
14
Grazie per l’articolo.
Non sono esperto in sicurezza, ma ho estremo rispetto a riguardo.
La funzione suggerita Jason T. Stiles è da considerarsi già buona?
O meglio usare librerie come htmlpurifier o phpids?
Rimanendo in tema, non sarebbe male parlare di programmi capaci di simulare molti tipi di attacchi. Io conosco solo Acunetix Web Vulnerability Scanner, ma ne esistono sicuramente molti altri
M.# - postato da Matteo - 22 Giugno 2011 - 13:42
15
Secondo me no.
Se non vuoi far inserire HTML, puoi usare htmlspecialchars($string, ENT_QUOTES). E’ importante anche specificare il charset della pagina via header HTTP.
Se vuoi far inserire HTML, ma vuoi che sia sicuro, con una libreria come htmlpurifier sei più tranquillo.
Se permetti di inserire HTML, fai attenzione. Qualcuno potrebbe inserire ad esempio un immagine che richiama la pagina http://tuo-sito.it/fai/qualcos.....n/dovresti
In questo caso puoi proteggerti salvando un hash in sessione e assicurarti che sia inviato nei form o nei link che eseguono azioni critiche.Infine, se vuoi far inserire un URL, hai bisogno di una validazione, non di un filtro o di uno str_replace di script :-)
16
@Fra_T - “Infine, se vuoi inserire un URL, hai bisogno…”
Io opterei per la preg_match al negativo. Forse potrebbe escludere alcuni URL ma..oh..se c’hai un URL con “mio_sito_mah.com” ..che URL ti sei andato a scegliere??
Ad ogni modo, penso che la preg_match per gli URL sia la più efficiente. O si fa come dice, o non se fà! :-)
Per il resto, interessanti i commenti di tutti. E’ evidente che il problema è più difficile quando si dà la possibilità agli utenti di inserire “commenti personalizzati”, quindi con tag HTML, ecc.
..altrimenti, il problema, credo, si pone molto meno.
Ciao a tutti!
# - postato da VùDdì - 05 Agosto 2011 - 14:40