Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

One pagepdf

313 views

Published on

  • Be the first to comment

  • Be the first to like this

One pagepdf

  1. 1. OWASP TOP 10 LE DIECI VULNERABILITÀ PIÙ CRITICHE NELLE APPLICAZIONI WEB EDIZIONE 2007 © 2002-2007 OWASP Foundation Questo documento è distribuito con licenza Creative Commons Attribution-ShareAlike 2.5
  2. 2. INDICE Indice Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Sommario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 A1 – Cross Site Scripting (XSS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 A2 – Injection Flaw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 A3 – Malicious File Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 A4 – Insecure Direct Object Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 A5 – Cross Site Request Forgery (CSRF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 A6 – Information Leakage and Improper Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 A7 – Broken Authentication and Session Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 A8 – Insecure Cryptographic Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 A9 – Insecure Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 A10 – Failure to Restrict URL Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Oltre la OWASP Top Ten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Riferiment i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 2
  3. 3. OWASP Top 10 2007 INTRODUZIONE Benvenuto nella OWASP Top 10 2007! Questa nuova edizione, completamente riscritta, elenca le vulnerabilità più critiche presenti nelle applicazioni web, discutendo su come è possibile difenderle e fornendo ulteriori riferimenti per chi volesse approfondire l’argomento. OBIETTIVO L’obiettivo primario della OWASP Top 10 è quello di educare sviluppatori, progettisti, analisti ed organizzazioni alla consapevolezza sui rischi delle più diffuse vulnerabilità presenti nelle applicazioni web. La Top 10 fornisce inoltre le basi metodologiche per la protezione delle applicazioni contro queste vulnerabilità, fornendo un buono spunto per iniziare alcune attività di programmazione sicura. La sicurezza non è una singola attività isolata. E’ inefficace sviluppare codice sicuro solo durante le prime implementazioni della tua applicazione. Nel corso del 2008 e degli anni successivi, la Top 10 potrebbe cambiare senza nemmeno cambiare una sola riga di codice all’interno delle tue applicazioni e facendo diventare conseguentemente i sistemi vulnerabili. Per maggiori informazioni si consiglia di leggere i suggerimenti presenti nella sezione Oltre la OWASP Top 10. L’attività di programmazione sicura deve interessare tutte le fasi del ciclo di sviluppo del software. Applicazioni web sicure sono solamente possibili all’interno di un SDLC sicuro. Programmi sicuri sono progettati e sviluppati intrinsecamente in maniera sicura. Ci sono almeno 300 problematiche che affliggono la sicurezza delle applicazioni web; queste 300 e più tematiche sono dettagliate all’interno della OWASP Guide, la quale deve essere considerata una guida essenziale per chiunque sviluppi applicazioni web oggi. Questo documento è prima di tutto un testo educativo, non uno standard. Si prega di non adottare questo documento come policy aziendale o standard senza prima informarci! Se necessiti di policy per la programmazione sicura o standard, OWASP porta avanti alcuni progetti sull’argomento. Considera anche la possibilità di partecipare attivamente o finanziariamente agli sforzi della comunità. RICONOSCIMENTI Vogliamo ringraziare MITRE per aver dato la possibilità di usare la Vulnerability Type Distribution in CVE in maniera libera. Il progetto OWASP Top Ten è gestito e sponsorizzato da Aspect Security. Capo Progetto: Andrew van der Stock (Executive Director, OWASP Foundation) Co-autori: Jeff Williams (Chair, OWASP Foundation), Dave Wichers (Conference Chair, OWASP Foundation) Vogliamo ringraziare i nostri correttori di bozze: · Raoul Endres per l’aiuto nel far progredire la Top 10 ed i suoi preziosi commenti · Steve Christey (MITRE) per l’approfondita revisione e l’aggiunta dei dati MITRE 3
  4. 4. · Jeremiah Grossman (White Hat Security) per la revisione e per aver fornito contributi riguardo i successi (e gli insuccessi) dei metodi di rilevamento automatici · Sylvan von Stuppe per l’esemplare revisione del testo · Colin Wong, Nigel Evans, Andre Gironda, Neil Smithline per i commenti inviati tramite email A nome del capitolo Italiano di OWASP, che ha curato la traduzione del presente documento, si vuole ringraziare (rigorosamente in ordine alfabetico): · Luca Carettoni · Paolo Perego · Simove Savi 4
  5. 5. OWASP Top 10 2007 SOMMARIO A1 – Cross Site Scripting (XSS) La vulnerabilità denominata XSS si presenta ogni qualvolta l’applicazione riceve dell’input dall’utente che poi viene inoltrato al web browser, senza prima essere correttamente validato e codificato. XSS permette ad un eventuale aggressore di eseguire script all’interno del browser, introducendo la possibilità’ di session hijacking, il defacement di siti, la propagazione di worms, ecc. A2 – Injection Flaws Le vulnerabilità definite “Injection flaws”, ed in particolare le SQL Injection, sono tristemente comuni nelle applicazioni web. La possibilità di inviare stringhe che sono interpretate dall’applicazione come comandi e query rappresenta la situazione ideale per questa categoria di vulnerabilità. Un aggressore può quindi modificare il flusso di esecuzione con l’intento di eseguire comandi e alterare dati. A3 – Malicious File Execution Il codice sorgente vulnerabile a “Remote File Inclusion” (abbreviata con RFI) permette ad un aggressore di includere istruzioni e dati malevoli all’interno dell’applicazione con effetti devastanti: nel peggiore dei casi è addirittura possibile la completa compromissione del server remoto. Gli attacchi di Malicious File Execution affliggono PHP, XML e qualsiasi altro framework che accetta nomi dei file e path dagli utenti. A4 – Insecure Direct Object Reference La vulnerabilità di “Direct Object Reference” si presenta quando uno sviluppatore espone esternamente un riferimento ad un componente o a parti dell’implementazione di oggetti come file, directory, record di basi di dati, oppure di chiavi come URL o parametri. Eventuali aggressori possono quindi manipolare questi riferimenti in maniera da accedere a risorse senza previa autorizzazione. A5 – Cross Site Request Forgery (CSRF) Un attacco di CSRF costringe il browser di una vittima autenticata in un sito Internet ad inviare una richiesta verso l’applicazione web vulnerabile, in maniera da eseguire azioni ostili a beneficio dell’aggressore. CSRF è tanto più dannoso e potente quanto lo è l’applicazione che viene attaccata, in termini di funzionalità. A6 – Information Leakage and Improper Error Handling Le applicazioni web possono consentire la fuga involontaria di informazioni riguardanti la configurazione o le modalità di funzionamento, nel momento in cui si presentano situazioni di errore non gestite. Gli aggressori usano questa famiglia di vulnerabilità per rubare dati confidenziali o portare a compimento attacchi ben più seri. A7 – Broken Authentication and Session Management Credenziali utente e token di sessione sono spesso non correttamente protetti. Gli aggressori possono compromettere password, chiavi di cifratura o token di autenticazione in maniera da impersonare altri utenti. A8 – Insecure Le applicazioni web utilizzano raramente in maniera corretta i 5
  6. 6. Cryptographic Storage meccanismi di crittografica disponibili oggi per proteggere dati e credenziali. Eventuali aggressori possono sfruttare le debolezze di dati crittografati per perpetrare furti di identità e altri crimini come le frodi con carta di credito. A9 – Insecure Communications Frequentemente le applicazioni web non utilizzano alcuna cifratura del traffico di rete anche quando sarebbe necessario per proteggere comunicazioni confidenziali. A10 – Failure to Restrict URL Access Altrettanto frequentemente, le applicazioni web proteggono l’accesso a funzioni critiche solamente evitando di esporre link o URL ad utenti non autenticati. Eventuali aggressori possono usare questa debolezza per accedere ed eseguire operazioni a cui non sono autorizzati, collegandosi direttamente a tali URL. Table 1: Le 10 vulnerabilità più critiche nelle applicazioni web nel 2007 6
  7. 7. OWASP Top 10 2007 METODOLOGIA La nostra metodologia, utilizzata per la top 10 2007, è semplice: analizzare i risultati della MITRE Vulnerability Trends for 2006 ed estrarre le prime 10 problematiche in ambito web. I risultati percentuali sono mostrati di seguito: Figure 2: Dati MITRE rispetto alle prime 10 problematiche nelle applicazioni web durante il 2006 Sebbene si è cercato di preservare l’associazione uno a uno con i dati grezzi recuperati dalla classificazione MITRE, abbiamo deliberatamente modificato alcune delle ultime categorie in maniera da meglio riflettere la causa delle problematiche. Se sei interessato alla classificazione finale MITRE con i dati grezzi del 2006, abbiamo pubblicato un foglio Excel nella pagina dedicata alla OWASP Top 10, all’interno del sito OWASP. Tutte le raccomandazioni in termini di soluzioni difensive si riferiscono ai tre principali web application framework: Java EE, ASP.NET e PHP. Per gli altri web application framework, come Ruby on Rails o Perl, è possibile adattare facilmente le medesime raccomandazioni al fine di soddisfare le specifiche esigenze imposte dai diversi ambienti. PERCHE’ ALCUNE IMPORTANTI PROBLEMATICHE SONO STATE RIMOSSE Le problematiche denominate “Unvalidated input” sono una delle principali sfide per ogni team di sviluppo e spesso la radice di molti problemi di sicurezza nelle applicazioni. E’ infatti possibile notare come molte delle problematiche nell’elenco abbiamo come raccomandazioni risolutive la validazione dell’input utente. Suggeriamo fortemente di creare un unico meccanismo di validazione centralizzato come componente delle vostre applicazioni web. Per maggiori informazioni è possibile consultare i seguenti articoli di OWASP, relativi alla validazione dei dati:  http://www.owasp.org/index.php/Data_Validation 7
  8. 8.  http://www.owasp.org/index.php/Testing_f or_Data_Validation Buffer overflows, integer overflows e le problematiche denominate format string sono vulnerabilità estremamente pericolose per programmi sviluppati con i linguaggi C o C++. Le soluzioni per questo genere di problematiche sono trattate da note comunità di esperti di sicurezza applicativa come SANS, CERT e dai produttori di ambienti di programmazione. Se il tuo codice è stato sviluppato con un linguaggio che può essere soggetto a buffer overflow, incoraggiamo la lettura dei seguenti articoli presenti sul sito web di OWASP:  http://www.owasp.org/index.php/Buffer_overflow  http://www.owasp.org/index.php/Testing_for_Buffer_Overflow Denial of Service è un pericoloso attacco che affligge ogni sito web sviluppato in qualsiasi linguaggio di programmazione. La valutazione all’interno dei dati MITRE relativa alle problematiche di DoS è insufficiente per poter inserire questa debolezza all’interno della top 10. Nel caso di problemi riconducibili a Denial of Service, è possibile consultare il sito OWASP e la Testing Guide:  http://www.owasp.org/index.php/Category:Denial_of_Service_Attack  http://www.owasp.org/index.php/Testing_for_Denial_of_Service Insecure configuration management affligge tutti i sistemi con particolare riferimento ad alcune tecnologie, come PHP. Tuttavia la valutazione dei dati MITRE non ci permette di includere questa problematica nell’edizione di quest’anno. Nel momento in cui viene effettuato il deploy della tua applicazione consigliamo di consultare la più recente OWASP Testing Guide per maggiori informazioni relative alla configurazione e gestione delle piattaforme di fruizione:  http://www.owasp.org/index.php/Configuration  http://www.owasp.org/index.php/Testing_for_infrastructure_configuration_manage PERCHE’ ABBIAMO AGGIUNTO ALCUNE PROBLEMATICHE IMPORTANTI Cross Site Request Forgery (CSRF) rappresenta la principale aggiunta in questa edizione della OWASP Top 10. Sebbene all’interno dei dati grezzi del MITRE questa vulnerabilità occupa solamente la 36esima posizione, crediamo che sia realmente importante iniziare a proteggere le applicazioni contro questa vulnerabilità. Nel caso di applicazioni critiche o che gestiscono dati sensibili, CSRF può provocare seri danni. CSRF è sicuramente più importante della sua attuale posizione nella classifica. Cryptography In accordo con i dati MITRE, l’utilizzo insicuro della crittografia non rappresenta più l’#8 e #9 posizione della classifica, sebbene rappresenti ancora la principale causa di perdita di informazioni e problematiche di conformità (per esempio, rispetto alla PCI DSS 1.1). 8
  9. 9. OWASP Top 10 2007 VULNERABILITÀ, NON ATTACCHI ! La precedente edizione della Top 10 conteneva attacchi, vulnerabilità e contromisure. In questa edizione ci siamo focalizzati unicamente rispetto alle vulnerabilità, sebbene la terminologia comunemente adottata combina vulnerabilità ed attacchi. Se le organizzazioni utilizzano questo documento per mettere in sicurezza le loro applicazioni e ridurre il rischio derivante dalle loro attività, ci si attende un’equivalente riduzione della probabilità di attacchi:  Phishing attacks che possono sfruttare una qualsiasi di queste vulnerabilità, in particolar luogo XSS, oltre ad eventuali debolezze dei meccanismi di autenticazione e autorizzazione (A1, A4, A7 e A10)  Privacy violations possono derivare dalla mancata validazione, da impropri controlli delle logiche di business e da meccanismi deboli di autorizzazione (A2, A4, A6, A7 e A10)  Identity theft (furto di identità) viene perpetrato in caso di meccanismi crittografici deboli o non esistenti (A8 e A9), inclusione remota di file (A3) e meccanismi deboli di autenticazione e di autorizzazione (A4, A7, A10)  Systems compromise, data alteration o data destruction sono attacchi solitamente perpetrati via injection (A2) ed inclusione remota di file (A3)  Financial loss attraverso l’utilizzo di transazioni non autorizzate e CSRF (A4, A5, A7, A10)  Reputation loss sfruttando una qualsiasi delle vulnerabilità presentate (A1 … A10) Una volta che l’organizzazione sposta la propria attenzione dai controlli reattivi verso la riduzione pro-attiva del rischio, è facilmente ipotizzabile che si migliori l’attinenza a standard di compliance, la riduzione del costo operazionale e si ottenga come risultato finale sistemi più robusti e sicuri. INCLINAZIONE La metodologia descritta precedentemente soffre di una naturale inclinazione rispetto alle 10 principali problematiche scoperte e pubblicate dalla comunità degli esperti di sicurezza (ndr. tralasciando quindi tutte quelle problematiche non ancora note, se non all’interno di piccoli gruppi di ricerca). D’altro canto, questo modello di scoperta delle vulnerabilità segue le tendenze degli attuali attacchi informatici, in particolar modo rispetto ad aggressori con capacità tecniche medio-basse (“script kiddy”). Proteggendo il tuo software rispetto alla top 10 è perciò possibile prevenire le comuni forme di attacco e definire un percorso per migliorare la sicurezza del software. RIFERIMENTI TRA LE DIVERSE VERSIONI DELLA TOP 10 Nell’attuale Top 10, rispetto alle passate edizioni, ci sono stati alcuni cambiamenti nella denominazione delle categorie di vulnerabilità anche laddove il contenuto non è stato completamente modificato. La principale ragione risiede nella decisione di non adottare la 9
  10. 10. convezione WAS XML in quanto tale classificazione non sembrava in linea con le moderne vulnerabilità e gli attuali attacchi e contromisure. Nella tabella successiva è possibile notare le differenze con la Top 10 2004 e la classificazione MITRE: OWASP Top 10 2007 OWASP Top 10 2004 MITRE 2006 Raw Ranking A1. Cross Site Scripting (XSS) A4. Cross Site Scripting (XSS) 1 A2. Injection Flaws A6. Injection Flaws 2 A3. Malicious File Execution (aggiunta) 3 A4. Insecure Direct Object Reference A2. Broken Access Control (divisa nella 2007 T10) 5 A5. Cross Site Request Forgery (CSRF) (aggiunta) 36 A6. Information Leakage and Improper Error Handling A7. Improper Error Handling 6 A7. Broken Authentication and Session Management A3. Broken Authentication and Session Management 14 A8. Insecure Cryptographic Storage A8. Insecure Storage 8 A9. Insecure Communications Discussa in A10. Insecure Configuration 8 (aggiunta) Management A10. Failure to Restrict URL Access A2. Broken Access Control (split in 2007 T10) 14 <rimossa nella versione 2007> A1. Unvalidated Input 7 <rimossa nella versione 2007> A5. Buffer Overflows 4, 8, and 10 <rimossa nella versione 2007> A9. Denial of Service 17 <rimossa nella versione 2007> A10. Insecure Configuration Management 29 10
  11. 11. OWASP Top 10 2007 A1 – CROSS SITE SCRIPTING (XSS) La vulnerabilità denominata “Cross site scripting”, spesso nota come XSS, rappresenta un sottoinsieme delle problematiche di HTML injection. XSS è la vulnerabilità più presente e pericolosa nelle applicazioni web. XSS si verifica ogni qualvolta un’applicazione accetta dell’input utente che viene inoltrato al web browser senza prima essere validato. Sfruttando la vulnerabilità di XSS, un aggressore è in grado di eseguire script nel browser della vittima. Diversi attacchi possono quindi essere perpetrati: dirottamento della sessione utente, modifica dei siti Internet visitati, inserimento di codice ostile nelle pagine HTML, attacchi di phishing sino alla completa compromissione del browser della vittima tramite codice malevolo. Tali attacchi sono solitamente sviluppati con il linguaggio JavaScript anche se ogni tipo di tecnologia di scripting supportato dal browser della vittima può essere sfruttata. SISTEMI AFFETTI Tutti i web application framework sono vulnerabili rispetto a Cross Site Scripting VULNERABILITÀ Ci sono tre tipologie di cross site scripting: “reflected”, “stored” e “DOM injection”. Cross Site Scripting reflected (riflesso) è la vulnerabilità più semplice da sfruttare e si verifica quando una pagina “riflette” dati immessi dall’utente direttamente al browser: echo $_REQUEST[’userinput’]; Nel caso di XSS stored (salvato), l’input utente è salvato in un file, un database o in altre tecnologie di storage e, solo successivamente, mostrato all’utente senza opportuna validazione. Questa categoria è particolarmente pericolosa nelle applicazioni quali i CMS, blog, forum ed in tutti quei sistemi dove un grande numero di utenti legge il contenuto di messaggi inviati da altri. Tramite XSS DOM based (basato sull’albero DOM – Document Object Model) vengono invece manipolati le variabili ed il codice JavaScript del sito Internet piuttosto che gli elementi HTML della pagina. Alternativamente, gli attacchi possono essere perpetrati sfruttando delle versioni ibride ottenute mescolando le tre categorie di questa vulnerabilità. Il pericolo nel Cross Site Scripting non è tanto nel tipo di attacco, quanto nei possibili scenari malevoli. Comportamenti inattesi del web browser o non standard possono introdurre ulteriori vettori di attacco. XSS è anche potenzialmente sfruttabile utilizzando componenti del browser stesso. Gli attacchi sono solitamente implementati in JavaScript, un potente linguaggio di scripting per il web. Utilizzando questa tecnologia, un aggressore può modificare ogni aspetto della pagina web visualizzata, manipolare l’albero DOM interno, cambiare lo stile della pagina oltre alla possibilità di aggiungere nuovi elementi (per esempio un finto login che invii le credenziali rubate verso il sito dell’aggressore). JavaScript permette inoltre l’uso di funzioni avanzate come XmlHttpRequest, solitamente usate da siti con tecnologia Ajax, sebbene la pagina vulnerabile non utilizzi tali caratteristiche avanzate. Sfruttando questa funzione è 11
  12. 12. spesso possibile bypassare le limitazioni imposte dalla “same source origination policy” ed inviare dati verso terzi siti ostili, creando quindi complessi worm e zombie che rimangono attivi sino alla chiusura del browser stesso. Nel caso di Ajax, gli attacchi non necessitano di interazione da parte dell’utente e sono completamente invisibili; in questo contesto vengono solitamente eseguiti pericolosi attacchi di Cross Site Request Forgery - CSRF (si veda la sezione A-5). VERIFICA DI SICUREZZA L’obiettivo è verificare che tutti i parametri usati dall’applicazione siano validati e/o codificati prima di essere inclusi all’interno delle pagine HTML. Approcci Automatici: Gli strumenti automatici di identificazione delle vulnerabilità sono in grado di identificare facilmente la categoria di XSS denominata “reflected”, ma difficilmente “Stored XSS” soprattutto se l’output del vettore di attacco è all’interno di sezioni protette da autenticazione (esempio: un input utente ostile che viene mostrato solo nella sezione per amministratori). Gli strumenti automatici di revisione del codice, invece, possono individuare API deboli o pericolose ma solitamente non sono in grado di determinare la presenza di validazione o encoding; per questa ragione i risultati dell’analisi contengono spesso falsi positivi. Entrambi gli strumenti non sono in grado di identificare XSS DOM based. Per questa ragione tutte le applicazioni Ajax che vengono solamente analizzate con questo genere di strumenti sono potenzialmente a rischio. Approcci Manuali: Se la validazione all’interno dell’applicazione è centralizzata, la modalità più efficiente di verificare la sicurezza è l’analisi manuale del codice stesso. Nel caso in cui la validazione sia distribuita in più punti all’interno del software, la verifica puntuale risulterà sicuramente più costosa in termini di tempo richiesto poiché la superficie di attacco dell’applicazione è maggiore. PROTEZIONE La miglior protezione contro XSS è la combinazione di “whitelist” usate per filtrare tutti i dati in ingresso e la codifica dell’output. La validazione dell’input permette il rilevamento di attacchi mentre la codifica dei caratteri in uscita previene ogni tentativo di esecuzione del codice di scripting nel browser. Prevenire il verificarsi di XSS all’interno di un’applicazione richiede un approccio architetturale consistente:  Validazione dell’input. Usare meccanismi standard di validazione dell’input in maniera da validare la lunghezza, il tipo, la sintassi e la logica di business prima di mostrare o salvare i dati. Utilizzare una strategia che segua la logica dell' “accetto solo quello che è utile per la mia applicazione”. Rifiutare input non valido piuttosto che tentare di sanitizzare potenziali dati ostili. Non dimenticare che anche i messaggi di errore possono contenere dati non validi.  Codifica severa dell’output. Assicurare che tutti i dati inviati dall’utente vengano appropriatamente codificati (in HTML o XML, a seconda della tipologia di output usata 12
  13. 13. OWASP Top 10 2007 dall’applicazione) prima di presentare tale output. Adottare un strategia di codifica di tutti i caratteri ad esclusione di un sottoinsieme molto limitato. Questo approccio è oggigiorno seguito anche dalla libreria “Microsoft Anti-XSS” e dalla “OWASP PHP Anti- XSS library”. Infine, ricordarsi di impostare la tipologia di encoding utilizzata dalle pagine di output in maniera da ridurre l’esposizione a varianti di XSS che possono sfruttare la non completa definizione della codifica.  Specificare la codifica di output (come ISO 8859-1 o UTF 8). Non permettere all’aggressore di scegliere la codifica utilizzata dalle pagine mostrate ai tuoi utenti.  Non utilizzare “blacklist” di validazione per determinare la presenza di XSS nell’input o per effettuare la codifica dell’output. Cercare e sostituire solamente pochi caratteri (“<” “>” e altri caratteri simili, oppure parole come “script”) è una pratica debole che può essere facilmente bypassata. Anche un semplice tag “<b>” non filtrato può essere considerato non sicuro in alcuni contesti. XSS permette un innumerevole quantità di varianti che consente di evadere i filtri di validazione basati su blacklist.  Porre attenzione ad errori di adattamento dell’input. L’input deve essere sempre decodificato e adattato rispetto ai meccanismi interni usati dall’applicazione, prima di essere validato. Assicurarsi che l’applicazione non effettui la decodifica dell’input due volte. Questo genere di errori può essere facilmente sfruttato per bypassare schemi di whitelisting, introducendo input malevolo codificato. Alcune raccomandazioni specifiche per tipologie di linguaggi:  Java: Utilizzare i meccanismi di output implementati nel framework “Struts” come <bean:write … >, oppure usare l’attributo JSTL escapeXML=”true” in <c:out … >. Non utilizzare <%= … %> al di fuori di opportuni meccanismi di codifica.  .NET: Utilizzare la libreria Microsoft Anti-XSS 1.5 liberamente scaricabile dal network per sviluppatori MSDN. Non assegnare il contenuto dei campi nei form direttamente dall’oggetto “Request”: username.Text = Request.QueryString(“username”); senza l’utilizzo della libreria citata. Comprendere quali controlli .NET codificano automaticamente l’output.  PHP: Assicurare che l’output venga filtrato usando le funzioni htmlentities() o htmlspecialchars() oppure usare la più recente versione della libreria OWASP PHP Anti- XSS library. Disabilitare “register_globals” se non è stata ancora disabilitata. ESEMPI  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4206  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3966  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5204 RIFERIMENTI  CWE: CWE-79, Cross-Site scripting (XSS) 13
  14. 14.  WASC Threat Classification, http://www.webappsec.org/projects/threat/classes/cross-site_scripting.shtml  OWASP – Cross site scripting, http://www.owasp.org/index.php/Cross_Site_Scripting  OWASP – Testing for XSS, http://www.owasp.org/index.php/Testing_for_Cross_site_scripting  OWASP Stinger Project (A Java EE validation filter), http://www.owasp.org/index.php/Category:OWASP_Stinger_Project  OWASP PHP Filter Project, http://www.owasp.org/index.php/OWASP_PHP_Filters  OWASP Encoding Project, http://www.owasp.org/index.php/Category:OWASP_Encoding_Project  RSnake, XSS Cheat Sheet, http://ha.ckers.org/xss.html  Klein, A., DOM Based Cross Site Scripting, http://www.webappsec.org/projects/articles/071105.shtml  .NET Anti-XSS Library, http://www.microsoft.com/downloads/details.aspx?FamilyID=efb9c819-53ff-4f82-bfaf-e11625130c25& DisplayLang=en 14
  15. 15. OWASP Top 10 2007 A2 – INJECTION FLAW Le vulnerabilità denominate “injection flaw”, di cui le SQL injection sono un noto esempio, risultano molto comuni nelle applicazioni web. Esistono differenti tipologie di “injection flaw” tra cui citiamo: SQL, LDAP, Xpath, XSLT, HTML, XML, l’injection di comandi di sistema e molte altre. L’iniezione avviene quando i dati forniti dall’utente vengono inviati ad un interprete come parte di un comando o di una query. Gli aggressori possono perciò aggirare l’interprete al fine di eseguire comandi non autorizzati attraverso l’inserimento di input appositamente forgiato. Le injection flaw permettono ad un aggressore di creare, leggere, aggiornare o eliminare arbitrariamente ogni tipo di dato utilizzato nell’applicazione. Nel peggiore dei casi, queste vulnerabilità possono permettere ad un aggressore di compromettere completamente l’applicazione ed il sottostante sistema, scavalcando persino complesse catene di firewall. SISTEMI AFFETTI Tutti i web application framework che utilizzano interpreti o che invocano altri processi sono vulnerabili all’iniezione di comandi. Queste considerazioni valgono per ogni componente del framework che potrebbe usare un interprete di qualche tipo nel proprio back-end. VULNERABILITÀ Se l’input dell’utente è passato direttamente all’interprete, senza opportuna validazione o codifica, l’applicazione è vulnerabile. Verifica se l’input utente è utilizzato direttamente all’interno di query dinamiche, come la seguente: PHP: $sql = “SELECT * FROM table WHERE id = ‘” . $_REQUEST[’id’] . “’”; Java: String query = “SELECT user_id FROM user_data WHERE user_name = ‘” + req.getParameter(“userID”) + “’ and user_password = ‘” + req.getParameter(“pwd”) +”’”; VERIFICA DI SICUREZZA L’obiettivo delle verifiche di sicurezza per prevenire questa famiglia di vulnerabilità consiste nell’accertarsi che i dati immessi dall’utente non possano modificare la semantica dei comandi e delle query inviate ad ogni interprete utilizzato dall’applicazione. Approcci Automatici: molti strumenti di identificazione automatica delle vulnerabilità sono in grado di ricercare problemi di iniezione, in particolare SQL injection. Gli strumenti di analisi statica del codice ricercano l’utilizzo insicuro di API; questi tool sono estremamente utili sebbene non sono in grado di verificare la presenza di validazione e i meccanismi di codifica implementati per contrastare queste vulnerabilità. Se l’applicazione risponde a particolari richieste con errori del tipo “501 / 500 internal server error” oppure senza dettagliati errori del database, gli strumenti automatici possono essere ostacolati anche in presenza di codice chiaramente vulnerabile. Gli strumenti automatici sono inoltre in grado di identificare attacchi di iniezione di codice LDAP, XML e Xpath. 15
  16. 16. Approcci Manuali: la maniera più efficiente ed accurata per prevenire queste vulnerabilità è la verifica del codice che invoca gli interpreti esterni. La persona incaricata di analizzare il codice dovrà verificare puntualmente l’utilizzo sicuro delle API e l’appropriata validazione e/o codifica utilizzata. Il test di queste problematiche può richiedere una notevole quantità di tempo anche per una minima copertura del codice, poiché la superficie di attacco nelle comuni applicazioni web è solitamente molto ampia. PROTEZIONE Evitare l’utilizzo di interpreti, quando possibile. Se è proprio necessario utilizzare interpreti esterni, la chiave per ottenere applicazioni sicure è l’utilizzo appropriato delle API che comporti una tipizzazione forte e l’utilizzo di librerie ORM (object relational mapping). Queste interfacce gestiscono tutte le problematiche di escaping dei dati. E’ importante notare che, sebbene queste librerie risolvono il problema, la validazione dell’input è altamente raccomandata per identificare attacchi. L’utilizzo di interpreti è pericoloso. Per questa ragione si consiglia di adottare tutte le possibili precauzioni, come mostrato nel seguito:  Validazione dell’input. Usare meccanismi standard di validazione dell’input in maniera da validare la lunghezza, il tipo, la sintassi e la logica di business prima di mostrare o salvare i dati. Utilizzare una strategia che segua la logica dell’ “accetto solo quello che è utile per la mia applicazione”. Rifiutare input non valido piuttosto che tentare di sanitizzare potenziali dati ostili. Non dimenticare che anche i messaggi di errore possono contenere dati non validi.  Utilizzare API con tipizzazione forte che utilizzino meccanismi di sostituzione dei parametri attuali, anche nel caso di stored procedure.  Forzare l’utilizzo dei più bassi privilegi necessari durante le connessioni a database e altre tipologie di back-end.  Evitare messaggi di errore dettagliati che possono risultare utili ad un potenziale aggressore  Utilizzare stored procedure poiché sono generalmente al riparo da attacchi di SQL injection. Porre comunque particolare attenzione poiché anche questa soluzione può essere sfruttata per attacchi di injection (per esempio attraverso l’uso della funzione exec() o concatenando argomenti all’interno della stored procedure).  Non usare interfacce per la generazione di query dinamiche (come la funzione mysql_query() o simili)  Non utilizzare semplici funzioni di escaping, come la funzione PHP addslashes() o la sostituzione di caratteri in str_replace(“’”, “’’”). Queste soluzioni sono deboli e sono state sfruttate con successo da aggressori. Nel caso di PHP, utilizzare la funzione mysql_real_escape_string() se si utilizza MySQL oppure usare PDO poiché non richiede escaping. Quando si utilizzano questi meccanismi è importante notare che le semplici funzioni di escaping non possono gestire i nomi delle tabelle! I nomi delle tabelle 16
  17. 17. OWASP Top 10 2007 devono essere definite da SQL sintatticamente valido e sono quindi completamente fuori dalle logiche che devono gestire i dati immessi dall’utente.  Porre attenzione ad errori di adattamento dell’input. L’input deve essere sempre decodificato e adattato rispetto ai meccanismi interni usati dall’applicazione, prima di essere validato. Assicurarsi che l’applicazione non effettui la decodifica dell’input due volte. Questo genere di errori può essere facilmente sfruttato per bypassare schemi di whitelisting, introducendo input malevolo codificato. Alcune raccomandazioni specifiche per tipologie di linguaggi:  Java EE – utilizzare i metodi PreparedStatement oppure framework ORM come Hibernate o Spring  .NET – utilizzare query con tipizzazione forte dei parametri, per esempio SqlCommand con SqlParameter oppure framework ORM come Hibernate.  PHP – utilizzare query con tipizzazione forte dei parametri (usando bindParam()) ESEMPI  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5121  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4953  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4592 RIFERIMENTI  CWE: CWE-89 (SQL Injection), CWE-77 (Command Injection), CWE-90 (LDAP Injection), CWE-91 (XML Injection), CWE-93 (CRLF Injection) e altre.  WASC Threat Classification, http://www.webappsec.org/projects/threat/classes/ldap_injection.shtml http://www.webappsec.org/projects/threat/classes/sql_injection.shtml http://www.webappsec.org/projects/threat/classes/os_commanding.shtml  OWASP, http://www.owasp.org/index.php/SQL_Injection  OWASP Guide, http://www.owasp.org/index.php/Guide_to_SQL_Injection  OWASP Code Review Guide, http://www.owasp.org/index.php/Reviewing_Code_for_SQL_Injection  OWASP Testing Guide, http://www.owasp.org/index.php/Testing_for_SQL_Injection  SQL Injection, http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf  Advanced SQL Injection, http://www.ngssoftware.com/papers/advanced_sql_injection.pdf 17
  18. 18.  More Advanced SQL Injection, http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf  Hibernate, an advanced object relational manager (ORM) for J2EE and .NET, http://www.hibernate.org/  J2EE Prepared Statements, http://java.sun.com/docs/books/tutorial/jdbc/basics/prepared.html  How to: Protect from SQL injection in ASP.Net, http://msdn2.microsoft.com/en-us/library/ms998271.aspx  PHP PDO functions, http://php.net/pdo 18
  19. 19. OWASP Top 10 2007 A3 – MALICIOUS FILE EXECUTION La vulnerabilità denominata “malicious file execution” è spesso presente in molte applicazioni. In alcuni casi, gli sviluppatori usano direttamente o concatenano input potenzialmente ostile con file o funzioni di stream. In altri casi, si fidano impropriamente di file dati in input. Su molte piattaforme, i moderni framework di sviluppo permettono di usare riferimenti ad oggetti esterni come ad esempio URL o risorse sul file system. Quando l’input non é sufficientemente controllato, possono essere inclusi contenuti ostili, i quali saranno successivamente processati o invocati dal web server. Questo permette agli aggressori di effettuare:  Esecuzione di codice da remoto  Installazione di root-kit e conseguente compromissione completa del sistema  Su Windows, la compromissione del sistema è possibile attraverso l’uso dei SMB file wrapper presenti nel framework PHP Questo attacco è particolarmente comune in PHP che quindi richiede estrema cura nel trattare stream o funzioni per file, in maniera da assicurarsi che l’input fornito dall’utente non influenzi i nomi dei file. SISTEMI AFFETTI Tutti i web application framework sono vulnerabili a “malicious file execution” se accettano nomi di file o file dall’utente. Esempi tipici includono: .NET assembly, il quale permette l’uso di nomi di file come argomenti, o codici che accettano il nome di un file scelto dall’utente per includere file locali. PHP è particolarmente vulnerabile all’attacco di “remote file include (RFI)” compiuto attraverso la modifica di parametri che sono utilizzati in funzioni per la gestione di file. VULNERABILITÀ Un costrutto comunemente vulnerabile è: include $_REQUEST[‘filename’]; Questa istruzione non solo permette l’inclusione di uno script remoto ostile, ma può essere usato per accedere a file locali presenti sul server (se PHP è su Windows, per via del supporto SMB nei file wrapper di PHP). Altri metodi di attacco includono:  Dati ostili caricati come file di sessione, dati di log o attraverso l’upload di immagini (tipico dei software per forum)  Usando stream di compressione o stream audio come zlib:// o ogg:// i quali non ispe-zionano il “PHP URL flag” interno e permettono così l’accesso a risorse remote anche se le opzioni di “allow_url_fopen” e “allow_url_include” sono disabilitate 19
  20. 20.  Usando wrapper PHP, come php://input e altri, per ottenere l’input dalla richiesta http POST invece che da un file  Usando il wrapper PHP data: come data:;base64,PD9waHAgcGhwaW5mbygp0z8+ Visto che l’elenco di funzioni pericolose risulta esteso, è vitale usare un’architettura di sicurezza che sia propriamente progettata. In particolare, un’architettura robusta è necessaria quando si deve gestire input forniti dall’utente che influenzano le scelte dei nomi dei file lato server. Anche se sono stati dati esempi in PHP, questo attacco è applicabile anche alle piattaforme .NET e J2EE. Le applicazioni scritte in questi framework richiedono particolare attenzione durante la stesusa dei meccanismi del codice per l’accesso sicuro, al fine di garantire che, nomi di file forniti o influenzati dall’utente, non permettano di evitare i controlli di sicurezza. Per esempio è possibile che documenti XML inviati da un attaccante abbiano un DTD ostile che forzi il parser XML a caricare un DTD remoto, effettuare il parsing ed elaborare i risultati. Una società di sicurezza Australiana ha dimostrato l’utilizzo di questa tecnica per effettuare port scanning all’interno di una rete aziendale. Per maggiori informazioni , si veda [SIF01] nei riferimenti di questo capitolo. Il danno che questa particolare vulnerabilità causa è direttamente collegato alla forza della sandbox offerta dal framework applicativo. Siccome l’ambiente di esecuzione in PHP è raramente isolato e non implementa il concetto di sandbox, il danno di un attacco è molto peggiore che su altre piattaforme. Attacchi di questo tipo sono quindi meno frequenti su sistemi con fiducia parziale o limitata all’interno di un’adeguata sandbox, come ad esempio un’applicazione web che gira all’interno della JVM con il security manager correttamente abilitato e configurato. VERIFICARE LA SICUREZZA Approccio automatizzato: i tool di scansione delle vulnerabilità avranno difficoltà nell’identificare i parametri che vengono utilizzati nell’inclusione di file o la sintassi per renderli funzionanti. I tool di analisi statica possono controllare se sono utilizzate API pericolose, ma non possono verificare se appropriate validazioni e codifiche sono dispiegate a protezione della vulnerabilità. Approccio manuale: la revisione del codice può identificare istruzioni che permetterebbero l’inclusione di file nell’applicazione, anche se l’analisi risulta spesso soggetta a falsi positivi. Sebbene la revisione del codice può rilevare queste vulnerabilità, risulta spesso difficile determinare i vettori di attacco. PROTEZIONE Prevenire il problema relativo all’inclusione di file da remoto richiede un’attenta pianificazione sia in fase di progettazione dell’architettura che in fase di sviluppo. In generale un’applicazione ben scritta non utilizzerà l’input fornito dall’utente nei nomi di file utilizzati da risorse server-based (come immagini, XML e SDL transform document) e avrà regole di firewall che impediranno nuove connessioni in uscita verso Internet o internamente verso 20
  21. 21. OWASP Top 10 2007 ogni altro server. Alcune applicazioni legacy hanno però spesso la necessità di accettare input fornito dall’utente. In questi casi, tra le considerazioni più importanti ci sono:  Usare una mappa per il riferimento indiretto all’oggetto (per maggiori dettagli vedere la sezione A4). Per esempio, quando è usato un nome parziale, considerare l’u-tilizzo dell’hash del riferimento parziale. Invece di: <select name=”language”> <option value=”English”>English</option> usare <select name=”language”> <option value=”78463a384a5aa4fad5fa73e2f506ecfc”>English</option> Considerare l’uso di “salt” per prevenire attacchi brute force del riferimento indiretto all’oggetto. Alternativamente basta usare valori d’indice come 1,2,3 e assicurarsi che i limiti dell’array siano controllati per rivelare attacchi di parameter tampering.  Usare meccanismi espliciti per controllare l’alterazione, se il tuo linguaggio lo supporta. Altrimenti considerare uno schema di denominazione delle variabili che aiuti ad evitare la modifica dei parametri in ingresso: $hostfile = &$_POST; // refer to POST varibles, not $_REQUEST $safe[‘filename’]= validate_file_name($hostfile[‘unsafe_filename’]); // make it safe Di conseguenza ogni operazione basata su input ostile è immediatamente evidente: NO: require_once($_POST[‘unsafe_filename’] . ‘inc.php’); SI: require_once($safe[‘filename’] . ‘inc.php’);  Validazione forte dell’input degli utenti usando una strategia che segua la logica dell’ “accetto solo quello che è utile per la mia applicazione”. Rifiutare input non valido piuttosto che tentare di sanitizzare potenziali dati ostili.  Aggiungere regole di firewall per prevenire connessioni a siti web esterni o verso i sistemi interni da parte del web server. Per sistemi critici, si consiglia di isolare il web server in una propria VLAN o subnet privata  Controllare che i file o i nomi di file forniti dall’utente non siano in grado di alte-rare altri controlli, come es. dati alterati negli oggetti di sessione, avatar e immagini, log in file PDF, file temporanei e così via  Considerare l’implementazione di una chroot jail o altri meccanismi di sandbox, come la virtualizzazione, per isolare l'applicazione da altri sistemi  PHP: Disabilitare “allow_url_fopen” e “allow_url_include” in php.ini e considera-re la compilazione di PHP senza includere queste funzionalità . Pochissime applicazioni necessitano di queste funzionalità; per questa ragione sarebbe opportuno disabilitarle 21
  22. 22.  PHP: Disabilitare “register_globals” e usare “E_STRICT” per identificare va-riabili non inizializzate  PHP: Assicurarsi che tutti i file e le funzioni di stream (stream_*) siano accu-ratamente esaminate. Assicurarsi che l’input dell’utente non sia fornito direttamen-te alle funzioni che prendono come argomento un nome di file: include() include_once() requie() requie_once() fopen() imagecreatefromXXX() file() file_get_contents() copy() dolete() unlink() upload_tmp_dir() $_FILES move_upload_file()  Con PHP, essere estremamente cauti se i dati sono passati a funzioni quali system() eval() passthru() o ‘ (l’operatore backtick)  Con J2EE, assicurarsi che il security manager sia abilitato e propriamente configurato e che l’applicazione gestisca le autorizzazioni in maniera opportuna  Con ASP.NET, si faccia riferimento alla documentazione sulla “partial trust”. Progetta-re la vostra applicazione in maniera “segmentata”, facendo in modo che la maggior parte dell’esecuzione si trovi nello stato di trust più basso possibile ESEMPI  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0360  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5220  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4722 RIFERIMENTI  CWE: CWE-98 (PHP File Inclusion), CWE-78 (OS Command Injection), CWE-95 (Eval injection), CWE-434 (Unrestricted file upload)  WASC Threat Classification, http://www.webappsec.org/projects/threat/classes/os_commanding.shtml  OWASP Guide, http://www.owasp.org/index.php/File_System#Includes_and_Remote_files  OWASP Testing Guide, http://www.owasp.org/index.php/Testing_for_Directory_Traversal  OWASP PHP Top 5, http://www.owasp.org/index.php/PHP_Top_5#P1:_Remote_Code_Execution  Stefan Esser, http://blog.php-security.org/archives/45-PHP-5.2.0-and-allow_url_include.html  [SIF01] SIFT, Web Services: Teaching an old dog new tricks, http://www.ruxcon.org.au/files/2006/web_services_security.ppt  OWASP Java Security Policy, http://www.owasp.org/index.php/OWASP_Java_Table_of_Contents#Defining_a_Java_Sec urity_Policy 22
  23. 23. OWASP Top 10 2007  Microsoft - Programming for Partial Trust, http://msdn2.microsoft.com/en-us/library/ms364059(VS.80).aspx 23
  24. 24. A4 – INSECURE DIRECT OBJECT REFERENCE Una vulnerabilità di “direct object reference” esiste quando uno sviluppatore espone un riferimento ad un’implementazione interna di un oggetto, come un file, una directory, un record di un database, o una chiave, un URL o parametri di un form. Un aggressore, a meno di controlli sull’accesso, può manipolare i riferimenti diretti all’oggetto per accedere ad altre risorse senza autorizzazione. Per esempio, in un’applicazione di Internet Banking è comune utilizzare il numero di account come primary key. Gli sviluppatori sono spesso tentati ad utilizzare questo riferimento in maniera diretta anche nell’interfaccia web. Anche se vengono utilizzate query SQL parametrizzate per prevenire attacchi di SQL injection, se non esiste nessun altro controllo che verifichi che l’utente sia il proprietario dell’account e quindi autorizzato a vederne il contenuto, un aggressore può vedere o cambiare tutti gli account. L’attacco consiste semplicemente nel falsificare il parametro relativo al numero di account. Questo tipo di attacco è accaduto al sito “Australian Taxation Office’s GST Start Up Assistance” nel 2000 dove un utente legittimo ma ostile ha semplicemente cambiato l’ABN (un identificativo per le tasse) presente nell’URL. L’utente raccolse dal sistema dettagli di circa 17000 società. Questo tipo di vulnerabilità è veramente comune e altrettanto poco testata nelle applicazioni moderne. SISTEMI AFFETTI Tutti i web application framework sono vulnerabili all’attacco di “insecure direct object reference”. VULNERABILITÀ Molte applicazioni espongono agli utenti i loro riferimenti agli oggetti interni. Gli aggressori usano la modifica dei parametri (“parameter tampering”) per cambiare i riferimenti e violare la progettata, ma non applicata, politica di controllo dell’accesso. Frequentemente questi riferimenti puntano al file system e ai database; ogni costrutto esposto dall’applicazione può però essere vulnerabile. Per esempio, se il codice permette che l’input dell’utente specifichi un nome di file o un path, questo può consentire agli aggressori di “saltare” fuori dalla directory dell’applicazione e accedere ad altre risorse. <select name=”language”><option value=”fr”>Français</option></select> … require_once ($_REQUEST[‘language’].”lang.php”); Questo codice può essere attaccato usando una stringa simile a “../../../../etc/passwd%00” che fa uso di null byte injection (per maggiori informazioni vedere la OWASP Guide) per accedere ad ogni risorsa nel file system del web server. In modo simile i riferimenti alle chiavi dei database sono frequentemente esposti. Un aggressore può attaccare questi parametri semplicemente indovinando o cercando un’altra 24
  25. 25. OWASP Top 10 2007 chiave valida. Spesso sono in sequenza naturale. Nell’esempio sottostante, anche se l’applicazione non presenta link a diversi “carrelli” e non è possibile effettuare SQL injection, un attaccante può ancora cambiare il parametro cartID per collegarsi a qualsiasi carrello: int cartID = Integre.parseInt( request.getParameter( “cartID” ) ); String query = “SELECT * FROM table WHERE cartID=” + cartID; VERIFICARE LA SICUREZZA L’obiettivo è verificare che l’applicazione non permetta ai riferimenti diretti agli oggetti di essere manipolati da un attaccante. Approccio automatizzato: i tool di scansione delle vulnerabilità avranno difficoltà nell’identificare quali parametri sono suscettibili a manipolazione o se la manipolazione funziona. I tool di analisi statica non conoscono realmente quali parametri devono avere un controllo dell’accesso prima del loro uso. Approccio manuale: una revisione del codice può tracciare i parametri critici e identificare se sono suscettibili a manipolazione. Un penetration test può verificare che la manipolazione sia possibile. Entrambe queste tecniche richiedono tempo per assicurare una copertura completa. PROTEZIONE La migliore protezione è quella di evitare l’esposizione a riferimenti diretti usando un indice, una mappa di riferimenti indiretti o altri metodi indiretti che sono facili da validare. Se un riferimento diretto ad un oggetto deve essere necessariamente usato, assicurarsi che l’utente sia autorizzato prima che lo utilizzi. È importante stabilire un modo standard per referenziare gli oggetti dell’applicazione:  Evitare di esporre riferimenti ad oggetti privati agli utenti ogni volta che è pos-sibile, come primary key o nomi di file  Validare in maniera estesa ogni riferimenti ad oggetti privati con un approccio “accept known good”  Verificare l’autorizzazione a tutti gli oggetti referenziati La soluzione migliore per prevenire l’attacco di manipolazione dei parametri è usare un valore indice o una mappa dei riferimenti. http://www.example.com/application?file=1 Se si devono esporre riferimenti diretti alle strutture di un database assicurarsi che i comandi SQL e gli altri metodi di accesso al database permettano di visualizzare solo i record autorizzati: int cartID = Integre.parseInt( request.getParameter( “cartID” ) ); User user = (User) request.getSession().getAttribute( “user” ); String query = “SELECT * FROM table WHERE cartID=” + cartID + “ AND userID=” + user.getID(); 25
  26. 26. ESEMPI  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0329  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4369  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0229 RIFERIMENTI  CWE: CWE-22 (Path Traversal), CWE-472 (Web Parameter Tampering)  WASC Threat Classification, http://www.webappsec.org/projects/threat/classes/abuse_of_functionality.shtml http://www.webappsec.org/projects/threat/classes/insufficient_authorization.shtml  OWASP Testing Guide, http://www.owasp.org/index.php/Testing_for_business_logic  OWASP Testing Guide Directory Traversal, http://www.owasp.org/index.php/Testing_for_Directory_Traversal  OWASP Access Control Vulnerability, http://www.owasp.org/index.php/Category:Access_Control_Vulnerability  GST Assist attack details, http://www.abc.net.au/7.30/stories/s146760.htm 26
  27. 27. OWASP Top 10 2007 A5 – CROSS SITE REQUEST FORGERY (CSRF) Pur non essendo un attacco nuovo, il Cross Site Request Forgery è semplice e devastante. Un attacco CSRF forza il browser di una vittima, opportunamente autenticata, ad inviare una richiesta verso l’applicazione web vulnerabile, la quale poi effettuerà l’azione scelta a nome della vittima. QUESTA VULNERABILITÀ È ESTREMAMENTE DIFFUSA. OGNI APPLICAZIONE CHE:  Non ha un controllo dell’autorizzazione per azioni vulnerabili  Processa una richiesta, includendo nella richiesta stessa un login di default (es. http://www.example.com/admin/doSomething.ctl?username=admin&passwd=admin)  Autorizza le richieste basandosi solo su credenziali che sono fornite automaticamente come cookie di sessione se si è correttamente autenticati nell’applicazione, o funzio-nalità “Remember me” se non si è correttamente autenticati nell’applicazione, o token Kerberos se parte di una Intranet tramite login integrato con Active Directory è a rischio. Sfortunatamente molte applicazioni web confidano solamente sulle credenziali inviate automaticamente come i cookie di sessione, tramite “basic authentication”, indirizzo IP sorgente, certificati SSL o credenziali di dominio Windows. Questa vulnerabilità è anche conosciuta con diversi altri nomi inclusi Session Riding, One- Click Attack, Cross Site Reference Forgery, Hostile Linking e Automation Attack. Anche l’acronimo XSRF è frequentemente usato. Sia OWASP che MITRE usano in maniera standard sia il termine Cross Site Request Forgery che l’acronimo CSRF. SISTEMI AFFETTI Tutti i web application framework sono vulnerabili ad attacchi di CSRF. VULNERABILITÀ Un tipico attacco CSRF contro un forum potrebbe assumere questa forma: indirizzare l’utente a richiamare qualche funzione come ad esempio la pagina di logout dell’applicazione. Il seguente tag in una pagina web visitata dalla vittima genererà una richiesta che farà effettuare il logout: <IMG SRC=”HTTP://WWW.EXAMPLE.COM/LOGOUT.PHP ”> Se una banca on-line consente alla sua applicazione di processare richieste, es. di trasferimento di fondi, potrebbe avvenire un attacco simile: <img src=”http://www.example.com/transfer.do?frmAcct=document.form.frmAcct &toAcct=4345754&toSWIFTid=434343&amt=3434.43”> Jeremiah Grossman, durante la presentazione Hacking Intranet Sites from the outside (BlackHat 2006) ha dimostrato che è possibile forzare un utente a fare cambiamenti sul suo router DSL senza previo consenso; anche se l’utente non sa che il router DSL ha 27
  28. 28. un’interfaccia web. Per questi attacchi, Jeremiah ha usato account di default sui router più comuni. Tutti questi attacchi funzionano perché le credenziali di autorizzazione dell’utente (tipicamente il cookie di sessione) sono automaticamente inclusi dal browser con le richieste, anche se l’attaccante non ha fornito nessuna credenziale. Se il tag HTML contenente l’attacco può essere inviato ad un’applicazione vulnerabile, la probabilità di trovare vittime “loggate” aumenta significativamente, in maniera simile all’aumento di rischio fra la vulnerabilità XSS stored e reflected. La vulnerabilità XSS non è richiesta per effettuare un attacco CSRF, sebbene ogni applicazione con una falla XSS è suscettibile a CSRF perché un attacco di questo tipo può sfruttare la falla XSS per rubare credenziali. Molti worm applicativi hanno usato entrambe le tecniche in maniera combinata. Quando si costruiscono delle difese contro attacchi CSRF bisogna anche focalizzarsi sull’eliminazione di vulnerabilità XSS dal momento che questa vulnerabilità può essere usata per aggirare molte delle difese dispiegate per difendersi da CSRF. VERIFICARE LA SICUREZZA L’obiettivo è verificare che l’applicazione sia protetta contro attacchi CSRF, generando e poi utilizzando token d’autorizzazione che non sono automaticamente sottomessi dal browser. Approccio automatizzato: tutt’oggi pochi scanner automatici possono rilevare vulnerabilità CSRF, anche se è un’operazione possibile per un motore di scansione sufficientemente abile. Comunque, se il vostro scanner di applicazioni rivela una vulnerabilità di Cross-Site Scripting e non si ha una protezione anti-CSRF, molto probabilmente sarete vulnerabili a semplici attacchi CSRF. Approccio manuale: il modo più veloce per verificare l’esistenza di una protezione contro i CSRF è eseguire un penetration test. Per verificare che il meccanismo sia forte e propriamente implementato, il modo migliore è la verifica puntuale dell’applicazione. PROTEZIONE Le applicazioni non devono fare affidamento solo su credenziali o token che sono automaticamente forniti dal browser. L’unica soluzione è usare un token custom che il browser non “ricorderà“ e che quindi non verrà incluso automaticamente in un attacco CSRF. Le seguenti strategie dovrebbero essere insite in ogni applicazione web:  Assicurarsi che non ci siano vulnerabilità XSS nelle vostre applicazioni (Vedi A1 - Cross Site Scripting)  Inserire in ogni form e URL token custom e randomici che non saranno automa-ticamente inviati dal browser. Per esempio, <form action=”/transfer.do” method=”post”> <input type=”hidden” name=”84389277730” value=”43847384383”> … 28
  29. 29. OWASP Top 10 2007 </form> Verificare che il token inviato sia corretto, rispetto all’utente corrente. Questi token possono essere unici per una particolare funzione, pagina, per utente, o semplicemente unici per tutta la sessione. Più il token è focalizzato su una particolare funzione e/o su un particolare insieme di dati, più forte sarà la protezione e più difficile sarà da costruire e mantenere il sistema di anti-CSRF token.  Per dati sensibili o transazioni di valore, ri-autenticarsi o usare la firma della transazione per assicurarsi che la richiesta sia autentica. Preparare meccanismi esterni come e-mail o contatti telefonici con lo scopo di verificare le richieste o notifi-carle all’utente  Non usare richieste GET per dati sensibili o per effettuare transazioni di va-lore. Usare solo metodi POST quando si processano dati sensibili provenienti dall’u-tente. L’URL può contenere token randomici in modo da creare un riferimento unico, il quale rende quasi impossibile effettuare attacchi CSRF  Il solo utilizzo di HTTP POST è una protezione insufficiente. Per proteggersi propriamente contro il CSRF bisogna combinarlo con token randomici non collegati al-l’autenticazione o ri-autenticare ogni richiesta critica  Per ASP.NET, settare una ViewStatusKey (si veda i riferimenti a fine sezione). Questa soluzione fornisce un tipo di controllo simile ai token randomici descritti sopra Sebbene i suggerimenti dati diminuiscono drasticamente la vostra esposizione, molti attacchi CSRF avanzati possono superare queste restrizioni. La tecnica migliore è utilizzare token unici e eliminare tutte le vulnerabilità XSS dell’applicazione. ESEMPI  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0192  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5116  MySpace Samy Interview: http://blog.outer-court.com/archive/2005-10-14-n81.html  An attack which uses Quicktime to perform CSRF attacks http://www.computerworld.com/action/article.do? command=viewArticleBasic&articleId=9005607&intsrc=hm_list RIFERIMENTI  CWE: CWE-352 (Cross-Site Request Forgery)  WASC Threat Classification: No direct mapping, but the following is a close match, http://www.webappsec.org/projects/threat/classes/abuse_of_functionality.shtml  OWASP CSRF, http://www.owasp.org/index.php/Cross-Site_Request_Forgery  OWASP Testing Guide, https://www.owasp.org/index.php/Testing_for_CSRF 29
  30. 30.  OWASP CSRF Guard, http://www.owasp.org/index.php/CSRF_Guard  OWASP PHP CSRF Guard, http://www.owasp.org/index.php/PHP_CSRF_Guard  RSnake, “What is CSRF?”, http://ha.ckers.org/blog/20061030/what-is-csrf/  Jeremiah Grossman, slides and demos of “Hacking Intranet sites from the outside” http://www.whitehatsec.com/presentations/whitehat_bh_pres_08032006.tar.gz  Microsoft, ViewStateUserKey details, http://msdn2.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic2 30
  31. 31. OWASP Top 10 2007 A6 – INFORMATION LEAKAGE AND IMPROPER ERROR HANDLING Le applicazioni possono, in maniera non intenzionale, rivelare informazioni circa la loro configurazione, il loro funzionamento interno o violare la riservatezza dei dati tramite una serie di problemi applicativi. Le applicazioni possono inoltre rivelare il loro stato interno attraverso il tempo speso per processare alcune operazioni o attraverso differenti risposte quando sollecitate con input differenti, come ad esempio la visualizzazione di uno stesso messaggio d’errore. Le applicazioni web spesso rivelano informazioni circa il loro stato interno attraverso messaggi d’errore dettagliati o messaggi di debug. Spesso queste informazioni possono essere utilizzate per lanciare o addirittura per automatizzare attacchi più sofisticati. SISTEMI AFFETTI Tutti i web application framework sono vulnerabili all’information leakage and improper error handling. VULNERABILITÀ Le applicazioni generano frequentemente messaggi di errore da visualizzare agli utenti. Molte volte questi messaggi d’errore sono abbastanza utili agli attaccanti in quanto rivelano dettagli implementativi o informazioni utili per sfruttare ulteriori vulnerabilità. Alcuni esempi tipici di queste vulnerabilità sono:  Messaggi d’errore dettagliati, dove indurre un errore causa la visualizzazione di informazioni come stack trace, istruzioni SQL terminate con errori o altri messaggi di debug  Funzioni che producono differenti risultati a fronte di input differenti. Ad esempio, l’inserimento dello stesso username ma di password differenti alla funzionalità di login, dovrebbe produrre lo stesso messaggio d’errore sia nel caso di utente inesistente che nel caso di password errata. Tuttavia la maggior parte dei sistemi produce codici d’errore differenti. VERIFICA DELLA SICUREZZA L’obiettivo è verificare che l’applicazione non riveli informazioni attraverso messaggi d’errore o altri tipi di messaggi. Approccio automatizzato: gli strumenti di vulnerability scan, spesso causano la generazione di messaggi d’errore che possono quindi essere valutati. Strumenti di analisi statica possono ricercare l’utilizzo di API che rivelano informazioni, pur non essendo in grado di verificare il significato di questi messaggi. Approccio manuale: una revisione del codice può ricercare porzioni del sistema dove la gestione degli errori non è ben implementata o dove vengono rivelate informazioni. In generale si tratta di un’attività che richiede molto tempo. Il semplice test a runtime può causare messaggi d’errore, anche se l’individuazione della natura applicativa dell’errore può essere un’impresa ardua. 31
  32. 32. PROTEZIONE Gli sviluppatori dovrebbero utilizzare strumenti come OWASP WebScarab per cercare di causare errori applicativi. Le applicazioni che non vengono testate in questo modo, saranno molto probabilmente soggette alla generazione di messaggi d’errore non previsti. Le applicazioni dovrebbero inoltre includere un meccanismo standard per gestire le eccezioni al fine di prevenire la rivelazione di informazioni riservate ad un aggressore. Prevenire l’esposizione di informazioni di sistema richiede disciplina. Le abitudini che seguono si sono rivelate efficaci contro questa categoria di vulnerabilità:  Verificare che tutto il team di sviluppo appia un approccio comune alla gestione delle eccezioni.  Disabilitare o limitare la generazione di messaggi d’errore. In particolare, non devono essere visualizzate informazioni di debug, stack trace o informazioni sui percorsi e sul file system ad utenti finali  Verificare che percorsi d’esecuzione che hanno multipli risultati restituiscono messaggi d’errore simili o identici più o meno nella stessa maniera. Se non è possibile, si consideri di inserire un tempo d’attesa casuale per tutte le transazioni in modo da mascherare la condizione d’errore all’attaccante  Differenti strati applicativi possono restituire risultati non previsti, come ad esempio lo strato di comunicazione con il database o il web server sottostante (IIS, Apache, ecc). E’ vitale che gli errori di ciascun strato applicativo siano controllati e configurati in modo da prevenire messaggi che possano essere utilizzati da un aggressore per un exploit  Essere consapevoli che i framework comunemente utilizzati restituiscono differenti codici d’errore HTTP in maniera dipendente se l’errore accade all’interno del codice del framework o nel codice applicativo custom. Può essere un buon investimento quello di creare un gestore d’errori di default, che restituisca appropriati messaggi d’errore  Scavalcare il meccanismo di gestione di default degli errori in maniera tale che venga restituito sempre il codice “200” (OK). In questo modo viene tolta ai tool di scansione automatizzata, la possibilità di discriminare tra un errore applicativo ed una condizione normale. Nonostante sia spesso considerato come “security through obscurity”, questo meccanismo può aumentare il livello di difesa  Alcune società hanno scelto di introdurre un codice d’errore casuale o addirittura unico per tutte le loro applicazioni. Questo può aiutare l’help desk a trovare la corretta soluzione per un problema particolare, ma può essere utilizzato anche da un attaccante per capire quale percorso d’esecuzione ha causato l’errore ESEMPI  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4899  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3389  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0580 32
  33. 33. OWASP Top 10 2007 REFERENZE  CWE: CWE-200 (Information Leak), CWE-203 (Discrepancy Information Leak), CWE-215 (Information Leak Through Debug Information), CWE-209 (Error Message Information Leak), others.  WASC Threat Classification, http://www.webappsec.org/projects/threat/classes/information_leakage.shtml  OWASP, http://www.owasp.org/index.php/Error_Handling  OWASP, http://www.owasp.org/index.php/Category:Sensitive_Data_Protection_Vulnerability 33
  34. 34. A7 – BROKEN AUTHENTICATION AND SESSION MANAGEMENT Meccanismi adeguati di autenticazione e di gestione della sessione sono un punto critico nella sicurezza di un’applicazione web. Le vulnerabilità in quest’area riguardano soprattutto la mancata protezione delle credenziali e dei token di sessione durante il loro ciclo di vita. Queste vulnerabilità possono portare l’aggressore a dirottare la sessione utente o ad accedere ad account amministrativi, compromettendo i controlli di autorizzazione e di profilatura. Inoltre, questa vulnerabilità può portare a problemi circa la riservatezza dei dati. SISTEMI AFFETTI Tutti i web application framework sono vulnerabili ad errori sui meccanismi di autenticazione e di gestione della sessione. VULNERABILITÀ Problemi nel sistema principale di autenticazione sono comuni ma le vulnerabilità sono spesso introdotte attraverso funzioni secondarie come il logout, la gestione della password, il timeout, la funzionalità “remember me”, domande riservate e l’aggiornamento dell’account. VERIFICA DELLA SICUREZZA Lo scopo è verificare che l’applicazione autentichi in maniera corretta gli utenti e che protegga in maniera adeguata le loro identità e le credenziali ad essi associate. Approccio automatizzato: strumenti di vulnerability scan non sono in grado di rilevare in maniera efficace vulnerabilità presenti in porzioni di codice custom per l’autenticazione e la gestione della sessione. Gli strumenti di analisi statica non sono altrettanto in grado di rilevare problemi legati a tali funzionalità. Approccio manuale: una code review e il test dell’applicazione, soprattutto se effettuati entrambi, sono molto efficaci per verificare che le funzionalità di autenticazione e di gestione della sessione siano implementate in maniera corretta. PROTEZIONE L’autenticazione si basa sulla comunicazione sicura delle credenziali d’accesso e sulla memorizzazione delle stesse. Come prima cosa occorre verificare che SSL sia l’unica opzione per tutte le parti dell’applicazione che richiedono l’autenticazione (si veda A9 – Insecure Communication), successivamente occorre verificare che tutte le credenziali vengano memorizzate utilizzando opportune funzioni di hash o di crifratura (si veda A8 – Insecure Cryptographic Storage). Prevenire errori nel codice di autenticazione richiede una pianificazione accurata. Le considerazioni più interessanti sono:  Utilizzare unicamente il sistema di gestione della sessione fornito dall’application server. Non bisogna scrivere o utilizzare meccanismi secondari per la gestione della sessione. 34
  35. 35. OWASP Top 10 2007  Non accettare identificativi di sessione nuovi, prestabiliti o invalidi, provenienti dall’URL o contenuti nella richiesta http dell’utente. Questo attacco viene chiamato “session fixation”  Limitare o eliminare dal codice, cookie custom di autenticazione o di gestione della sessione, come funzionalità “remember me” o funzionalità di single sign-on sviluppate in casa. Questo suggerimento non si applica a meccanismi robusti e comprovati di SSO o di autenticazione federata  Utilizzare un solo meccanismo di autenticazione che sia robusto. Si presti attenzione che questo meccanismo non sia soggetto in maniera semplice ad attacchi di spoofing o a “reply attack”  Non permettere che la procedura di autenticazione avvenga da una pagina non cifrata. Occorre sempre iniziare il processo di login da una pagina cifrata, avente un nuovo token di sessione per prevenire il furto di credenziali, attachi di phishing e di session fixation  Si consideri l’eventualità di generare una nuova sessione una volta completata con successo l’autenticazione o un cambio di privilegi.  Assicurarsi che ogni pagina abbia un link alla funzionalità di logout. Il logout deve distruggere tutte le informazioni di sessione lato server e tutti i cookie presenti sul browser. Si consideri il fattore umano: è meglio non chiedere alcuna conferma per evitare che gli utenti chiudano il browser che presenta loro la pagina di conferma.  Utilizzare un periodo di timeout dopo il quale viene effettuato il logout automatico per le sessioni inattive (un minor tempo di timeout comporta un livello di sicurezza maggiore).  Utilizzare unicamente funzioni robuste per l’autenticazione (domande e risposte, reset della password) in quanto queste sono credenziali come username e password o token di autenticazione. Occorre applicare una funzione di hash one-way per prevenire attacchi legati alla disclosure di informazioni.  Non rendere visibili gli identificativi di sessione o porzioni di credenziali valide nell’URL o nei log (non si deve effettuare il session rewriting o memorizzare la password degli utenti nei file di log)  Controllare la password vecchia quando viene cambiata  Non dipendere da credenziali che possono essere falsificate come unica forma di autenticazione, inclusi gli indirizzi IP o un range di indirizzi, DNS o reverse DNS lookup, l’header referrer o simili.  Fare attenzione nell’inviare informazioni riservate tramite email (si veda RSNAKE01 all’interno dei riferimenti a fine sezione) come meccanismo per il reset della password. Utilizzare numeri causali e limitati nel tempo per il reset delle credenziali d’accesso. Inviare inoltre un’email di conferma dopo l’avvenuto reset. Fare attenzione nel caso in cui l’applicazione permetta di modificare l’email di registrazione 35
  36. 36. degli utenti; inviare sempre un’email di conferma all’indirizzo precedentemente registrato. ESEMPI  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6145  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6229  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6528 REFERENZE  CWE: CWE-287 (Authentication Issues), CWE-522 (Insufficiently Protected Credentials), CWE-311 (Reflection attack in an authentication protocol)  WASC Threat Classification, http://www.webappsec.org/projects/threat/classes/insufficient_authentication.shtml http://www.webappsec.org/projects/threat/classes/credential_session_prediction.shtml http://www.webappsec.org/projects/threat/classes/session_fixation.shtml  OWASP Guide, http://www.owasp.org/index.php/Guide_to_Authentication  OWASP Code Review Guide, http://www.owasp.org/index.php/Reviewing_Code_for_Authentication  OWASP Testing Guide, http://www.owasp.org/index.php/Testing_for_authentication  RSNAKE01, http://ha.ckers.org/blog/20070122/ip-trust-relationships-xss-and-you 36
  37. 37. OWASP Top 10 2007 A8 – INSECURE CRYPTOGRAPHIC STORAGE Proteggere dati sensibili con la crittografia e’ diventata una pratica importante nelle applicazioni web moderne. In molti casi, le applicazioni non cifrano nemmeno le informazioni. Nei casi in cui si utilizzata la crittografia, la stessa e’ spesso malamente progettata oppure vengono inappropriatamente utilizzati i meccanismi di “chiper”. Queste vulnerabilità possono portare alla divulgazione di dati sensibili e conseguenti violazioni. SISTEMI AFFETTI Tutti i framework per applicazioni web sono vulnerabili all’utilizzo di algoritmi insicuri di crittografia. VULNERABILITÀ La prevenzione di vulnerabilità crittografiche richiede estrema pianificazione. Problemi tipici includono:  Non applicare cifratura su dati sensibili  Utilizzare algoritmi artigianali  Utilizzo insicuro di algoritmi di crittografia forte  Utilizzo di algoritmi di cifratura con vulnerabilità note (MD5, SHA-1, RC3, RC4, ecc…)  Utilizzo di chiavi salvate in maniera statica nel codice o in archivi non protetti VERIFICA DELLA SICUREZZA L’obiettivo e’ di verificare che l’applicazione utilizzi un’opportuna cifratura per salvare informazioni sensibili. Approccio automatici: i tool per la scansione di vulnerabilità non possono effettuare verifiche sulla cifratura dei dati salvati. Approccio manuale: come nel caso delle scansioni automatiche, la verifica di sicurezza tramite testing black-box non è possibile. La revisione del codice e’ la maniera migliore per verificare che un’applicazione utilizzi un’opportuna cifratura per dati sensibili ed implementi correttamente gli algoritmi e la gestione delle chiavi. In alcuni casi, questa attività può richiede l’analisi della configurazione di sistemi esterni. PROTEZIONE L’aspetto più importante è assicurarsi che ogni informazione che deve essere cifrata venga in effetti protetta. A corredo, è importante verificare che la specifica tecnologia crittografica sia opportunamente implementata. A cause delle innumerevoli possibilità di utilizzo improprio della crittografia, è opportuno considerare le successive raccomandazioni come parte dell’analisi per assicurare una gestione sicura della tecnologia crittografica: 37
  38. 38.  Non creare algoritmi di cifratura. Utilizzare solamente algoritmi pubblici approvati, come AES, la crittografia a chiave pubblica RSA, e SHA-256 o migliori per le operazioni di hashing  Non utilizzare algoritmi deboli, come MD5 / SHA1. Scegliere alternative più sicure come SHA-256 o migliori  Genera chiavi di cifratura online e salva le chiavi private con estrema cautela. Non trasmettere chiavi private tramite canali insicuri  Assicurati che le credenziali di accesso a sistemi, quali basi di dati e MQ siano adeguatamente protetti (tramite permessi stretti sul file system e ulteriori controlli), oppure siano cifrati in maniera sicura e non facilmente ottenibili da utenti locali o remoti  Assicurati che i dati salvati sul disco non siano facilmente decifrabili. Per esempio, la cifratura di un database è inutile se la connessione di accesso al database non cifrato risulta disponibile  Sotto PCI Data Security Standard requisito 3, è necessario proteggere i dati del titolare della carta. L’osservanza PCI DSS è obbligatoria dal 2008 per i commercianti e chiunque altro si occupi di carte di credito. Buona pratica è quella di memorizzare solamente i dati strettamente necessari, come la banda magnetica o il numero di conto (PAN, altrimenti noto come il numero di carta di credito). Se si memorizza il PAN, i requisiti DSS di conformità sono significativi. Ad esempio, non è mai permesso lasciare il numero CVV (il numero a tre cifre sul retro della carta) in qualsiasi circostanza. Per ulteriori informazioni, vedere il PCI DSS e gli orientamenti per l'attuazione dei controlli ESEMPI  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6145  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1664  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-1101 (valido per molti JAVA EE container) REFERENZE  CWE: CWE-311 (Failure to encrypt data), CWE-326 (Weak Encryption), CWE-321 (Use of hard-coded cryptographic key), CWE-325 (Missing Required Cryptographic Step) e altri  WASC Threat Classification  OWASP, http://www.owasp.org/index.php/Cryptography  OWASP Guide, http://www.owasp.org/index.php/Guide_to_Cryptography 38
  39. 39. OWASP Top 10 2007  OWASP, http://www.owasp.org/index.php/Insecure_Storage  OWASP, http://www.owasp.org/index.php/How_to_protect_sensitive_data_in_URL’s  PCI Data Security Standard v1.1, https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf  Bruce Schneier, http://www.schneier.com/  CryptoAPI Next Generation, http://msdn2.microsoft.com/en-us/library/aa376210.aspx 39
  40. 40. A9 – INSECURE COMMUNICATION Molto frequentemente le applicazioni non cifrano il traffico di rete in maniera da proteggere tutte le comunicazioni sensibili. La crittografia di canale (solitamente SSL) deve essere usata per tutti i collegamenti autenticati, in particolare su Internet, le pagine web accessibili, ma anche le connessioni di backend. Altrimenti, l'applicazione risulterà vulnerabile ad aggressori opportunamente posizionati, in quanto esporrà token di sessione e/o di autenticazione. Connessioni cifrate dovrebbero essere usate ogni volta che dati sensibili, quali la carta di credito o altre informazioni riservate, vengono trasmessi. In alcuni casi, gli aggressori forzano l’utilizzo di meccanismi insicuri di cifratura (tramite “downgrading”) nelle applicazioni. Lo standard PCI richiede che tutte le informazioni trasmesse su Internet e relative a carte di credito siano crittografate. SISTEMI AFFETTI Tutti i framework per applicazioni web sono vulnerabili all’utilizzo di trasmissioni non sicure VULNERABILITÀ La mancata cifratura in comunicazioni sensibili comporta la possibilità, per un aggressore in grado di catturare il traffico della rete (sniffing), di accedere alla conversazione e ad eventuali credenziali o informazioni sensibili trasmesse. A seconda delle tipologie, alcune reti sono più o meno suscettibili alle problematiche di sniffing. Inoltre è importante considerare il fatto che un aggressore potrebbe eventualmente compromettere un computer nella rete, risultando quindi in grado di installare rapidamente uno sniffer per catturare credenziali di altri sistemi. L’utilizzo di SSL per le comunicazioni con gli utenti finali è un aspetto critico, considerando che quest’ultimi accedono spesso alle applicazioni tramite reti insicure. Quando le comunicazioni HTTP includono credenziali di autenticazione o token di sessione in ogni singola richiesta, tutto il traffico autenticato deve essere incanalato tramite SSL. Tale meccanismo non deve essere applicato solamente per le richieste di login. Cifrare le comunicazioni da e verso i back-end server è altrettanto importante. Sebbene queste reti siano probabilmente più sicure, le informazioni che passano attraverso questi canali sono più sensibili ed estese. Per questa ragione, l’utilizzo di SSL sui back-end è un aspetto decisamente importante. Per molte organizzazioni, la cifratura di dati sensibili come carte di credito e numeri dell’assistenza sociale è diventata parte integrante di regolamentazioni finanziare o legate alla privacy. La negligenza nell’utilizzo di SSL per connessioni che trasportano tali informazioni comporta un rischio di compliance. VERIFICA DELLA SICUREZZA L’obiettivo della verifica di sicurezza consiste nell’accertarsi che l’applicazione utilizzi opportuna cifratura per tutte le comunicazioni sensibili ed autenticate. 40
  41. 41. OWASP Top 10 2007 Approccio automatico: i tool di scansione automatici possono verificare che SSL sia utilizzato per il front-end, ed eventualmente evidenziare relative problematiche. Purtroppo questi tool non hanno accesso alle connessioni di back-end e non sono quindi in grado di verificarne la loro sicurezza. I tool di analisi statica possono aiutare durante l’analisi delle comunicazioni verso i sistemi di back-end, sebbene non sono in grado di interpretare la logica funzionale richiesta per tutti i tipi di sistemi. Approccio manuale: sebbene il test manuale permetta di verificare puntualmente l’effettivo utilizzo di SSL, oltre ad evidenziare specifiche problematiche sul lato front-end, l’approccio automatico risulta probabilmente più efficiente. La revisione manuale del codice permette di verificare l’utilizzo corretto di connessioni SSL verso tutte le connessioni di back-end. PROTEZIONE La protezione più importante è rappresentata dall’utilizzo di SSL per ogni connessione autenticata, o in qualsiasi caso si trasmetta informazioni sensibili. Essendoci una serie di dettagli tecnici importanti da considerare durante la configurazione di SSL in ambito web, la comprensione e analisi dello specifico sistema è particolarmente importante. A titolo di esempio si pensi ad un noto browser: IE 7.0 fornisce un barra verde per evidenziare certificati SSL validi e fidati. Pur rappresentando un meccanismo di verifica efficace, questo controllo non fornisce alcuna indicazione sull’utilizzo sicuro della tecnologia di crittografia.  Utilizzare SSL per tutte le connessioni autenticate che trasmettono dati sensibili o di valore, come credenziali, dettagli relativi alle carte di credito, informazioni private o legate allo stato di salute  Assicurarsi che tutte le comunicazioni tra gli elementi infrastrutturali, come web server e database, siano propriamente protetti tramite l’uso di canali di trasmissione sicuri o cifratura a livello di protocollo per credenziali o altre informazioni  Sotto PCI Data Security Standard requisito 4, è necessario proteggere i dati in transito del titolare della carta. L’osservanza di PCI DSS è obbligatoria dal 2008 per i commercianti e chiunque altro si occupi di carte di credito. In generale, clienti, partner, il personale amministrativo e l'accesso online ai sistemi devono essere criptati utilizzando SSL o simili. Per ulteriori informazioni, vedere il PCI DSS e gli orientamenti per l'attuazione dei controlli. ESEMPI  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6430  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4704  http://www.schneier.com/blog/archives/2005/10/scandinavian_at_1.htm l REFERENZE  CWE: CWE-311 (Failure to encrypt data), CWE-326 (Weak Encryption), CWE-321 (Use of hard-coded cryptographic key), CWE-325 (Missing Required Cryptographic Step) e altri  WASC Threat Classification 41
  42. 42.  OWASP Testing Guide, Testing for SSL / TLS, https://www.owasp.org/index.php/Testing_for_SSL-TLS  OWASP Guide, http://www.owasp.org/index.php/Guide_to_Cryptography  Foundstone - SSL Digger, http://www.foundstone.com/index.htm? subnav=services/navigation.htm&subcontent=/services/overview_s3i_des.htm  NIST, SP 800-52 Guidelines for the selection and use of transport layer security (TLS) Implementations, http://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf  NIST SP 800-95 Guide to secure web services, http://csrc.nist.gov/publications/drafts.html#sp800-95 42
  43. 43. OWASP Top 10 2007 A10 – FAILURE TO RESTRICT URL ACCESS L’unica protezione per l’accesso ad un URL è frequentemente legato al fatto che il link non sia presente all’interno delle pagine mostrare ad utenti non autenticati. Dall’altro canto, un aggressore opportunamente motivato o fortunato potrebbe essere in grado di trovare e accedere a tali pagine, invocandone funzionalità e visualizzando dati. Il concetto di “security through obscurity” non è da considerarsi come una protezione sufficiente per l’accesso a funzioni o dati sensibili. Un meccanismo di controllo d’accesso deve essere effettuato prima di permettere qualsiasi richiesta verso funzioni sensibili, in maniera da assicurare che solo utenti autorizzati vi possano accedere. SISTEMI AFFETTI Tutti i framework per applicazioni web sono vulnerabili alle problematiche di “failure to restrict URL access” VULNERABILITÀ Il principale metodo di attacco per questa vulnerabilità è chiamato “forced browsing” e consiste nel tentativo di indovinare link nascosti e, tramite tecniche bruteforce, accedere a pagine non protette. Nelle applicazioni web, il codice relativo al controllo d’accesso tende ad evolvere e diffondersi in diversi componenti, risultando in un modello di sicurezza complesso che ne rende difficile la comprensione per sviluppatori ed esperti di sicurezza. La complessità aumenta la possibilità che errori di implementazione occorrano e, conseguentemente alcune pagine vengano lasciate esposte. Alcuni degli errori comuni riguardano:  URL “nascosti” or “speciali” visualizzabili solo ad amministratori o utenti privilegiati all’interno del layer di presentazione ma accessibili a tutti gli utenti che sono a conoscenza dello specifico link. A titolo di esempio, “/admin/adduser.php” e “approveTransfer.do” sono due risorse molto comuni. Questo tipo di problematica è particolarmente presente all’interno del codice utilizzato per sviluppare barre di menu.  Le applicazioni permettono spesso l’accesso a file “nascosti”, come file XML statici o report di sistema, affidandosi allla “security through obscurity”  La logica funzionale che controlla le policy di accesso risulta datata ed insufficiente. Immaginiamo che “approveTransfer.do” sia stato disponibile per tutti gli utenti in precedenti versioni dell’applicazione. A causa dell’introduzione di controlli SOX, questo script deve essere disponibile solamente ad utenti privilegiati. Una possibile (ed errata) modifica dell’applicazione potrebbe consistere nel nascondere tale link all’interno del menu applicativo senza effettivamente interrogare i meccanismi di controllo di accesso  Il codice che analizza i privilegi utente risiede sul lato client e non sul server, come accadde nel caso del MacWorld 2007, i cui pass “Platinum” del valore di 1700$ erano controllati tramite JavaScript sul lato browser invece che sul server 43
  44. 44. VERIFICA DELLA SICUREZZA La verifica deve consistere nell’accertarsi che i meccanismi di controllo d’accesso siano implementati correttamente, in maniera consistente tra layer di presentazione e business logic, per tutti gli URL dell’applicazione. Approccio automatico: sia i dispositivi di scansione di vulnerabilità che gli strumenti di analisi statica incontrano difficoltà con la verifica del controllo di accesso dell’URL per motivi differenti. I dispositivi di scansione di vulnerabilità hanno difficoltà a trovare le pagine nascoste affette da questa problematica e determinare quali pagine dovrebbero essere visibili ad ogni utente, mentre gli strumenti di analisi statica hanno difficoltà ad identificare i comandi di accesso e di collegare il livello di presentazione con la business logic. Approccio manuale: il metodo più efficiente e più corretto è di utilizzare una combinazione di revisione del codice e di test di sicurezza per verificare il meccanismo di controllo di accesso. Se il meccanismo è centralizzato, la verifica può essere abbastanza efficiente. Se il meccanismo si distribuisce attraverso tutto il codice applicativo, la verifica può richiede più tempo. Se il meccanismo è applicato esternamente, la configurazione deve essere esaminata e provata. PROTEZIONE La chiave nell’implementazione di un sistema di protezione contro l’accesso non autorizzato agli URL è un’attività dispendiosa in termini di tempo, poiché richiede la creazione di una matrice che riassumi tutti i ruoli e le funzioni usati all’interno dell’applicazione web. Le applicazioni web devono forzare il controllo d’accesso per ogni URL e logica di business. Non e’ sufficiente implementare un controllo d’accesso nel layer di presentazione, lasciando non protetta la logica di business. Inoltre non è sufficiente controllare una sola volta che l’utente sia autorizzato, ma il controllo deve essere effettuato per ogni richiesta successiva. Il rischio è che un eventuale aggressore potrebbe saltare alcuni passi di navigazione, in cui il controllo viene effettuato, ed accedere a pagine successive opportunamente forgiando alcuni parametri. Il controllo di accesso per gli URL richiedere una pianificazione attenta. Alcune importanti considerazioni sono:  Assicurarsi che la matrice del controllo di accesso sia parte della progettazione dell’applicazione, della sua architettura e della business logic  Assicurarsi che tutti gli URL e le funzioni della business logic siano protetti da un effettivo meccanismo di controllo di accesso che permetta di verificare il ruolo dell’utente e i suoi privilegi, ancora prima di qualsiasi operazione. Accertarsi che questo controllo venga effettuato per ogni singola operazione e non solamente all’inizio di ogni funzione  Effettuare un penetration test prima di rilasciare il codice in maniera da assicurarsi che l’applicazione non possa essere abusata da un aggressore sufficientemente motivato 44
  45. 45. OWASP Top 10 2007  Fare attenzione all’utilizzo di direttive “include” e librerie, specialmente nel caso di file con estensioni eseguibili come .php. Dove possibile, utilizzare componenti al di fuori della web root. Inoltre queste risorse devono essere verificate in maniera da assicurare che non sia possibile accederle direttamente e che, per esempio, non si possa controllare una specifica costante creata dall’applicazione  Non presumere che gli utenti non siano a conoscenza di URL speciali, nascosti o link a API. Assicurarsi sempre che tutte le funzioni di amministrazione o che richiedono alti privilegi siano protette  Bloccare l’accesso a tutti i file che l’applicazione non deve fornire. Idealmente, questo filtro dovrebbe essere implementato con la teoria dell’ “accetta solo il buono” e fornire solamente estensioni permesse (per esempio, .html, .pdf, .php). Questo permette di bloccare qualsiasi tentativo di accesso a file di log, file xml, ecc. che non devono essere fruiti dall’utente finale  Mantenere aggiornati, tramite patches e protezioni antivirus, tutti i componenti applicativi come processori XML, di testo, di immagini, ecc. i quali gestiscono dati forniti dall’utente ESEMPI  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0147  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0131  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1227 REFERENZE  CWE: CWE-325 (Direct Request), CWE-288 (Authentication Bypass by Alternate Path), CWE-285 (Missing or Inconsistent Access Control)  WASC Threat Classification, http://www.webappsec.org/projects/threat/classes/predictable_resource_location.shtml  OWASP, http://www.owasp.org/index.php/Forced_browsing  OWASP Guide, http://www.owasp.org/index.php/Guide_to_Authorization 45
  46. 46. OLTRE LA OWASP TOP TEN La OWASP Top 10 è solamente l’inizio del tuo viaggio verso la sicurezza delle applicazioni web. “I sei miliardi di persone nel mondo possono essere divise in due categorie: il primo gruppo è composto da chi è consapevole del perchè ottime aziende di software rilasciano prodotti con bug, mentre il secondo è composto da chi non è altrettanto consapevole. Quelli nel primo gruppo tendono a dimenticare la vita prima che il giovanile entusiasmo venisse spezzato dalla realtà. A volte capita di incontrare una persona appartenente al secondo gruppo...la quale è sconvolta dal fatto che ogni azienda di software rilasci un prodotto ancora prima che l’ultimo bug venga risolto.” Eric Sink, Guardian May 25, 2006 La maggior parte degli utenti appartiene al secondo gruppo. Il modo in cui viene gestito il problema rappresenta un’opportunità per migliorare il tuo codice ed in generale lo stato della sicurezza web. Miliardi di dollari vengono persi ogni anno e moltissime persone sono vittime di furti di identità e frodi online a causa delle vulnerabilità discusse in questo documento. PER GLI ARCHITETTI ED I PROGETTISTI DI SOFTWARE Per garantire l’appropriata sicurezza delle tue applicazioni devi conoscere quello che vuoi mettere in sicurezza (asset classification), conoscere le minacce ed i rischi derivanti dalla mancata sicurezza applicativa in maniera da indirizzare i tuoi sforzi. Progettare qualsiasi tipo di applicazione complessa richiede una buona dose di sicurezza.  Assicurati che venga applicata la filosofia del “tanto quanto basta” per la definizione dei rischi e la classificazione delle risorse. Sebbene le attuali leggi di conformità (SOX, HIPAA, Basel, ecc.) impongono delle sempre più maggiori pressioni verso le aziende, può essere appropriato investire molte più risorse e tempo rispetto a quanto richiesto dalle misure minime, in particolare se le linee guide sono note e notoriamente più rigide dei requisiti minimi.  Domanda quali sono i requisiti applicativi in termini di business, in particolare rispetto ai requisiti non funzionali  Lavora insieme al tuo cliente sulla OWASP Secure Software Contract Annex  Incoraggia l’adozione di pratiche di sicurezza progettuali – includendo le logiche di “difesa in profondità’” e alcuni semplici modelli utilizzati nell’analisi delle minacce (si faccia riferimento a [HOW1] all’interno dei riferimenti bibliografici.  Assicurati che vengano soddisfatti i requisiti di confidenzialità’, integrità’, disponibilità e non ripudio  Assicurati che i progetti siano consistenti rispetto alle security policy e agli standard come il COBIT e la PCI DSS 1.1 46

×