2. Indice
Introduzione
Ciclo di sviluppo software
Attività Security Related
Attack 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 2
3. 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.
Ci interessa sapere quali sono le attività
che ci permettono di scrivere
applicazioni più sicure e
contemporaneamente risparmiare
tempo e soldi.
OWASP 3
4. Introduzione – Cost of fixing security flaws
Il costo per rimediare ad una vulnerabilità aumenta con il
progredire delle fasi.
OWASP 4
5. 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
OWASP 5
6. Introduzione – Defect ratio
“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 6
7. Ciclo di sviluppo software – Software
Security VS Application Security
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 7
8. 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.
OWASP 8
10. Ciclo di sviluppo software – Waterfall model
(Security Oriented)
OWASP 10
11. Attack Patterns – Cosa sono?
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 11
12. Attack Patterns – Un esempio
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 12
13. Security Requirements – (1)
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 13
14. Security Requirements – (2)
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 mandatorio
all‟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 14
15. Security Requirements – (3)
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 15
16. Abuse Cases – Cosa sono
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 16
17. Abuse Cases – Creare Abuse Case utili
Processo
Creare 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 17
18. Security Patterns – Cosa sono
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 18
19. Security Patterns – Applicazione
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 19
20. Security Patterns – Un esempio concreto (1)
Pattern J2EE Intercepting Validator
Avere un meccanismo semplice e flessibile per validare i dati ricevuti
dall‟esterno.
OWASP 20
21. Security Patterns – Un esempio concreto (2)
Funzionamento del Pattern J2EE Intercepting Validator
OWASP 21
22. Security Patterns – Altri esempi di pattern
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 form
di 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 risk
assessment o ulteriori analisi.
OWASP 22
23. Threat Modeling
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 23
24. Threat Modeling
START
Identificazione degli assets: identificare cosa si
vuole proteggere. Senza assets da proteggere Identificazione
degli assets da
proteggere
non vi sono minacce.
Identificazione degli Entry Points: identificare in
Identificazione
degli entry points
che modo posso accedere agli assets. Modellazione del
sistema
Modellazione del sistema: utilizzo di formalismi
per modellare il sistema Identificazione
delle minacce
Identificazione delle minacce: identificare le Valutazione delle
minacce di ogni asset.
minacce e loro
risoluzione
Valutazione delle minacce e risoluzione: valutare NO
Sono state
identificate
tutte le
tramite un modello di valutazione, il rischio di
minacce?
ogni minaccia. Generazione
threat model
Generazione Threat Model: generare la
documentazione finale. OWASP 24
25. Threat Modeling
Gli Attack Tree rappresentano
un utile formalismo Web form
Authentication
Bypass
nell‟identificazione
delle minacce.
2. Furto del 4. Attacco di
1. Modifica delle 3. Attacco di
token di brute force sul
credenziali nel brute force sulla
sessione di token di
DB web form
un’altro utente sessione
1.2 Accesso 2.2 Il token non Il token viene
2.1 ’applicazione deve essere creato dal
1.1 Accesso indiretto al DB
è vulnerabile ad modificato framework
diretto al DB Tramite SQL
attacchi XSS durante la sottostante
Injection
sessione
L’accesso Ad ogni
Le query
diretto al DB è richiesta viene
uilizzano i
mitigato dalla data
prepared
presenza di un “freschezza” al
statements
firewall token
OWASP 25
26. Threat Modeling – Data Flow Diagram (1)
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 26
27. Threat Modeling – Data Flow Diagram (2)
Esempio di Livello0
OWASP 27
28. Coding Security Principles
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 appositi
PHP AntiXSS Library
http://www.owasp.org/index.php/Category:OWASP_PHP_AntiXSS_Libr
ary_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 tali
OWASP 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 28
29. Coding Security Principles – Esempi
Utilizzo di librerie e funzioni “safe”
Safe String handling
Secure random number generator
Secure unique file creation
Utilizzo di Secure Coding Convention
Controllare 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 29
30. Security Code Review
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 esecuzione
Bottom 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 30
31. Security Code Review – Riferimenti
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_P
roject
OWASP 31
32. Security Testing – Introduzione (1)
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 codice
Tipicamente si tratta di test di unità
Viene effettuato utilizzando tutta la conoscenza
posseduta (no Black Box)
Non dare nulla per scontato
OWASP 32
33. Security Testing – Introduzione (2)
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 33
34. Security Testing – Creazione Test (1)
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 34
35. Security Testing – Creazione Test (2)
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 35
36. Security Testing – Creazione Test (3)
Creazione dei valori di test per casi numerici
Valore 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 36
37. Security Testing – Creazione Test (4)
Creazione dei valori di test per variabili stringa
Delimitatore 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 37
38. Penetration Testing – Introduzione
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 38
39. Penetration Testing – Processo black box (1)
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 39
40. Penetration Testing – Processo black box (2)
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 40
41. Penetration Testing – Processo black box (3)
Tips & Tricks
Per 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 discovery
per identificare eventuali risorse di backup o file di configurazione
Utilizzate dei tool automatici di force browsing. Questi tool
permettono tramite crawling di identificare eventuali pagine a cui
l‟accesso è permesso solo tramite autenticazione
OWASP 41
42. Penetration Testing – Considerazioni
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 42
43. Visione globale
Attack Patterns Security Patterns
Knowledge Base
Requisiti e
Casi d’uso
Security
Abuse Cases
Requirements
Data Flow
Diagram
Utilizza
Software
Threat
Design
Modeling Utilizza
Attack Trees
Implementazione e
Testing
Security Penetration Secure Code
Testing Testing Review
OWASP 43
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.
OWASP 44
