Download - Infosecurity 2008
Copyright © The OWASP FoundationPermission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.
The OWASP Foundation
OWASP
http://www.owasp.org
Costruire software sicuro dallefondamenta
Antonio Parata
Infosecurity 20086 Febbraio 2008
OWASP 2
IndiceIntroduzione
Ciclo di sviluppo software
Attività Security RelatedAttack Patterns
Abuse Cases
Security Requirements
Security Patterns
Threat Modeling
Coding Security Principles
Security Code Review
Security Testing
Penetration Testing
Visione Globale
Conclusioni e Sviluppi Futuri
OWASP
Introduzione – di cosa parliamo?
Parleremo della attività all‟interno di un SDLC, non del SDLC.
Ci permette di astrarci dal singolo ciclo di sviluppo software.
Ci permette di scegliere quale attività meglio si sposa con le nostre necessità e quale implementare per prima all‟interno del nostro processo di sviluppo.
3
Ci interessa sapere quali sono le attività che ci permettono di scrivere
applicazioni più sicure e contemporaneamente risparmiare
tempo e soldi.
OWASP
Introduzione – Cost of fixing security flaws
Il costo per rimediare ad una vulnerabilità aumenta con il progredire delle fasi.
4
OWASP
Introduzione – Defect, Bug, Flaw
Defect: “tutte le vulnerabilità sono dei difetti, indipendentemente dal fatto che siano al livello di codice o di design”.
Bug: “un bug è una vulnerabilità presente al livello di codice”.
Flaw: “una flaw è una vulnerabilità al livello di design“.
Definizioni tratte da Software Security – Gary McGraw 2007
5
OWASP
Introduzione – Defect ratio
6
“In media il 50% dei difetti sono bug e il restante 50% sono
Flaw” da Software Security - Gary McGraw 2007
La sola attività di code review mira a risolvere solo metà delle potenziali
vulnerabilità presenti.
OWASP
Ciclo di sviluppo software – Software Security VS Application Security
7
Software Security: comprende tutte quelle attività che trovano posto all‟interno del ciclo di sviluppo software, ad esempio:
Security Requirements
Threat Modeling
Secure Code Auditing
Penetration testing
…
Application Security: comprende tutte quelle attività che trovano posto in una fase post sviluppo, ad esempio:
Penetration testing
Secure deployment
Security Response Planning
…
OWASP
Ciclo di sviluppo software – Alcuni modelli
Esistono vari cicli di sviluppo software, ognuno con pregi e difetti
A Cascata: utile nello sviluppo di programmi con requisiti ben definiti e poco variabili (ad esempio compilatori).
Iterativo: utile nello sviluppo di progetti medio/grossi. Permette una buona gestione del processo di sviluppo e permette di far fronte ai cambiamenti (fino ad un certo punto).
Metodi agili: il codice è la documentazione. Utile in quei casi in cui i requisiti sono poco chiari. Non adatto per progetti di grosse dimensioni.
8
OWASP
Ciclo di sviluppo software – Waterfall model
9
OWASP
Ciclo di sviluppo software – Waterfall model(Security Oriented)
10
OWASP
Attack Patterns – Cosa sono?
11
Concetto derivante dai Design Patterns.
Raggruppano le caratteristiche che hanno in comune alcune vulnerabilità.
Utilizzati per individuare quali sono le maggiori aree a rischio nella propria applicazione.
Vengono utilizzati non solo nella stesura dei requisiti, ma anche nelle successive fasi del SDLC
Non è necessario modificare il SDLC.Vengono utilizzati come Knowledge Base aziendale
Necessitano di uno sforzo iniziale di definizione e catalogazione
OWASP
Attack Patterns – Un esempio
12
Buffer Overflow Attack Pattern
Goal: Sfruttare vulnerabilità da buffer overflow per eseguire un
codice malevolo sul sistema target.
Precondizioni: Un attaccante deve essere in grado
di poter eseguire programmi sul sistema target.
Attacco:
AND
1. Identificare programmi eseguibili privilegiati sul sistema
target che siano suscettibili a buffer overflow.
2. Creare un vettore d’attacco che conterrà il codice
malevolo che si vuole far eseguire.
3. Creare il codice malevolo che si vuole far eseguire
(anche detto payload).
4. Eseguire il programma in modo che prenda in input il
vettore d’attacco creato al punto 2.
Postcondizioni: il payload viene eseguito sul sistema target.
OWASP
Security Requirements – (1)
13
Utilizzo ortogonale a quello degli abuse cases (li vedremo a breve).
Specificano che caratteristiche di sicurezza il software dovrà garantire durante il suo operato. Analogamente specificano anche in che modo si intende porre rimedio in fase di design/sviluppo ai possibili attacchi identificati tramite gli abuse cases.
Elicitazione dei Security Requirements:Sessioni di brainstorming
Utilizzo di attack patterns
La loro integrazione all‟interno del SDLC è nella fase di definizione dei requisiti.
È una fase parallela a quella di definizione degli abus cases, ma è fondamentale tenere le due fasi separate.
OWASP
Security Requirements – (2)
14
Una volta identificati i Security Requirements è buona cosa elencarli secondo un ben preciso criterio in modo da decidere quali requisiti di sicurezza implementare per primi.
Varie metodologie di prioritizzazione esistono:Binary Search Tree: si comparano a due a due i requisiti e in base a quale si considera più importante si crea un albero binario bilanciato.
Numeral Assignment Technique: ad ogni requisito si assegna un numero da 1 (desiderato) a 5 (mandatorio). In questo modo si crea una scala di importanza dei requisiti che varia dal mandatorioall‟inessenziale.
Analytical Hierarchy Process (AHP): utilizza una matrice “valore/costo di implementazione”. In ogni cella vi è un requisito. In seguito si crea un diagramma con sulle ascisse i requisiti e sulle ordinate il rapporto costo/valore.
OWASP
Security Requirements – (3)
15
Esempi:“L‟applicazione deve prevedere l‟identificazione e l‟autenticazione degli utenti. Devono essere definiti degli opportuni ruoli a cui devono essere assegnati opportuni privilegi.”
“L‟applicazione deve prevedere un sistema di accounting. I dati dell‟utente e le informazioni personali devono essere memorizzate in modo sicuro (utilizzando ad esempio funzioni di hash). Il sistema deve anche prevedere un metodo per evitare che gli utenti scelgano password deboli (minimizzare attacchi di dizionario e di brute force)”
“Tutte le richieste ricevute dal server vengono convogliate verso un unico punto di validazione dell‟input, in cui vengono applicati una serie di filtri con tipologia white list.”
OWASP
Abuse Cases – Cosa sono
16
Anche detti Misuse Cases, vengono realizzati per aiutare il progettista a pensare come un attaccante.
Generalmente creati tramite sessioni di Brainstorming.
A differenza dei requisiti, gli Abuse Cases dovranno avere un corrispettivo piano di mitigazione all‟interno dell‟applicazione.
L‟integrazione all‟interno del SDLC avviene nella fase dei requisiti.
Viene aggiunta un‟ulteriore fase in parallelo a quelle esistenti.
OWASP
Abuse Cases – Creare Abuse Case utili
17
ProcessoCreare un team di analisti e di esperti di sicurezza per il Brainstorming
Analizzare i requisiti (di sicurezza e non) e gli use case disponibili
Identificazione delle minacce
Utilizzando le minacce identificate utilizzare gli attack patterns per vedere in che modo le minacce possono realizzarsi
A partire dall‟analisi precedente creare i relativi abuse case
Esempio:“Un utente malintenzionato può aggirare le restrizioni sull‟input che vengono applicate sul client, inviando una richiesta appositamente forgiata utilizzando tool esterni.”
OWASP
Security Patterns – Cosa sono
18
Utilizzati nella fase di progettazione, per costruire un design “sicuro by default”.
Le applicazioni web sono generalmente realizzate con architetture multi-tier
Web Tier: riceve le richieste degli utenti ed è responsabile per l‟accesso ai componenti del Business Tier
Business Tier: gestisce la logica di business e i relativi dati di business
Integration Tier: Gestisce e facilita la comunicazione con “data source” esterni
Per ogni tier esistono security patterns per la loro messa in sicurezza.
OWASP
Security Patterns – Applicazione
19
Patterns-Driven Security Design:Creare un‟architettura (design di alto livello) candidata dell‟applicazione
Eseguire un‟analisi del rischio sull‟architettura prescelta
Progettare l‟applicazione utilizzando i security design conosciuti, in modo da soddisfare i requisiti di sicurezza dell‟applicazione.
Se non esiste un security pattern adatto, modificare il design dell‟applicazione in modo che rispetti il requisito. In seguito aggiungere il nuovo pattern di design all‟elenco posseduto.
Come gli attack pattern non vi è una vera e propria integrazione all‟interno del SDLC, ma fanno invece parte della knowledge base aziendale.
Elenchi di security patterns e ulteriori informazioni possono essere reperite da http://www.securitypatterns.org/
OWASP
Security Patterns – Un esempio concreto (1)
20
Pattern J2EE Intercepting ValidatorAvere un meccanismo semplice e flessibile per validare i dati ricevuti dall‟esterno.
OWASP
Security Patterns – Un esempio concreto (2)
21
Funzionamento del Pattern J2EE Intercepting Validator
OWASP
Security Patterns – Altri esempi di pattern
22
Web Tier:Secure Communication: descrive l‟utilizzo di un canale di comunicazione sicuro per lo scambio di dati tra client-client o client-server.
Single Access Point: questo pattern detta l‟utilizzo di un singolo punto di accesso ai servizi di business, passando attraverso una formdi login.
Session: Specifica come le informazioni di sessione dovrebbero essere mantenute in un ambiente multi-threaded e multi-user.
Business Tier:Role: questo pattern specifica come utilizzare i ruoli per separare uno specifico utente dai propri privilegi.
Security Event Logging: questo pattern specifica come catturare e tenere traccia degli eventi security-related, per eventuali riskassessment o ulteriori analisi.
OWASP
Threat Modeling
23
Tra le fasi più importanti per la produzione di software sicuro.
Lo scopo è quello di identificare, valutare e porre rimedio alle minacce identificate.
Esistono molteplici definizioni
Utilizza Attack tree
Data flow diagram
Risk Evaluation model
Attività di tipo iterativo da affiancare in parallelo alla fase di design.
Produce un documento, il Threat Model, contenente le minacce e le vulnerabilità identificate (tra le altre
cose).
OWASP
Threat Modeling
24
Identificazione degli assets: identificare cosa si vuole proteggere. Senza assets da proteggere non vi sono minacce.
Identificazione degli Entry Points: identificare in che modo posso accedere agli assets.
Modellazione del sistema: utilizzo di formalismi per modellare il sistema
Identificazione delle minacce: identificare le minacce di ogni asset.
Valutazione delle minacce e risoluzione: valutare tramite un modello di valutazione, il rischio di ogni minaccia.
Generazione Threat Model: generare la documentazione finale.
START
Identificazione
degli assets da
proteggere
Identificazione
degli entry points
Modellazione del
sistema
Identificazione
delle minacce
Valutazione delle
minacce e loro
risoluzione
Sono state
identificate
tutte le
minacce?
NO
Generazione
threat model
OWASP
Threat Modeling
25
Gli Attack Tree rappresentano un utile formalismo nell‟identificazione delle minacce.
Web form
Authentication
Bypass
1. Modifica delle
credenziali nel
DB
2. Furto del
token di
sessione di
un’altro utente
3. Attacco di
brute force sulla
web form
4. Attacco di
brute force sul
token di
sessione
1.2 Accesso
indiretto al DB
Tramite SQL
Injection
1.1 Accesso
diretto al DB
L’accesso
diretto al DB è
mitigato dalla
presenza di un
firewall
Le query
uilizzano i
prepared
statements
2.1 ’applicazione
è vulnerabile ad
attacchi XSS
2.2 Il token non
deve essere
modificato
durante la
sessione
Ad ogni
richiesta viene
data
“freschezza” al
token
Il token viene
creato dal
framework
sottostante
OWASP
Threat Modeling – Data Flow Diagram (1)
26
I DFD risultano utili nel comprendere la struttura dell‟applicazione e i suoi punti critici.
Esistono vari livelli di rappresentazione:Context Diagram: è il primo livello, vengono rappresentati solo le entità di interazione e un singolo processo (l‟applicazione)
Livello0: L‟applicazione viene scomposta e ulteriori dettagli come l‟interazione con eventuali basi di dati o ulteriori processi viene evidenziata:
Livello1: …
Vengono anche rappresentati i “trust boundaries” ovvero punti in cui vi è un fluire di dati da una zona a bassi privilegi ad una zona con privilegi maggiori.
OWASP
Threat Modeling – Data Flow Diagram (2)
27
Esempio di Livello0
OWASP
Coding Security Principles
28
Sottostare a dei principi (meglio se policy) di scrittura di codice sicuro può far diminuire drasticamente la possibilità di inserire vulnerabilità nel codice.
È possibile utilizzare framework appositiPHP AntiXSS Libraryhttp://www.owasp.org/index.php/Category:OWASP_PHP_AntiXSS_Library_Project
OWASP Validation Project http://www.owasp.org/index.php/Category:OWASP_Validation_Project
ESAPI - Enterprise Security API http://www.owasp.org/index.php/ESAPI
Utilizzo di standard o riconosciuti come taliOWASP Guide http://www.owasp.org/index.php/Guide_Table_of_Contents
OWASP PHP Project http://www.owasp.org/index.php/Category:OWASP_PHP_Project
OWASP
Coding Security Principles – Esempi
29
Utilizzo di librerie e funzioni “safe”Safe String handling
Secure random number generator
Secure unique file creation
Utilizzo di Secure Coding ConventionControllare sempre il valore di ritorno
Utilizzo di header file che sollevano un errore quando si utilizza una funzione considerata “unsafe”
Eliminare il codice obsoleto o mai raggiungibile (dead code)
Riutilizzo del codice ove possibile
OWASP
Security Code Review
30
Tra le fasi più efficaci per l‟identificazione di errori nel codice.
Sessioni da massimo quattro ore con un intervallo a metà sessione
Varie strategie di esecuzioneBottom Up
Top Down
Ibrida
Attività “Brain Intensive”Un buon tool di analisi statica del codice sorgente può far diminuire drasticamente i tempi di analisi.
Attività da includere nella fase di testing e analisi.
OWASP
Security Code Review – Riferimenti
31
Per quel che riguarda i tool ne esistono diversi tra cui:Milk (utilizza Orizon) http://downloads.sourceforge.net/milk/milk-0.10.tar.gz?use_mirror=osdn
LAPSE http://www.owasp.org/index.php/Category:OWASP_Orizon_Project
Pixy http://pixybox.seclab.tuwien.ac.at/pixy/
Anche se la letteratura non è molto ricca, esistono delle buone fonti:
“The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities” da considerarsi la bibbia del security code review
OWASP Code Review Project http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project
OWASP
Security Testing – Introduzione (1)
32
Il testing è l‟attività ortogonale alla fase di analisi.A volte è più facile identificare degli errori con dei semplici test invece di analizzare il codice
Generalmente effettuato internamente alla propria azienda
Necessità una approfondita conoscenza del codice prodotto e delle sue funzionalità
Per effettuare i test si necessita di un certo ambiente di esecuzione che non è semplice ricreare
Coprono solo limitate porzioni di codiceTipicamente si tratta di test di unità
Viene effettuato utilizzando tutta la conoscenza posseduta (no Black Box)
Non dare nulla per scontato
OWASP
Security Testing – Introduzione (2)
33
Concentrarsi su test di negativitàSi tende a creare test positivi
Necessità di una fase iniziale di configurazione dell‟ambiente (Scaffolding)
Creazione degli eventuali Driver
Creazione degli eventuali Stub
Creazione degli oracoli
La sua integrazione all‟interno del‟SDLC si basa sulla modifica della normale attività di testing.
OWASP
Security Testing – Creazione Test (1)
34
Per la realizzazione di test efficaci tenere conto dei seguenti criteri:
Statement Coverage: Selezionare un insieme di test tali che il programma esegua ogni statement almeno una volta.
Edge Coverage: Selezionare un insieme di test tali che il programma attraversi ogni nodo del grafo di controllo almeno una volta.
Condition Coverage: Selezionare un insieme di test tali che il programma attraversi ogni nodo del grafo di controllo e in più ogni condizione atomica delle condizioni più complesse sia eseguita almeno una volta.
Path-Coverage: Selezionare un insieme di test tali che il programma percorra ognuno dei singoli path esistenti.
OWASP
Security Testing – Creazione Test (2)
35
Attenzione!!!la formalità è cosa buona ma ricordate che siete dei tester, non dei teorici. Il vostro scopo è assicurarsi
che non ci siano vulnerabilità nel software che state testando.
OWASP
Security Testing – Creazione Test (3)
36
Creazione dei valori di test per casi numericiValore di confine della condizione
Valore di confine della condizione + 1
Valore di confine della condizione – 1
0
-1
Massimo numero interno positivo
Massimo numero intero positivo - 1
Minimo numero interno negativo
Massimo numero interno positivo / 2
(Massimo numero intero positivo / 2) - 1
Minimo numero intero negativo / 2
OWASP
Security Testing – Creazione Test (4)
37
Creazione dei valori di test per variabili stringaDelimitatore di campo (ad esempio: „, “, ;, :, …)
Format String (%n, %s, %x, …)
Codifica dei caratteri (%27, …)
Caratteri di controlli o non facenti parte dei dati (<, >, &, |, …)
Ripetizione stringa per valori di potenza di 2
OWASP
Penetration Testing – Introduzione
38
Tra le attività più in voga per mettere alla prova la sicurezza dei propri applicativi.
Tipicamente eseguita in fasi inoltrate del SDLC
Esistono varie tipologie di testing che si differenziano sul livello di conoscenza posseduto
Black Box
White Box
Gray Box (anche detto Glass Box)
In un ciclo di sviluppo security oriented, la finalità principale dovrebbe essere di individuare vulnerabilità nel Deployment dell‟applicazione.
Evitare di ripetere gli “unit-level” test, già fatti nella fase precedente e concentrarsi su quei test che non si è potuti svolgere (test di sistema)
OWASP
Penetration Testing – Processo black box (1)
39
Info Ghatering: scoperta dei servizi presenti (e loro versione) sugli IP da testare. Fase eseguita attraverso l‟aiuto di tool automatici (nmap, dirbuster, etc…).
Vulnerability Discovery: si cerca di identificare le vulnerabilità del sistema:
Utilizzo di tool automatici come nikto, appscan o webinspect per effettuare uno scan di tutti i servizi attivi con il fine di identificare eventuali vulnerabilità note.
Utilizzo di tool di brute force come Cain o Dirbuster.
Utilizzo di tool di fuzzing come Peach, beStorm o codenomicon. Per protocolli custom si può sempre utilizzare sulley per scriversene uno da soli.
Utilizzo di tool di code injection come sqlninja o sqlmap.
OWASP
Penetration Testing – Processo black box (2)
40
Exploiting: si cerca di sfruttare le vulnerabilità identificate per penetrare nel sistema.
Ricerca di exploit su siti dedicati
Utilizzo di suite apposite (vedi Metasploit, Canvas o Core Impact)
Utilizzo di tool che oltre al discovery effettuano anche l‟attacco (vedi sqlninja o sqlmap)
Se avete in azienda un “exploiter” è il momento di farlo lavorare
Report: scrittura del report.
OWASP
Penetration Testing – Processo black box (3)
41
Tips & TricksPer applicazioni scritte in linguaggio di medio/basso livello come C o C++, fate abbondante uso di tool di fuzzing
In caso di testing di applicazioni web, per prima cosa identificate le form di autenticazione e lanciate dei brute force tenendo conto dei vincoli che impone il sistema (ad esempio lo username è di soli numeri piuttosto che la propria e-mail oppure il campo della password è limitato a 6 caratteri)
Dopo il brute force sull‟account lanciate un tool di resource discoveryper identificare eventuali risorse di backup o file di configurazione
Utilizzate dei tool automatici di force browsing. Questi toolpermettono tramite crawling di identificare eventuali pagine a cui l‟accesso è permesso solo tramite autenticazione
OWASP
Penetration Testing – Considerazioni
42
Quanto prima presentato è un tipico processo di un penetration test di livello applicativo effettuato esternamente
Un penetration test dovrebbe essere effettuato con una certa regolarità
Comparsa di nuove metodologie di attacco
Comparsa di nuove vulnerabilità nelle librerie utilizzate
Introduzione di modifiche (errate) alla configurazione dei sistemi
…
Affidarsi anche ad aziende esterne permette di testare l‟applicazione in modo più efficace
Aziende specializzate hanno un maggiore know-how
Possiedono tool specifici
Possono essere a conoscenza di vulnerabilità non note alla comunità (0day)
OWASP 43
Visione globale
Abuse CasesSecurity
Requirements
Threat
Modeling
Attack Trees
Data Flow
Diagram
Secure Code
Review
Security
Testing
Penetration
Testing
Attack Patterns Security Patterns
Knowledge Base
Utilizza
Utilizza
Requ
isiti
e
Casi
d’us
o
Softw
are
Desig
n
Impl
emen
tazio
ne e
Test
ing
OWASP 44
Conclusioni e Sviluppi Futuri
Correzione delle vulnerabilità già dalle prime fasi del SDLC.
Esistono svariate attività che possono essere incluse nel SDLC per aumentare la sicurezza dell‟applicazione già dalle prime fasi.
Includere tali attività in modo incrementale all‟interno del proprio SDLC.
In futuro si prevede:Un‟ulteriore evoluzione per le attività presenti nelle prime fasi del SDLC.
Comparsa di tool per automatizzare o comunque facilitare buona parte delle attività presentate.
Comparsa di (ulteriori) metodologie per quantificare (qualitativamente o quantitativamente) la sicurezza del proprio software.