Un`introduzione - Master Sicurezza
Transcript
Un`introduzione - Master Sicurezza
Sicurezza Applicativa: Un’introduzione Roma, 23 Giugno 2011 Copyright © 2011 Euery S.r.l. All rights reserved. The information contained in this document may change without notice, and may have been altered or changed if you have received it from a source other than Euery S.r.l. All information provided in this document is provided "AS IS" with all faults without warranty of any kind, either expressed or implied. To the fullest extent permissible pursuant to applicable law, Euery S.r.l. disclaims all warranties, expressed or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Euery S.r.l. be liable for any damages whatsoever, including direct, indirect, incidental, consequential, or special damages, arising from the use or dissemination hereof, even if Euery S.r.l. authorized representative have been advised of the possibility of such damages. No part of this document shall be reproduced, republished, uploaded, posted, transmitted, or distributed by any means without written permission from Euery S.r.l. Agenda dell’incontro Mercato di Riferimento Concetti di Application Security Cicli di sviluppo software (SDLC) Cicli di sviluppo software security oriented (SSDLC) Threat Modeling Penetration Testing Penetration Testing: Demo Secure Code Review Secure Code Review: Demo Secure Programming www.euery.com Relatori Antonio Parata: Co-fondatore della società di ricerca e sviluppo software “Euery”. Laureato presso la facoltà di “Ingegneria Informatica” del Politecnico di Milano. È in possesso della certificazione professionale CSSLP (Certified Secure Software Lifecycle Professional). Co-autore della OWASP Testing Guide v.2 e v.3 e ricercatore attivo nel campo della Software Security. Per anni è stato Security Auditor presso il centro operativo di sicurezza (SOC) di una nota compagnia di telecomunicazioni. www.euery.com Francesco Beatino: Co-fondatore della società di ricerca e sviluppo software “Euery”. Ha frequentato la facoltà di “Sicurezza dei Sistemi e delle Reti Informatiche” presso il Polo Didattico e di ricerca di Crema. E’ stato Technical Member del progetto internazionale di ricerca Honeynet.org e Technical Editor per la rivista polacca Hakin9. È in possesso della certificazione professionale CEH (Certified Ethical Hacker). Per anni è stato Security Analyst e Security Service Manager presso il centro operativo di sicurezza (SOC) di una nota compagnia di telecomunicazioni. È stato co-responsabile della rubrica “Vulnerabilità” della rivista italiana “ICT Security Magazine”. Mercato di Riferimento Secondo la fonte Gartner, anche in considerazione delle contromisure adottate negli ultimi anni per il controllo degli accessi alla infrastruttura e la messa in protezione dei dati, negli ultimi tempi oltre il 75% degli attacchi sono stati indirizzati direttamente verso le applicazioni , causando gravi danni di immagine e pesanti perdite finanziarie; Gli obiettivi degli attacchi sono le vulnerabilità che si celano all’interno delle applicazioni software; Le vulnerabilità applicative sono quasi sempre presenti anche perché fino ad ora le politiche di qualità del software ed i relativi investimenti si sono concentrate soprattutto sulla correzione delle difettosità funzionali e sulle performance delle logiche applicative, trascurando l’attuazione di pratiche di progettazione e programmazione che garantiscono la sicurezza del codice. www.euery.com Mercato di Riferimento II Le vulnerabilità applicative vengono continuamente introdotte dagli stessi team di sviluppo interni alle aziende, dai fornitori, dalle soluzioni open-source: alcuni analisti affremano che il 64% degli sviluppatori non sono confidenti di poter scrivere applicazioni sicure (fonte: Microsoft Developer Research); Il numero delle tipologie di attacchi cresce in maniera esponenziale: dalle circa 2500 identificate nel 2000, si è passati ad oltre 50000 nel 2009 e continuamente se ne scoprono delle nuove (fonte: CERT); www.euery.com Riflessioni Quanto costa corregere i problemi? Errori Architetturali Errori di Codifica Errori di Integrazione www.euery.com Scoperti in fase di Disegno Scoperti in fase di Codifica Scoperti in fase di Integrazione Scoperti in fase Collaudo Scoperti in fase di Produzione 1x 5x 10x 20x 30x 1x 10x 20x 30x 1x 10x 15x Sicurezza applicativa: Cenni storici La pratica di sviluppare applicazioni software capaci di operare correttamente anche in condizioni di attacco da parte di agenti di minaccia esterni viene definita Software Security. Il primo libro e testo accademico ad esprimersi sull’argomento apparve nel 2001 e fu una chiara dimostrazione dell’ interesse e dello studio della tematica da parti di sviluppatori, software architect ed esperti di sicurezza informatica la cui attenzione fino a quel momento rimaneva concentrata su firewall, intrusion detection e sistemi antivirus. Una vera e propria rivoluzione di pensiero quindi. Il testo si chiamava Building Secure Software. www.euery.com Sicurezza applicativa: Cenni storici (II) La comunità blackhats, nel contempo, percepì la reale possibilità di portare con successo attacchi informatici alle applicazioni. Da qui l’inizio della diffusione delle prime e fondamentali best practices in materia di sicurezza applicativa, le prime tra tutte riconducibili ad una buona ingegnerizzazione del software, una piena comprensione delle minaccie più comuni, compresi i difetti propri dei linguaggi di programmazione, ma soprattutto una considerazione della problematica fin dalle prime fasi del ciclo di sviluppo. www.euery.com Sicurezza applicativa: Principi Secure By Default L’applicazione software dovrebbe utilizzare caratteristiche di sicurezza di default: ad esempio, l’abilitazione automatica di meccanismi di costruzione di password complesse piuttosto che procedure di rinnovo delle stesse secondo una scadenza di natura temporale. Least Privilege Il principio nasce dall’esigenza di limitare eventuali danni derivanti, ad esempio, da condizioni di errore, incidenti di sicurezza o utilizzo non autorizzato dell’applicazione software. Alla base dell’assioma la raccomandazione che gli utenti – così come le stesse applicazioni – siano in possesso di un insieme minimo di privilegi richiesti per l’esecuzione delle proprie attività lavorative inibendo così eventuali accessi, seppur involontari, a funzionalità critiche dell’applicativo piuttosto che al file system o base di dati. Defence In Depth Il principio del Defence In Depth asserisce che dove un controllo dovrebbe essere equilibrato al rischio, più controlli contemporanei ma che contrastino lo stesso rischio in maniera diversa costituiscono di certo la soluzione ottimale. Nel campo del Secure Coding tale principio può essere, ad esempio, così contestualizzato: un controllo di auditing centralizzato può essere efficacemente unito al requisito di tracciare la totalità degli accessi degli utenti. www.euery.com SDLC: Software Development Life Cycle Il criterio con cui una metodologia di sviluppo o un modello di processo scompongono l'attività di realizzazione di applicazioni software in sottoattività fra loro coordinate viene definito ciclo di vita del software. www.euery.com Attività SDLC Quasi tutti i modelli di ciclo di vita del software prevedono una scomposizione del processo di sviluppo in attività e sottoattività. www.euery.com SDLC: Analisi La fase di analisi, che costituisce lo studio preliminare sul contesto in cui il prodotto software dovrà inserirsi quindi sulle caratteristiche che dovrà esibire, ed eventualmente su costi e aspetti logistici della sua realizzazione. La fase può essere scomposta in sottoattività quali, ad esempio, analisi e modellazione del dominio applicativo, analisi di fattibilità ed analisi dei requisiti. www.euery.com SDLC: Progetto La fase di progetto, durante la quale, in funzione dei requisiti esposti in fase di analisi, vengono definite le linee essenziali della struttura dell’applicazione da realizzare. www.euery.com SDLC: Implementazione La fase di implementazione, ovvero la realizzazione concreta del progetto. L'implementazione ha lo scopo di attuare la soluzione. www.euery.com SDLC: Collaudo Obiettivo della fase è la misurazione di quanto il sistema realizzato soddisfi i requisiti stabiliti nella fase di analisi, quindi valutarne la correttezza rispetto alle specifiche. www.euery.com SDLC: Manutenzione Include tutte le attività di modifica del software successive alla fase di rilascio quali ad esempio, correzione dei difetti, porting su diversi ambienti operativi o estensione delle funzionalità. www.euery.com SSDLC: Secure Software Development Life Cycle Si definisce SSDLC (Secure Software Development Life Cycle) un ciclo di vita sicuro del software atto a considerare ed implementare opportune attività di sicurezza nel corso di tutte le sue fasi: analisi, progettazione, sviluppo, test e manutenzione. www.euery.com Sicurezza all’interno del SSDLC (I) Analisi: analisi dei requisiti di sicurezza, analisi dei rischi, identificazione delle minacce, analisi delle probabilità di impatto delle minacce, casi di Abuso e UML per la sicurezza del software, linee guida sull'usabilità del software, analisi tradizionale nel SDLC; Progetttazione: analisi dei rischi, UML per la sicurezza del software, linee guida sull'usabilità del software, progettazione tradizionale nel SDLC; Sviluppo: programmazione sicura del codice, test di sicurezza basati sull'analisi dei rischi, analisi statica del codice, sviluppo tradizionale nel SDLC; Test: analisi dei rischi, penetration test (approccio blackbox o code review), mitigazione dei rischi, test tradizionali nel SDLC; Manutenzione: analisi dei rischi, penetration test, manutenzione tradizionale nel SDLC. www.euery.com Sicurezza all’interno del SSDLC (II) www.euery.com Sicurezza all’interno del SSDLC (III) www.euery.com SSDLC: Alcuni esempi Alcuni famosi esempi di cicli di sviluppp software orientati alla sicurezza sono rappresentati da: SDL (Secure Software Development Lifecycle) CLASP (Comprehensive Lightweight Application Security Process) www.euery.com SDL (I) Uno dei programmi di maggiore successo nato dall'iniziativa Trustworthy computing di Microsoft è sicuramente il Security Development Lifecycle (SDL), il rigoroso processo di programmazione sicura che interessa i principali e più esposti software Microsoft. Da quando nel 2004 il processo è divenuto obbligatorio, le applicazioni e i sistemi operativi di Redmond hanno subito una forte riduzione delle vulnerabilità: Windows Vista, nel primo anno dopo il suo rilascio ufficiale ha visto ridurre del 45% il numero di vulnerabilità scoperte e corrette rispetto a Windows XP (66 contro 119), mentre per un prodotto critico nelle applicazioni Web come Sql Server, la riduzione dei bug di sicurezza è stato di ben 91%. www.euery.com SDL (II) www.euery.com SDL (III) Punti focali del processo SDL sono, senz’altro, costituiti dalla creazione di un modello di minacce (threat modeling), l’uso di strumenti di analisi statica del codice, revisioni tecniche ed attività di verifica del codice. www.euery.com CLASP Il modello CLASP (Comprehensive, Lightweight Application Security Process) fornito dal progetto OWASP fornisce un approccio strutturato all’integrazione di attività di sicurezza all’interno di ogni fase di un normale ciclo di sviluppo software. Tale processo è definito mediante cinque prospettive di alto livello chiamate viste. www.euery.com Capability Maturity Model Il Capability Maturity Model Integration è uno standard dei requisti di processo aziendali, sviluppato dal Carnegie Mellon University. È l'erede del CMM, sviluppato dal 1987 al 1997. E’ un modello che indica ventidue Aree di processi aziendali (Process area) strutturate su cinque livelli, ognuna con i propri obiettivi generici (Generic Goal) e specifici (Specific Goal). Gli obiettivi generici e specifici sono implementati da una sequenza temporale di attività generiche (Generic practice) e specifiche (specific practice), che hanno determinate tipologie di output (tipical work product). www.euery.com SSE-CMM L’ SSE-CMM (Systems Security Engineering-Capability Maturity Model) è uno specifico modello di processo - adottato come standard ISO/IEC 21827 oltre che standard de facto nel settore - utilizzabile per migliorare e valutare la capacità di ingegnerizzazione, circa gli aspetti legati alla sicurezza del software, all’interno di un’organizzazione. Il modello deriva dal Capability Maturity Model Integration ossia uno standard dei requisti di processo aziendali, sviluppato dal Carnegie Mellon University e promosso dall'Ufficio del Segretario della Difesa USA (OSD), dal SEI e dall'Associazione Industriale per la Difesa Nazionale. www.euery.com SAMM Software Assurance Maturity Model (SAMM) è un framework open - i cui autori ne permettono e ne favoriscono quindi il libero studio e l'apporto di modifiche – sviluppato al fine di supportare le organizzazioni nella formulazione di strategie relative alla sicurezza del software. Caratteristica del framework è la flessibilità con cui è stato definito che lo rende particolarmente adattabile tanto dalle piccole aziende, quanto dalle medie e grandi organizzazioni, slegandosi completamente, e nel comtempo, dallo specifico stile di sviluppo adottato. www.euery.com SAMM (II) ! www.euery.com BSIMMv2 Il Building Security In Maturity Model è un modello sviluppato con lo scopo di supportare la corretta pianificazione e governo di iniziative di sicurezza legate alle applicazioni software. BSIMM è strutturato in 110 attività ripartite sui 12 campi del Software Security Framework (SSF), a sua volta suddiviso in tre livelli di maturità. www.euery.com Threat Modeling La modellazione delle minacce è il processo di valutazione e documentazione dei rischi associati alla sicurezza di un particolare sistema e/o applicazione software. Il processo di modellazione può essere adottato per determinare un elemento denominato “Threat Profile“ associato all’applicazione, ovvero lo scenario non fidato in cui l’applicativo dovrà essere eseguito. Mediante l’adozione di opportune tecniche quali, ad esempio, l’identificazione degli entry point, ovvero i punti di accesso all’applicazione, Privilege Boundaries e Threat Tree è possibile identificare strategie di mitigazione efficaci per contrastare potenziali minacce a cui potrebbe essere soggetta l’applicazione. www.euery.com Threat Modeling (II) La modellazione delle minacce permette, inoltre, di giustificare l’introduzione o l’eliminazione di eventuali feature all’interno dell’applicazione oltre che governare, al fine di proteggere gli asset dell’applicazione, l’introduzione di nuove policy o pratiche di sicurezza all’interno del sistema. www.euery.com Threat Modeling: Modellazione del sistema Identificazione delle minacce: Il primo aspetto è relativo all’identificazione delle minacce associate, ad esempio, all’applicazione oggetto della modellazione. Tale fase può essere realizzata mediante l’utilizzo di Data Flow Diagrams (DFD) piuttosto che diagrammi UML. L’adozione di tali diagrammi consente l’identificazione, infatti, della totalità dei punti di ingresso all’applicazione quali, ad esempio, sorgenti di dati esterni, eventuali Application Program Interface (API), piuttosto che Web Services e/o interfacce utente. www.euery.com Threat Modeling: Comprensione delle minacce Al fine di identificare correttamente le possibili minacce associate ad ogni singolo punto di ingresso dell’applicazione è fondamentale comprendere le relative azioni ed implicazioni di sicurezza che potrebbero affliggere il sistema oggetto di modellazione a fronte di un’ eventuale violazione. www.euery.com Threat Modeling: Categorizzazione delle minacce La categorizzazione delle minacce di sicurezza può essere ottenuta mediante l’adozione di un modello denominato STRIDE sviluppato da Microsoft. STRIDE è l'acronimo che riunisce la gamma dei rischi per la protezione a cui può essere soggetta l'applicazione. Le sei categorie di rischi (Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service, and Elevation of privilege) consentono di identificare le vulnerabilità ed i possibili vettori di attacco nelle applicazioni. www.euery.com Threat Modeling: Possibili mitigazioni Al fine di determinare il rimedio associato ad una minaccia identificata è possibile generare un diagramma ad albero denominato Threat Tree. www.euery.com Threat Modeling: Un esempio www.euery.com Threat Modeling Tool (Microsoft) www.euery.com Penetration Testing Il Penetration Test, chiamato anche “Security Probe”, è un attività riconducibile ad un’indagine sperimentale sulla sicurezza di un computer, di una rete piuttosto che di un’applicazione software con lo scopo di individuare vulnerabilità che potrebbero essere sfruttate da un utente malintenzionato per ottenere accessi non autorizzati. www.euery.com Penetration Testing (II) Varie tipologie: Black Box: Nessuna informazione sul sistema; Gray Box: Minime informazioni sul sistema. Ad esempio architettura di base ed account alla sezione autenticata disponibili. White Box: Pieno accesso alle informazioni sul sistema. Spesso ingloba anche attività di Bug Hunting attraverso una secure code review. www.euery.com Penetration Testing: Fasi Profilazione dell’applicazione, identificazione di pagine o sezioni critiche, identificazione di eventuali componenti di terze parti installati; Esecuzione di una prima scansione attraverso tools automatici e studio delle vulnerabilità identificate; Analisi manuale delle vulnerabilità identificate e delle sezioni considerati critiche; Exploiting delle vulnerabilità per confermarne la presenza; Valutazione dell’impatto delle vulnerabilità e stesura report. www.euery.com Penetration Testing: Considerazioni Le applicazioni scritte in PHP risultano in media più vulnerabili rispetto alle controparti scritte in J2EE e ASP .NET (vuoi anche perché sono le più diffuse); Spesso i PT si risolvono attraverso l’identificazione di applicazioni di gestione erroneamente accessibili (ad es. phpmyadmin) oppure attraverso delle password deboli (ad es. root, toor, r00t, password, 123456); Sfruttamento di vulnerabilità note sugli applicativi installati (ad es. utilizzo di CMS vulnerabili) www.euery.com Penetration Testing: Un esempio Vulnerabilità di SQL Injection dump della tabella utenti (username e MD5 password); Brute forcing MD5 tramite rainbow tables password dell’utente (s3cr3t); Accesso alla parte autenticata del sito; Errore logico nel caricamento di file upload di un file con estenzione .php; Esecuzione di codice remoto con utente Apache; Kernel vulnerabile Run Exploit www.euery.com Download exploit da exploit-db root Penetration Testing DEMO www.euery.com Secure Code Review (I) Scopo principale dell’attività di Secure Code Review è l’analisi, automatica e manuale, del codice sorgente di un’applicazione software al fine di individuarne eventuali vulnerabilità di sicurezza. www.euery.com Secure Code Review (II) Possibili bug, con conseguenti ripercussioni sulla sicurezza del software, possono riguardare, ad esempio: blocchi try/catch/finally/switch vuoti; codice morto quali variabili locali, parametri o metodi inusati; costrutti if/while vuoti; espressioni o classi esageratamente complesse, contenenti if non necessari o cicli annidati; codice duplicato, tipicamente frutto di cut and paste. www.euery.com Secure Code Review: Strategie di analisi Diverse strategie di analisi del codice Data-flow: scelta una certa variabile si esegue solo il codice interessato da quest’ultima cercando di individuarne le vulnerabilità; Control-flow: scelto un componente lo si analizza riga per riga cercando di individuarne le vulnerabilità. www.euery.com Terminologia (I) Per avere un maggior livello di dettaglio e per evitare che uno stesso termine sia usato in letteratura con significati diversi, il glossario IEEE [IEEE90] propone le seguenti definizioni: Un malfunzionamento o guasto (failure) è un funzionamento di un programma diverso daquanto previsto dalla sua specifica; Un difetto o anomalia (fault) è la causa di un malfunzionamento; Un errore (error) è l’origine di un difetto. www.euery.com Terminologia (II) Si definisce Sink Point il punto in cui qualora un’eventuale input malevolo dovesse essere processato si avrebbero potenziali problemi di sicurezza; Si definisce Entry Point l’indirizzo di memoria corrispondente a un punto nel codice che è inteso come la destinazione di un "salto lungo" (long jump), sia esso interno o esterno; E’ detto Taint Input l’input considerato malevolo; Si definiscono Punti di Filtering i punti in cui l’input “taint” diventa “non taint”. www.euery.com Desk Check Il modo più elementare di effettuare un controllo statico è basato sull’analisi informale del codice, condotta “a mano” – in inglese desk check – o mediante l’ausilio di strumenti automatici. Le tecniche più comuni per effettuare questo tipo di controlli statici sono l’ispezione ed il walkthrough. Entrambi hanno lo scopo di trovare e denunciare dei difetti senza però che il revisore si sostituisca al progettista o al programmatore, a cui comunque rimane il compito di scoprire l’errore e correggere il codice. www.euery.com Desk Check (II) La principale differenza fra ispezione e walkthrough risiede nel tipo di errori che la tecnica si prefigge di scoprire. Il walkthrough è inteso come un’esecuzione simulata del codice e porta generalmente a scoprire difetti originati da errori algoritmici; L’ispezione ha invece, di norma, obiettivi ristretti e prestabiliti: poiché i difetti sono raggruppabili in categorie è plausibile che un controllo ottenga migliori risultati se concentrato su un solo tipo di difetti. www.euery.com Analisi statica supportata da strumenti Oltre al desk check, è possibile eseguire una verifica statica usando opportuni strumenti. Da un punto di vista teorico, avere un prova formale della correttezza di un programma, ottenuta a partire dall’analisi del codice, corrisponde all’esecuzione su tutti i possibili insiemi di dati d’ingresso. Diverse le teorie di analisi statica che approssimano la prova formale “ideale”: Model checking (controllo sul modello) Esecuzione simbolica Analisi statica in compilazione www.euery.com Testing (I) Il test di sistema è la più canonica delle attività di validazione che valuta ogni caratteristica di qualità del prodotto software nella sua completezza, avendo come documento di riscontro i requisiti dell’utente. Le tecniche più adottate per i test sul sistema sono basate su criteri funzionali. Gli obiettivi dei controlli sono mirati a esercitare il sistema sotto ben determinati aspetti alcuni dei quali verranno illustrati di seguito. www.euery.com Testing (II) Facility Test (test delle funzionalità): È il più intuitivo dei controlli, quello cioè che mira a controllare che ogni funzionalità del prodotto stabilita nei requisiti sia stata realizzata correttamente. Security Test: Cercando di accedere a dati o a funzionalità che dovrebbero essere riservate, si controlla l’efficacia dei meccanismi di sicurezza del sistema. www.euery.com Testing (III) Usability Test: Con questo controllo si vuole valutare la facilità d’uso del prodotto da parte dell’utente finale. È una valutazione su una delle caratteristiche di un prodotto software fra le più soggettive. Il controllo deve prendere in esame oltre al prodotto anche tutta la documentazione che lo accompagna e deve tener conto del livello di competenza dell’utenza e delle caratteristiche operative dell’ambiente d’uso del prodotto. www.euery.com Testing (IV) Performance Test: È un controllo mirato a valutare l’efficienza di un sistema soprattutto rispetto ai tempi di elaborazione e ai tempi di risposta. È un tipo di controllo critico per quelle categorie di prodotti, come ad esempio i sistemi in tempo reale, per le quali ai requisiti funzionali si aggiungono rigorosi vincoli temporali. Storage Use Test: È ancora un controllo legato all’efficienza di un sistema, ma mirato alla richiesta di risorse – la memoria in particolare – durante il funzionamento, e ha implicazioni sull’ambiente operativo richiesto per poter installare il sistema. www.euery.com Test Mutazionale Una strategia diversa è rappresentata dal test mutazionale. La tecnica si applica incongiunzione con altri criteri di test: nella sua formulazione è prevista infatti l’esistenza, oltre al programma da controllare, anche di un insieme di test già realizzati. La strategia prevede di introdurre modifiche controllate nel programma originale. Le modifiche riguardano in genere l’alterazione del valore delle variabili e la variazione delle condizioni booleane. www.euery.com Test di Regressione La strategia ha l’obiettivo di controllare se, dopo una modifica apportata per una necessità di sviluppo, il software è regredito, se cioè siano stati introdotti dei difetti non presenti nella versione precedente alla modifica. La strategia consiste nel riapplicare al software modificato i test progettati per la sua versione originale e confrontare i risultati. www.euery.com Secure Code Review e Testing a confronto Sono attività del tutto complementari che utilizzate in modo congiunto hanno un forte effetto sinergico nell’incrementare la sicurezza del software. Sono complementari perché: Il Testing individua misconfigurazioni ed errori del codice; Il testing individua errori logici nell’applicazione oltre che errori implementativi; Non permette di capire quale sia la root cause; Non ha piena visibilità del funzionamento dell’applicazione; La code review identifica tutti gli errori presenti nel codice; Permette di individuare anche alcuni errori logici (errata implementazione di algoritmi crittografici, etc …); Permette di capire quale è la root-cause di una data vulnerabilità; Ha una totale visibilità del funzionamento dell’applicazione. www.euery.com Secure Code Review DEMO www.euery.com Secure Programming (I) Tra gli aspetti più importanti quando si vuole adottare un SSDLC; Il primo passo è rendere gli sviluppatori consci dell’importanza di sviluppatore codice sicuro; Il secondo passo è adottare delle linee guida per lo sviluppo di codice sicuro e di affiancare a ciò l’utilizzo di framework o librerie che aiutino a scrivere codice più sicuro. www.euery.com Secure Programming (II) Un esempio: Boolean isAdmin = true; try { If (username.equals(“admin”) && password.equals(“password”)) isAdmin = true; else isAdmin = false; } Catch {} DoAdminOperation(isAdmin); Non rispetta il principio di Fail Securely. www.euery.com Domande? www.euery.com