Costruire software sicuro dalle
                    fondamenta



                         Antonio Parata
                ...
Indice
  Introduzione
  Ciclo di sviluppo software
  Attività Security Related
     Attack Patterns
     Abuse Cases
     ...
Introduzione – di cosa parliamo?

 Parleremo della attività all‟interno di un SDLC, non del
 SDLC.
    Ci permette di astr...
Introduzione – Cost of fixing security flaws

 Il costo per rimediare ad una vulnerabilità aumenta con il
 progredire dell...
Introduzione – Defect, Bug, Flaw

 Defect: “tutte le vulnerabilità sono dei difetti,
 indipendentemente dal fatto che sian...
Introduzione – Defect ratio

“In media il 50% dei difetti sono bug e il restante 50% sono
Flaw” da Software Security - Gar...
Ciclo di sviluppo software – Software
     Security VS Application Security
Software Security: comprende tutte quelle atti...
Ciclo di sviluppo software – Alcuni modelli

Esistono vari cicli di sviluppo software, ognuno con pregi
e difetti
   A Cas...
Ciclo di sviluppo software – Waterfall model




                                     OWASP     9
Ciclo di sviluppo software – Waterfall model
              (Security Oriented)




                                      O...
Attack Patterns – Cosa sono?
  Concetto derivante dai Design Patterns.
  Raggruppano le caratteristiche che hanno in comun...
Attack Patterns – Un esempio
 Buffer Overflow Attack Pattern
 Goal: Sfruttare vulnerabilità da buffer overflow per eseguir...
Security Requirements – (1)

  Utilizzo ortogonale a quello degli abuse cases (li
  vedremo a breve).
     Specificano che...
Security Requirements – (2)

  Una volta identificati i Security Requirements è buona
  cosa elencarli secondo un ben prec...
Security Requirements – (3)

  Esempi:
    “L‟applicazione deve prevedere l‟identificazione e l‟autenticazione degli
    u...
Abuse Cases – Cosa sono

  Anche detti Misuse Cases, vengono realizzati per
  aiutare il progettista a pensare come un att...
Abuse Cases – Creare Abuse Case utili
  Processo
     Creare un team di analisti e di esperti di sicurezza per il
     Bra...
Security Patterns – Cosa sono
  Utilizzati nella fase di progettazione, per costruire un
  design “sicuro by default”.
  L...
Security Patterns – Applicazione
  Patterns-Driven Security Design:
     Creare un‟architettura (design di alto livello) c...
Security Patterns – Un esempio concreto (1)
  Pattern J2EE Intercepting Validator
     Avere un meccanismo semplice e fles...
Security Patterns – Un esempio concreto (2)
  Funzionamento del Pattern J2EE Intercepting Validator




                  ...
Security Patterns – Altri esempi di pattern
  Web Tier:
     Secure Communication: descrive l‟utilizzo di un canale di
   ...
Threat Modeling
  Tra le fasi più importanti per la produzione di
  software sicuro.
  Lo scopo è quello di identificare, ...
Threat Modeling
                                                                START


 Identificazione degli assets: ide...
Threat Modeling
 Gli Attack Tree rappresentano
 un utile formalismo                                                 Web fo...
Threat Modeling – Data Flow Diagram (1)

   I DFD risultano utili nel comprendere la struttura
   dell‟applicazione e i su...
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 diminu...
Coding Security Principles – Esempi
  Utilizzo di librerie e funzioni “safe”
     Safe String handling
     Secure random ...
Security Code Review
  Tra le fasi più efficaci per l‟identificazione di errori nel
  codice.
     Sessioni da massimo qua...
Security Code Review – Riferimenti
  Per quel che riguarda i tool ne esistono diversi tra cui:
     Milk (utilizza Orizon)...
Security Testing – Introduzione (1)
  Il testing è l‟attività ortogonale alla fase di analisi.
     A volte è più facile i...
Security Testing – Introduzione (2)
  Concentrarsi su test di negatività
     Si tende a creare test positivi
  Necessità ...
Security Testing – Creazione Test (1)

  Per la realizzazione di test efficaci tenere conto dei
  seguenti criteri:
     S...
Security Testing – Creazione Test (2)



                     Attenzione!!!
la formalità è cosa buona ma ricordate che sie...
Security Testing – Creazione Test (3)

  Creazione dei valori di test per casi numerici
     Valore di confine della condi...
Security Testing – Creazione Test (4)
 Creazione dei valori di test per variabili stringa
    Delimitatore di campo (ad es...
Penetration Testing – Introduzione
  Tra le attività più in voga per mettere alla prova la
  sicurezza dei propri applicat...
Penetration Testing – Processo black box (1)
    Info Ghatering: scoperta dei servizi presenti (e loro
    versione) sugli...
Penetration Testing – Processo black box (2)
    Exploiting: si cerca di sfruttare le vulnerabilità
    identificate per p...
Penetration Testing – Processo black box (3)
    Tips & Tricks
       Per applicazioni scritte in linguaggio di medio/bass...
Penetration Testing – Considerazioni
   Quanto prima presentato è un tipico processo di un
   penetration test di livello ...
Visione globale


                              Attack Patterns        Security Patterns


                               ...
Conclusioni e Sviluppi Futuri

   Correzione delle vulnerabilità già dalle prime fasi del
   SDLC.
   Esistono svariate at...
Upcoming SlideShare
Loading in …5
×

Infosecurity 2008

635
-1

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
635
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
11
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Infosecurity 2008

  1. 1. 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
  2. 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. 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. 4. Introduzione – Cost of fixing security flaws Il costo per rimediare ad una vulnerabilità aumenta con il progredire delle fasi. OWASP 4
  5. 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. 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. 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. 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
  9. 9. Ciclo di sviluppo software – Waterfall model OWASP 9
  10. 10. Ciclo di sviluppo software – Waterfall model (Security Oriented) OWASP 10
  11. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 21. Security Patterns – Un esempio concreto (2) Funzionamento del Pattern J2EE Intercepting Validator OWASP 21
  22. 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. 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. 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. 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. 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. 27. Threat Modeling – Data Flow Diagram (2) Esempio di Livello0 OWASP 27
  28. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×