• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Infosecurity 2008
 

Infosecurity 2008

on

  • 778 views

 

Statistics

Views

Total Views
778
Views on SlideShare
766
Embed Views
12

Actions

Likes
1
Downloads
8
Comments
0

3 Embeds 12

http://www.linkedin.com 7
https://www.linkedin.com 3
http://www.slideshare.net 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Infosecurity 2008 Infosecurity 2008 Presentation Transcript

    • Costruire software sicuro dalle fondamenta Antonio Parata antonio.parata@emaze.net OWASP Infosecurity 2008 6 Febbraio 2008 Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation http://www.owasp.org
    • 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
    • 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
    • Introduzione – Cost of fixing security flaws Il costo per rimediare ad una vulnerabilità aumenta con il progredire delle fasi. OWASP 4
    • 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
    • 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
    • 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
    • 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
    • Ciclo di sviluppo software – Waterfall model OWASP 9
    • Ciclo di sviluppo software – Waterfall model (Security Oriented) OWASP 10
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Security Patterns – Un esempio concreto (2) Funzionamento del Pattern J2EE Intercepting Validator OWASP 21
    • 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
    • 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
    • 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
    • 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
    • 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
    • Threat Modeling – Data Flow Diagram (2) Esempio di Livello0 OWASP 27
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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