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

antonio.parata@emaze.net

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.