Le Dieci Vulnerabilità più Critiche delle Applicazioni Web

Transcript

1 Le Dieci Vulnerabilità più Critiche delle Applicazioni Web Aggiornamento 2004 Gennaio 27, 2004 Copyright The Open Web Application Security Project (OWASP). Tutti I diritti riservati. E permessa la copia, distribuzione e modifica del presente documento purché venga mantenuta la nota antecedente che attribuisce I diritti sul medesimo di OWASP

2 Commenti La scoperta di nuove vulnerabilità a cadenza settimanale porta ad un sovraccarico di lavoro per mantenere aggiornati i sistemi allo stato dell arte. A questo scopo, vengono in aiuto le liste di vulnerabilità e le best practices. "L Open Web Application Security Project ha prodotto per le applicazioni Web e i Database una lista delle 10 vulnerabilità più critiche note, incluse le modalità per la messa in sicurezza delle stesse. Tali criticità vengono spesso sottovalutate, ma è importante capire che dovrebbero essere considerate come le problematiche a livello network. Se ogni singola azienda le eliminasse, di sicuro ne beneficerebbe la sicurezza dell intera Internet." J. Howard Beales, III, Direttore del Federal Trade Commission's Bureau of Consumer Protection, in occasione dell Information Technology Association of America's Internet Policy Committee, Venerdì, Dicembre 12, 2003 Una cattiva configurazione, disattenzioni e software con errori, possono creare disastri su Internet. Una delle principali aree di impatto delle vulnerabilità applicative è il WWW. Da progetto, I servizi web vengono considerati open e affidabili e di solito fungono da interfaccia per risorse importanti. Per questo motivo è necessario che vengano messi in sicurezza. Purtroppo la pletora di criticità riscontrate quotidianamente rende difficoltosa l individuazione di un punto d inizio da cui partire. La lista OWASP delle 10 vulnerabilità più critiche offre all utente una visione oggettiva su cui iniziare un analisi. Le società dovrebbero concentrare i loro sforzi su questi 10 punti, avendo la certezza di affronta re il problema della sicurezza applicativa su Web nel modo più efficiente possibile. Eugene H. Spafford, Docente di Computer Sciences, Purdue University e Direttore Esecutivo della Purdue University Center for Education and Research in Information Assurance and Security (CERIAS) Questa lista inizia a scalfire la punta di un enorme iceberg. La realtà che si nasconde è sconvolgente: La maggior parte dei software applicativi su Web è scritta in barba ai principi di sicurezza, di ingegnerizzazione del software, delle implicazioni di esecuzione e senza dubbio al senso comune. Dr. Peter G. Neumann, Principal Scientist, SRI International Computer Science Lab, Moderatore dell ACM Risks Forum, Autore di Computer-Related Risks Questa lista è importante allo stesso tempo sia per gli sviluppatori che per gli utenti e i produttori. Permetterà ai produttori di evitare gli errori compiuti centinaia di volte all interno delle applicazioni Web e darà agli utenti un set di requisiti base di sicurezza da chiedere ai produttori stessi, identificando così chi si attiene a queste linee guida fondamentali e chi no. Steven M. Christey, Principal Information Security Engineer and CVE Editor, Mitre La OWASP Top Ten mette in evidenza uno dei rischi più sottovalutati dagli svilupatori e dalle aziende che operano sul Web. Il comun denominatore di questa lista non è la caccia ai software con errori, bensì all assenza di un attenzione verso la sicurezza i n fase di sviluppo dell applicazione stessa. Il primo passo che ogni organizzazione dovrebbe compiere per indirizza re la propria attenzione verso la sicurezza applicativa è la messa in opera di questi 10 punti. Jeffrey R. Williams, Aspect Security CEO and OWASP Top Ten Project Leader "Non esiste alcuna bacchetta magica per la risoluzione dei problemi di sicurezza relativi alle applicazioni Web. Ciò richied e un ottimo team, molta esperienza, molto training e l utilizzo di soluzioni allo stato dell arte. La Top Ten OWASP fornisce un ottimo punto di partenza per comprendere il problema della sicurezza applicativa e per iniziare una gestione mirata delle risorse a propria disposizione." Mark Curphey, Fondatore dell OWASP e Direttore dell Application Security Consulting, Foundstone Strategic Security.

3 Dalle pagine Web al calcolo numerico, alcune aziende comprano programmi, molte li sviluppano e tutti li utilizzano. Nonostante tutto, errori di programmazione avvengono quotidianamente, anche da parte di persone con 50 anni di esperienza. L incapacità di imparare dai propri errori e da quelli del passato ci pone di fronte ad un numero di rischi elevato. Non dobbiamo meravigliarci se il numero di attacchi verso le applicazioni è in costante aumento. Nel compilare questa lista, OWASP ha fornito un grande servizio sia agli sviluppatori che agli utenti comuni. Ora dipende da loro l applicazione delle regole e delle best practices contenute all interno di questo fondamentale documento. Dr. Charles P. Pfleeger, CISSP, Master Security Architect, Cable & Wireless, Autore di Security in Computing La sicurezza è il nuovo ROI. Le aziende devono essere in grado di fornire applicazioni web e servizi web affidabili ai loro partner; i principali fruitori di questa tipologia di soluzioni sono le compagnie assicuratrici. Non dobbiamo però fermarci a questo; una cattiva gestione delle policy sulla sicurezza dei dati all interno di un azienda può mettere a repentaglio anche la parte commerciale. Scontentare i propri clienti è una cosa, tentare di recuperare i propri dati da un sistema corrotto è un altra. Robert A. Parisi, Jr., Senior VP and Chief Underwriting Officer, AIG ebusiness Risk Solutions Gli sviluppatori web dovrebbero sapere che il grado di protezione attribuito alle applicazioni e ai dati contenuti in esse è direttamente proporzionale al modo in cui scrivono il codice. La Top Ten OWASP rappresenta un ottimo punto di partenza per capire come programmare in sicurezza e per evitare i buchi che affliggono le applicazioni web Chris Wysopal, Direttore del Research & Inc. Le aziende mediche hanno un bisogno primario nel fornire applicazioni web che tutelino la privacy dei fruitori. La Top ten OWASP aiuterà le organizzazioni mediche a valutare la sicurezza delle applicazioni e soluzioni Web. Qualsiasi organizzazione che utilizza app licazioni contenenti tali criticità potrebbe avere difficoltà nell essere conforme alle norme HIPAA Lisa Gallagher, Senior VP, Information and Technology Accreditations, URAC "Con l aumento del numero di aziende che affidano in outsourcing la creazione di applicazioni web, lo sviluppo di soluzioni Web Security-oriented dovrebbe essere prioritario. La OWASP Top Ten affronta le vulnerabilità più diffuse, fornendo uno strumento fondamentale per la stes ura d i policy aziendali per la sicurezza delle applicazioni Web oriented." Stuart McClure, President and CTO of Foundstone Inc. Di solito la sicurezza delle applicazioni viene affrontata da specialisti del settore, dopo che lo sviluppo è terminato e tutti i requisiti di business sono stati rispettati. In Oracle abbiamo riscontrato che la messa in sicurezza dei software ha più successo se effettuata fin dalla fase di sviluppo. Gli sviluppatori devono avere una conoscenza di base delle vulnerabilità più diffuse e allo stesso tempo devono conoscere il modo in cui evitarle, mentre i manager che si occupano del rilascio dei prodotti debbono controllare es clusivamente che tutti i requisiti di sicurezza siano rispettati. La OWASP Top Ten è un ottimo punto di partenza per gettare le basi di una consapevolezza del problema security tra gli sviluppatori e per preparare una checklist da rispettare in fase di sviluppo. John Heimann, Direttore della Security in Oracle Corp. In molti hanno vis to in rete elenchi di vulnerabilità risolvibili con patching. Queste però indicano solo la presenza di criticità di pro grammi di terze parti che puoi o meno avere in esecuzione sulla tua rete. L utilizzo di questa Top Ten permetterà al software sviluppato di essere al di fuori di tutte queste liste! John Viega, Chief Scientist, Secure Software Inc., co-autore di Building Secure Software

4 Indice Introduzione... 1 Background... 3 Novità... 4 La Top Ten OWASP... 5 A1 Unvalidated Input... 7 A2 Broken Access Control... 9 A3 Broken Authentication e Session Management A4 Cross-Site Scripting (XSS) A5 Buffer Overflow A6 Injection Flaw A7 Improper Error Handling A8 Insecure Storage A9 Denial of Service A10 Insecure Configuration Management...27 Conclusioni... 29

5 Introduzione Il progetto Open Web Application Security Project (OWASP) è stato creato per aiutare le aziende e le organizzazioni a capire e migliorare la sicurezza delle loro applicazioni e dei servizi web. La Top Ten è stata creata per focalizzare l attenzione verso le vulnerabilità più critiche. La sicurezza delle applicazioni web è diventata un argomento fondamentale dal momento che moltissime aziende cercano di rendere disponibili in rete un numero sempre più crescente di contenuti e servizi. Nello stesso tempo, gli hacker hanno rivolto l attenzione verso gli errori di sviluppo comunemente inseriti dagli sviluppatori. Quando un organizzazione pubblica un servizio web è come se invitasse tutto il mondo ad inviare richieste http. Gli attacchi contenuti all interno di queste attraversano firewalls, filtri, piattaforme di sicurezza e sistemi IDS senza lasciare traccia in quanto si trovano all interno di richieste http legittime. Anche i siti più sicuri che utilizzano SSL accettano queste richieste senza effettuare particolari controlli. Ciò significa che il codice della tua applicazione web è parte del tuo sistema di sicurezza. Con l aumentare del numero di applicazioni web all interno del tuo sistema aumenta anche il perimetro di esposizione. Le problematiche riportate in questa lista non sono nuove. La maggior parte di esse è ben nota da decenni. Purtroppo, per una serie di motivazioni, la maggior parte degli sviluppatori continua ad inserire sempre gli stessi errori all interno dei programmi mettendo a rischio non solo la sicurezza dei propri clienti, ma anche la sicurezza di tutta Internet. Non esiste una panacea per risolvere tutti questi problemi. Oggi l analisi e le tecnologie di protezione stanno migliorando, ma solitamente si riesce al massimo ad affrontare solo un set minimo di problematiche. Per affrontare gli argomenti riportati nel presente documento, le aziende dovranno cambiare la loro filosofia di sviluppo, occuparsi della formazione del personale, aggiornare i processi di sviluppo e utilizzare le tecnologie appropriate (quando necessario). La OWASP Top Ten comprende una lista di vulnerabilità che richiedono un intervento immediato. Eventuale codice esistente dovrebbe essere immediatamente controllato in quanto questi errori vengo sfruttati puntualmente dagli hacker. I progetti in fase di sviluppo dovrebbero includere nei documenti di requisiti, di progettazione e di test dei riferimenti a queste criticità per verificarne l assenza all interno del software. I project manager dovrebbero includere all interno della pianificazione preventivata un intervallo di tempo e del budget per le attività di sicurezza applicativa. Dovrebbero tener conto anche del training per gli sviluppatori, della creazione di policy di sicurezza applicativa, di prevedere dei meccanismi di sicurezza, dei penetration test e delle fasi di revisione del codice. Incoraggiamo le aziende ad adottare la OWASP Top Ten come standard base di sicurezza e ad impegnarsi nel produrre applicazioni Web esenti da tali vulnerabilità. Abbiamo preferito presentare questa lista seguendo il formato della Top Venti SANS/FBI in modo da facilitarne l uso e la comprensione. La lista SANS è focalizzata soprattutto su criticità a livello network e sulle infrastrutture applicative. Poiché ogni sito web è unico, la OWASP Top Ten è focalizzata su particolari tipi di vulnerabilità presenti di frequenti all interno di applicazioni Web. Queste categorie sono state standardizzate all interno dell OASIS Web Application Security (WAS) XML Project. Il contenuto di questa lista è il risultato dell analisi degli esperti OWASP, la cui esperienza include analisi di sicurezza per i servizi governativi, finanziari, farmaceutici, manifatturieri, e anche in ambienti di sviluppo software e di tecnologie. L obbietivo di questo documento è quello di introdurre le vulnerabilità Web apllicative più critiche. Si possono trovare numerosi libri e guide che descrivono tali criticità in dettaglio e forniscono una guida dettagliata per la loro rimozione. Una di queste è la Guida OWASP disponibile sul sito 1

6 La OWASP Top Ten è un documento in costante evoluzione. Include spiegazioni e indicazioni utili per eliminare questi tipi di vulnerabilità. E nostra premura aggiornare la lista e le istruzioni ogni qualvolta vengano individuati metodi e soluzioni più efficaci ed ovviamente siamo lieti di accettare anche il tuo aiuto. La tua esperienza nel bloccare attacchi esterni e nell eliminare queste criticità possono aiutare anche altre persone che verranno dopo di te. Inviaci eventuali suggerimenti via all indirizzo topten@owasp.org inserendo come soggetto OWASP Top Ten Comments Questo documento è stato tradotto dalla versione originale in italiano da Matteo Paolelli (matteo.paolelli@gmail.com). OWASP ringrazia l aiuto e il supporto di Aspect Security per il ruolo svolto nella fase di ricerca e di stesura del presente documento 2

7 Background La sfida per l identificazione delle vulnerabilità web più critiche è un impresa piuttosto ardua. Attualmente non esiste nemmeno uno standard comune sul significato del termine sicurezza applicativa web. Alcuni ritenevano che questa lista si dovesse focalizzare esclusivamente su problematiche di sicurezza che affliggono applicazioni web custom. Altri invece ritenevano utile includere tutto il livello applicativo, comprese le librerie, le configurazioni dei server e i protocolli a livello applicativo. Con la speranza di analizzare le problematiche più critiche per le aziende, abbiamo deciso di avere un ampia interpretazione del concetto di sicurezza applicativa web cercando di evitare le problematiche a livello network ed infrastrutturale. Un altro ostacolo è stato rappresentato dal fatto che ogni specifica vulnerabilità è unica così com è unico ogni sito web di ogni singola organizzazione. Avrebbe poco senso fare riferimento a vulnerabilità specifiche di particolari siti web per ogni singola organizzazione, soprattutto perché questi dovrebbero essere risolti nel momento in cui un ampia audience entra a conoscenza della singola vulnerabilità. Per questo abbiamo mantenuto la nostra analisi ad un livello più alto, individuando delle macrocategorie. Nella prima versione di questo documento, abbiamo pensato di classificare un ampio spettro di problemi all interno di categorie con un significato ben individuato. Sono state studiate una serie di classificazioni di vulnerabilità e i loro relativi schemi, ottenendo in questo modo un set di categorie. I fattori che caratterizzano una buona categoria di vulnerabilità includono criticità correlate tra di loro con contromisure simili e che si verificano spesso all interno delle applicazioni web. In questa versione del documento stiamo introducendo una schematizzazione raffinata. Tali schemi sono stati sviluppati durante il nostro lavoro svolto sul comitato tecnico dell OWASP WAS, nel quale abbiamo descritto un elenco di problematiche dalle quali i ricercatori possono descrivere delle firme in formato XML. Scegliere tra tutte le vulnerabilità disponibili le dieci più critiche, ha un suo indice di difficoltà. Allo stato delle cose non vi sono statistiche affidabili circa le problematiche di sicurezza relative alle applicazioni web. In futuro, sarà un nostro target primario analizzare la frequenza con la quale certe criticità si presentano all interno del codice applicativo ed utilizzare queste metriche per tarare la top ten. Com è ovvio, tale processo non avverrà nell immediato. Sappiamo che non c è una risposta giusta per poter affermare con certezza l appartenenza di una vulnerabilità ad una determinata categoria. Ogni organizzazione deve ponderare con certezza il peso dell impatto di una singola vulnerabilità sulle attività aziendali. Nello stesso tempo, la pubblicazione di questo elenco metterà in evidenza il rischio al quale sono esposte una vasta gamma di società. La stessa top ten non ha un ordine precostituito in quanto sarebbe impossibile determinare quale di esse può avere un impatto più significativo rispetto alle altre. Il progetto OWASP Top Ten è un attività in continua evoluzione con l obbiettivo di sensibilizzare il pubblico più ampio possibile in relazione alle problematiche di sicurezza applicativa web. Questo documento verrà aggiornato annualmente, partendo dalle discussioni presenti sulla mailing list OWASP e all indirizzo topten@owasp.org.. 3

8 Novità OWASP ha impiegato molto tempo da quando l'ultima top ten è stata rilasciata nel gennaio Questo aggiornamento incorpora tutte le discussioni, gli aggiornamenti, le opinioni e i dibattiti nella comunità di OWASP durante il corso dei 12 mesi passati. Ci sono state in generale delle leggere modifiche a tutte le parti della Top Ten, e solamente alcuni cambi notevoli: WAS-XML Allineamento Uno dei nuovi progetti iniziati nel 2003 è stato la creazione del Web Application Security Technical Committee (WAS TC) presso l OASIS. L obbiettivo del WAS TC è stato quello di produrre uno schema di classificazione per le vulnerabilità delle applicazioni web e di un modello per offrire una guida per poter effettuare delle stime di rischio. Infine, uno schema XML per descrivere le best pratice da utilizzare in fase di analisi e sulle macchine di test. Il progetto OWASP Top Ten ha utlizzato il WAS TC come riferimento per rivedere le singole categorie della Top Ten e fornire un approccio standardizzato per la classificazione delle vulnerabilità web. Il Glossario WAS definisce un linguaggio comune per l analisi della sicurezza applicativa web e OWASP ha scelto di ulitizzarlo in questo contesto. Aggiornamento sul Denial of Service L unica aggiunta all elenco delle categorie appartenenti alla Top Ten è stata quella riguardante il Denial of Service (A9). Da alcune ricerche effettuate, un vasto numero di organizzazioni sono vulnerabili a questo attacco. Basandoci sugli effetti e sulle conseguenze possibili per questa criticità, abbiamo deciso di includerlo all interno della Top Ten. Per integrare in modo ottimale questo nuovo item, abbiamo unito le vecchie categorie A9 (remote Administration Flaws) e A2 (Broken Access Control), considerandole come delle categorie speciali all interno della nuova A9 DoS. Ciò è stato possibile in quanto le soluzioni per il DoS sono le stesse delle precedenti categorie. La tabella riportata in seguito indica le variazioni effettuate sulla Top Ten e include il glossario WAS. Nuova Top Ten 2004 Top Ten 2003 Nuovo glossario WAS A1 Unvalidated Input A1 Unvalidated Parameters Input Validation A2 Broken Access Control A3 Broken Authentication and Session Management A2 Broken Access Control (A9 Remote Administration Flaws) A3 Broken Account and Session Management Access Control Authentication and Session Management A4 Cross Site Scripting (XSS) Flaws A4 Cross Site Scripting (XSS) Flaws Input Validation->Cross site scripting A5 Buffer Overflows A5 Buffer Overflows Buffer Overflows A6 Injection Flaws A6 Command Injection Flaws Input Validation->Injection A7 Improper Error Handling A7 Error Handling Problems Error Handling A8 Insecure Storage A8 Insecure Use of Cryptography Data Protection A9 Denial of Service N/A Availability A10 Insecure Configuration Management A10 Web and Application Server Misconfiguration Application Configuration Management Infrastructure Configuration Management 4

9 La Top Ten OWASP La lista che segue rappresenta l elenco delle vulnerabilità delle applicazioni web più critiche. Ogni singola vulnerabilità è corredata da una breve descrizione. Le vulnerabilità più critiche delle Applicazioni Web A1 Unvalidated Input Le informazioni ricevute a seguito di una richiesta, non vengono validate dall applicazione web. Questa tecnica può essere utilizzata per accedere alla parte di backend attraverso l applicazione web in questione. A2 Broken Access Control Non vengono applicate restrizioni appropriate su quello che possono fare o meno gli utenti. Un utente malintenzionato può accedere ad account di altri utenti, visualizzare file sensibili o utilizzare funzionalità non autorizzate. A3 A4 Broken Authentication and Session Management Cross Site Scripting (XSS) Flaws Le credenziali degli account e i token di sessione non sono protetti in modo adeguato. In questo modo possono essere compromesse le password, le chiavi, i cookie di sessione oppure altri token che permettono di bypassare le restrizioni di autenticazione per poter assumere un altra identità. L applicazione web può essere utlizzata come strumento per sferrare un attacco sul browser dell utente finale. Con questa vulnerabilità è possibile carpire il token di sessione, attaccare la macchina locale, oppure accedere ai contenuti protetti dell utente attaccato. A5 Buffer Overflows In alcune applicazioni web, alcuni componenti non eseguono un controllo formale sui caratteri in ingresso di alcune forme di linguaggio particolari. Ciò causa un crash dell applicazione, fornendo la possibilità di prendere controllo di un processo. Queste componenti possono essere CGI, librerie, drivers e componenti dell application server web. A6 Injection Flaws Alcune applicazioni web scambiano dei parametri quando accedono a parti esterne del sistema o al sistema operativo installato in locale. Se un utente malintenzionato riesce ad incapsulare dei comandi dannosi all interno di questi parametri, il sistema esterno può eseguirli dietro comando dell applicazione web A7 Improper Error Handling Sono condizioni d errore che si verificano durante normali operazioni quando queste non vengono gestite correttamente. In questo modo è possibile ottenere informazioni su sistema, creare indisponibilità del servizio, causare il blocco di alcuni sistemi di sicurezza oppure far crashare il server. A8 Insecure Storage Le applicazioni web utlizzano solitamente funzioni crittografiche per proteggere I dati e le credenziali di accesso. Tali funzioni e il codice utilizzato per integrarle all interno dell applicazione web molto spesso viene realizzato in modo grossolano, causando un indebolimento del sistema di protezione. A9 A10 Denial of Service Insecure Configuration Management Un utente può saturare una applicazione web con un numero di richieste pari da non permettere più l accesso all applicazione. In questo modo è possibile far disconnettere gli utenti dal proprio account oppure si può bloccare l intero servizio. Un ottima configurazione del server è necessaria per il corretto funzionamento dell applicazione. Spesso i server hanno un enorme insieme di parametri di 5

10 configurazione e spesso i settaggi standard non sono adeguati. 6

11 A1 Unvalidated Input A1.1 Descrizione Le applicazioni web utlizzano l input delle HTTP request (e spesso anche dai file) per determinare il tipo di risposta. Un utente può modificare parti di una HTTP request, incluso la url, la query string, gli header, i cookie, i form field e gli hidden field per provare a bypassare i meccanismi di sicurezza del sito. I nomi tipici degli attacchi che si basano su una simile tecnica includono: forced browsing, command insertion, cross site scripting, buffer overflow, format string attack, SQL injection, cookie poisoning e hidden field manipulation. Ognuna di queste singole tipologie verrà descritta più apporfonditamente in seguito. A4 Cross Site Scripting riguardano dati di input che contengono script da eseguire sui broswer degli utenti A5 Buffer Overflow riguardano dai di input formattati in modo da sovrascrivere il program execution space A6 Injection Flaw riguardano dati di input modificati in modo da contenere dei comandi eseguibili. Alcuni siti cercano di proteggersi filtrando in ingresso dati considerati pericolosi. Il problema è che i modi per codificare le informazioni sono innumerevoli. Questo tipo di formato non va confuso con la cifratura dei dati, poiché sono facilmente decodificabili. Nonostante questo, gli sviluppatori dimendicano spesso di decodificare tutti i parametri nella loro forma più semplice, prima di processarli. Tutti i parametri vanno convertiti nella forma più semplice altrimenti alcuni dati possono essere mascherati in modo da bypassare I filtri. Questo procedimento di semplificazione è noto come canonicalizzazione. Poiché tutti i dati HTTP in input possono essere rappresentati in formati molteplici, questa tecnica può essere utlizzata per nascondere qualsiasi tipologia di attacco descritta in questo documento. Ciò rende l operazione di filtraggio molto difficoltosa. Un sorprendente numero di applicazioni web utilizza meccanismi solo su lato client per validare i dati in ingresso. Questi meccanismi possono essere facilmente aggirati, lasciando l applicazione web senza alcuna protezione contro dei parametri dannosi. In tal modo è possibile generare una request HTTP usando tools come telnet. Non ci si deve preoccupare su ciò che lo sviluppatore ha previsto per la parte client. Da notare che il processo di validazione sul lato client è ideale per migliorare le performance, ma non ha alcun beneficio dal punto di vista della sicurezza. Per proteggersi da questi tipi di attacchi è necessario un controllo dal lato server. Una volta introdotti questi check, i controlli client-side possono essere inclusi per migliorare l utilizzo dell applicazione web da parte degli utenti e per diminuire il carico di traffico non lecito verso il server web. Questi tipi di attacchi stanno aumentando considerevolmente di numero grazie anche alla diffusione di strumenti che permettono di variare in maniera casuale i parametri utilizzati. L impatto di questo attacco non va sottovalutato. Un enorme numero di questi potrebbe essere bloccato se gli sviluppatori validassero i dati in ingresso prima di utilizzarli. Finché una applicazione web non ha un sistema centralizzato per la validazione delle request HTTP (e da qualsiasi altra sorgente), criticità basate su questa tipologia continueranno ad imperversare. A1.2 Sistemi Vulerabili Tutti I Web Server, gli Application Server e le applicazioni Web. A1.3 Esempi e Riferimenti OWASP Guide to Building Secure Web Applications and Web Services, Capitolo 8: Data Validation Modsecurity project (modulo di Apache per la validazione HTTP) How to Build an HTTP Request Validation Engine (J2EE validation with Stinger) Have Your Cake and Eat it Too (.NET validation) 7

12 A1.4 Come determinare se si è vulnerabili o meno Qualsiasi parte di una HTTP request non validata da un sistema di controllo server-side è marcata come pericolosa. Il modo più semplice per trovare dei parametri dannosi è quello di procedere ad una accurata revisione del codice, cercando tutte le chiamate in cui l informazione è estratta da una HTTP request. Per esempio, in una applicazione J2EE abbiamo la classe HttpServletRequest. Dopodiché è sufficente eseguire il codice per vedere dove questa variabile viene utilizzata. Se la variabile non è controllata prima del suo uso, molto probabilmente c è un errore. In Perl, si dovrebbe considerare il caso di utilizzare l opzione T Taint. E altresì possibile visualizzare l uso di parametri tainted attraverso dei tool come il WebScarab OWASP. Inserendo valori non conformi all interno di HTTP request e analizzando la risposta dell application server, si può controllare dove questi valori vengono utilizzati A1.5 Come Proteggersi Il modo migliore per proteggersi è quello di assicurarsi che i parametri vengano validati prima di un loro effettivo utilizzo. Un componente centralizzato o una libreria è di sicuro il modo più efficiente, in quanto l operazione di controllo del codice viene effettuata nello stesso momento. Ogni singolo parametro dovrebbe essere analizato in modo tale da specificare quale tipo di dato possa essere ammesso in ingresso. Sistemi di controllo basati su firme o su liste di dati considerati dannosi si rivelano molto spesso insufficenti e difficile da manutenere. I parametri da controllare in fase di validazione sono: Il tipo di dato (string, integer, real, etc ) Il set di caratteri consentito La lunghezza minima e massima Controllare se è permesso il tipo NULL Controllare se il parametro è richiesto o meno Controllare se sono permessi i duplicati Intervallo numerico Specificare i valori ammessi (numerazione) Specificare i pattern (espressioni regolari) Una nuova tipologia di dispositivi di sicurezza noti come web application firewall, possono fornire un meccanismo di validazione. In modo da essere efficente, il dispositivo deve essere configurato in modo tale da avere una classificazione ben precisa di ciò che sia permesso o meno per ogni singolo parametro del sito web. Ciò include una protezione adeguata per tutti i tipi di dati ricevuti da una HTTP request, inclusi le URL, i form, i cookie, le query string, gli hidden field e i parametri. Il progetto OWASP Filters si occupa di creare delle componenti utilizzabili in svariati linguaggi per prevenire il maggior numero di vulnerabilità legate a problemi di validazione. Il motore di validazione Stinger HTTP request stinger.sourceforge.net è stato sviluppato dall OWASP per gli ambienti J2EE. 8

13 A2 Broken Access Control A2.1 Descrizione Il controllo degli accessi, noto come processo di autorizzazione, è il modo in cui una applicazione web permette l accesso a contenuti e funzioni per alcuni utenti piuttosto che altri. Questi controlli vengono eseguiti dopo la fase di autenticazione e servono per decidere cosa gli utenti possano fare o meno. Il controllo degli accessi sembra un problema semplice ma spesso nasconde delle difficoltà di implementazione. Un sistema di accesso web è spesso correlato al contenuto e alle tipologie di funzioni fornite dal sito. In aggiunta, gli utenti possono essere raggruppati in un numero di gruppi o ruoli con differenti credenziali e privilegi. Gli sviluppatori sottostimano spesso la difficoltà di implementare un sistema di controllo degli accessi affidabile. La maggior parte di questi schemi non sono stati sviluppati ad hoc ma si sono semplicemente evoluti assieme al sito web. In questi casi, le regole per il controllo degli accessi sono inserite in varie posizioni all interno del codice. In questo modo, diventa praticamente impossibile capire il metodo utilizzato nel momento in cui ci si avvicina alla fase di pubblicazione del sito. Non è difficile scoprire ed exploitare degli schemi di accesso vulnerabili. Ciò che viene eseguito più di frequente è cercare di richiamare funzioni o contenuti che non potrebbero essere accessibili. Una volta scoperto l errore, le conseguenze possono essere devastanti. Oltre che a visualizzare contenuti senza avere le necessarie credenziali, è possibile modificare e cancellare i dati, eseguire funzioni non autorizzate oppure prendere controllo dell amministrazione del sito. Un problema tipico dei sistemi d accesso riguarda le interfacce amministrative che permettono la gestione di un server web via internet. Queste interfacce vengono usate spesso per la gestione degli utenti, dei dati e dei contenuti. In molti casi i siti permettono di disporre di una elevata granularità di profili amministrativi. A causa di tutto ciò, queste interfacce sono i primi bersagli utilizzati per attacchi interni o esterni. A2.2 Sistemi Vulnerabili Tutti i server web, gli application web server e gli ambienti di sviluppo web sono vulnerabili a questi attacchi. Anche i server web statici, se non correttamente configurati, possono essere attaccati utlizzando questi metodi. A2.3 Esempi e Riferimenti OWASP Guide to Building Secure Web Applications and Web Services, Capitolo 8: Access Control: Access Control (aka Authorization) in Your J2EE Application A2.4 Come determinare se si è vulnerabili o meno Virtualmente ogni sito ha dei requisiti per il controllo degli accessi, perciò una policy di controllo accessi deve essere documentata in maniera inequivocabile. In aggiunta, la documentazione di progetto deve contenere dei punti nei quali viene incoraggiato un rafforzamento di questa policy. Se tale documentazione non è presente, molto probabilmente il sito risulterà vulnerabile. Allo stesso modo, anche la parte di codice che implementa le policy di controllo degli accessi deve essere verificata. Tale codice dovrebbe essere ben strutturato, modulare e preferibilmente centralizzato. Dovrebbe essere eseguita una revisione puntuale del codice per validarne la corretta implementazione. In aggiunta, potrebbe essere utile eseguire dei penetration test per determinare eventuali problemi nello schema di controllo accessi. 9

14 E necessario controllare anche il modo in cui viene gestita la fase di amministrazione: come vengono applicate le modifiche alle pagine web e come queste vengo pubblicate sul server di produzione. Se gli amministratori possono apportare tali modifiche da remoto, è necessario capire quali sono i canali di accesso e se lo scambio di dati avviene in maniera protetta. Controlla ogni singola interfaccia in modo che solo gli amministratori autorizzati possano accedervi. Se vi sono diversi tipi di raggruppamento di dati che possono essere accessibili attraverso l interfaccia, assicurati che solo i dati autorizzati possano essere visionati. Se tali interfaccie utilizzano comandi esterni, revisiona l utilizzo di questi comando per assicurarti che nessuno di questi sia soggetto alle vulnerabilità di command injection descritte in questo documento. A2.5 Come proteggersi Il passo più importante è quello di pensare ad uno schema di accesso e trasformarlo in una policy di sicurezza applicativa. Noi raccomandiamo l uso di una matrice di controllo d accesso per definire le singole regole. Senza una documentazione della policy, non c è una definizione di ciò che è ritenuto sicuro per un sito. Nella policy vanno indicati gli utenti che possono accedere al sistema e a quali funzioni e contenuti ognuno di questi utenti può accedere. Tale meccanismo deve essere testato a lungo per assicurarsi che non vi sia possibilità di bypassarlo. Questo tipo deve prevedere il controllo di un ampia tipologia di account e vari tentativi per accedere a contenuti o funzioni non autorizzate. Alcune problematiche tipiche di uno schema d accesso sono: Insecure ID la maggior parte dei siti web utlizza dei tipi di ID, chiavi o indici per identificare utenti, ruoli, contenuti, oggetti o funzioni. Se un utente cattura queste informazioni ei valori forniti al sistema non vengono validati per verificarne l utente che esegue tale operazione, si può prendere controllo dei sistema d accesso e visionare qualsiasi tipo di dato o funzione. Le applicazioni web non dovrebbero affidarsi solo sulla segretezza degli ID di accesso. Forced Browsing supera i controlli di accesso molti siti prevedono che gli utenti debbano passare alcuni controlli prima di avere accesso ad URL spesso nidificati profondamente nel sito. Questi check non devono essere facilmente aggirabili da un utente che provi a saltare la pagina con il controllo di sicurezza. Path Traversal questo attacco include nella http request informazioni di path relativo (es.../../target_dir/target_file ). Con questo tipo di attacchi è possibile accedere a file che normalmente non sono direttamente accessibili da nessuno, oppure sarebbero negati. E possibile sfruttare questo attacco con delle URL formattate ad hoc oppure in qualsiasi dato in input che tenta di accedere ad un file (es. chiamate di sistema e comandi shell). File Permission molti server web utilizzano sistemi di controllo d accesso forniti dal file system della piattaforma in uso. Anche se tutti i dati vengono conservati su server posizionati nel backend, ci sono sempre dei file conservati localmente sui web e application server che non devono essere accessibili da tutti (file di configurazione, file default e script). Solamente i file che devono essere visualizzati dagli utenti via web devono essere marcati come leggibili usando il sistema di gestione dei permessi del sistema operativo (la maggior parte delle directory deve essere nascosta e pochissimi file se non nessuno, deve essere marcato come eseguibile). Client Side Caching molti utenti accedono alle applicazioni web da computer nelle librerie, scuole, aeroporti e altri luoghi pubblici. Le pagine contenute nella cache del browser possono essere usate per accedere a dati altrimenti inaccessibili. Gli sviluppatori dovono usare dei meccanismi multipli, inclusi gli HTTP headers e i meta tags per essere sicuri che le pagine contenenti dati e/o informazioni sensibili non siano conservate nella cache dei browser degli utenti. Vi sono alcuni componenti che possono essere di ausilio nel tentativo di rinforzare i propri meccanismi di accesso. Così come per la validazione dei parametri, tali componenti devono essere configurati con un set di definizioni ben precise sui quali le richieste di accesso siano valide o meno per il sito web considerato. Nell uso di questi componenti è necessario capire esattamente il tipo di aiuto che viene fornito per migliorare le policy d accesso al sito e quali altri punti non riesce a gestire, in modo da poterlo inserire all interno del codice nel modo più appropriato. Per le funzioni amministrative, la raccomandazione primaria è quella di non permettere l amministrazione del sito attraverso l interfaccia principale. Abilitando tali interfacce, la maggior parte delle organizzazioni devono accettare il rischio di rendere disponibili tali interfacce da eventuali attacchi esterni. Se è necessaria una amministrazione remota, questa può essere effettuata senza fornire un accesso diretto alla macchina. In aiuto vengono le tecnologie VPN, le quali sono in grado di fornire ad un amministratore esterno accesso al sito in modo sicuro attraverso una connessione protetta sul backend. 10

15 A3 Broken Authentication e Session Management A3.1 Descrizione La gestione della fase di sessione web include tutti le sezioni di autenticazione degli utenti e di gestione delle sessioni attive. Il processo di autenticazione è estremamente critico, ma c è da dire che anche i meccanismi più solidi di autenticazione possono essere indeboliti da funzioni di amministrazione delle credenziali, inclusi i cambi password, l aggiornamento degli account e altre funzioni collegate. Poiché questa tipologia di attacchi è comune a molte applicazioni web, tutte le funzioni di gestione autenticazione devono richiedere una riautenticazione anche se l utente ha un ID di sessione valido. La gestione degli utenti su web coinvolge tipicamente l utilizzo di una user id e di una password. Sono disponibili commercialmente dei metodi di autenticazione più efficaci (ad esempio software e dispositivi crittografici hardware tipo token o interfacce biometriche). Il problema principale di questi sistemi è legato al loro costo che potrebbe essere proibitivo per la maggior parte delle applicazioni web. Un elevato numero di vulnerabilità relative alla gestione degli account e di sessione può compromettere il sistema di amministrazione degli account. La maggior parte dei team di sviluppo sottovaluta la complessità nello sviluppare degli schemi di autenticazione e di gestione di sessione in modo da poter proteggere le credenziali degli utenti in tutti gli aspetti del sito. Le applicazioni web devono instaurare delle sessioni per tenere traccia delle http request per ogni singolo utente. L HTTP non fornisce questo tipo di controllo, per questo motivo gli sviluppatori devono crearle ad hoc. Molto spesso, l ambiente di sviluppo fornisce capacità di creazione delle sessioni, ma la maggior parte dei programmatori preferisce crearsi i propri token di sessione. In ambedue i casi, se i token di sessione non vengono protetti adeguatamente, un utente maleintenzionato può dirottare una sessione attiva e assumere l identità di un utente. La creazione di uno schema di autenticazione sicuro e affidabile è stata spesso trascurata. Fino a che tutte le credenziali di autenticazione e gli indentificativi di sessione non verranno protetti tramite canale SSL, in qualsiasi momento è possibile eseguire attacchi come il cross site scripting tali da permettere ad un utente di dirottare una sessione e assumere l identità di un altro. A3.2 Sistemi Affetti Tutti i server web, gli application server e gli ambienti di sviluppo web, sono vulnerabili al broken authentication e alle problematiche di session management. A3.3 Esempi e Riferimenti OWASP Guide to Building Secure Web Applications and Web Services, Capitolo 6: Authentication and Capitolo 7: Session Management: White paper on the Session Fixation Vulnerability in Web-based Applications: White paper on Password Recovery for Web-based Applications

16 A3.4 Come determinare se si è vulnerabili o meno Sia la revisione del codice che i penetration test possono essere utilizzati per diagnosticare i problemi di autenticazione e di gestione della sessione. Controlla ogni aspetto dei meccanismi di autenticazione per assicurarti che le credenziali degli utenti siano sempre protette in ogni situazione, mentre sono memorizzate in locale (ad esempio sul disco fisso) e quando sono in transito (ad esempio durante la fase di login). Controlla ogni meccanismo disponibile per modificare le credenziali di un utente in modo da assicurarti che solo l utente autorizzato possa cambiarle. Controlla i tuoi meccanismi di gestione della sessione per assicurarti che gli identificativi di sessione siano protetti sempre e che siano utilizzati in modo dai minimizzare la possibilità di tentativi di modifiche accidentali e/o volute. A3.5 Come proteggersi Un utilizzo attento ed appropriato di meccanismi di gestione di autenticazione e sessione (sia personalizzato che non), dovrebbe ridurre significativamente ogni possibilità di problemi. Un primo passo è senza dubbio quello di definire e documentare le policy in uso nel sito, rispettando una gestione sicura delle credenziali degli utenti. La chiave per avere dei meccanismi affidabili è quella di implementare consistentemente tali policy. Alcune aree critiche sono: Efficacia della password le password dovrebbero avere delle restrizioni in riguardo al numero minimo di caratteri e alla complessità della password stessa. La complessità tipicamente richiede l uso di combinazioni di caratteri alfabetici, numerici e non numerici. Gli utenti dovrebbero cambiare la propria password periodicamente. Allo stesso modo dovrebbe essere inibita la possibilità di utilizzare password già scadute precedentemente. Uso della password dovrebbe essere configurato un numero prefissato di tentativi di login per unità di tempo. I tentativi falliti dovrebbero essere loggati. Le password errate, utilizzate nella fase di login, non dovrebbero essere conservate. Ciò permetterebbe di carpire la password dell utente, una volta entrati in possesso dei log. Il sistema non dovrebbe indicare se l username o la password sono stati inseriti erroneamente in fase di login. L utente dovrebbe essere informato della data dell ultimo tentativo (avvenuto positivamente) di login. Anche il numero di tentativi errati dall ultimo login effettuato dovrebbe essere conservato. Controlli per il cambio della password un singolo meccanismo di cambio password dovrebbe essere utilizzato (in qualsiasi situazione). Gli utenti dovrebbero fornire al sistema la vecchia e la nuova password (qualora decidano di modificarla). Se le password dimenticate dovessero essere inviate via agli utenti, il sistema dovrebbe chiedere all utente di riautenticarsi (anche se l utente sta cambiando il proprio indirizzo ). In questo caso un utente malintenzionato (che accede temporaneamente alla sessione), può semplicemente cambiare l indirizzo e ricevere la password dimenticata. Archiviazione delle password tutte le password devono essere conservate sotto forma di hash oppure cifrate in qualsiasi modo esse vengano conservate. E preferibile l utilizzo di una funzione di hash, in quanto non reversibile. La cifratura dovrebbe essere utilizzata quando, per necessità, la password deve essere mostrata in chiaro. Le password non dovrebbero essere mai cablate in nessun codice sorgente. Le chiavi di decifrazione devono essere protette in modo da assicurarne l integrità e la riservatezza massima. Protezione delle credenziali in transito l unica tecnica efficiente è quella di proteggere tutta la fase di login utlizzando protocolli come SSL. La semplice trasformazione in hash della password, prima della trasmissione della medesima, fornisce una scarsa protezione. La transazione potrebbe essere intercettata e ritrasmessa anche se l attuale password non è nota. Protezione del Session ID la sessione utente dovrebbe essere protetta con SSL. Se ciò viene realizzato, nessuno può intercettare il session ID, cosa che rappresenta il rischio più elevato. Se per motivi di performance ciò non fosse possibile, il session ID va protetto in altri modi. Per prima cosa, non deve essere mai incluso nella URL, in quanto potrebbe essere intercettato dal browser, inviato tramite l http referer o accidentalmente inoltrato ad un altro sito. I session ID dovrebbero essere lunghi e complicate catene di numeri randomici che non possano essere facilmente indovinati. I session ID dovrebbero anche cambiare di frequente durante una sessione. Tutto questo per ridurre la durata di validità di un session ID. I session id dovrebbero cambiare quando si passa ad utilizzare protocolli come SSL. Valori di Session ID scelti da un utente non dovrebbero essere mai utilizzati. 12

17 Liste di Account i sistemi dovrebbero essere progettati in modo da evitare l accesso alla lista dei nomi degli account presenti sul sito. Se queste liste devono essere mostrate, si raccomanda di usare degli pseudonimi che mappano i nomi veri degli account. In questo modo, lo pseudonimo non può essere utlilizzato per un tentativo di login o per altri metodi di attacco su di un account utente. Cache del browser i dati di autenticazione e di sessione non dovrebbero mai essere trasmessi come parte della GET; al contrario dovrebbero essere utlizzate sempre delle POST. Le pagine di autenticazione dovrebbero essere marcate con il tag no cache ; in questo modo si può prevenire la possibiltà di usare il tasto back per tornare alla schermata di login e reinviare le credenziali utilizzate precedentemente. Molti browser supportano il flag autocomplete=false per prevenire la conservazione delle credenziali all intero della autocomplete cache. Trust Relationship l architettura del sito deve evitare il trust implicito tra le varie componenti quando possibile. Ogni singolo componente dovrebbe autenticare sé stesso ad un altro componente col quale sta interagendo, a meno che ci sia un ottima ragione per non farlo (problemi di performance o mancanza di un meccanismo utlizzabile). Se sono richieste delle relazioni di trust, è necessario implementare delle procedure e dei meccanismi architetturali estremamente ristrettivi, in modo che non si possa abusare di tale trust (a causa dell evoluzione architetturale del sito nel tempo). 13

18 A4 Cross-Site Scripting (XSS) A4.1 Descrizione Le vulnerabilità di cross-site scripting (indicate solitamente con XSS) si verificano quando un utente utilizza un applicazione web per inviare del codice malevolo, generalmente sotto forma di script, ad un altro utente. Questi script tendono a distribuirsi con una rapidità estrema e si verificano ovunque una applicazione web utilizzi dei dati in ingresso da un utente, senza eseguire un controllo formale su essi. Un utente può utilizzare il XSS per inviare codice ad chiunque. Il browser del destinatario di tale attacco non ha possibilità di capire che tale script non dovrebbe essere eseguito. Poiché il browser crede che lo script provenga da una sorgente fidata (il server web con il quale interagisce), il codice è in grado di accedere ai cookie, ai token di sessione oppure ad altre informazioni sensibili conservate dal browser ed utilizzate sul sito in essere. Questi script possono anche riscrivere il contenuto della pagina HTML. Gli attacchi di XSS possono essere raccolti in due categorie: stored e reflected. Gli attacchi di tipo stored sono quelli in cui il codice modificato è conservato permanentemente sui server target, ad esempio nei data base, nel messaggio di un forum, nel log dei visitatori, nel campo commenti etc. La vittima riceve lo script dal server una volta che cerca di accedere all informazione richiesta. Gli attacchi di tipo Reflected appartengono a quella tipologia in cui il codice modificato è reinviato dal server (messaggio di errore, risultati di ricerca oppure tutti gli altri tipi di risposte che includono tutto o parte dei dati in ingresso inviati al server nella request HTTP). Gli attacchi reflected vengono inviati ai destinatari attraverso altri strumenti (ad esempio nei messaggi oppure posizionati sui web server). Nel momento in cui un utente clicca su un link modificato oppure invia un form (adeguatamente modificato), il codice viaggia attraverso il server web vulnerabile, il quale reinvia l attacco al browser dell utente. Di conseguenza, il browser esegue il codice (poiché proviene da un server fidato ). Le conseguenze di un attacco di XSS sono le stesse (sia per la tipologia stored che per quella reflected ). La differenza risiede nel modo in cui il codice arriva al server. Non bisogna farsi ingannare nel pensare che un sito in sola lettura oppure di tipo vetrina sia non vulnerabile ad attacchi di XSS. Il XSS è in grado di provocare una serie di problemi per l utente finale, spaziando da problemi banali (come ad esempio mail indesiderate etc.) fino ad arrivare alla compromissione del proprio account. Gli attacchi di XSS più critici coinvolgono l acquisizione dei cookie di sessione dell utente, permettendo di entrare in possesso della sessione dell utente (completo controllo dell account). Altri attacchi riguardano la perdita di riservatezza dei file dell utente finale, l installazione di cavalli di troia, il reindirizzamento dell utente su alcuni siti o pagine web e la modifica del contenuto delle pagine visualizzate. Una vulnerabilità di XSS può permetere di modificare un agenzia di stampa oppure una news, causando (ad esempio) la variazione del valore delle azioni di una azienda. Un altro esempio potrebbe essere il danno causato ad una casa farmaceutica in seguito alle modifiche del dosaggio di un medicinale. Le tecniche frequentemente utilizzate prevedono un numero variabile di metodi per codificare la parte modificata del tag (ad esempio utilizzando l Unicode), in modo tale da rendere la richiesta meno sospetta per l utente. Vi sono centinaia di variabili d attacco possibili, incluse le versioni che non richiedono alcun simbolo < >. Per questa ragione, il tentativo di filtrare questi script, ha poche possibilità di successo. Al contrario, OWASP consiglia di validare i dati in ingresso in modo estremamente rigoroso (ovvero, prevedere quali sono gli unici tipi di dati che l applicazione è in grado di validare). Gli attacchi di XSS normalmente si trovano incapsulati nei Javascript. Come sempre, qualsiasi contenuto attivo può essere una fonte di pericolo: ActiveX (OLE), Vbscript, Shockwave, Flash ed altri. Le vulnerabilità di XSS possono presentarsi anche all interno di web application server. La maggior parte dei web application server genera delle semplici pagine web per visualizzare eventuali messaggi d errore (pagine 404 page not found, 500 internal server error ). Se queste pagine contengono parte delle informazioni richieste dall utente (per esempio l URL che si è tentato di accedere), potrebbero essere vulnerabili ad un attacco XSS. L eventualità che un sito contenga vulnerabilità di tipo XSS è estremamente elevata. Ci sono una varietà di modi per indurre applicazioni web a reindirizzare del codice artefatto. Gli sviluppatori che tentano di filtrare in uscita la maggior parte di queste request, molto spesso sottovalutano possibili attacchi o dati incapsulati. Ricercare queste criticità non è difficoltoso, poiché tutto ciò di cui si necessita è solo l accesso ad un broswer e del tempo a disposizione. Sono fruibili un ampio numero di strumenti gratuiti per individuare eventuali falle nei sistemi e allo stesso tempo per creare del codice modificato e tentare un attacco di XSS. 14

19 A4.2 Sistemi Vulnerabili Tutti I server web, gli application server e gli ambienti di sviluppo web sono affetti da vulnerabilità di tipo XSS A4.3 Esempi e Riferimenti The Cross Site Scripting FAQ: CERT Advisory on Malicious HTML Tags: CERT Understanding Malicious Content Mitigation Cross-Site Scripting Security Exposure Executive Summary: Understanding the cause and effect of CSS Vulnerabilities: OWASP Guide to Building Secure Web Applications and Web Services, Capitolo 8: Data Validation How to Build an HTTP Request Validation Engine (J2EE validation with Stinger) Have Your Cake and Eat it Too (.NET validation) A4.4 Come determinare se si è vulnerabili o meno E molto difficile identificare e rimuovere, da una applicazione web, delle vulnerabilità di XSS. Il modo migliore per riscontrarle è quello di eseguire una revisione del codice ed identificare tutti i punti in cui i dati in ingresso da una HTTP request possano transitare all interno di un output HTML. E da tenere presente che una varietà di tag HTML può essere utilizzata per inviare un javascript artefatto. Alcuni tool come Nessus, Nikto e altri, possono aiutare nella ricerca di queste falle, anche se sono in grado di eseguire un controllo superficiale. Se parte di un sito web dovesse risultare vulnerabile, molto probabilmente ci saranno problemi anche in altre parti. A4.5 Come Proteggersi Il miglior modo per proteggere una applicazione web da attacchi di XSS è quello di assicurarsi che vegna effettuato un controllo di validazione dei dati in ingresso in modo estremamente rigoroso (rispetto ai dati ritenuti ammissibili per l applicazione) per gli header, i cookie, le query string, i campi form e i file nascosti (ad esempio, tutti i parametri). La fase di validazione non dovrebbe cercare di identificare e rimuovere i componenti attivi. Ci sono troppe tipologie di contenuti attivi e troppi modi per poterli codificare, in modo da eludere eventuali filtri. OWASP raccomanda l applicazione di una policy di sicurezza che specifichi esattamente la tipologia dei dati da trattare. Policy basate su firme digitali o liste di falsi positivi, sono di complessa gestione e tendono ad essere incomplete. La codifica degli output di un utente è in grado di inibire delle falle di XSS, prevenendo l inserimento di script dall essere trasmessi all utente in modo da poterli eseguire in locale. Le applicazioni possono beneficiare di un livello di protezione significativo, convertendo i seguenti caratteri all interno degli output generati nell appropriato HTLM entity encoding: Da: A: < < > > ( ( ) ) # # & & Il progetto OWASP Filters produce dei componenti riutilizzabili in vari linguaggi di programmazione, per prevenire la maggior parte delle falle di tampering dei parametri, incluso il XSS. OWASP ha anche rilasciato CodeSeeker, un firewall che lavora 15

20 a livello applicativo. In aggiunta, il programma di training OWASP Web Goat include lezioni sul Cross Side Scripting e sulla codifica dei dati. 16