Impedire il Cross-site scripting XXS e riparare le vul­ne­ra­bi­li­tà

Per il­lu­stra­re meglio cosa significa con­cre­ta­men­te il Cross-site scripting per i gestori di siti e vi­si­ta­to­ri, trovate di seguito una breve lista e spie­ga­zio­ne dei diversi tipi di XSS.

Ri­chia­man­do un URL ma­ni­po­la­to o inviando un modulo già pronto, lo script dannoso viene inviato al web server, che lo rimanda nuo­va­men­te al client senza ve­ri­fi­car­lo. Il codice dannoso non viene salvato sul server ed esiste solo tem­po­ra­nea­men­te nella pro­du­zio­ne del sito at­tra­ver­so il client dan­neg­gia­to. Gli obiettivi più diffusi sono siti web dinamici o ap­pli­ca­zio­ni e-mail.

Esempio: in questa variante XSS l’ag­gres­so­re colloca il suo script in un link già pronto. In seguito tenta di inoltrare il link (so­prat­tut­to tramite e-mail). Il codice dannoso contenuto viene attivato solo se l’utente apre il link ricevuto e a quel punto, gli si presenta per esempio una schermata di login simile a quella del suo online banking. Invece di mandare i dati al server della banca, lo script fa in modo che avvenga una de­via­zio­ne nell’indirizzo che l’hacker ha pre­ce­den­te­men­te definito. 

Con un XSS per­si­sten­te o costante gli script dannosi vengono salvati sul server e, ad ogni chiamata, con­se­gna­te tramite il client. A tale scopo queste ap­pli­ca­zio­ni web vengono se­le­zio­na­te per l’attacco, salvano i dati utente lato server e in seguito li con­se­gna­no senza verifica o co­di­fi­ca­zio­ne. Par­ti­co­lar­men­te soggetti a questo tipo di scripting sono blog e forum. 

Esempio: in un forum gli in­ter­ven­ti degli utenti vengono salvati in un database, spesso senza un suf­fi­cien­te controllo. Questa è l’occasione giusta per gli hacker, che ag­giun­go­no ad un post normale uno script dannoso. Gli utenti ignari ricevono il relativo link del post per e-mail o arrivano in modo casuale alla voce cor­ri­spon­den­te ed eseguono lo script aprendolo. 

Le con­se­guen­ze negative che un Cross-site scripting ha per gli utenti e i gestori di siti non vanno sot­to­va­lu­ta­te: come utenti rischiate la perdita dei vostri dati o passate in­con­sa­pe­vol­men­te come complici in­vo­lon­ta­ri degli hacker. Come gestori di un sito siete re­spon­sa­bi­li dei dati dei vostri clienti e dei vostri vi­si­ta­to­ri, i quali possono essere coinvolti in modo diretto in seguito ad attacchi: contenuti dannosi e in­ter­ru­zio­ni del server riducono il numero di vi­si­ta­to­ri e, a lungo termine, motori di ricerca come Google rea­gi­sco­no con pe­na­liz­za­zio­ni e po­ten­zia­li clienti co­min­cia­no a mostrare sfiducia. Questo può causare perdite fi­nan­zia­rie, pertanto sia che siate gestori di siti sia semplici utenti dovreste prendere as­so­lu­ta­men­te misure per evitare i Cross-site scripting.

Il modo più semplice per evitare i Cross-site scripting è di­sat­ti­va­re il supporto Ja­va­Script nel browser. Se Ja­va­Script è di­sat­ti­va­to, gli XSS basati su DOM che puntano a Ja­va­Script non hanno alcun effetto, in quanto l’ap­pli­ca­zio­ne dannosa non può neanche essere avviata. Per alcuni browser esistono inoltre add-on che aiutano a pro­teg­ger­si da attacchi XSS come ad esempio le esten­sio­ni NoScript per Mozilla. Nelle im­po­sta­zio­ni pre­de­fi­ni­te tutti i contenuti attivi dei siti come Ja­va­Script, Java-Applets, Adobe Flash o Microsoft Sil­ver­light sono bloccati in modo au­to­ma­ti­co. Su richiesta potete bloccare tem­po­ra­nea­men­te una pagina o metterla nella whitelist, se siete as­so­lu­ta­men­te sicuri che sia af­fi­da­bi­le. Un ultimo consiglio valido non soltanto per gli attacchi XSS: siate sempre scettici nei confronti di dati esterni, come i link, e metteteli sempre sotto la lente d’in­gran­di­men­to prima di uti­liz­zar­li.

Affinché le vostre ap­pli­ca­zio­ni web non offrano una base per attacchi XSS dovete in primo luogo con­si­de­ra­re come insicuri tutti i valori di input. Prima che il server li riceva, do­vreb­be­ro essere ana­liz­za­ti. In questo caso il metodo più sicuro, come avviene con l’add-on NoScript per i client, è quello di creare una whitelist. Se siete in grado di eseguire la scansione di in­for­ma­zio­ni sul vostro sito e abilitare soltanto contenuti af­fi­da­bi­li, create in questo modo una pro­te­zio­ne ec­cel­len­te contro attacchi Cross-site scripting.

Oltre ai valori immessi, anche i dati in uscita do­vreb­be­ro essere messi al sicuro.  Sarebbe quindi ne­ces­sa­rio che i pro­ble­ma­ti­ci me­ta­ca­rat­te­ri HTML vengano so­sti­tui­ti dai relativi ri­fe­ri­men­ti di caratteri; per questo i me­ta­ca­rat­te­ri vengono visti come caratteri normali e script po­ten­zial­men­te dannosi non vengono avviati. La maggior parte dei linguaggi di pro­gram­ma­zio­ne e di scripting come Perl, Ja­va­Script o PHP hanno a tale scopo funzioni già pre­de­fi­ni­te per la so­sti­tu­zio­ne o il ma­sche­ra­men­to di caratteri, che potete uti­liz­za­re senza esi­ta­zio­ne. Semplici attacchi XSS possono essere respinti grazie all’uso di firewalls.

Il Cross-site scripting co­sti­tui­sce spesso solo lo stadio iniziale per attacchi più ag­gres­si­vi, che potete sventare già sul nascere con una pro­te­zio­ne completa dei flussi di dati in entrata e in uscita del vostro server web.