Smau Milano 2014 - Andrea Zwirner

23 ottobre 2014SMAU 2014

Andrea Zwirner – LinkspiritSicurezza delle applicazioni web

1

Sicurezza delle applicazioni web

Andrea Zwirner – Linkspirit

[email protected]

@AndreaZwirner



2Andrea Zwirner 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 sicurezza informatica

– Consulenza nella progettazione sicura di software e sistemi

– Verifiche di sicurezza su software e sistemi

– Formazione in materia di sicurezza informatica



3Andrea Zwirner Partecipo a diversi progetti legati la ricerca e divulgazione della

cultura sulla sicurezza informatica



4La sicurezza informaticaInsieme di misure di carattere organizzativo, tecnologico e procedurale mirate a garantire

– CONFIDENZIALITÀ

– INTEGRITÀ

– DISPONIBILITÀ

dell'informazione.



5Sicurezza 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



6



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



8Consapevolezza



9Titolo della Presentazione e della slide

“[…] 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



10Sicurezza delle applicazioni web 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

– Ampia superficie d'attacco

– Svariati petabyte di informazioni di miliardi di utenti (privati, aziende, banche e governi)

– Accesso diretto alle macchine degli utenti stessi



11La metodologia

O W A S PThe Open Web Application Security Project



12Cos'è l'OWASP

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”



13Cosa fa l'OWASP Attiva nel campo della 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



14Progetti OWASP interessanti Top Ten Project

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



15Top Ten Project 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



16Top 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



17A1 – Injection 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



18A1 – Impatti 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



19A1 – Esempio SQL Injection Parametrizzazione insicura di una query SQL

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)








Parametri attesi


Esempio di parametro inatteso

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








Parametri attesi



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

SELECT * FROM tab WHERE id = '23'; DROP TABLE tab; --'



23A1 – Injection fun!



24A1 – Injection fun!

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



25A1 – OS Injection Parametrizzazione insicura di un comando shell

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


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



26A1 – Prevenzione 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!



27A1 – Rilevazione 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



28A1 – Esempio di parametrizzazione sicura 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);



29A2 – Broken Auth and Session Mgmt 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



30A2 – Impatti Difficoltà di sfruttamento: media

Impatto tecnico: grave

– Accesso con i privilegi di autorizzazione di qualunque utente, anche amministrativo


– Proporzionale al valore di business dei dati trattati o delle funzioni applicative

– Considerare l'impatto sul business della pubblicazione della falla (attacchi e reputazione)



31A2 – Scenari d'attacco 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



32A2 – Prevenzione 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



33A2 – Rilevazione [1/2] 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?



34A2 – Rilevazione [2/2] Le sessioni hanno timeout?

Gli utenti possono disconnettersi?

Gli id di sessione sono cambiati in seguito ad ogni variazione nel livello di autorizzazione?

Le password e gli id di sessione sono scambiati attraverso canali crittografati? (→ A6: Sensitive Data Exposure)



35A4 – Insecure Direct Object References 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



36A4 – Impatti 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



37A4 – Scenario d'attacco

1. conto = _post['conto'];

2. query = prepara('SELECT * FROM conti WHERE conto = %', conto);

3. result = invia_al_database(query);


L'attaccante non deve fare altro che modificare il parametro POST conto ed otterrà il risultato per un conto per cui non possiede autorizzazione.



38A4 – Prevenzione 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 di fornire il contenuto



39A4 – Esempio sicuro Mappatura agli oggetti

1. query = prepara('SELECT prendiContiSessione(%)', session_id);

2. conti[] = invia_al_database(query);

3. metti_conti_in_dropdown(conti[], dropdown);

… qui c'è l'interazione dell'utente …



40A4 – Esempio sicuro

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



41A4 – Rilevazione e prevenzione 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 in 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!



42



[email protected]

@AndreaZwirner



43A8 – Cross-site Request Forgery (CSRF) 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



44A8 – Impatti Difficoltà di sfruttamento: media

Impatto tecnico: medio

– Per quanto distruttive, l'attaccante può far eseguire solo funzioni cui l'utente è autorizzato


– Considerare l'importanza a livello di business dei dati trattati

– Considerare l'importanza di non essere certi dell'effettiva intenzione dell'utente



45A8 – Esempio L'utente è autenticato sul sito www.sito.it e visita (volontariamente o

meno) una pagina del sito dell'attaccante contenente:

<img src='http://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



46A8 – Prevenzione 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 con tempi inversamente proporzionali al livello di autorizzazione degli utenti



47A8 - Rilevazione 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 più gettonate

– In caso di limiti di tempo o budget concentrarsi su queste

Tenere in considerazione che, per prevenire attacchi del tipo CSRF, non si può fare affidamento su cookies o indirizzi IP di provenienza



48



[email protected]

@AndreaZwirner



49Riferimenti 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 – Ding 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

Smau Milano 2014 - Andrea Zwirner

Technology

Transcript of Smau Milano 2014 - Andrea Zwirner

La pratica della Sicurezza Informatica dall'artigianato ...profs.sci.univr.it/~mastroeni/download/CurrSecurity/zwirner_linkspirit… · 24 febbraio 2015 Andrea Zwirner – Linkspirit

Seminario sulla sicurezza delle reti · Seminario sulla sicurezza delle reti – secondo modulo 1 Seminario sulla sicurezza delle reti Andrea Zwirner [email protected] @AndreaZwirner

Smau Milano 2014 - Andrea Boscaro

Smau Torino 2013 Andrea Bacchetti

Personal Branding - Smau 2010

Smau Firenze 2015 - KPMG

SMAU MILANO – 17/18/19 OTTOBRE ROMA BARI Progetto Smau ... · pag. 1 IL PROGETTO Progetto Smau Business Roadshow 2012 LA FORMULA Il nuovo format Smau È ideato congiuntamente agli

Workshop SMAU Milan

Contributi e finanziamenti per imprese e start up andrea povelato smau padova 2013

Smau Milano 2016 - Andrea Michinelli e Stefano Ricci | Sanità

Smau Milano 2016 - Andrea Michinelli e Stefano Ricci | Geotagging

Smau Firenze 2015 - Easygov

Smau bologna2014

Speciale SMAU

La pratica della Sicurezza Informatica dall'artigianato …profs.scienze.univr.it/~mastroeni/download/CurrSecurity/... · 2016. 2. 4. · 24 febbraio 2015 Andrea Zwirner – Linkspirit

SMAU Milano 2015

Smau milano 2013 andrea bacchetti

Smau mi 2012

SMAU firenze i_Dome

Smau Bari 2010 Andrea De Maggio