Come detto negli articoli precedenti, il cross-site scripting è un problema complesso, che si sviluppa su due differenti fronti. Da un lato vi sono i browser web, la cui assenza di sicurezza è insita nella
stessa progettazione: essi sono realizzati al fine di soddisfare le richieste che vengono inoltrate, innocue o dannose che siano; non rientra dunque nei loro compiti verificarne la natura. Dall’altro lato, vi sono gli sviluppatori web che non creano applicazioni sicure, che possano opportunamente gestire eventuali vulnerabilità ad attacchi di cross-site scripting.
Se un’applicazione web non possedesse tali vulnerabilità, gestendo un opportuno filtraggio dei dati in ingresso, l’attaccante non avrebbe infatti modo di iniettare il proprio codice JavaScript malevolo che, di conseguenza, non avrebbe modo di giungere all’utente finale. In caso contrario, la vittima risulterebbe totalmente disarmata, avendo come unica possibile difesa il browser che, come già detto, non è in grado di offrire tale forma di sicurezza.
Per quanto detto, gran parte del sistema di prevenzione per attacchi XSS è demandato all’utente finale, il quale può agire in due modi distinti: disabilitare l’esecuzione di script da parte del browser o accedere solo ed esclusivamente a siti che ritiene sicuri. Il primo approccio è impensabile: ridurrebbe il campo d’azione dell’utente in rete e la sua possibilità ad accedere a tutti i contenuti che impiegano script, ovvero alla maggior parte di essi.
Di seguito verrà quindi trattata in dettaglio l’operazione di filtraggio, adottabile dai siti web come possibile contromisura ad attacchi di cross-site scripting.
Verranno inoltre descritte le tecniche sfruttabili dall’utente finale per evitare di diventare vittima di tali attacchi. Si noti che, anche in questo caso, la migliore arma resta comunque una buona dose di paranoia.
Continua a Leggere :
You may be the one to comment first. Please leave your message below.
