3. OWASP Top 10 2007
INTRODUZIONE
Benvenuto nella OWASP Top 10 2007! Questa nuova edizione, completamente riscritta,
elenca le vulnerabilità più critiche presenti nelle applicazioni web, discutendo su come è
possibile difenderle e fornendo ulteriori riferimenti per chi volesse approfondire l’argomento.
OBIETTIVO
L’obiettivo primario della OWASP Top 10 è quello di educare sviluppatori,
progettisti, analisti ed organizzazioni alla consapevolezza sui rischi delle più diffuse
vulnerabilità presenti nelle applicazioni web. La Top 10 fornisce inoltre le basi metodologiche
per la protezione delle applicazioni contro queste vulnerabilità, fornendo un buono spunto per
iniziare alcune attività di programmazione sicura.
La sicurezza non è una singola attività isolata. E’ inefficace sviluppare codice sicuro
solo durante le prime implementazioni della tua applicazione. Nel corso del 2008 e degli anni
successivi, la Top 10 potrebbe cambiare senza nemmeno cambiare una sola riga di codice
all’interno delle tue applicazioni e facendo diventare conseguentemente i sistemi vulnerabili.
Per maggiori informazioni si consiglia di leggere i suggerimenti presenti nella sezione Oltre la
OWASP Top 10.
L’attività di programmazione sicura deve interessare tutte le fasi del ciclo di
sviluppo del software. Applicazioni web sicure sono solamente possibili all’interno di un
SDLC sicuro. Programmi sicuri sono progettati e sviluppati intrinsecamente in maniera sicura.
Ci sono almeno 300 problematiche che affliggono la sicurezza delle applicazioni web; queste
300 e più tematiche sono dettagliate all’interno della OWASP Guide, la quale deve essere
considerata una guida essenziale per chiunque sviluppi applicazioni web oggi.
Questo documento è prima di tutto un testo educativo, non uno standard. Si prega
di non adottare questo documento come policy aziendale o standard senza prima informarci!
Se necessiti di policy per la programmazione sicura o standard, OWASP porta avanti alcuni
progetti sull’argomento. Considera anche la possibilità di partecipare attivamente o
finanziariamente agli sforzi della comunità.
RICONOSCIMENTI
Vogliamo ringraziare MITRE per aver dato la possibilità di usare la
Vulnerability Type Distribution in CVE in maniera libera.
Il progetto OWASP Top Ten è gestito e sponsorizzato da Aspect Security.
Capo Progetto: Andrew van der Stock (Executive Director, OWASP Foundation)
Co-autori: Jeff Williams (Chair, OWASP Foundation), Dave Wichers (Conference Chair, OWASP
Foundation)
Vogliamo ringraziare i nostri correttori di bozze:
· Raoul Endres per l’aiuto nel far progredire la Top 10 ed i suoi preziosi commenti
· Steve Christey (MITRE) per l’approfondita revisione e l’aggiunta dei dati MITRE
3
4. · Jeremiah Grossman (White Hat Security) per la revisione e per aver fornito contributi
riguardo i successi (e gli insuccessi) dei metodi di rilevamento automatici
· Sylvan von Stuppe per l’esemplare revisione del testo
· Colin Wong, Nigel Evans, Andre Gironda, Neil Smithline per i commenti inviati tramite
email
A nome del capitolo Italiano di OWASP, che ha curato la traduzione del presente documento,
si vuole ringraziare (rigorosamente in ordine alfabetico):
· Luca Carettoni
· Paolo Perego
· Simove Savi
4
5. OWASP Top 10 2007
SOMMARIO
A1 – Cross Site Scripting
(XSS)
La vulnerabilità denominata XSS si presenta ogni qualvolta
l’applicazione riceve dell’input dall’utente che poi viene inoltrato
al web browser, senza prima essere correttamente validato e
codificato. XSS permette ad un eventuale aggressore di eseguire
script all’interno del browser, introducendo la possibilità’ di
session hijacking, il defacement di siti, la propagazione di
worms, ecc.
A2 – Injection Flaws Le vulnerabilità definite “Injection flaws”, ed in particolare le SQL
Injection, sono tristemente comuni nelle applicazioni web. La
possibilità di inviare stringhe che sono interpretate
dall’applicazione come comandi e query rappresenta la
situazione ideale per questa categoria di vulnerabilità. Un
aggressore può quindi modificare il flusso di esecuzione con
l’intento di eseguire comandi e alterare dati.
A3 – Malicious File
Execution
Il codice sorgente vulnerabile a “Remote File Inclusion”
(abbreviata con RFI) permette ad un aggressore di includere
istruzioni e dati malevoli all’interno dell’applicazione con effetti
devastanti: nel peggiore dei casi è addirittura possibile la
completa compromissione del server remoto. Gli attacchi di
Malicious File Execution affliggono PHP, XML e qualsiasi altro
framework che accetta nomi dei file e path dagli utenti.
A4 – Insecure Direct
Object Reference
La vulnerabilità di “Direct Object Reference” si presenta quando
uno sviluppatore espone esternamente un riferimento ad un
componente o a parti dell’implementazione di oggetti come file,
directory, record di basi di dati, oppure di chiavi come URL o
parametri. Eventuali aggressori possono quindi manipolare
questi riferimenti in maniera da accedere a risorse senza previa
autorizzazione.
A5 – Cross Site Request
Forgery (CSRF)
Un attacco di CSRF costringe il browser di una vittima
autenticata in un sito Internet ad inviare una richiesta verso
l’applicazione web vulnerabile, in maniera da eseguire azioni
ostili a beneficio dell’aggressore. CSRF è tanto più dannoso e
potente quanto lo è l’applicazione che viene attaccata, in termini
di funzionalità.
A6 – Information Leakage
and Improper Error
Handling
Le applicazioni web possono consentire la fuga involontaria di
informazioni riguardanti la configurazione o le modalità di
funzionamento, nel momento in cui si presentano situazioni di
errore non gestite. Gli aggressori usano questa famiglia di
vulnerabilità per rubare dati confidenziali o portare a
compimento attacchi ben più seri.
A7 – Broken
Authentication and
Session Management
Credenziali utente e token di sessione sono spesso non
correttamente protetti. Gli aggressori possono compromettere
password, chiavi di cifratura o token di autenticazione in
maniera da impersonare altri utenti.
A8 – Insecure Le applicazioni web utilizzano raramente in maniera corretta i
5
6. Cryptographic Storage meccanismi di crittografica disponibili oggi per proteggere dati e
credenziali. Eventuali aggressori possono sfruttare le debolezze
di dati crittografati per perpetrare furti di identità e altri crimini
come le frodi con carta di credito.
A9 – Insecure
Communications
Frequentemente le applicazioni web non utilizzano alcuna
cifratura del traffico di rete anche quando sarebbe necessario
per proteggere comunicazioni confidenziali.
A10 – Failure to Restrict
URL Access
Altrettanto frequentemente, le applicazioni web proteggono
l’accesso a funzioni critiche solamente evitando di esporre link o
URL ad utenti non autenticati. Eventuali aggressori possono
usare questa debolezza per accedere ed eseguire operazioni a
cui non sono autorizzati, collegandosi direttamente a tali URL.
Table 1: Le 10 vulnerabilità più critiche nelle applicazioni web nel 2007
6
7. OWASP Top 10 2007
METODOLOGIA
La nostra metodologia, utilizzata per la top 10 2007, è semplice: analizzare i risultati della
MITRE Vulnerability Trends for 2006 ed estrarre le prime 10 problematiche in ambito web. I
risultati percentuali sono mostrati di seguito:
Figure 2: Dati MITRE rispetto alle prime 10 problematiche nelle applicazioni web durante il 2006
Sebbene si è cercato di preservare l’associazione uno a uno con i dati grezzi recuperati dalla
classificazione MITRE, abbiamo deliberatamente modificato alcune delle ultime categorie in
maniera da meglio riflettere la causa delle problematiche.
Se sei interessato alla classificazione finale MITRE con i dati grezzi del 2006, abbiamo
pubblicato un foglio Excel nella pagina dedicata alla OWASP Top 10, all’interno del sito
OWASP.
Tutte le raccomandazioni in termini di soluzioni difensive si riferiscono ai tre principali web
application framework: Java EE, ASP.NET e PHP. Per gli altri web application framework, come
Ruby on Rails o Perl, è possibile adattare facilmente le medesime raccomandazioni al fine di
soddisfare le specifiche esigenze imposte dai diversi ambienti.
PERCHE’ ALCUNE IMPORTANTI PROBLEMATICHE SONO STATE RIMOSSE
Le problematiche denominate “Unvalidated input” sono una delle principali sfide per ogni
team di sviluppo e spesso la radice di molti problemi di sicurezza nelle applicazioni. E’ infatti
possibile notare come molte delle problematiche nell’elenco abbiamo come raccomandazioni
risolutive la validazione dell’input utente. Suggeriamo fortemente di creare un unico
meccanismo di validazione centralizzato come componente delle vostre applicazioni web. Per
maggiori informazioni è possibile consultare i seguenti articoli di OWASP, relativi alla
validazione dei dati:
http://www.owasp.org/index.php/Data_Validation
7
8. http://www.owasp.org/index.php/Testing_f or_Data_Validation
Buffer overflows, integer overflows e le problematiche denominate format string sono
vulnerabilità estremamente pericolose per programmi sviluppati con i linguaggi C o C++. Le
soluzioni per questo genere di problematiche sono trattate da note comunità di esperti di
sicurezza applicativa come SANS, CERT e dai produttori di ambienti di programmazione. Se il
tuo codice è stato sviluppato con un linguaggio che può essere soggetto a buffer overflow,
incoraggiamo la lettura dei seguenti articoli presenti sul sito web di OWASP:
http://www.owasp.org/index.php/Buffer_overflow
http://www.owasp.org/index.php/Testing_for_Buffer_Overflow
Denial of Service è un pericoloso attacco che affligge ogni sito web sviluppato in qualsiasi
linguaggio di programmazione. La valutazione all’interno dei dati MITRE relativa alle
problematiche di DoS è insufficiente per poter inserire questa debolezza all’interno della top
10. Nel caso di problemi riconducibili a Denial of Service, è possibile consultare il sito OWASP
e la Testing Guide:
http://www.owasp.org/index.php/Category:Denial_of_Service_Attack
http://www.owasp.org/index.php/Testing_for_Denial_of_Service
Insecure configuration management affligge tutti i sistemi con particolare riferimento ad
alcune tecnologie, come PHP. Tuttavia la valutazione dei dati MITRE non ci permette di
includere questa problematica nell’edizione di quest’anno. Nel momento in cui viene
effettuato il deploy della tua applicazione consigliamo di consultare la più recente OWASP
Testing Guide per maggiori informazioni relative alla configurazione e gestione delle
piattaforme di fruizione:
http://www.owasp.org/index.php/Configuration
http://www.owasp.org/index.php/Testing_for_infrastructure_configuration_manage
PERCHE’ ABBIAMO AGGIUNTO ALCUNE PROBLEMATICHE IMPORTANTI
Cross Site Request Forgery (CSRF) rappresenta la principale aggiunta in questa edizione
della OWASP Top 10. Sebbene all’interno dei dati grezzi del MITRE questa vulnerabilità
occupa solamente la 36esima posizione, crediamo che sia realmente importante iniziare a
proteggere le applicazioni contro questa vulnerabilità. Nel caso di applicazioni critiche o che
gestiscono dati sensibili, CSRF può provocare seri danni. CSRF è sicuramente più importante
della sua attuale posizione nella classifica.
Cryptography In accordo con i dati MITRE, l’utilizzo insicuro della crittografia non
rappresenta più l’#8 e #9 posizione della classifica, sebbene rappresenti ancora la principale
causa di perdita di informazioni e problematiche di conformità (per esempio, rispetto alla PCI
DSS 1.1).
8
9. OWASP Top 10 2007
VULNERABILITÀ, NON ATTACCHI !
La precedente edizione della Top 10 conteneva attacchi, vulnerabilità e contromisure. In
questa edizione ci siamo focalizzati unicamente rispetto alle vulnerabilità, sebbene la
terminologia comunemente adottata combina vulnerabilità ed attacchi. Se le organizzazioni
utilizzano questo documento per mettere in sicurezza le loro applicazioni e ridurre il rischio
derivante dalle loro attività, ci si attende un’equivalente riduzione della probabilità di
attacchi:
Phishing attacks che possono sfruttare una qualsiasi di queste vulnerabilità, in
particolar luogo XSS, oltre ad eventuali debolezze dei meccanismi di autenticazione e
autorizzazione (A1, A4, A7 e A10)
Privacy violations possono derivare dalla mancata validazione, da impropri controlli
delle logiche di business e da meccanismi deboli di autorizzazione (A2, A4, A6, A7 e
A10)
Identity theft (furto di identità) viene perpetrato in caso di meccanismi crittografici
deboli o non esistenti (A8 e A9), inclusione remota di file (A3) e meccanismi deboli di
autenticazione e di autorizzazione (A4, A7, A10)
Systems compromise, data alteration o data destruction sono attacchi
solitamente perpetrati via injection (A2) ed inclusione remota di file (A3)
Financial loss attraverso l’utilizzo di transazioni non autorizzate e CSRF (A4, A5, A7,
A10)
Reputation loss sfruttando una qualsiasi delle vulnerabilità presentate (A1 … A10)
Una volta che l’organizzazione sposta la propria attenzione dai controlli reattivi verso la
riduzione pro-attiva del rischio, è facilmente ipotizzabile che si migliori l’attinenza a standard
di compliance, la riduzione del costo operazionale e si ottenga come risultato finale sistemi
più robusti e sicuri.
INCLINAZIONE
La metodologia descritta precedentemente soffre di una naturale inclinazione rispetto alle 10
principali problematiche scoperte e pubblicate dalla comunità degli esperti di sicurezza (ndr.
tralasciando quindi tutte quelle problematiche non ancora note, se non all’interno di piccoli
gruppi di ricerca). D’altro canto, questo modello di scoperta delle vulnerabilità segue le
tendenze degli attuali attacchi informatici, in particolar modo rispetto ad aggressori con
capacità tecniche medio-basse (“script kiddy”). Proteggendo il tuo software rispetto alla top
10 è perciò possibile prevenire le comuni forme di attacco e definire un percorso per
migliorare la sicurezza del software.
RIFERIMENTI TRA LE DIVERSE VERSIONI DELLA TOP 10
Nell’attuale Top 10, rispetto alle passate edizioni, ci sono stati alcuni cambiamenti nella
denominazione delle categorie di vulnerabilità anche laddove il contenuto non è stato
completamente modificato. La principale ragione risiede nella decisione di non adottare la
9
10. convezione WAS XML in quanto tale classificazione non sembrava in linea con le moderne
vulnerabilità e gli attuali attacchi e contromisure. Nella tabella successiva è possibile notare
le differenze con la Top 10 2004 e la classificazione MITRE:
OWASP Top 10 2007 OWASP Top 10 2004 MITRE 2006
Raw Ranking
A1. Cross Site Scripting (XSS) A4. Cross Site Scripting (XSS) 1
A2. Injection Flaws A6. Injection Flaws 2
A3. Malicious File Execution (aggiunta) 3
A4. Insecure Direct Object Reference A2. Broken Access Control (divisa nella
2007 T10)
5
A5. Cross Site Request Forgery (CSRF)
(aggiunta)
36
A6. Information Leakage and Improper
Error Handling
A7. Improper Error Handling 6
A7. Broken Authentication and Session
Management
A3. Broken Authentication and Session
Management
14
A8. Insecure Cryptographic Storage A8. Insecure Storage 8
A9. Insecure Communications
Discussa in A10. Insecure Configuration
8
(aggiunta)
Management
A10. Failure to Restrict URL Access A2. Broken Access Control (split in 2007
T10)
14
<rimossa nella versione 2007>
A1. Unvalidated Input 7
<rimossa nella versione 2007>
A5. Buffer Overflows 4, 8, and 10
<rimossa nella versione 2007>
A9. Denial of Service 17
<rimossa nella versione 2007>
A10. Insecure Configuration Management 29
10
11. OWASP Top 10 2007
A1 – CROSS SITE SCRIPTING (XSS)
La vulnerabilità denominata “Cross site scripting”, spesso nota come XSS, rappresenta un
sottoinsieme delle problematiche di HTML injection. XSS è la vulnerabilità più presente e
pericolosa nelle applicazioni web. XSS si verifica ogni qualvolta un’applicazione accetta
dell’input utente che viene inoltrato al web browser senza prima essere validato.
Sfruttando la vulnerabilità di XSS, un aggressore è in grado di eseguire script nel browser
della vittima. Diversi attacchi possono quindi essere perpetrati: dirottamento della sessione
utente, modifica dei siti Internet visitati, inserimento di codice ostile nelle pagine HTML,
attacchi di phishing sino alla completa compromissione del browser della vittima tramite
codice malevolo. Tali attacchi sono solitamente sviluppati con il linguaggio JavaScript anche
se ogni tipo di tecnologia di scripting supportato dal browser della vittima può essere
sfruttata.
SISTEMI AFFETTI
Tutti i web application framework sono vulnerabili rispetto a Cross Site Scripting
VULNERABILITÀ
Ci sono tre tipologie di cross site scripting: “reflected”, “stored” e “DOM injection”.
Cross Site Scripting reflected (riflesso) è la vulnerabilità più semplice da sfruttare e si verifica
quando una pagina “riflette” dati immessi dall’utente direttamente al browser:
echo $_REQUEST[’userinput’];
Nel caso di XSS stored (salvato), l’input utente è salvato in un file, un database o in altre
tecnologie di storage e, solo successivamente, mostrato all’utente senza opportuna
validazione. Questa categoria è particolarmente pericolosa nelle applicazioni quali i CMS,
blog, forum ed in tutti quei sistemi dove un grande numero di utenti legge il contenuto di
messaggi inviati da altri.
Tramite XSS DOM based (basato sull’albero DOM – Document Object Model) vengono invece
manipolati le variabili ed il codice JavaScript del sito Internet piuttosto che gli elementi HTML
della pagina.
Alternativamente, gli attacchi possono essere perpetrati sfruttando delle versioni ibride
ottenute mescolando le tre categorie di questa vulnerabilità. Il pericolo nel Cross Site
Scripting non è tanto nel tipo di attacco, quanto nei possibili scenari malevoli. Comportamenti
inattesi del web browser o non standard possono introdurre ulteriori vettori di attacco. XSS è
anche potenzialmente sfruttabile utilizzando componenti del browser stesso.
Gli attacchi sono solitamente implementati in JavaScript, un potente linguaggio di scripting
per il web. Utilizzando questa tecnologia, un aggressore può modificare ogni aspetto della
pagina web visualizzata, manipolare l’albero DOM interno, cambiare lo stile della pagina oltre
alla possibilità di aggiungere nuovi elementi (per esempio un finto login che invii le
credenziali rubate verso il sito dell’aggressore). JavaScript permette inoltre l’uso di funzioni
avanzate come XmlHttpRequest, solitamente usate da siti con tecnologia Ajax, sebbene la
pagina vulnerabile non utilizzi tali caratteristiche avanzate. Sfruttando questa funzione è
11
12. spesso possibile bypassare le limitazioni imposte dalla “same source origination policy” ed
inviare dati verso terzi siti ostili, creando quindi complessi worm e zombie che rimangono
attivi sino alla chiusura del browser stesso. Nel caso di Ajax, gli attacchi non necessitano di
interazione da parte dell’utente e sono completamente invisibili; in questo contesto vengono
solitamente eseguiti pericolosi attacchi di Cross Site Request Forgery - CSRF (si veda la
sezione A-5).
VERIFICA DI SICUREZZA
L’obiettivo è verificare che tutti i parametri usati dall’applicazione siano validati e/o codificati
prima di essere inclusi all’interno delle pagine HTML.
Approcci Automatici: Gli strumenti automatici di identificazione delle vulnerabilità sono in
grado di identificare facilmente la categoria di XSS denominata “reflected”, ma difficilmente
“Stored XSS” soprattutto se l’output del vettore di attacco è all’interno di sezioni protette da
autenticazione (esempio: un input utente ostile che viene mostrato solo nella sezione per
amministratori). Gli strumenti automatici di revisione del codice, invece, possono individuare
API deboli o pericolose ma solitamente non sono in grado di determinare la presenza di
validazione o encoding; per questa ragione i risultati dell’analisi contengono spesso falsi
positivi.
Entrambi gli strumenti non sono in grado di identificare XSS DOM based. Per questa ragione
tutte le applicazioni Ajax che vengono solamente analizzate con questo genere di strumenti
sono potenzialmente a rischio.
Approcci Manuali: Se la validazione all’interno dell’applicazione è centralizzata, la modalità
più efficiente di verificare la sicurezza è l’analisi manuale del codice stesso. Nel caso in cui la
validazione sia distribuita in più punti all’interno del software, la verifica puntuale risulterà
sicuramente più costosa in termini di tempo richiesto poiché la superficie di attacco
dell’applicazione è maggiore.
PROTEZIONE
La miglior protezione contro XSS è la combinazione di “whitelist” usate per filtrare tutti i dati
in ingresso e la codifica dell’output. La validazione dell’input permette il rilevamento di
attacchi mentre la codifica dei caratteri in uscita previene ogni tentativo di esecuzione del
codice di scripting nel browser.
Prevenire il verificarsi di XSS all’interno di un’applicazione richiede un approccio
architetturale consistente:
Validazione dell’input. Usare meccanismi standard di validazione dell’input in
maniera da validare la lunghezza, il tipo, la sintassi e la logica di business prima di
mostrare o salvare i dati. Utilizzare una strategia che segua la logica dell' “accetto solo
quello che è utile per la mia applicazione”. Rifiutare input non valido piuttosto che
tentare di sanitizzare potenziali dati ostili. Non dimenticare che anche i messaggi di
errore possono contenere dati non validi.
Codifica severa dell’output. Assicurare che tutti i dati inviati dall’utente vengano
appropriatamente codificati (in HTML o XML, a seconda della tipologia di output usata
12
13. OWASP Top 10 2007
dall’applicazione) prima di presentare tale output. Adottare un strategia di codifica di
tutti i caratteri ad esclusione di un sottoinsieme molto limitato. Questo approccio è
oggigiorno seguito anche dalla libreria “Microsoft Anti-XSS” e dalla “OWASP PHP Anti-
XSS library”. Infine, ricordarsi di impostare la tipologia di encoding utilizzata dalle
pagine di output in maniera da ridurre l’esposizione a varianti di XSS che possono
sfruttare la non completa definizione della codifica.
Specificare la codifica di output (come ISO 8859-1 o UTF 8). Non permettere
all’aggressore di scegliere la codifica utilizzata dalle pagine mostrate ai tuoi utenti.
Non utilizzare “blacklist” di validazione per determinare la presenza di XSS
nell’input o per effettuare la codifica dell’output. Cercare e sostituire solamente pochi
caratteri (“<” “>” e altri caratteri simili, oppure parole come “script”) è una pratica
debole che può essere facilmente bypassata. Anche un semplice tag “<b>” non
filtrato può essere considerato non sicuro in alcuni contesti. XSS permette un
innumerevole quantità di varianti che consente di evadere i filtri di validazione basati
su blacklist.
Porre attenzione ad errori di adattamento dell’input. L’input deve essere
sempre decodificato e adattato rispetto ai meccanismi interni usati dall’applicazione,
prima di essere validato. Assicurarsi che l’applicazione non effettui la decodifica
dell’input due volte. Questo genere di errori può essere facilmente sfruttato per
bypassare schemi di whitelisting, introducendo input malevolo codificato.
Alcune raccomandazioni specifiche per tipologie di linguaggi:
Java: Utilizzare i meccanismi di output implementati nel framework “Struts”
come <bean:write … >, oppure usare l’attributo JSTL escapeXML=”true” in <c:out …
>. Non utilizzare <%= … %> al di fuori di opportuni meccanismi di codifica.
.NET: Utilizzare la libreria Microsoft Anti-XSS 1.5 liberamente scaricabile dal
network per sviluppatori MSDN. Non assegnare il contenuto dei campi nei form
direttamente dall’oggetto “Request”: username.Text = Request.QueryString(“username”);
senza l’utilizzo della libreria citata. Comprendere quali controlli .NET codificano
automaticamente l’output.
PHP: Assicurare che l’output venga filtrato usando le funzioni htmlentities() o
htmlspecialchars() oppure usare la più recente versione della libreria OWASP PHP Anti-
XSS library. Disabilitare “register_globals” se non è stata ancora disabilitata.
ESEMPI
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4206
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3966
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5204
RIFERIMENTI
CWE: CWE-79, Cross-Site scripting (XSS)
13
14. WASC Threat Classification,
http://www.webappsec.org/projects/threat/classes/cross-site_scripting.shtml
OWASP – Cross site scripting,
http://www.owasp.org/index.php/Cross_Site_Scripting
OWASP – Testing for XSS,
http://www.owasp.org/index.php/Testing_for_Cross_site_scripting
OWASP Stinger Project (A Java EE validation filter),
http://www.owasp.org/index.php/Category:OWASP_Stinger_Project
OWASP PHP Filter Project,
http://www.owasp.org/index.php/OWASP_PHP_Filters
OWASP Encoding Project,
http://www.owasp.org/index.php/Category:OWASP_Encoding_Project
RSnake, XSS Cheat Sheet,
http://ha.ckers.org/xss.html
Klein, A., DOM Based Cross Site Scripting,
http://www.webappsec.org/projects/articles/071105.shtml
.NET Anti-XSS Library,
http://www.microsoft.com/downloads/details.aspx?FamilyID=efb9c819-53ff-4f82-bfaf-e11625130c25&
DisplayLang=en
14
15. OWASP Top 10 2007
A2 – INJECTION FLAW
Le vulnerabilità denominate “injection flaw”, di cui le SQL injection sono un noto esempio,
risultano molto comuni nelle applicazioni web. Esistono differenti tipologie di “injection flaw”
tra cui citiamo: SQL, LDAP, Xpath, XSLT, HTML, XML, l’injection di comandi di sistema e molte
altre.
L’iniezione avviene quando i dati forniti dall’utente vengono inviati ad un interprete come
parte di un comando o di una query. Gli aggressori possono perciò aggirare l’interprete al fine
di eseguire comandi non autorizzati attraverso l’inserimento di input appositamente forgiato.
Le injection flaw permettono ad un aggressore di creare, leggere, aggiornare o eliminare
arbitrariamente ogni tipo di dato utilizzato nell’applicazione. Nel peggiore dei casi, queste
vulnerabilità possono permettere ad un aggressore di compromettere completamente
l’applicazione ed il sottostante sistema, scavalcando persino complesse catene di firewall.
SISTEMI AFFETTI
Tutti i web application framework che utilizzano interpreti o che invocano altri processi sono
vulnerabili all’iniezione di comandi. Queste considerazioni valgono per ogni componente del
framework che potrebbe usare un interprete di qualche tipo nel proprio back-end.
VULNERABILITÀ
Se l’input dell’utente è passato direttamente all’interprete, senza opportuna validazione o
codifica, l’applicazione è vulnerabile. Verifica se l’input utente è utilizzato direttamente
all’interno di query dinamiche, come la seguente:
PHP:
$sql = “SELECT * FROM table WHERE id = ‘” . $_REQUEST[’id’] . “’”;
Java:
String query = “SELECT user_id FROM user_data WHERE user_name = ‘” + req.getParameter(“userID”) +
“’ and user_password = ‘” + req.getParameter(“pwd”) +”’”;
VERIFICA DI SICUREZZA
L’obiettivo delle verifiche di sicurezza per prevenire questa famiglia di vulnerabilità consiste
nell’accertarsi che i dati immessi dall’utente non possano modificare la semantica dei
comandi e delle query inviate ad ogni interprete utilizzato dall’applicazione.
Approcci Automatici: molti strumenti di identificazione automatica delle vulnerabilità sono in
grado di ricercare problemi di iniezione, in particolare SQL injection. Gli strumenti di analisi
statica del codice ricercano l’utilizzo insicuro di API; questi tool sono estremamente utili
sebbene non sono in grado di verificare la presenza di validazione e i meccanismi di codifica
implementati per contrastare queste vulnerabilità. Se l’applicazione risponde a particolari
richieste con errori del tipo “501 / 500 internal server error” oppure senza dettagliati errori
del database, gli strumenti automatici possono essere ostacolati anche in presenza di codice
chiaramente vulnerabile. Gli strumenti automatici sono inoltre in grado di identificare attacchi
di iniezione di codice LDAP, XML e Xpath.
15
16. Approcci Manuali: la maniera più efficiente ed accurata per prevenire queste vulnerabilità è la
verifica del codice che invoca gli interpreti esterni. La persona incaricata di analizzare il
codice dovrà verificare puntualmente l’utilizzo sicuro delle API e l’appropriata validazione e/o
codifica utilizzata. Il test di queste problematiche può richiedere una notevole quantità di
tempo anche per una minima copertura del codice, poiché la superficie di attacco nelle
comuni applicazioni web è solitamente molto ampia.
PROTEZIONE
Evitare l’utilizzo di interpreti, quando possibile. Se è proprio necessario utilizzare interpreti
esterni, la chiave per ottenere applicazioni sicure è l’utilizzo appropriato delle API che
comporti una tipizzazione forte e l’utilizzo di librerie ORM (object relational mapping). Queste
interfacce gestiscono tutte le problematiche di escaping dei dati. E’ importante notare che,
sebbene queste librerie risolvono il problema, la validazione dell’input è altamente
raccomandata per identificare attacchi.
L’utilizzo di interpreti è pericoloso. Per questa ragione si consiglia di adottare tutte le possibili
precauzioni, come mostrato nel seguito:
Validazione dell’input. Usare meccanismi standard di validazione dell’input in
maniera da validare la lunghezza, il tipo, la sintassi e la logica di business prima di
mostrare o salvare i dati. Utilizzare una strategia che segua la logica dell’ “accetto
solo quello che è utile per la mia applicazione”. Rifiutare input non valido piuttosto che
tentare di sanitizzare potenziali dati ostili. Non dimenticare che anche i messaggi di
errore possono contenere dati non validi.
Utilizzare API con tipizzazione forte che utilizzino meccanismi di sostituzione dei
parametri attuali, anche nel caso di stored procedure.
Forzare l’utilizzo dei più bassi privilegi necessari durante le connessioni a
database e altre tipologie di back-end.
Evitare messaggi di errore dettagliati che possono risultare utili ad un potenziale
aggressore
Utilizzare stored procedure poiché sono generalmente al riparo da attacchi di SQL
injection. Porre comunque particolare attenzione poiché anche questa soluzione può
essere sfruttata per attacchi di injection (per esempio attraverso l’uso della funzione
exec() o concatenando argomenti all’interno della stored procedure).
Non usare interfacce per la generazione di query dinamiche (come la funzione
mysql_query() o simili)
Non utilizzare semplici funzioni di escaping, come la funzione PHP addslashes() o
la sostituzione di caratteri in str_replace(“’”, “’’”). Queste soluzioni sono deboli e sono
state sfruttate con successo da aggressori. Nel caso di PHP, utilizzare la funzione
mysql_real_escape_string() se si utilizza MySQL oppure usare PDO poiché non richiede
escaping.
Quando si utilizzano questi meccanismi è importante notare che le semplici funzioni
di escaping non possono gestire i nomi delle tabelle! I nomi delle tabelle
16
17. OWASP Top 10 2007
devono essere definite da SQL sintatticamente valido e sono quindi completamente
fuori dalle logiche che devono gestire i dati immessi dall’utente.
Porre attenzione ad errori di adattamento dell’input. L’input deve essere
sempre decodificato e adattato rispetto ai meccanismi interni usati dall’applicazione,
prima di essere validato. Assicurarsi che l’applicazione non effettui la decodifica
dell’input due volte. Questo genere di errori può essere facilmente sfruttato per
bypassare schemi di whitelisting, introducendo input malevolo codificato.
Alcune raccomandazioni specifiche per tipologie di linguaggi:
Java EE – utilizzare i metodi PreparedStatement oppure framework ORM come
Hibernate o Spring
.NET – utilizzare query con tipizzazione forte dei parametri, per esempio SqlCommand
con SqlParameter oppure framework ORM come Hibernate.
PHP – utilizzare query con tipizzazione forte dei parametri (usando bindParam())
ESEMPI
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5121
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4953
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4592
RIFERIMENTI
CWE: CWE-89 (SQL Injection), CWE-77 (Command Injection), CWE-90 (LDAP Injection),
CWE-91 (XML Injection), CWE-93 (CRLF Injection) e altre.
WASC Threat Classification,
http://www.webappsec.org/projects/threat/classes/ldap_injection.shtml
http://www.webappsec.org/projects/threat/classes/sql_injection.shtml
http://www.webappsec.org/projects/threat/classes/os_commanding.shtml
OWASP,
http://www.owasp.org/index.php/SQL_Injection
OWASP Guide,
http://www.owasp.org/index.php/Guide_to_SQL_Injection
OWASP Code Review Guide,
http://www.owasp.org/index.php/Reviewing_Code_for_SQL_Injection
OWASP Testing Guide,
http://www.owasp.org/index.php/Testing_for_SQL_Injection
SQL Injection,
http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
Advanced SQL Injection,
http://www.ngssoftware.com/papers/advanced_sql_injection.pdf
17
18. More Advanced SQL Injection,
http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf
Hibernate, an advanced object relational manager (ORM) for J2EE and .NET,
http://www.hibernate.org/
J2EE Prepared Statements,
http://java.sun.com/docs/books/tutorial/jdbc/basics/prepared.html
How to: Protect from SQL injection in ASP.Net,
http://msdn2.microsoft.com/en-us/library/ms998271.aspx
PHP PDO functions, http://php.net/pdo
18
19. OWASP Top 10 2007
A3 – MALICIOUS FILE EXECUTION
La vulnerabilità denominata “malicious file execution” è spesso presente in molte
applicazioni. In alcuni casi, gli sviluppatori usano direttamente o concatenano input
potenzialmente ostile con file o funzioni di stream. In altri casi, si fidano impropriamente di
file dati in input. Su molte piattaforme, i moderni framework di sviluppo permettono di usare
riferimenti ad oggetti esterni come ad esempio URL o risorse sul file system. Quando l’input
non é sufficientemente controllato, possono essere inclusi contenuti ostili, i quali saranno
successivamente processati o invocati dal web server.
Questo permette agli aggressori di effettuare:
Esecuzione di codice da remoto
Installazione di root-kit e conseguente compromissione completa del sistema
Su Windows, la compromissione del sistema è possibile attraverso l’uso dei SMB file
wrapper presenti nel framework PHP
Questo attacco è particolarmente comune in PHP che quindi richiede estrema cura nel
trattare stream o funzioni per file, in maniera da assicurarsi che l’input fornito dall’utente non
influenzi i nomi dei file.
SISTEMI AFFETTI
Tutti i web application framework sono vulnerabili a “malicious file execution” se accettano
nomi di file o file dall’utente. Esempi tipici includono: .NET assembly, il quale permette l’uso
di nomi di file come argomenti, o codici che accettano il nome di un file scelto dall’utente per
includere file locali.
PHP è particolarmente vulnerabile all’attacco di “remote file include (RFI)” compiuto
attraverso la modifica di parametri che sono utilizzati in funzioni per la gestione di file.
VULNERABILITÀ
Un costrutto comunemente vulnerabile è:
include $_REQUEST[‘filename’];
Questa istruzione non solo permette l’inclusione di uno script remoto ostile, ma può essere
usato per accedere a file locali presenti sul server (se PHP è su Windows, per via del supporto
SMB nei file wrapper di PHP).
Altri metodi di attacco includono:
Dati ostili caricati come file di sessione, dati di log o attraverso l’upload di immagini
(tipico dei software per forum)
Usando stream di compressione o stream audio come zlib:// o ogg:// i quali non ispe-zionano
il “PHP URL flag” interno e permettono così l’accesso a risorse remote anche
se le opzioni di “allow_url_fopen” e “allow_url_include” sono disabilitate
19
20. Usando wrapper PHP, come php://input e altri, per ottenere l’input dalla richiesta http
POST invece che da un file
Usando il wrapper PHP data: come data:;base64,PD9waHAgcGhwaW5mbygp0z8+
Visto che l’elenco di funzioni pericolose risulta esteso, è vitale usare un’architettura di
sicurezza che sia propriamente progettata. In particolare, un’architettura robusta è
necessaria quando si deve gestire input forniti dall’utente che influenzano le scelte dei nomi
dei file lato server.
Anche se sono stati dati esempi in PHP, questo attacco è applicabile anche alle piattaforme
.NET e J2EE. Le applicazioni scritte in questi framework richiedono particolare attenzione
durante la stesusa dei meccanismi del codice per l’accesso sicuro, al fine di garantire che,
nomi di file forniti o influenzati dall’utente, non permettano di evitare i controlli di sicurezza.
Per esempio è possibile che documenti XML inviati da un attaccante abbiano un DTD ostile
che forzi il parser XML a caricare un DTD remoto, effettuare il parsing ed elaborare i risultati.
Una società di sicurezza Australiana ha dimostrato l’utilizzo di questa tecnica per effettuare
port scanning all’interno di una rete aziendale. Per maggiori informazioni , si veda [SIF01] nei
riferimenti di questo capitolo.
Il danno che questa particolare vulnerabilità causa è direttamente collegato alla forza della
sandbox offerta dal framework applicativo. Siccome l’ambiente di esecuzione in PHP è
raramente isolato e non implementa il concetto di sandbox, il danno di un attacco è molto
peggiore che su altre piattaforme. Attacchi di questo tipo sono quindi meno frequenti su
sistemi con fiducia parziale o limitata all’interno di un’adeguata sandbox, come ad esempio
un’applicazione web che gira all’interno della JVM con il security manager correttamente
abilitato e configurato.
VERIFICARE LA SICUREZZA
Approccio automatizzato: i tool di scansione delle vulnerabilità avranno difficoltà
nell’identificare i parametri che vengono utilizzati nell’inclusione di file o la sintassi per
renderli funzionanti. I tool di analisi statica possono controllare se sono utilizzate API
pericolose, ma non possono verificare se appropriate validazioni e codifiche sono dispiegate a
protezione della vulnerabilità.
Approccio manuale: la revisione del codice può identificare istruzioni che permetterebbero
l’inclusione di file nell’applicazione, anche se l’analisi risulta spesso soggetta a falsi positivi.
Sebbene la revisione del codice può rilevare queste vulnerabilità, risulta spesso difficile
determinare i vettori di attacco.
PROTEZIONE
Prevenire il problema relativo all’inclusione di file da remoto richiede un’attenta pianificazione
sia in fase di progettazione dell’architettura che in fase di sviluppo. In generale
un’applicazione ben scritta non utilizzerà l’input fornito dall’utente nei nomi di file utilizzati da
risorse server-based (come immagini, XML e SDL transform document) e avrà regole di
firewall che impediranno nuove connessioni in uscita verso Internet o internamente verso
20
21. OWASP Top 10 2007
ogni altro server. Alcune applicazioni legacy hanno però spesso la necessità di accettare
input fornito dall’utente.
In questi casi, tra le considerazioni più importanti ci sono:
Usare una mappa per il riferimento indiretto all’oggetto (per maggiori dettagli
vedere la sezione A4). Per esempio, quando è usato un nome parziale, considerare l’u-tilizzo
dell’hash del riferimento parziale. Invece di:
<select name=”language”> <option value=”English”>English</option>
usare
<select name=”language”> <option value=”78463a384a5aa4fad5fa73e2f506ecfc”>English</option>
Considerare l’uso di “salt” per prevenire attacchi brute force del riferimento indiretto
all’oggetto. Alternativamente basta usare valori d’indice come 1,2,3 e assicurarsi che i
limiti dell’array siano controllati per rivelare attacchi di parameter tampering.
Usare meccanismi espliciti per controllare l’alterazione, se il tuo linguaggio lo
supporta. Altrimenti considerare uno schema di denominazione delle variabili che aiuti
ad evitare la modifica dei parametri in ingresso:
$hostfile = &$_POST; // refer to POST varibles, not $_REQUEST
$safe[‘filename’]= validate_file_name($hostfile[‘unsafe_filename’]); // make it safe
Di conseguenza ogni operazione basata su input ostile è immediatamente evidente:
NO: require_once($_POST[‘unsafe_filename’] . ‘inc.php’);
SI: require_once($safe[‘filename’] . ‘inc.php’);
Validazione forte dell’input degli utenti usando una strategia che segua la logica
dell’ “accetto solo quello che è utile per la mia applicazione”. Rifiutare input non valido
piuttosto che tentare di sanitizzare potenziali dati ostili.
Aggiungere regole di firewall per prevenire connessioni a siti web esterni o verso i
sistemi interni da parte del web server. Per sistemi critici, si consiglia di isolare il web
server in una propria VLAN o subnet privata
Controllare che i file o i nomi di file forniti dall’utente non siano in grado di alte-rare
altri controlli, come es. dati alterati negli oggetti di sessione, avatar e immagini,
log in file PDF, file temporanei e così via
Considerare l’implementazione di una chroot jail o altri meccanismi di sandbox,
come la virtualizzazione, per isolare l'applicazione da altri sistemi
PHP: Disabilitare “allow_url_fopen” e “allow_url_include” in php.ini e considera-re
la compilazione di PHP senza includere queste funzionalità . Pochissime applicazioni
necessitano di queste funzionalità; per questa ragione sarebbe opportuno disabilitarle
21
22. PHP: Disabilitare “register_globals” e usare “E_STRICT” per identificare va-riabili
non inizializzate
PHP: Assicurarsi che tutti i file e le funzioni di stream (stream_*) siano accu-ratamente
esaminate. Assicurarsi che l’input dell’utente non sia fornito direttamen-te
alle funzioni che prendono come argomento un nome di file:
include() include_once() requie() requie_once() fopen() imagecreatefromXXX() file()
file_get_contents() copy() dolete() unlink() upload_tmp_dir() $_FILES move_upload_file()
Con PHP, essere estremamente cauti se i dati sono passati a funzioni quali system()
eval() passthru() o ‘ (l’operatore backtick)
Con J2EE, assicurarsi che il security manager sia abilitato e propriamente configurato
e che l’applicazione gestisca le autorizzazioni in maniera opportuna
Con ASP.NET, si faccia riferimento alla documentazione sulla “partial trust”. Progetta-re
la vostra applicazione in maniera “segmentata”, facendo in modo che la maggior
parte dell’esecuzione si trovi nello stato di trust più basso possibile
ESEMPI
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0360
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5220
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4722
RIFERIMENTI
CWE: CWE-98 (PHP File Inclusion), CWE-78 (OS Command Injection), CWE-95 (Eval
injection), CWE-434 (Unrestricted file upload)
WASC Threat Classification,
http://www.webappsec.org/projects/threat/classes/os_commanding.shtml
OWASP Guide,
http://www.owasp.org/index.php/File_System#Includes_and_Remote_files
OWASP Testing Guide,
http://www.owasp.org/index.php/Testing_for_Directory_Traversal
OWASP PHP Top 5,
http://www.owasp.org/index.php/PHP_Top_5#P1:_Remote_Code_Execution
Stefan Esser,
http://blog.php-security.org/archives/45-PHP-5.2.0-and-allow_url_include.html
[SIF01] SIFT, Web Services: Teaching an old dog new tricks,
http://www.ruxcon.org.au/files/2006/web_services_security.ppt
OWASP Java Security Policy,
http://www.owasp.org/index.php/OWASP_Java_Table_of_Contents#Defining_a_Java_Sec
urity_Policy
22
23. OWASP Top 10 2007
Microsoft - Programming for Partial Trust,
http://msdn2.microsoft.com/en-us/library/ms364059(VS.80).aspx
23
24. A4 – INSECURE DIRECT OBJECT REFERENCE
Una vulnerabilità di “direct object reference” esiste quando uno sviluppatore espone un
riferimento ad un’implementazione interna di un oggetto, come un file, una directory, un
record di un database, o una chiave, un URL o parametri di un form. Un aggressore, a meno
di controlli sull’accesso, può manipolare i riferimenti diretti all’oggetto per accedere ad altre
risorse senza autorizzazione.
Per esempio, in un’applicazione di Internet Banking è comune utilizzare il numero di account
come primary key. Gli sviluppatori sono spesso tentati ad utilizzare questo riferimento in
maniera diretta anche nell’interfaccia web. Anche se vengono utilizzate query SQL
parametrizzate per prevenire attacchi di SQL injection, se non esiste nessun altro controllo
che verifichi che l’utente sia il proprietario dell’account e quindi autorizzato a vederne il
contenuto, un aggressore può vedere o cambiare tutti gli account. L’attacco consiste
semplicemente nel falsificare il parametro relativo al numero di account.
Questo tipo di attacco è accaduto al sito “Australian Taxation Office’s GST Start Up
Assistance” nel 2000 dove un utente legittimo ma ostile ha semplicemente cambiato l’ABN
(un identificativo per le tasse) presente nell’URL. L’utente raccolse dal sistema dettagli di
circa 17000 società. Questo tipo di vulnerabilità è veramente comune e altrettanto poco
testata nelle applicazioni moderne.
SISTEMI AFFETTI
Tutti i web application framework sono vulnerabili all’attacco di “insecure direct object
reference”.
VULNERABILITÀ
Molte applicazioni espongono agli utenti i loro riferimenti agli oggetti interni. Gli aggressori
usano la modifica dei parametri (“parameter tampering”) per cambiare i riferimenti e violare
la progettata, ma non applicata, politica di controllo dell’accesso. Frequentemente questi
riferimenti puntano al file system e ai database; ogni costrutto esposto dall’applicazione può
però essere vulnerabile.
Per esempio, se il codice permette che l’input dell’utente specifichi un nome di file o un path,
questo può consentire agli aggressori di “saltare” fuori dalla directory dell’applicazione e
accedere ad altre risorse.
<select name=”language”><option value=”fr”>Français</option></select>
…
require_once ($_REQUEST[‘language’].”lang.php”);
Questo codice può essere attaccato usando una stringa simile a “../../../../etc/passwd%00” che
fa uso di null byte injection (per maggiori informazioni vedere la OWASP Guide) per accedere
ad ogni risorsa nel file system del web server.
In modo simile i riferimenti alle chiavi dei database sono frequentemente esposti. Un
aggressore può attaccare questi parametri semplicemente indovinando o cercando un’altra
24
25. OWASP Top 10 2007
chiave valida. Spesso sono in sequenza naturale. Nell’esempio sottostante, anche se
l’applicazione non presenta link a diversi “carrelli” e non è possibile effettuare SQL injection,
un attaccante può ancora cambiare il parametro cartID per collegarsi a qualsiasi carrello:
int cartID = Integre.parseInt( request.getParameter( “cartID” ) ); String query = “SELECT *
FROM table WHERE cartID=” + cartID;
VERIFICARE LA SICUREZZA
L’obiettivo è verificare che l’applicazione non permetta ai riferimenti diretti agli oggetti di
essere manipolati da un attaccante.
Approccio automatizzato: i tool di scansione delle vulnerabilità avranno difficoltà
nell’identificare quali parametri sono suscettibili a manipolazione o se la manipolazione
funziona. I tool di analisi statica non conoscono realmente quali parametri devono avere un
controllo dell’accesso prima del loro uso.
Approccio manuale: una revisione del codice può tracciare i parametri critici e identificare se
sono suscettibili a manipolazione. Un penetration test può verificare che la manipolazione sia
possibile. Entrambe queste tecniche richiedono tempo per assicurare una copertura
completa.
PROTEZIONE
La migliore protezione è quella di evitare l’esposizione a riferimenti diretti usando un indice,
una mappa di riferimenti indiretti o altri metodi indiretti che sono facili da validare. Se un
riferimento diretto ad un oggetto deve essere necessariamente usato, assicurarsi che l’utente
sia autorizzato prima che lo utilizzi.
È importante stabilire un modo standard per referenziare gli oggetti dell’applicazione:
Evitare di esporre riferimenti ad oggetti privati agli utenti ogni volta che è pos-sibile,
come primary key o nomi di file
Validare in maniera estesa ogni riferimenti ad oggetti privati con un approccio
“accept known good”
Verificare l’autorizzazione a tutti gli oggetti referenziati
La soluzione migliore per prevenire l’attacco di manipolazione dei parametri è usare un valore
indice o una mappa dei riferimenti.
http://www.example.com/application?file=1
Se si devono esporre riferimenti diretti alle strutture di un database assicurarsi che i comandi
SQL e gli altri metodi di accesso al database permettano di visualizzare solo i record
autorizzati:
int cartID = Integre.parseInt( request.getParameter( “cartID” ) ); User user = (User)
request.getSession().getAttribute( “user” ); String query = “SELECT * FROM table WHERE
cartID=” + cartID + “ AND userID=” + user.getID();
25
27. OWASP Top 10 2007
A5 – CROSS SITE REQUEST FORGERY (CSRF)
Pur non essendo un attacco nuovo, il Cross Site Request Forgery è semplice e devastante. Un
attacco CSRF forza il browser di una vittima, opportunamente autenticata, ad inviare una
richiesta verso l’applicazione web vulnerabile, la quale poi effettuerà l’azione scelta a nome
della vittima.
QUESTA VULNERABILITÀ È ESTREMAMENTE DIFFUSA.
OGNI APPLICAZIONE CHE:
Non ha un controllo dell’autorizzazione per azioni vulnerabili
Processa una richiesta, includendo nella richiesta stessa un login di default (es.
http://www.example.com/admin/doSomething.ctl?username=admin&passwd=admin)
Autorizza le richieste basandosi solo su credenziali che sono fornite automaticamente
come cookie di sessione se si è correttamente autenticati nell’applicazione, o funzio-nalità
“Remember me” se non si è correttamente autenticati nell’applicazione, o token
Kerberos se parte di una Intranet tramite login integrato con Active Directory
è a rischio. Sfortunatamente molte applicazioni web confidano solamente sulle credenziali
inviate automaticamente come i cookie di sessione, tramite “basic authentication”, indirizzo
IP sorgente, certificati SSL o credenziali di dominio Windows.
Questa vulnerabilità è anche conosciuta con diversi altri nomi inclusi Session Riding, One-
Click Attack, Cross Site Reference Forgery, Hostile Linking e Automation Attack. Anche
l’acronimo XSRF è frequentemente usato. Sia OWASP che MITRE usano in maniera standard
sia il termine Cross Site Request Forgery che l’acronimo CSRF.
SISTEMI AFFETTI
Tutti i web application framework sono vulnerabili ad attacchi di CSRF.
VULNERABILITÀ
Un tipico attacco CSRF contro un forum potrebbe assumere questa forma: indirizzare l’utente
a richiamare qualche funzione come ad esempio la pagina di logout dell’applicazione. Il
seguente tag in una pagina web visitata dalla vittima genererà una richiesta che farà
effettuare il logout:
<IMG SRC=”HTTP://WWW.EXAMPLE.COM/LOGOUT.PHP ”>
Se una banca on-line consente alla sua applicazione di processare richieste, es. di
trasferimento di fondi, potrebbe avvenire un attacco simile:
<img src=”http://www.example.com/transfer.do?frmAcct=document.form.frmAcct
&toAcct=4345754&toSWIFTid=434343&amt=3434.43”>
Jeremiah Grossman, durante la presentazione Hacking Intranet Sites from the outside
(BlackHat 2006) ha dimostrato che è possibile forzare un utente a fare cambiamenti sul suo
router DSL senza previo consenso; anche se l’utente non sa che il router DSL ha
27
28. un’interfaccia web. Per questi attacchi, Jeremiah ha usato account di default sui router più
comuni.
Tutti questi attacchi funzionano perché le credenziali di autorizzazione dell’utente
(tipicamente il cookie di sessione) sono automaticamente inclusi dal browser con le richieste,
anche se l’attaccante non ha fornito nessuna credenziale.
Se il tag HTML contenente l’attacco può essere inviato ad un’applicazione vulnerabile, la
probabilità di trovare vittime “loggate” aumenta significativamente, in maniera simile
all’aumento di rischio fra la vulnerabilità XSS stored e reflected. La vulnerabilità XSS non è
richiesta per effettuare un attacco CSRF, sebbene ogni applicazione con una falla XSS è
suscettibile a CSRF perché un attacco di questo tipo può sfruttare la falla XSS per rubare
credenziali. Molti worm applicativi hanno usato entrambe le tecniche in maniera combinata.
Quando si costruiscono delle difese contro attacchi CSRF bisogna anche focalizzarsi
sull’eliminazione di vulnerabilità XSS dal momento che questa vulnerabilità può essere usata
per aggirare molte delle difese dispiegate per difendersi da CSRF.
VERIFICARE LA SICUREZZA
L’obiettivo è verificare che l’applicazione sia protetta contro attacchi CSRF, generando e poi
utilizzando token d’autorizzazione che non sono automaticamente sottomessi dal browser.
Approccio automatizzato: tutt’oggi pochi scanner automatici possono rilevare vulnerabilità
CSRF, anche se è un’operazione possibile per un motore di scansione sufficientemente abile.
Comunque, se il vostro scanner di applicazioni rivela una vulnerabilità di Cross-Site Scripting
e non si ha una protezione anti-CSRF, molto probabilmente sarete vulnerabili a semplici
attacchi CSRF.
Approccio manuale: il modo più veloce per verificare l’esistenza di una protezione contro i
CSRF è eseguire un penetration test. Per verificare che il meccanismo sia forte e
propriamente implementato, il modo migliore è la verifica puntuale dell’applicazione.
PROTEZIONE
Le applicazioni non devono fare affidamento solo su credenziali o token che sono
automaticamente forniti dal browser. L’unica soluzione è usare un token custom che il
browser non “ricorderà“ e che quindi non verrà incluso automaticamente in un attacco CSRF.
Le seguenti strategie dovrebbero essere insite in ogni applicazione web:
Assicurarsi che non ci siano vulnerabilità XSS nelle vostre applicazioni (Vedi
A1 - Cross Site Scripting)
Inserire in ogni form e URL token custom e randomici che non saranno automa-ticamente
inviati dal browser. Per esempio,
<form action=”/transfer.do” method=”post”>
<input type=”hidden” name=”84389277730” value=”43847384383”>
…
28
29. OWASP Top 10 2007
</form>
Verificare che il token inviato sia corretto, rispetto all’utente corrente. Questi token
possono essere unici per una particolare funzione, pagina, per utente, o semplicemente
unici per tutta la sessione. Più il token è focalizzato su una particolare funzione e/o su un
particolare insieme di dati, più forte sarà la protezione e più difficile sarà da costruire e
mantenere il sistema di anti-CSRF token.
Per dati sensibili o transazioni di valore, ri-autenticarsi o usare la firma della
transazione per assicurarsi che la richiesta sia autentica. Preparare meccanismi
esterni come e-mail o contatti telefonici con lo scopo di verificare le richieste o notifi-carle
all’utente
Non usare richieste GET per dati sensibili o per effettuare transazioni di va-lore.
Usare solo metodi POST quando si processano dati sensibili provenienti dall’u-tente.
L’URL può contenere token randomici in modo da creare un riferimento unico, il
quale rende quasi impossibile effettuare attacchi CSRF
Il solo utilizzo di HTTP POST è una protezione insufficiente. Per proteggersi
propriamente contro il CSRF bisogna combinarlo con token randomici non collegati al-l’autenticazione
o ri-autenticare ogni richiesta critica
Per ASP.NET, settare una ViewStatusKey (si veda i riferimenti a fine sezione). Questa
soluzione fornisce un tipo di controllo simile ai token randomici descritti sopra
Sebbene i suggerimenti dati diminuiscono drasticamente la vostra esposizione, molti attacchi
CSRF avanzati possono superare queste restrizioni. La tecnica migliore è utilizzare token unici
e eliminare tutte le vulnerabilità XSS dell’applicazione.
ESEMPI
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0192
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5116
MySpace Samy Interview: http://blog.outer-court.com/archive/2005-10-14-n81.html
An attack which uses Quicktime to perform CSRF attacks
http://www.computerworld.com/action/article.do?
command=viewArticleBasic&articleId=9005607&intsrc=hm_list
RIFERIMENTI
CWE: CWE-352 (Cross-Site Request Forgery)
WASC Threat Classification: No direct mapping, but the following is a close match,
http://www.webappsec.org/projects/threat/classes/abuse_of_functionality.shtml
OWASP CSRF,
http://www.owasp.org/index.php/Cross-Site_Request_Forgery
OWASP Testing Guide,
https://www.owasp.org/index.php/Testing_for_CSRF
29
30. OWASP CSRF Guard,
http://www.owasp.org/index.php/CSRF_Guard
OWASP PHP CSRF Guard,
http://www.owasp.org/index.php/PHP_CSRF_Guard
RSnake, “What is CSRF?”,
http://ha.ckers.org/blog/20061030/what-is-csrf/
Jeremiah Grossman, slides and demos of “Hacking Intranet sites from the outside”
http://www.whitehatsec.com/presentations/whitehat_bh_pres_08032006.tar.gz
Microsoft, ViewStateUserKey details,
http://msdn2.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic2
30
31. OWASP Top 10 2007
A6 – INFORMATION LEAKAGE AND IMPROPER ERROR HANDLING
Le applicazioni possono, in maniera non intenzionale, rivelare informazioni circa la loro
configurazione, il loro funzionamento interno o violare la riservatezza dei dati tramite una
serie di problemi applicativi. Le applicazioni possono inoltre rivelare il loro stato interno
attraverso il tempo speso per processare alcune operazioni o attraverso differenti risposte
quando sollecitate con input differenti, come ad esempio la visualizzazione di uno stesso
messaggio d’errore.
Le applicazioni web spesso rivelano informazioni circa il loro stato interno attraverso
messaggi d’errore dettagliati o messaggi di debug. Spesso queste informazioni possono
essere utilizzate per lanciare o addirittura per automatizzare attacchi più sofisticati.
SISTEMI AFFETTI
Tutti i web application framework sono vulnerabili all’information leakage and improper error
handling.
VULNERABILITÀ
Le applicazioni generano frequentemente messaggi di errore da visualizzare agli utenti. Molte
volte questi messaggi d’errore sono abbastanza utili agli attaccanti in quanto rivelano dettagli
implementativi o informazioni utili per sfruttare ulteriori vulnerabilità.
Alcuni esempi tipici di queste vulnerabilità sono:
Messaggi d’errore dettagliati, dove indurre un errore causa la visualizzazione di
informazioni come stack trace, istruzioni SQL terminate con errori o altri messaggi di
debug
Funzioni che producono differenti risultati a fronte di input differenti. Ad esempio,
l’inserimento dello stesso username ma di password differenti alla funzionalità di
login, dovrebbe produrre lo stesso messaggio d’errore sia nel caso di utente
inesistente che nel caso di password errata. Tuttavia la maggior parte dei sistemi
produce codici d’errore differenti.
VERIFICA DELLA SICUREZZA
L’obiettivo è verificare che l’applicazione non riveli informazioni attraverso messaggi d’errore
o altri tipi di messaggi.
Approccio automatizzato: gli strumenti di vulnerability scan, spesso causano la generazione di
messaggi d’errore che possono quindi essere valutati. Strumenti di analisi statica possono
ricercare l’utilizzo di API che rivelano informazioni, pur non essendo in grado di verificare il
significato di questi messaggi.
Approccio manuale: una revisione del codice può ricercare porzioni del sistema dove la
gestione degli errori non è ben implementata o dove vengono rivelate informazioni. In
generale si tratta di un’attività che richiede molto tempo. Il semplice test a runtime può
causare messaggi d’errore, anche se l’individuazione della natura applicativa dell’errore può
essere un’impresa ardua.
31
32. PROTEZIONE
Gli sviluppatori dovrebbero utilizzare strumenti come OWASP WebScarab per cercare di
causare errori applicativi. Le applicazioni che non vengono testate in questo modo, saranno
molto probabilmente soggette alla generazione di messaggi d’errore non previsti. Le
applicazioni dovrebbero inoltre includere un meccanismo standard per gestire le eccezioni al
fine di prevenire la rivelazione di informazioni riservate ad un aggressore.
Prevenire l’esposizione di informazioni di sistema richiede disciplina. Le abitudini che seguono
si sono rivelate efficaci contro questa categoria di vulnerabilità:
Verificare che tutto il team di sviluppo appia un approccio comune alla gestione delle
eccezioni.
Disabilitare o limitare la generazione di messaggi d’errore. In particolare, non
devono essere visualizzate informazioni di debug, stack trace o informazioni sui
percorsi e sul file system ad utenti finali
Verificare che percorsi d’esecuzione che hanno multipli risultati
restituiscono messaggi d’errore simili o identici più o meno nella stessa
maniera. Se non è possibile, si consideri di inserire un tempo d’attesa casuale per
tutte le transazioni in modo da mascherare la condizione d’errore all’attaccante
Differenti strati applicativi possono restituire risultati non previsti, come ad esempio lo
strato di comunicazione con il database o il web server sottostante (IIS, Apache, ecc).
E’ vitale che gli errori di ciascun strato applicativo siano controllati e
configurati in modo da prevenire messaggi che possano essere utilizzati da
un aggressore per un exploit
Essere consapevoli che i framework comunemente utilizzati restituiscono differenti
codici d’errore HTTP in maniera dipendente se l’errore accade all’interno del codice
del framework o nel codice applicativo custom. Può essere un buon investimento
quello di creare un gestore d’errori di default, che restituisca appropriati
messaggi d’errore
Scavalcare il meccanismo di gestione di default degli errori in maniera tale che venga
restituito sempre il codice “200” (OK). In questo modo viene tolta ai tool di scansione
automatizzata, la possibilità di discriminare tra un errore applicativo ed una condizione
normale. Nonostante sia spesso considerato come “security through obscurity”,
questo meccanismo può aumentare il livello di difesa
Alcune società hanno scelto di introdurre un codice d’errore casuale o addirittura
unico per tutte le loro applicazioni. Questo può aiutare l’help desk a trovare la corretta
soluzione per un problema particolare, ma può essere utilizzato anche da un
attaccante per capire quale percorso d’esecuzione ha causato l’errore
ESEMPI
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4899
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3389
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0580
32
33. OWASP Top 10 2007
REFERENZE
CWE: CWE-200 (Information Leak), CWE-203 (Discrepancy Information Leak), CWE-215
(Information Leak Through Debug Information), CWE-209 (Error Message Information
Leak), others.
WASC Threat Classification,
http://www.webappsec.org/projects/threat/classes/information_leakage.shtml
OWASP,
http://www.owasp.org/index.php/Error_Handling
OWASP,
http://www.owasp.org/index.php/Category:Sensitive_Data_Protection_Vulnerability
33
34. A7 – BROKEN AUTHENTICATION AND SESSION MANAGEMENT
Meccanismi adeguati di autenticazione e di gestione della sessione sono un punto critico nella
sicurezza di un’applicazione web. Le vulnerabilità in quest’area riguardano soprattutto la
mancata protezione delle credenziali e dei token di sessione durante il loro ciclo di vita.
Queste vulnerabilità possono portare l’aggressore a dirottare la sessione utente o ad
accedere ad account amministrativi, compromettendo i controlli di autorizzazione e di
profilatura. Inoltre, questa vulnerabilità può portare a problemi circa la riservatezza dei dati.
SISTEMI AFFETTI
Tutti i web application framework sono vulnerabili ad errori sui meccanismi di autenticazione
e di gestione della sessione.
VULNERABILITÀ
Problemi nel sistema principale di autenticazione sono comuni ma le vulnerabilità sono
spesso introdotte attraverso funzioni secondarie come il logout, la gestione della password, il
timeout, la funzionalità “remember me”, domande riservate e l’aggiornamento dell’account.
VERIFICA DELLA SICUREZZA
Lo scopo è verificare che l’applicazione autentichi in maniera corretta gli utenti e che
protegga in maniera adeguata le loro identità e le credenziali ad essi associate.
Approccio automatizzato: strumenti di vulnerability scan non sono in grado di rilevare in
maniera efficace vulnerabilità presenti in porzioni di codice custom per l’autenticazione e la
gestione della sessione. Gli strumenti di analisi statica non sono altrettanto in grado di
rilevare problemi legati a tali funzionalità.
Approccio manuale: una code review e il test dell’applicazione, soprattutto se effettuati
entrambi, sono molto efficaci per verificare che le funzionalità di autenticazione e di gestione
della sessione siano implementate in maniera corretta.
PROTEZIONE
L’autenticazione si basa sulla comunicazione sicura delle credenziali d’accesso e sulla
memorizzazione delle stesse. Come prima cosa occorre verificare che SSL sia l’unica opzione
per tutte le parti dell’applicazione che richiedono l’autenticazione (si veda A9 – Insecure
Communication), successivamente occorre verificare che tutte le credenziali vengano
memorizzate utilizzando opportune funzioni di hash o di crifratura (si veda A8 – Insecure
Cryptographic Storage).
Prevenire errori nel codice di autenticazione richiede una pianificazione accurata.
Le considerazioni più interessanti sono:
Utilizzare unicamente il sistema di gestione della sessione fornito dall’application
server. Non bisogna scrivere o utilizzare meccanismi secondari per la gestione della
sessione.
34
35. OWASP Top 10 2007
Non accettare identificativi di sessione nuovi, prestabiliti o invalidi,
provenienti dall’URL o contenuti nella richiesta http dell’utente. Questo attacco viene
chiamato “session fixation”
Limitare o eliminare dal codice, cookie custom di autenticazione o di
gestione della sessione, come funzionalità “remember me” o funzionalità di single
sign-on sviluppate in casa. Questo suggerimento non si applica a meccanismi robusti e
comprovati di SSO o di autenticazione federata
Utilizzare un solo meccanismo di autenticazione che sia robusto. Si presti
attenzione che questo meccanismo non sia soggetto in maniera semplice ad attacchi
di spoofing o a “reply attack”
Non permettere che la procedura di autenticazione avvenga da una pagina
non cifrata. Occorre sempre iniziare il processo di login da una pagina cifrata, avente
un nuovo token di sessione per prevenire il furto di credenziali, attachi di phishing e di
session fixation
Si consideri l’eventualità di generare una nuova sessione una volta completata con
successo l’autenticazione o un cambio di privilegi.
Assicurarsi che ogni pagina abbia un link alla funzionalità di logout. Il logout
deve distruggere tutte le informazioni di sessione lato server e tutti i cookie presenti
sul browser. Si consideri il fattore umano: è meglio non chiedere alcuna conferma per
evitare che gli utenti chiudano il browser che presenta loro la pagina di conferma.
Utilizzare un periodo di timeout dopo il quale viene effettuato il logout automatico
per le sessioni inattive (un minor tempo di timeout comporta un livello di sicurezza
maggiore).
Utilizzare unicamente funzioni robuste per l’autenticazione (domande e
risposte, reset della password) in quanto queste sono credenziali come username e
password o token di autenticazione. Occorre applicare una funzione di hash one-way
per prevenire attacchi legati alla disclosure di informazioni.
Non rendere visibili gli identificativi di sessione o porzioni di credenziali valide nell’URL
o nei log (non si deve effettuare il session rewriting o memorizzare la password degli
utenti nei file di log)
Controllare la password vecchia quando viene cambiata
Non dipendere da credenziali che possono essere falsificate come unica
forma di autenticazione, inclusi gli indirizzi IP o un range di indirizzi, DNS o reverse
DNS lookup, l’header referrer o simili.
Fare attenzione nell’inviare informazioni riservate tramite email (si veda
RSNAKE01 all’interno dei riferimenti a fine sezione) come meccanismo per il reset
della password. Utilizzare numeri causali e limitati nel tempo per il reset delle
credenziali d’accesso. Inviare inoltre un’email di conferma dopo l’avvenuto reset. Fare
attenzione nel caso in cui l’applicazione permetta di modificare l’email di registrazione
35
37. OWASP Top 10 2007
A8 – INSECURE CRYPTOGRAPHIC STORAGE
Proteggere dati sensibili con la crittografia e’ diventata una pratica importante nelle
applicazioni web moderne. In molti casi, le applicazioni non cifrano nemmeno le informazioni.
Nei casi in cui si utilizzata la crittografia, la stessa e’ spesso malamente progettata oppure
vengono inappropriatamente utilizzati i meccanismi di “chiper”.
Queste vulnerabilità possono portare alla divulgazione di dati sensibili e conseguenti
violazioni.
SISTEMI AFFETTI
Tutti i framework per applicazioni web sono vulnerabili all’utilizzo di algoritmi insicuri di
crittografia.
VULNERABILITÀ
La prevenzione di vulnerabilità crittografiche richiede estrema pianificazione.
Problemi tipici includono:
Non applicare cifratura su dati sensibili
Utilizzare algoritmi artigianali
Utilizzo insicuro di algoritmi di crittografia forte
Utilizzo di algoritmi di cifratura con vulnerabilità note (MD5, SHA-1, RC3, RC4, ecc…)
Utilizzo di chiavi salvate in maniera statica nel codice o in archivi non protetti
VERIFICA DELLA SICUREZZA
L’obiettivo e’ di verificare che l’applicazione utilizzi un’opportuna cifratura per salvare
informazioni sensibili.
Approccio automatici: i tool per la scansione di vulnerabilità non possono effettuare verifiche
sulla cifratura dei dati salvati.
Approccio manuale: come nel caso delle scansioni automatiche, la verifica di sicurezza
tramite testing black-box non è possibile. La revisione del codice e’ la maniera migliore per
verificare che un’applicazione utilizzi un’opportuna cifratura per dati sensibili ed implementi
correttamente gli algoritmi e la gestione delle chiavi. In alcuni casi, questa attività può
richiede l’analisi della configurazione di sistemi esterni.
PROTEZIONE
L’aspetto più importante è assicurarsi che ogni informazione che deve essere cifrata venga in
effetti protetta. A corredo, è importante verificare che la specifica tecnologia crittografica sia
opportunamente implementata. A cause delle innumerevoli possibilità di utilizzo improprio
della crittografia, è opportuno considerare le successive raccomandazioni come parte
dell’analisi per assicurare una gestione sicura della tecnologia crittografica:
37
38. Non creare algoritmi di cifratura. Utilizzare solamente algoritmi pubblici approvati,
come AES, la crittografia a chiave pubblica RSA, e SHA-256 o migliori per le operazioni
di hashing
Non utilizzare algoritmi deboli, come MD5 / SHA1. Scegliere alternative più sicure
come SHA-256 o migliori
Genera chiavi di cifratura online e salva le chiavi private con estrema
cautela. Non trasmettere chiavi private tramite canali insicuri
Assicurati che le credenziali di accesso a sistemi, quali basi di dati e MQ
siano adeguatamente protetti (tramite permessi stretti sul file system e ulteriori
controlli), oppure siano cifrati in maniera sicura e non facilmente ottenibili da utenti
locali o remoti
Assicurati che i dati salvati sul disco non siano facilmente decifrabili. Per
esempio, la cifratura di un database è inutile se la connessione di accesso al database
non cifrato risulta disponibile
Sotto PCI Data Security Standard requisito 3, è necessario proteggere i dati del titolare
della carta. L’osservanza PCI DSS è obbligatoria dal 2008 per i commercianti e
chiunque altro si occupi di carte di credito. Buona pratica è quella di memorizzare
solamente i dati strettamente necessari, come la banda magnetica o il numero di
conto (PAN, altrimenti noto come il numero di carta di credito). Se si memorizza il PAN,
i requisiti DSS di conformità sono significativi. Ad esempio, non è mai permesso
lasciare il numero CVV (il numero a tre cifre sul retro della carta) in qualsiasi
circostanza. Per ulteriori informazioni, vedere il PCI DSS e gli orientamenti per
l'attuazione dei controlli
ESEMPI
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6145
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1664
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-1101 (valido per molti JAVA
EE container)
REFERENZE
CWE: CWE-311 (Failure to encrypt data), CWE-326 (Weak Encryption), CWE-321 (Use
of hard-coded cryptographic key), CWE-325 (Missing Required Cryptographic Step) e
altri
WASC Threat Classification
OWASP,
http://www.owasp.org/index.php/Cryptography
OWASP Guide,
http://www.owasp.org/index.php/Guide_to_Cryptography
38
39. OWASP Top 10 2007
OWASP,
http://www.owasp.org/index.php/Insecure_Storage
OWASP,
http://www.owasp.org/index.php/How_to_protect_sensitive_data_in_URL’s
PCI Data Security Standard v1.1,
https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf
Bruce Schneier,
http://www.schneier.com/
CryptoAPI Next Generation,
http://msdn2.microsoft.com/en-us/library/aa376210.aspx
39
40. A9 – INSECURE COMMUNICATION
Molto frequentemente le applicazioni non cifrano il traffico di rete in maniera da proteggere
tutte le comunicazioni sensibili. La crittografia di canale (solitamente SSL) deve essere usata
per tutti i collegamenti autenticati, in particolare su Internet, le pagine web accessibili, ma
anche le connessioni di backend. Altrimenti, l'applicazione risulterà vulnerabile ad aggressori
opportunamente posizionati, in quanto esporrà token di sessione e/o di autenticazione.
Connessioni cifrate dovrebbero essere usate ogni volta che dati sensibili, quali la carta di
credito o altre informazioni riservate, vengono trasmessi. In alcuni casi, gli aggressori forzano
l’utilizzo di meccanismi insicuri di cifratura (tramite “downgrading”) nelle applicazioni.
Lo standard PCI richiede che tutte le informazioni trasmesse su Internet e relative a carte di
credito siano crittografate.
SISTEMI AFFETTI
Tutti i framework per applicazioni web sono vulnerabili all’utilizzo di trasmissioni non sicure
VULNERABILITÀ
La mancata cifratura in comunicazioni sensibili comporta la possibilità, per un aggressore in
grado di catturare il traffico della rete (sniffing), di accedere alla conversazione e ad eventuali
credenziali o informazioni sensibili trasmesse. A seconda delle tipologie, alcune reti sono più
o meno suscettibili alle problematiche di sniffing. Inoltre è importante considerare il fatto che
un aggressore potrebbe eventualmente compromettere un computer nella rete, risultando
quindi in grado di installare rapidamente uno sniffer per catturare credenziali di altri sistemi.
L’utilizzo di SSL per le comunicazioni con gli utenti finali è un aspetto critico, considerando
che quest’ultimi accedono spesso alle applicazioni tramite reti insicure. Quando le
comunicazioni HTTP includono credenziali di autenticazione o token di sessione in ogni
singola richiesta, tutto il traffico autenticato deve essere incanalato tramite SSL. Tale
meccanismo non deve essere applicato solamente per le richieste di login.
Cifrare le comunicazioni da e verso i back-end server è altrettanto importante. Sebbene
queste reti siano probabilmente più sicure, le informazioni che passano attraverso questi
canali sono più sensibili ed estese. Per questa ragione, l’utilizzo di SSL sui back-end è un
aspetto decisamente importante.
Per molte organizzazioni, la cifratura di dati sensibili come carte di credito e numeri
dell’assistenza sociale è diventata parte integrante di regolamentazioni finanziare o legate
alla privacy. La negligenza nell’utilizzo di SSL per connessioni che trasportano tali
informazioni comporta un rischio di compliance.
VERIFICA DELLA SICUREZZA
L’obiettivo della verifica di sicurezza consiste nell’accertarsi che l’applicazione utilizzi
opportuna cifratura per tutte le comunicazioni sensibili ed autenticate.
40
41. OWASP Top 10 2007
Approccio automatico: i tool di scansione automatici possono verificare che SSL sia utilizzato
per il front-end, ed eventualmente evidenziare relative problematiche. Purtroppo questi tool
non hanno accesso alle connessioni di back-end e non sono quindi in grado di verificarne la
loro sicurezza. I tool di analisi statica possono aiutare durante l’analisi delle comunicazioni
verso i sistemi di back-end, sebbene non sono in grado di interpretare la logica funzionale
richiesta per tutti i tipi di sistemi.
Approccio manuale: sebbene il test manuale permetta di verificare puntualmente l’effettivo
utilizzo di SSL, oltre ad evidenziare specifiche problematiche sul lato front-end, l’approccio
automatico risulta probabilmente più efficiente. La revisione manuale del codice permette di
verificare l’utilizzo corretto di connessioni SSL verso tutte le connessioni di back-end.
PROTEZIONE
La protezione più importante è rappresentata dall’utilizzo di SSL per ogni connessione
autenticata, o in qualsiasi caso si trasmetta informazioni sensibili. Essendoci una serie di
dettagli tecnici importanti da considerare durante la configurazione di SSL in ambito web, la
comprensione e analisi dello specifico sistema è particolarmente importante.
A titolo di esempio si pensi ad un noto browser: IE 7.0 fornisce un barra verde per evidenziare
certificati SSL validi e fidati. Pur rappresentando un meccanismo di verifica efficace, questo
controllo non fornisce alcuna indicazione sull’utilizzo sicuro della tecnologia di crittografia.
Utilizzare SSL per tutte le connessioni autenticate che trasmettono dati sensibili o di
valore, come credenziali, dettagli relativi alle carte di credito, informazioni private o
legate allo stato di salute
Assicurarsi che tutte le comunicazioni tra gli elementi infrastrutturali, come web server
e database, siano propriamente protetti tramite l’uso di canali di trasmissione sicuri o
cifratura a livello di protocollo per credenziali o altre informazioni
Sotto PCI Data Security Standard requisito 4, è necessario proteggere i dati in transito
del titolare della carta. L’osservanza di PCI DSS è obbligatoria dal 2008 per i
commercianti e chiunque altro si occupi di carte di credito. In generale, clienti,
partner, il personale amministrativo e l'accesso online ai sistemi devono essere
criptati utilizzando SSL o simili. Per ulteriori informazioni, vedere il PCI DSS e gli
orientamenti per l'attuazione dei controlli.
ESEMPI
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6430
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4704
http://www.schneier.com/blog/archives/2005/10/scandinavian_at_1.htm l
REFERENZE
CWE: CWE-311 (Failure to encrypt data), CWE-326 (Weak Encryption), CWE-321 (Use
of hard-coded cryptographic key), CWE-325 (Missing Required Cryptographic Step) e
altri
WASC Threat Classification
41
42. OWASP Testing Guide, Testing for SSL / TLS,
https://www.owasp.org/index.php/Testing_for_SSL-TLS
OWASP Guide,
http://www.owasp.org/index.php/Guide_to_Cryptography
Foundstone - SSL Digger, http://www.foundstone.com/index.htm?
subnav=services/navigation.htm&subcontent=/services/overview_s3i_des.htm
NIST, SP 800-52 Guidelines for the selection and use of transport layer security (TLS)
Implementations, http://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf
NIST SP 800-95 Guide to secure web services,
http://csrc.nist.gov/publications/drafts.html#sp800-95
42
43. OWASP Top 10 2007
A10 – FAILURE TO RESTRICT URL ACCESS
L’unica protezione per l’accesso ad un URL è frequentemente legato al fatto che il link non sia
presente all’interno delle pagine mostrare ad utenti non autenticati. Dall’altro canto, un
aggressore opportunamente motivato o fortunato potrebbe essere in grado di trovare e
accedere a tali pagine, invocandone funzionalità e visualizzando dati. Il concetto di “security
through obscurity” non è da considerarsi come una protezione sufficiente per l’accesso a
funzioni o dati sensibili. Un meccanismo di controllo d’accesso deve essere effettuato prima
di permettere qualsiasi richiesta verso funzioni sensibili, in maniera da assicurare che solo
utenti autorizzati vi possano accedere.
SISTEMI AFFETTI
Tutti i framework per applicazioni web sono vulnerabili alle problematiche di “failure to
restrict URL access”
VULNERABILITÀ
Il principale metodo di attacco per questa vulnerabilità è chiamato “forced browsing” e
consiste nel tentativo di indovinare link nascosti e, tramite tecniche bruteforce, accedere a
pagine non protette. Nelle applicazioni web, il codice relativo al controllo d’accesso tende ad
evolvere e diffondersi in diversi componenti, risultando in un modello di sicurezza complesso
che ne rende difficile la comprensione per sviluppatori ed esperti di sicurezza. La complessità
aumenta la possibilità che errori di implementazione occorrano e, conseguentemente alcune
pagine vengano lasciate esposte.
Alcuni degli errori comuni riguardano:
URL “nascosti” or “speciali” visualizzabili solo ad amministratori o utenti privilegiati
all’interno del layer di presentazione ma accessibili a tutti gli utenti che sono a
conoscenza dello specifico link. A titolo di esempio, “/admin/adduser.php” e
“approveTransfer.do” sono due risorse molto comuni. Questo tipo di problematica è
particolarmente presente all’interno del codice utilizzato per sviluppare barre di menu.
Le applicazioni permettono spesso l’accesso a file “nascosti”, come file XML statici o
report di sistema, affidandosi allla “security through obscurity”
La logica funzionale che controlla le policy di accesso risulta datata ed insufficiente.
Immaginiamo che “approveTransfer.do” sia stato disponibile per tutti gli utenti in
precedenti versioni dell’applicazione. A causa dell’introduzione di controlli SOX, questo
script deve essere disponibile solamente ad utenti privilegiati. Una possibile (ed
errata) modifica dell’applicazione potrebbe consistere nel nascondere tale link
all’interno del menu applicativo senza effettivamente interrogare i meccanismi di
controllo di accesso
Il codice che analizza i privilegi utente risiede sul lato client e non sul server, come
accadde nel caso del MacWorld 2007, i cui pass “Platinum” del valore di 1700$ erano
controllati tramite JavaScript sul lato browser invece che sul server
43
44. VERIFICA DELLA SICUREZZA
La verifica deve consistere nell’accertarsi che i meccanismi di controllo d’accesso siano
implementati correttamente, in maniera consistente tra layer di presentazione e business
logic, per tutti gli URL dell’applicazione.
Approccio automatico: sia i dispositivi di scansione di vulnerabilità che gli strumenti di analisi
statica incontrano difficoltà con la verifica del controllo di accesso dell’URL per motivi
differenti. I dispositivi di scansione di vulnerabilità hanno difficoltà a trovare le pagine
nascoste affette da questa problematica e determinare quali pagine dovrebbero essere
visibili ad ogni utente, mentre gli strumenti di analisi statica hanno difficoltà ad identificare i
comandi di accesso e di collegare il livello di presentazione con la business logic.
Approccio manuale: il metodo più efficiente e più corretto è di utilizzare una combinazione di
revisione del codice e di test di sicurezza per verificare il meccanismo di controllo di accesso.
Se il meccanismo è centralizzato, la verifica può essere abbastanza efficiente. Se il
meccanismo si distribuisce attraverso tutto il codice applicativo, la verifica può richiede più
tempo. Se il meccanismo è applicato esternamente, la configurazione deve essere esaminata
e provata.
PROTEZIONE
La chiave nell’implementazione di un sistema di protezione contro l’accesso non autorizzato
agli URL è un’attività dispendiosa in termini di tempo, poiché richiede la creazione di una
matrice che riassumi tutti i ruoli e le funzioni usati all’interno dell’applicazione web. Le
applicazioni web devono forzare il controllo d’accesso per ogni URL e logica di business. Non
e’ sufficiente implementare un controllo d’accesso nel layer di presentazione, lasciando non
protetta la logica di business. Inoltre non è sufficiente controllare una sola volta che l’utente
sia autorizzato, ma il controllo deve essere effettuato per ogni richiesta successiva. Il rischio è
che un eventuale aggressore potrebbe saltare alcuni passi di navigazione, in cui il controllo
viene effettuato, ed accedere a pagine successive opportunamente forgiando alcuni
parametri.
Il controllo di accesso per gli URL richiedere una pianificazione attenta. Alcune importanti
considerazioni sono:
Assicurarsi che la matrice del controllo di accesso sia parte della
progettazione dell’applicazione, della sua architettura e della business logic
Assicurarsi che tutti gli URL e le funzioni della business logic siano protetti
da un effettivo meccanismo di controllo di accesso che permetta di verificare il
ruolo dell’utente e i suoi privilegi, ancora prima di qualsiasi operazione. Accertarsi che
questo controllo venga effettuato per ogni singola operazione e non solamente
all’inizio di ogni funzione
Effettuare un penetration test prima di rilasciare il codice in maniera da
assicurarsi che l’applicazione non possa essere abusata da un aggressore
sufficientemente motivato
44
45. OWASP Top 10 2007
Fare attenzione all’utilizzo di direttive “include” e librerie, specialmente nel
caso di file con estensioni eseguibili come .php. Dove possibile, utilizzare componenti
al di fuori della web root. Inoltre queste risorse devono essere verificate in maniera da
assicurare che non sia possibile accederle direttamente e che, per esempio, non si
possa controllare una specifica costante creata dall’applicazione
Non presumere che gli utenti non siano a conoscenza di URL speciali,
nascosti o link a API. Assicurarsi sempre che tutte le funzioni di amministrazione o
che richiedono alti privilegi siano protette
Bloccare l’accesso a tutti i file che l’applicazione non deve fornire.
Idealmente, questo filtro dovrebbe essere implementato con la teoria dell’ “accetta
solo il buono” e fornire solamente estensioni permesse (per esempio, .html, .pdf,
.php). Questo permette di bloccare qualsiasi tentativo di accesso a file di log, file xml,
ecc. che non devono essere fruiti dall’utente finale
Mantenere aggiornati, tramite patches e protezioni antivirus, tutti i
componenti applicativi come processori XML, di testo, di immagini, ecc. i quali
gestiscono dati forniti dall’utente
ESEMPI
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0147
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0131
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1227
REFERENZE
CWE: CWE-325 (Direct Request), CWE-288 (Authentication Bypass by Alternate Path),
CWE-285 (Missing or Inconsistent Access Control)
WASC Threat Classification,
http://www.webappsec.org/projects/threat/classes/predictable_resource_location.shtml
OWASP,
http://www.owasp.org/index.php/Forced_browsing
OWASP Guide,
http://www.owasp.org/index.php/Guide_to_Authorization
45
46. OLTRE LA OWASP TOP TEN
La OWASP Top 10 è solamente l’inizio del tuo viaggio verso la sicurezza delle applicazioni
web.
“I sei miliardi di persone nel mondo possono essere divise in due categorie: il primo
gruppo è composto da chi è consapevole del perchè ottime aziende di software rilasciano
prodotti con bug, mentre il secondo è composto da chi non è altrettanto consapevole.
Quelli nel primo gruppo tendono a dimenticare la vita prima che il giovanile entusiasmo
venisse spezzato dalla realtà.
A volte capita di incontrare una persona appartenente al secondo gruppo...la quale è
sconvolta dal fatto che ogni azienda di software rilasci un prodotto ancora prima che
l’ultimo bug venga risolto.”
Eric Sink, Guardian May 25, 2006
La maggior parte degli utenti appartiene al secondo gruppo.
Il modo in cui viene gestito il problema rappresenta un’opportunità per migliorare il tuo
codice ed in generale lo stato della sicurezza web. Miliardi di dollari vengono persi ogni anno
e moltissime persone sono vittime di furti di identità e frodi online a causa delle vulnerabilità
discusse in questo documento.
PER GLI ARCHITETTI ED I PROGETTISTI DI SOFTWARE
Per garantire l’appropriata sicurezza delle tue applicazioni devi conoscere quello che vuoi
mettere in sicurezza (asset classification), conoscere le minacce ed i rischi derivanti dalla
mancata sicurezza applicativa in maniera da indirizzare i tuoi sforzi. Progettare qualsiasi tipo
di applicazione complessa richiede una buona dose di sicurezza.
Assicurati che venga applicata la filosofia del “tanto quanto basta” per la
definizione dei rischi e la classificazione delle risorse. Sebbene le attuali leggi di
conformità (SOX, HIPAA, Basel, ecc.) impongono delle sempre più maggiori pressioni
verso le aziende, può essere appropriato investire molte più risorse e tempo rispetto a
quanto richiesto dalle misure minime, in particolare se le linee guide sono note e
notoriamente più rigide dei requisiti minimi.
Domanda quali sono i requisiti applicativi in termini di business, in particolare
rispetto ai requisiti non funzionali
Lavora insieme al tuo cliente sulla OWASP Secure Software Contract Annex
Incoraggia l’adozione di pratiche di sicurezza progettuali – includendo le
logiche di “difesa in profondità’” e alcuni semplici modelli utilizzati nell’analisi delle
minacce (si faccia riferimento a [HOW1] all’interno dei riferimenti bibliografici.
Assicurati che vengano soddisfatti i requisiti di confidenzialità’, integrità’,
disponibilità e non ripudio
Assicurati che i progetti siano consistenti rispetto alle security policy e agli
standard come il COBIT e la PCI DSS 1.1
46
