Owasp parte1-rel1.1

2,304 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,304
On SlideShare
0
From Embeds
0
Number of Embeds
23
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • In questo contesto si muove l ’ organizzazione Open Web Application Security Project (OWASP) per cercare di sensibilizzare il maggior numero di realtà organizzative verso le problematiche della Web Application Security . In particolare, la missione di OWASP è la diffusione nella comunità degli sviluppatori di una nuova “ coscienza ” sulla sicurezza proponendo principi e best practice per lo sviluppo di codice “ sicuro ” . OWASP nasce da un gruppo composto di volontari che produce tools , standard e documentazione open-source di qualità professionale. La comunità OWASP incentiva l'organizzazione di conferenze, la scrittura di articoli e discussioni riguardanti la Web Application Security . La partecipazione in OWASP è libera ed aperta a tutti come il materiale disponibile sul portale http://www.owasp.org . OWASP ha attualmente diversi progetti in essere, alcuni dei quali giunti ad un buon livello di maturità. Tra questi spiccano WebScarab, un tool da utilizzare per condurre vulnerabilty assessment , WebGoat una vera e propria palestra per i pentester e una serie di guide che stanno diventando lo standard de facto per lo sviluppo di applicativi web “ sicuri ” . DISA:Defense Information Systems Agency FTC: US Federal Trade Commisson Here's a brief overview.  OWASP has thousands of members, over 500 in 38 local chapters, and many more participating in projects.  The website gets several million hits every month.  The downloads of the Guide, TopTen, WebScarab, and WebGoat are through the roof.  And best of all, there are a large number of significant commercial organizations that have adopted OWASP materials into their standards and guidelines, including DISA, FTC, VISA, Mastercard, American Express, and most large financial institutions. We want OWASP to be *the* application security community, and we're doing as much as we can to make sure it becomes that.  The key project is to create a real applicaiton security standard.  Also we need to articulate a full application security process and fill in all the gaps.  We have some of the pieces (guide, testing, tools) but we need to put them all together so people can understand better.  There's also the papers project to help develop community.
  • Vedremo come tali linee guida si declinano nella sicurezza applicativa
  • Far notare come riservatezza (rendere l ’ informazione protetta) e integrità possono essere messi in relazione con incapsulamento. Disponibilità (rendere disponibile le informazioni alle persone autorizzate) ha a che fare con il concetto di polimorfismo (uno stessa informazione può avere caratteristiche diverse) e di ereditarietà.
  • Far notare come riservatezza (rendere l ’ informazione protetta) e integrità possono essere messi in relazione con incapsulamento. Disponibilità (rendere disponibile le informazioni alle persone autorizzate) ha a che fare con il concetto di polimorfismo (uno stessa informazione può avere caratteristiche diverse) e di ereditarietà.
  • Tralasciamo per comodità l ’ enumerazione della varie forme di autenticazione (debole, forte, biometrica, basata sui certificati, etc.) Concentriamoci sulle linee guida da seguire nella fase di coding. Illustriamo qualcuno dei 19 controlli/linee guida previsti per l ’ autenticazione.
  • Tralasciamo per comodità l ’ enumerazione della varie forme di autenticazione (debole, forte, biometrica, basata sui certificati, etc.) Concentriamoci sulle linee guida da seguire nella fase di coding. Illustriamo qualcuno dei 19 controlli/linee guida previsti per l ’ autenticazione.
  • Owasp parte1-rel1.1

    1. 1. Sviluppo sicuro di Applicazioni WEB
    2. 2. Mi Presento…. <ul><li>Claudio Di Giovanni </li></ul><ul><li>Ingegnere Informatico </li></ul><ul><li>Modelli di Ottimizzazione dei Sistemi Produttivi </li></ul><ul><li>CTO Solving Team / Responsabile del Bid Office </li></ul><ul><li>Mi occupo di Sviluppo SW su piattaforma JAVA-J2EE da circa 10 anni. </li></ul><ul><li>Passione per i Design Patterns. </li></ul>
    3. 3. AGENDA 1. Introduzione alle WEBAPP 2. Web Application Security 3. OWASP 4. SSDLC 5. OWASP e compliance con altre discipline/metodologie 6. Top 10 2007 vulnerabilities
    4. 4. … .Prima di Iniziare Un piccolo assessment….. Un video (csrf) interessante che illustra una vulnerabilità molto insidiosa presente sulle webapp…..
    5. 5. Anatomia di un attacco Cross Site Request Forgery (CSRF) 1/3 Dettaglio del CSRF
    6. 6. Anatomia di un attacco Cross Site Request Forgery (CSRF) 2/3 Dettaglio del CSRF
    7. 7. Anatomia di un attacco Cross Site Request Forgery (CSRF) 3/3 Dettaglio del CSRF
    8. 8. E se ciò non bastasse….– XSS e Defacement
    9. 9. Statistiche IBM
    10. 10. Framework OO Architetture Argomenti introduttivi ● Principio 1: Chi difende deve difendere tutto, chi attacca può utilizzare un punto debole; ● Principio 2: Chi difende può farlo solo rispetto a vulnerabilità note, chi attacca può tentare qualcosa di nuovo…. ● Principio 3: Chi difende deve farlo rispettando le regole, chi attacca no….
    11. 11. Web Application I framework Tutti si basano sul concetto di macchina virtuale: sistema che astrae dall ’ HW e dal SO e traduce un linguaggio intermedio in istruzioni macchina. Produttore Framework Caratteristiche SUN J2EE/JEE5 EJB / EJB3 /JPA (JRE- Bytecode) Microsoft .NET CLR - MSIL
    12. 12. Web Application I framework J2EE/JEE5 .NET
    13. 13. Web Application Due parole sui linguaggi OO <ul><li>OO Come astrazione della realtà. </li></ul><ul><li>Proprietà e Metodi </li></ul>
    14. 14. Web Application Due parole sui linguaggi OO <ul><li>Eta </li></ul><ul><li>Pensione </li></ul><ul><li>codiceFiscale </li></ul>Persona NO Integrità Riservatezza Disponibilità Incapsulamento Ereditarietà Polimorfismo Pilastri della Sicurezza delle Informazioni Pilastri dell ’ OO
    15. 15. Web Application Security Il modello <ul><li>Client leggero </li></ul><ul><li>Porte 80:443: è proprio qui che passano i pericoli… </li></ul><ul><li>Alta Disponibilità </li></ul><ul><li>Partizionamento fisico e logico (MVC) – no SPOF </li></ul><ul><li>Auth Bio  non aiuta; Il problema è il codice. </li></ul>HEADER BODY HEADER BODY
    16. 16. Web Application Security Le Criticità <ul><li>Quali sono i problemi utilizzando questo modello: </li></ul><ul><li>75% incidenti avviene via HTTP (Gartner group) </li></ul><ul><li>Firewall + SSL + 2FA non implicano necessariamente che l ’ applicazione sia “ sicura ” </li></ul><ul><li>Le minacce più importanti derivano dal modo in cui il sw è stato progettato e scritto. </li></ul><ul><li>Normalmente il processo di sviluppo del software non include le funzionalità di sicurezza </li></ul>
    17. 17. Web Application Security Cosa non è, cosa è la …. <ul><li>Non è un prodotto. </li></ul><ul><li>È progettazione, sviluppo e testing “ sicuro ” di applicativi critici per il business aziendale in modo che il servizio non sia vulnerabile a possibili attacchi web  Non riguarda eventuali exploit di SO. </li></ul><ul><li>Time to Market sempre più ristretti </li></ul><ul><li>Complessità sempre crescente </li></ul>Meno tempo ed attenzione alle caratteristiche di sicurezza applicativa
    18. 18. OWASP <ul><li>Il progetto Open Web Application Security Project (OWASP) nasce da un gruppo composto di volontari che produce tool, standard e documentazione open-source di qualità professionale </li></ul><ul><li>La comunità OWASP incentiva l'organizzazione di conferenze, la nascita di local chapter, la scrittura di articoli, paper, e discussioni riguardanti la Web Security </li></ul><ul><li>La partecipazione in OWASP è free ed aperta a tutti, come il materiale disponibile sul portale www.owasp.org </li></ul>
    19. 19. Cos ’ è OWASP <ul><li>Migliaia di membri, di cui 500 nei 38 capitoli locali e altri partecipanti ai progetti </li></ul><ul><li>Milioni di hit al mese su sito www.owasp.org </li></ul><ul><li>Hanno adottato la documentazione OWASP nei loro standard e linee guida: </li></ul><ul><li>Defense Information Systems Agency (DISA) </li></ul><ul><li>US Federal Trade Commisson ( FTC) </li></ul><ul><li>VISA, Mastercard, American Express </li></ul><ul><li>Oracle </li></ul><ul><li>Foundstone Inc. </li></ul>
    20. 20. I progetti OWASP (1) Guida per la progettazione di applicativi web “ sicuri ” http://www.owasp.org/documentation/guide.html OWASP Top Ten Vulnerability http://www.owasp.org/documentation/topten.html Web Application Penetration Test http://www.owasp.org/documentation/testing.html Tool per Pentester e code reviewer: WebScarab: http://www.owasp.org/software/webscarab.html WebGoat: http://www.owasp.org/software/webgoat.html Stinger: http://www.owasp.org/software/validation/stinger.html Articoli, standard http://www.owasp.org/papers.html -http://www.owasp.org/standards.html
    21. 21. <ul><li>OWASP Orizon Project </li></ul><ul><li>L ’ obiettivo di questo progetto è quello di sviluppare un motore estensibile di revisione del codice che possa essere utilizzato da tool che verifichino la sicurezza del codice sorgente. Esistono d ue approcci per la revisione del codice: </li></ul><ul><ul><li>revisione statica </li></ul></ul><ul><ul><li>revisione dinamica </li></ul></ul><ul><li>Entrambi utilizzano un approccio automatizzato con l'ausilio di tool manuali con il raffinamento dei risultati del tool per eliminare i falsi positivi </li></ul>I progetti OWASP (2)
    22. 22. OWASP Classic ASP Security Project Il progetto mira a creare un framework sicuro per le applicazioni sviluppate in Classic ASP attraverso l ’ integrazione degli esistenti progetti OWASP con documentazione relativa a questa particolare tecnologia attraverso la creazione di librerie dedicate alla sicurezza. OWASP .NET Project Lo scopo di questo progetto è quello di fornire un repository centralizzato di informazioni e tool per professionisti dell ’IT che utilizzano il Framework MS .NET per lo sviluppo di web application e services. I progetti OWASP (3)
    23. 23. Compliance OWASP con altre metodologie OSSTMM
    24. 24. Start…. Presentazione di un framework basato su OWASP per la scrittura di codice sicuro. Questa presentazione riguarda la “ Sicurezza nelle applicazioni Web. ” E ’ opportuno partire dal Ciclo di Vita di una applicazione .
    25. 25. SDLC E la sicurezza? Bè basta un Penetration Test a valle, no???
    26. 26. La Sicurezza nel SDLC Un Framework possibile….agile ed economico Spesso in passato mi è capitato che il progetto su cui lavoravo virasse improvvisamente sulle tematiche di sviluppo sicuro o di sicurezza in generale di lunedì mattina……la domenica avevano trasmesso “ The Net ” , “ Hackers ” …. E che dire di progetti così organizzati?
    27. 27. E la Sicurezza nelle gare d ’ appalto? <ul><li>Quando va bene la richiesta è del tipo: </li></ul><ul><li>“ […] sicurezza applicativa da realizzare tramite specifica applicazione di gestione di profilo degli utenti. “ </li></ul><ul><li>Spesso la sicurezza viene declinata esclusivamente così: </li></ul><ul><ul><li>Protezione dati personali </li></ul></ul><ul><ul><li>Accessi </li></ul></ul><ul><ul><li>Sicurezza Fisica </li></ul></ul>
    28. 28. E la Sicurezza nelle gare d ’ appalto? (2) Parlare di sicurezza applicativa in questi termini è come se le norme di sicurezza stradale prendessero in considerazione solo misure relative all ’ auto e non al guidatore….
    29. 29. La Sicurezza nel SDLC Un Framework possibile….agile ed economico Da qui nasce l ’ idea di un framework – derivato da OWASP - che può aiutare le organizzazioni ad assicurare un processo (dall ’ inception al testing) di sviluppo delle applicazioni web con un obiettivo: avere requisiti sicuri e non requisiti di sicurezza (questi ultimi danno l ’ idea di un approccio a posteriori….). Security Features != Secure Features
    30. 30. La Sicurezza nel SDLC Un Framework possibile….agile ed economico Il framework verrà fornito su richiesta. Fase Elaborati Classici Attività / Elaborati di Sicurezza Inception Piano di Progetto Piano di Qualità … . 1. Essential Skills for Secure Programmers. 2. “ Linee Guida per la sicurezza applicativa ” da fornire agli sviluppatori interni ed ai fornitori esterni. (Policy) Design Analisi Funzionale Analisi Tecnica Piano e spec. Dei Test Threat Modeling Process (TMP) Progettazione Test in base ai risultati del TMP Coding - Safe Coding & Code review Testing Rapporto dei Test … . Penetration Test Report. Pretendere comunque l ’ effettuazione dei test relativi alla Top 10 Vulnerabilities 200x. + TMP iterativo
    31. 31. La Sicurezza nel SDLC Un Framework possibile….agile ed economico Il modello proposto copre un progetto di sviluppo software a partire dalla costituzione del gruppo di lavoro fino alla fase di testing. Best practice, CheckList e linee guida da sole non bastano: occorre un processo strutturato che copra le fase di progettazione, design e testing.
    32. 32. La Sicurezza nelle applicazioni già sviluppate… Un Framework possibile….agile ed economico Fase Elaborati Classici Attività / Elaborati di Sicurezza - - 1. Essential Skills for Secure Programmers. 2. “ Linee Guida per la sicurezza applicativa ” da fornire agli sviluppatori interni ed ai fornitori esterni. (Policy) - - Threat Modeling Process (TMP) Progettazione Test in base ai risultati del TMP - - Code review Testing Rapporto dei Test … . Penetration Test Report. Pretendere comunque l ’ effettuazione dei test relativi alla Top 10 Vulnerabilities 200x. + TMP iterativo
    33. 33. Formare la squadra...non così
    34. 34. E ’ il momento di formare la squadra <ul><li>Accertarsi che la squadra abbia un insieme minimo di conoscenze su tematiche quali vulnerabilità web e safe coding  Essential Skill for secure java-j2ee Programmers…. </li></ul><ul><li>Pubblicazione del Novembre 2007 del SANS Institute </li></ul><ul><li>Si tratta di una serie di test atti a comprovare le competenze del gruppo di lavoro su 9 aree di conoscenza. </li></ul><ul><li>E ’ opportuno sottoporre al test il gruppo di lavoro. </li></ul>
    35. 35. Essential Skills for Secure Java-J2EE Programmers. Task 1 – Data Handling Java programmers must be able to write programs that read input from interfaces, properly validate, and output these data. Programmers should be familiar with these attack scenarios: Cross-site Scripting (XSS) and SQL-Injection. 1.5 [……….]Parameterized Queries. Java programmers must understand the security risks introduced by using dynamic queries with untrusted data. Programmers must understand how mitigate those risks by using Java ’ s PreparedStatement to securely interact with databases.
    36. 36. Essential Skills for Secure Java-J2EE Programmers. <ul><li>Task 2 – Authentication & Session Management. </li></ul><ul><li>Task 3 – Access Control (Authorization). </li></ul><ul><li>Task 4 – Java Types & JVM Management. </li></ul><ul><li>Task 5 – Application Faults & Logging. </li></ul><ul><li>Task 6 – Encryption Services. </li></ul><ul><li>Task 7 – Secure Architecture & Coding Principles </li></ul><ul><ul><li>01.7.1: Thread Safety </li></ul></ul><ul><ul><li>01.7.2: Singletons. </li></ul></ul><ul><ul><li>01.7.3: JAVA EE Filters. </li></ul></ul><ul><ul><li>01.7.4: MVC & IOC </li></ul></ul><ul><ul><li>01.7.5: Secure Coding Principles( least privilege, secure initialization, separation of data from code…. </li></ul></ul>
    37. 37. Essential Skills for Secure Java-J2EE Programmers. La conoscenza e la formazione su tali tematiche è un momento essenziale. Costa poco e rende molto. Come si può pensare di fare una code review alla ricerca di flaw se non si sa cosa e dove cercare????
    38. 38. Linee Guida <ul><li>“ Secure Default ” </li></ul><ul><li>Principio del “ Least Privilege ” </li></ul><ul><li>Principio del “ Defense in depth ” </li></ul><ul><li>Fallire in modo “ sicuro ” </li></ul><ul><li>I sistemi esterni sono insicuri </li></ul><ul><li>Semplificare (simple design, separare codice e dati, design patterns, i pilastri della Programmazione OO) </li></ul>Rif. “ Writing Secure Code ” di Howard e LeBlanc
    39. 39. Secure Default <ul><li>Utilizzare caratteristiche di sicurezza di default </li></ul><ul><li>Esempio </li></ul><ul><li>abilitazione automatica di meccanismi di costruzione di password di una certa complessità; </li></ul><ul><li>abilitazione del meccanismo di scadenza delle pwd. </li></ul><ul><li>UBUNTU per default nasconde l ’ account di amministrazione (su richiesta è possibile guadagnare l ’ amministrazione: sudo…); in windows…. </li></ul><ul><li>MACOSX non nasconde l ’ account di amministrazione comunque talvolta è richiesta l ’ immissione della pwd di amministrazione…. </li></ul>
    40. 40. Least Privilege Accertarsi che gli utenti (e più in generale gli stessi applicativi) abbiano l ’ insieme minimo di privilegi richiesti per eseguire correttamente il proprio lavoro… Per la serie: non offrire il fianco al nemico…
    41. 41. Defense in Depth Due controlli sono meglio di uno…… Nel campo del secure coding questo può prendere la forma di validazione basata su più livelli, così come implementare un controllo di auditing centralizzato unito al requisito di tracciare gli accessi utenti ad ogni pagina.
    42. 42. Fallire in modo sicuro Controllare le eccezioni. TryCatchFinally. E a volte non basta isAdmin = true; try { codeWhichMayFail(); isAdmin = isUserInRole( “ Administrator ” ); } catch (Exception ex) { log.write(ex.toString()); } Se codeWhichMayFail() fallisce, l ’ utente è amministratore per default.
    43. 43. Sistemi esterni Le SOA vanno di moda ma occorre prestare particolare attenzione.
    44. 44. Semplicità Mantenere il codice semplice. Commentare. Non serve essere sempre all ’ ultima moda…(SEAM, STRUTS2, etc.) Un po' meno framework e più incapsulamento, ereditarietà e polimorfismo Pattern (ma senza esagerare…..illustrare figura!) + (anti-if)
    45. 45. Semplicità (2) NO!!!
    46. 46. Introduzione al Threat Modeling identificare e valorizzare le minacce Finora si è parlato di “ Linee Guida ” e di “ Essential Skill ” al fine di definire una sorta di policy per mitigare il rischio delle minacce. Ma come fare ad individuare il reale rischio di tali minacce in modo da classificarle sulla base del loro potenziale impatto sull ’ applicazione? Threat Modeling Process.
    47. 47. Threat Modeling - identificare e valorizzare le minacce <ul><li>Gli obiettivi sono: </li></ul><ul><li>Identificare le minacce più gravi e partire da queste per mitigare il rischio </li></ul><ul><li>Fornire un approccio strutturato e più efficiente dal punto di vista dei costi </li></ul><ul><li>I vantaggi del TMP sono: </li></ul><ul><li>aiuta a capire meglio l ’ applicazione; </li></ul><ul><li>Aiuta a scovare bug in fase di Design: non solo bug in fase di code review, non solo bug durante il testing…..Inutile dire quanto è più importante scovare errori in fase di progettazione! </li></ul>
    48. 48. Threat Modeling Flow
    49. 49. Scomporre l ’ applicativo <ul><li>Step facilitato dal fatto che il TMP viene fatto a valle dell ’ analisi tecnica e funzionale. </li></ul><ul><li>Raffinare il diagramma architetturale </li></ul><ul><ul><li>Mostrare il meccanismo di autenticazione /autorizzazione </li></ul></ul><ul><ul><li>Mostrare le tecnologie </li></ul></ul><ul><ul><li>Identificare i punti di entrata </li></ul></ul><ul><li>Utilizzare UML o anche DFD </li></ul>
    50. 50. Scomporre l ’ applicativo (2) Tracciare i confini dell ’ applicazione e procedere per raffinamenti successivi senza andare troppo nel dettaglio (max 2-3 livelli) al fine di identificare macro blocchi detti Threat Target.
    51. 51. Scomporre l ’ applicativo (3) Applicazione per il pagamento degli stipendi
    52. 52. Livello 1
    53. 53. Identificare le minacce (1) A quali generi di pericoli può essere esposta l ’ applicazione? <ul><li>Metodo#1: Lista delle minacce </li></ul><ul><ul><li>Cominciare con una lista delle possibili minacce </li></ul></ul><ul><ul><li>Identificare le minacce per l ’ applicazione </li></ul></ul><ul><li>Metodo#2: STRIDE </li></ul><ul><ul><li>Lista categorizzata di tutti i tipi di minacce </li></ul></ul><ul><ul><li>Identificare le minacce per tipo/categoria </li></ul></ul>Il passo va fatto per ciascun componente individuato al passo precedente
    54. 54. Identificare le minacce (2) <ul><li>Spoofing: può un attaccante accedere utilizzando una falsa identità? </li></ul><ul><li>Tampering: può un attaccante modificare i dati che arrivano all ’ applicazione? </li></ul><ul><li>Repudiation: se un attaccante nega un attacco, è possibile provare il contrario? </li></ul><ul><li>Information disclosure: può un attaccante accedere a dati privati? </li></ul><ul><li>Denial of Service: può un attaccante ridurre la disponibilità del sistema? </li></ul><ul><li>Elevation of privilege: può un attaccante assumere l ’ identità di un utente privilegiato? </li></ul>STRIDE
    55. 55. Identificare le minacce (3) Nel pensare alle vulnerabilità è opportuno pensare alle cause e agli effetti. STRIDE è un modo di classificare le minacce sulla base dei loro effetti. La classificazione delle minacce sulla base delle loro cause può assumere la forma di un manuale di best-practice e safe coding come quello proposto.
    56. 56. Identificare le minacce (4) Affinchè una minaccia possa essere messa in atto, potrebbero essere necessari vari step. Per illustrare ciò si utilizza lo strumento degli attack tree. Costruire l ’ albero delle minacce. Occorre evitare che un dipendente possa ottenere informazioni sullo stipendio di un collega. Occorre proteggere il dato da occhi indiscreti. Categoria: information Disclosure Nota: l ’ attacco può essere portato attraverso uno sniffer (adapter in modalità promiscua….) o compromettendo il router…
    57. 57. Identificare le minacce (5) Albero delle Minacce Nota 1: una minaccia deve far riferimento ad un Threat Target. Nota 2: è un modo di capire come può essere portata/attuata quella minaccia. Nota 3: Talvolta la linea tratteggiata indica la minaccia più probabile.
    58. 58. Documentare le minacce Utilizzando un template
    59. 59. Misurare le minacce Valutazione del Rischio Modello Semplice: DREAD (scala da 1 a 15)
    60. 60. DREAD
    61. 61. DREAD - Esempio
    62. 62. Dettaglio delle minaccia Descrizione Minaccia Un utente malintenzionato vede dati confidenziali di un altro utente Threat Target Payroll Response Categoria della Minaccia Information Disclosure Rischio Damage Potential:2 Reproducibility: 3 Exploitability:2 Affected Users: 3 Discoverability: 3 Complessivo: 13/15
    63. 63. Proviamo a ricapitolare.
    64. 64. Mitigare i Rischi <ul><li>Una volta individuate le minacce e la loro pericolosità occorre: </li></ul><ul><li>determinare quali tecniche possono aiutare nel mitigare i rischi. </li></ul><ul><li>Scegliere le appropriate tecnologie. </li></ul><ul><li>Nota: Tecnica != Tecnologia </li></ul>
    65. 65. Mitigare i Rischi Tipo di Minaccia Tecnica per mitigare Tecnologie Spoofing Identity Autenticazione Appropriata Basic Auth Digest Auth Form Based X.509 Certificate … .. Tampering with data Autorizzazione Appropriata ACL Ip restriction Repudiation Firme Digitali Timestamp Audit trail SSL…. Information Disclosure Autorizzazione Crittografia SSL … Denial of service Filtering QoS … Elevation of Privilege Run with least privilege
    66. 66. Mitigare i Rischi del nostro es. Minaccia Tecnica per mitigare Tecnologie Sniffing dei dati di payroll - Information Disclosure Autorizzazione Crittografia SSL / IPSEC
    67. 67. Introduzione al Safe Coding (Best Practice) I risultati forniti dal Threat Modeling, già in fase di progettazione, aiutano ad individuare tecniche e tecnologie in grado di mitigare i rischi, ovvero in grado di scrivere codice più sicuro.
    68. 68. Safe Coding / Best Practice <ul><li>Meccanismi di autenticazione </li></ul><ul><li>Autorizzazione e metodi di controllo degli accessi </li></ul><ul><li>Validazione dei dati in input e output </li></ul><ul><li>Gestione delle sessioni web </li></ul><ul><li>Audit e Logging </li></ul><ul><li>Riservatezza delle informazioni e crittografia </li></ul><ul><li>Insecure Configuration Management </li></ul><ul><li>La gestione degli errori </li></ul><ul><li>Denial of Service (DoS) </li></ul><ul><li>Phishing </li></ul>Estratto OWASP Web App Security Guide
    69. 69. Autenticazione A titolo di esempio, in quest ’ area sono previsti ben 19 controlli: <ul><li>Evitare meccanismi di positive auth; </li></ul><ul><li>Evitare sql injection </li></ul><ul><li>Evitare l ’ uso dell ’ header REFERRER per prendere decisioni </li></ul><ul><li>No a “ Browser Remember Password ” (autocomplete=off) </li></ul><ul><li>Forzare la scelta di username e password appropriati (non devono contenere nome + cognome e tutte le varianti) </li></ul>
    70. 70. Autorizzazione Siete certi che la vostra applicazione la controlli correttamente?
    71. 71. Validazione <ul><li>Le informazioni fornite dal client non dovrebbero mai essere considerate di fiducia. E ’ necessario assicurare che i dati inviati dal client al server: </li></ul><ul><li>non siano alterati (integrity check); </li></ul><ul><li>siano sintatticamente corretti; </li></ul><ul><li>rispettino le regole di business dell ’ applicativo. </li></ul>
    72. 72. Validazione <ul><li>Ad ognuno il suo……per esempio: </li></ul><ul><li>il livello di presentazione dovrebbe validare le problematiche web, </li></ul><ul><li>quello di persistenza dovrebbe validare i temi di persistenza come SQL Injection. </li></ul>
    73. 73. Validazione Esempio di Business Rule Validation Esempio: Alice si collega alla propria banca e decide di effettuare un bonifico. Nel migliore dei casi il numero del conto è nascosto nella form….. (la minaccia è il parameter tampering ) Il miglior approccio consiste nel mantenere un parametro lato server che si riferisca al numero del conto dell ’ utente ed utilizzare questa informazione e non quella ricevuta dal client all ’ atto del pagamento, per effettuare la transazione.
    74. 74. Validazione Esempio di parameter tampering.
    75. 75. Validazione (tasto dx e….) Esempio di parameter tampering (2).
    76. 76. Validazione Regole di Data Validation: 4 Strategie 1. Accettare solo il “ known good ” Se ad esempio l ’ applicazione si aspetta un codice postale statunitense, la cosa migliore è validare il parametro in ingresso affinché sia un tipo compatibile, abbia una lunghezza e una sintassi di un codice postale. public String validateAUpostCode(String postcode) { return (Pattern.matches(&quot;^(((2|8|9)d{2})|((02|08|09)d{2})|([1- 9]d{3}))$&quot;, postcode)) ? postcode : ''; }
    77. 77. Validazione Regole di Data Validation: 4 Strategie 2. Scartare il “ known bad ” Se l ’ applicativo non si aspetta di ricevere un carattere come %3f o JavaScript per processare correttamente l ’ input, è bene non accettare le stringhe che contengano tali informazioni. ( REGEXP ). Questo processo può prevedere fino a 90 espressioni regolari da controllare . Ovviamente tale approccio non è sicuro in quanto la lista delle espressioni regolari è in continuo aggiornamento.
    78. 78. Validazione Regole di Data Validation: 4 Strategie 3. Sanitize (bonifica) L ’ input sanitizing consiste nell ’ eliminare o traslare caratteri (come quelli presenti nell ’ HTML) con l ’ obiettivo di rendere l ’ input “ safe ” . Ad esempio: public String quoteApostrophe(String input) { return str.replaceAll(&quot;[']&quot;, &quot;&rsquo;&quot;); } 4. Nessuna Validazione: NO!
    79. 79. Validazione Validare per evitare: Input -> Output == cross-site scripting Input -> System == command injection Input -> Query == SQL injection Input -> Fixed buffer or format string == overflow Input -> Integer == overflow
    80. 80. Gestione Sessioni Protocollo http Stateless Cookie Funzionamento
    81. 81. Gestione Sessioni Exposed Session Variables Dati di sessione in un area protetta dell ’ app server Regeneration of Session Tokens Per ridurre il rischio di session hijacking e attacchi di brute force, il server può rendere nullo il token dopo un certo periodo e rigenerarne uno nuovo. Ciò riduce la finestra temporale di attacco. Session Forging/Brute-Forcing Detection and/or Lockout Molte applicazioni non segnalano quando un utente prova migliaia di possibili token per tentare il brute forcing  Bloccare l ’ IP di provenienza.
    82. 82. Gestione Sessioni Weak Session Cryptographic Algorithms Se il token di autenticazione risulta predicibile, un attaccante non ha più bisogno di catturare le variabili di sessione dell ’ utente remoto, ma può semplicemente indovinare il token ed utilizzare la sessione di un altro utente (session hijacking). I token di sessione dovrebbero essere unici, non predicibili, resistenti al reverse engineering e prevedere un time-out di validità.
    83. 83. Gestione Sessioni Session Token Transmission Se un session token viene catturato durante la trasmissione in rete o rubato utilizzando un XSS attack, l ’ account può essere soggetto ad un replay o session hijacking. Per evitare questo si può associare il session ID, l ’ indirizzo IP e altri attributi dell ’ header dell ’ utente con un hash: se nelle richieste successive l ’ hash calcolato non è identico a quello memorizzato, significa che è occorso un attacco di session fixation. Session Tokens on Logout Al momento del logout utente è necessario distruggere la sessione e riscrivere il session cookie sul browser utente.
    84. 84. Gestione Sessioni Session Hijacking Furto/Manomissione del Token di sessione. Come Proteggersi: Prevedere tempi di durata brevi Uso di cookie non persistenti Evitare l ’ uso dell ’ url rewriting.
    85. 85. Phishing Il Phishing è un attacco rivolto agli utenti di un ’ applicazione che sfrutta, sia tecniche di “ ingegneria sociale ” in combinazione con la scarsa padronanza degli strumenti informatici degli utenti (che fanno apparire un criminale come un ’ identità fidata), che le vulnerabilità dell ’ applicativo. Qualcuno, anche molto noto, dice : “ Vi sono poche precauzioni da seguire da parte degli sviluppatori per ridurre il rischio, essendo la maggior parte dei controlli di phishing relativi all ’ educazione informatica degli utenti. ” …. Non è vero: vi sono diverse cose che possono e devono essere fatte (vedremo dopo a proposito di XSS e CSRF…)
    86. 86. Phishing (2) <ul><li>Gli utenti rimangono vittima perché: </li></ul><ul><li>Raramente controllano la sintassi delle URL contenute nelle mail ricevute e alle quali si collegano, ovvero non distinguono in generale se il browser punta all ’ originale URL: “ www.bancaXYZ.it ” invece che alla fasulla: “ www.bankaXYZ.it ” . </li></ul><ul><li>Non controllano i mittenti delle mail ricevute ne tanto meno l ’ eventuale autenticità della firma digitale della stessa. </li></ul><ul><li>Non controllano la validità del certificato presentato dal server, per cui è possibile ridirigere un utente verso un sito falso con tanto di certificato SSL generato da una propria Certification Authority ovviamente non riconosciuta come affidabile (cfr. vulnerabilità del protocollo SSL alla certificate based authentication). </li></ul><ul><li>In generale non sono “ educati alla sicurezza ” . </li></ul>
    87. 87. Introduzione alla Code Review <ul><li>Abbiamo visto: </li></ul><ul><li>Linee Guida </li></ul><ul><li>Safe Coding </li></ul><ul><li>Analisi delle Minacce </li></ul><ul><li>Ma che tipo di interventi si possono effettuare sul codice già scritto??? </li></ul>
    88. 88. Code Review <ul><li>Prevede due fasi: </li></ul><ul><li>Una fase di test automatizzato per evidenziare problemi evidenti oppure imperfezioni nel design dell ’ applicazione e nella connessione tra moduli differenti </li></ul><ul><li>Una fase di revisione manuale dove utilizzando i risultati della fase precedente per effettuare controlli più affinati sulla semantica e sull ’ ingegnerizzazione del codice applicativo </li></ul><ul><li>Il punto di partenza di una code review è quello di tracciare delle metriche sul codice in esame. </li></ul><ul><li>La misura della complessità di un modulo software può dare delle informazioni di massima sulla probabilità di errori semantici o di disegno architetturale </li></ul>
    89. 89. Code Review <ul><li>Alcune metriche utili in questa fase sono: </li></ul><ul><li>Numero di linee di codice </li></ul><ul><li>Numero di linee di commento </li></ul><ul><li>Numero di metodi (per i linguaggio OO) </li></ul><ul><li>Indice di Complessità ciclomatica (calcola il numero di branch decisionali e istruzioni di loop all ’ interno di un flusso di controllo) </li></ul><ul><li>Numero di classi </li></ul><ul><li>Numero di metodi </li></ul>
    90. 90. Code Review <ul><li>Effettura una buona fase di Static code review getta le basi per focalizzare l ’ intervento manuale del revisore. </li></ul><ul><li>E ’ possibile automatizzare questa fase: </li></ul><ul><li>JavaMetrics (http://www.semdesigns.com/Products/Metrics/JavaMetrics.html ) </li></ul><ul><li>SmartBear - CodeReviewer </li></ul><ul><li>M Square Technologies - RMS ( http://msquaredtechnologies.com ) </li></ul><ul><li>Jupiter Ecplise Plugin ( http://csdl.ics.hawaii.edu/Tools/Jupiter/ ) </li></ul><ul><li>SSW Code Auditor ( http://www.ssw.com.au/SSW/codeauditor/ ) </li></ul><ul><li>Fortify (http://www.fortifysoftware.com) </li></ul>
    91. 91. Code Review Cenni su Jupiter Ecplise Plugin ( http://csdl.ics.hawaii.edu/Tools/Jupiter/ ) Configuration: The review initiator sets up the review, defining a unique &quot;Review ID&quot; and specifying the files to be reviewed, who will review the code, and what issues can be raised. Depending on your organization, the review initiator could be the author, the team leader, or someone in QA. Individual review: Each reviewer examines the code individually, using a review checklist and raising issues as they encounter them. Team review: The review team (including the author) meet to discuss issues and decide on actions to take. Rework: The developer goes through the raised issues and fixes them
    92. 92. Code Review <ul><li>Utilizzando i risultati dei test automatizzati il focus della revisione verrà diretto verso: </li></ul><ul><li>Le classi che accettano input dall ’ esterno (form html, connessioni ftp, ... ) </li></ul><ul><li>Le classi che producono output (per evitare race condition o DoS verso la memoria di massa disponibile) </li></ul><ul><li>Le classi con elevato indice di un numero di cicli e costrutti di controllo. Queste classi sono a prima vista più complesse quindi la probabilità di bug che possono portare ad una security issue sono maggiori. </li></ul><ul><li>Le classi con minor numero di commenti. Queste classi probabilmente sono poco manutenute, occorre quindi che siano testate in maniera più intensiva </li></ul>
    93. 93. Code Review Durante la fase di revisione statica verranno proposte delle modifiche da apportare al codice e all ’ infrastruttura per sopperire alle carenze individuate. Le modifiche verranno discusse col team di sviluppo in un ’ ottica di confronto costruttivo tra team e revisore
    94. 94. Testing Testing Guide OWASP Ver. 2.1 Tool
    95. 95. Metodologie di Testing Presenti nella prima parte della guida
    96. 96. Testing – Manual Inspection&Review Ispezione “ manuale ” di procedure , processi ed eventualmente tecnologie (es.: design architetturale) e del loro impatto sulla sicurezza dell'applicazione testata. Vengono effettuate attraverso interviste agli analisti, agli sviluppatori e ai gestori dell'applicazione, o attraverso la lettura di documentazione esistente. Vantaggi: applicabile fin dalle prime fasi; non richiede supporti tecnologici Svantaggi: Tempi lunghi; Documentazione non sempre disponibile; skill mix elevati
    97. 97. Testing – Threat Modeling Analisi delle minacce tramite classificazione degli asset. Applicabile fin dalle prime fasi di design e sviluppo in modo da poterne utilizzare i risultati nella fase di coding. Vantaggi: applicabile fin dalle prime fasi; flessibile Svantaggi: un buon modello non implica necessariamente che il codice scritto sia sicuro
    98. 98. Testing – Code Review Controllo del codice sorgente sia manuale che automatico. Vantaggi: accurata e rapida Svantaggi: richiede skill-mix elevati.
    99. 99. Testing – Penetration Test Simulazione di attacchi all ’ applicazione. Deve coinvolgere strumenti e mente…. Vantaggi: rapidi risultati in tempi brevi Svantaggi: non può essere applicata all ’ inizio del SDLC. Nota: esiste una checklist che contiene i test cui sottoporre l ’ applicazione raggruppati per tipologia
    100. 100. Testing Framework
    101. 101. Strumenti di testing: OWASP WebScarab <ul><li>WebScarab è un tool java sviluppato da OWASP per il testing black box di applicazioni web. </li></ul><ul><li>Si interpone tra il browser e l'applicazione stessa, intercettando le richieste di uno e le risposte dell'altra, consentendo all'utente di visualizzarle, analizzarle e modificarle a piacere, allo scopo di esplorare il funzionamento dell'applicazione e trovarne le eventuali vulnerabilità. </li></ul><ul><li>Non fornisce modalità di scansione automatica. L'approccio è prettamente manuale, e richiede da parte dell'utente buone conoscenze del protocollo HTTP. </li></ul>
    102. 102. Strumenti di testing: OWASP WebScarab http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
    103. 103. WebGoat – Una Web Application come palestra per attacchi WebGoat è una applicazione deliberatamente insicura, sviluppata in J2EE, gestita dall'OWASP allo scopo di insegnare alcune lezioni sulla sicurezza delle applicazioni Web. In ogni lezione l'utente deve dimostrare di aver capito dove si trova il problema di sicurezza, sfruttando la reale vulnerabilità presente.
    104. 104. WebGoat – Una Web Application come palestra per attacchi DEMO
    105. 105. Altri Tool di Penetration Test <ul><li>NIKTO </li></ul><ul><li>Paros Proxy </li></ul><ul><li>WEB Scarab </li></ul><ul><li>WEB Inspect </li></ul><ul><li>Wisker </li></ul><ul><li>BurpSuite </li></ul><ul><li>WIKTO </li></ul><ul><li>Acunetix </li></ul><ul><li>WathFire appscan </li></ul><ul><li>N-Stealth </li></ul>
    106. 106. Domande? Grazie per l ’ attenzione Claudio Di Giovanni [email_address]

    ×