OWASP TOP 10

LE DIECI VULNERABILITÀ PIÙCRITICHE NELLE APPLICAZIONI WEB

EDIZIONE 2007

© 2002-2007 OWASP FoundationQuesto documento è distribuito con licenza Creative Commons Attribution-ShareAlike 2.5

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

Riferimenti ............................................................................................................................ 50

2

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

• 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

OWASP Top 10 2007

SOMMARIOA1 – 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

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

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

http://www.owasp.org/index.php/Testing_for_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

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

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 2006Raw 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 (aggiunta)

Discussa in A10. Insecure Configuration Management

8

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

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

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

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

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

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

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

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.shtmlhttp://www.webappsec.org/projects/threat/classes/sql_injection.shtmlhttp://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

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

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

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

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

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_Security_Policy

22

OWASP Top 10 2007

Microsoft - Programming for Partial Trust, http://msdn2.microsoft.com/en-us/library/ms364059(VS.80).aspx

23

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

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

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.shtmlhttp://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

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

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

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

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

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 λ’individuazione della natura applicativa dell’errore può essere un’impresa ardua.

31

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

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

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 – InsecureCommunication), successivamente occorre verificare che tutte le credenziali vengano memorizzate utilizzando opportune funzioni di hash o di crifratura (si veda A8 – InsecureCryptographic 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

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

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.shtmlhttp://www.webappsec.org/projects/threat/classes/credential_session_prediction.shtmlhttp://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

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

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

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

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

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.html

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

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

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

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

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

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

OWASP Top 10 2007

PER GLI SVILUPPATORI

Molti sviluppatori conoscono già le pratiche base della sicurezza in ambito web. In ogni caso, per padroneggiare questo argomento e’ necessario avere un’esperienza pratica estensiva. Chiunque può’ provare a “rompere” un’applicazione (per esempio tramite un penetration test); queste pratiche aiutano a comprendere come costruire software sicuro con l’obiettivo di avere completa competenza sull’argomento.

Considera la possibilità di unirti ai progetti OWASP oppure partecipare agli incontri del tuo capitolo locale

Chiedi di poter partecipare ad un training sul secure coding se hai a disposizione un budget per la formazione. Richiedi un budget per la formazione, se non lo hai!

Sviluppa le caratteristiche del tuo software in maniera sicura – adotta un approccio di “difesa in profondità’” e prediligi soluzioni semplici

Adotta gli standard per la scrittura del codice i quali incoraggiano l’uso di costrutti sicuri

Ritocca la base di codice esistente in maniera da utilizzare tutti i meccanismi di sicurezza all’interno della piattaforma scelta, con l’uso di query parametrizzate

Rivedi la OWASP Guide ed inizia ad applicare controlli scelti al tuo codice. A differenza di molte guide sulla sicurezza applicativa, la OWASP Guide aiuta nello sviluppo di software sicuro piuttosto che illustrare le tecniche di attacco.

Effettua test sul tuo codice per ricercare eventuali problematiche e fai diventare questa attività una pratica regolare nella fase di testing e debug.

Considera i testi suggeriti nella bibliografia, se c'è’ qualche riferimento utile rispetto al tuo contesto di sviluppo.

PER I PROGETTI OPEN SOURCE

L’Open Source rappresenta una sfida particolare per la sicurezza applicativa nel web. Ci sono milioni di persone impegnate in progetti Open Source: da progetti personali sviluppati da singoli sino a progetti più grandi come Apache, Tomcat e complesse applicazioni web come PostNuke.

Considera la possibilità’ di unirti ai progetti OWASP oppure partecipare agli incontri del tuo capitolo locale

Se il tuo progetto ha più di quattro sviluppatori, considera la possibilità di formare una persona e renderla esperta di sicurezza

Sviluppa le caratteristiche del tuo software in maniera sicura – adotta un approccio di “difesa in profondità” e prediligi soluzioni semplici

47

Adotta gli standard di scrittura del codice i quali incoraggiano l’uso di costrutti sicuri

Adotta la pratica nota con il nome di “responsible disclosure policy” per assicurare che le vulnerabilità software siano gestite opportunamente.

Considera i testi suggeriti nella bibliografia, se c'è’ qualche riferimento utile rispetto al tuo contesto di sviluppo.

PER I PROJECT MANAGER

I responsabili dell’applicazione devono spesso fronteggiare i vincoli imposti dalle risorse limitate e dal tempo disponibile, specialmente nel caso di applicazioni commerciali.

I responsabili devono:

Lavorare insieme ai produttori di software sulla OWASP Secure Software Contract Annex

Assicurarsi che nei requisiti di business siano contemplate le caratteristiche non funzionali (NFRs) come i requisiti di sicurezza

Incoraggiare l’uso di pratiche progettuali sicure che includino l’uso di meccanismi di sicurezza “by default”- un approccio di “difesa in profondità” e soluzioni semplici

Assumere o formare sviluppatori con provate competenze nella sicurezza

Effettuare test per identificare eventuali problematiche attraverso tutte le fasi del ciclo di vita del software: dal progetto, allo sviluppo, test e messa in opera.

Allocare le opportune risorse, sufficiente budget e tempo all’interno del progetto per poter risolvere potenziali problemi di sicurezza

PER I DIRIGENTI

La tua organizzazione deve seguire un ciclo di sviluppo del software (SDLC) sicuro in tutte le fasi, che si adatti alle necessità della tua organizzazione. La risoluzione di eventuali vulnerabilità è meno costosa durante lo sviluppo del software stesso, rispetto al costo necessario una volta che il software e’ distribuito. Un SDLC razionale include differenti aspetti, oltre a quelli indicati nella Top 10:

Per software sviluppato da terzi, assicurare l’adozione di policy di sicurezza e stipulare contratti che comprendano clausole inerenti alla sicurezza

Per software sviluppato in proprio, adottare tutti i principi di programmazione sicura all’interno delle tue linee guida

Fornisci l’adeguata formazione ai tuoi sviluppatori rispetto alle problematiche di sicurezza e assicurati che siano costantemente aggiornati

48

OWASP Top 10 2007

All’interno del budget, includi l’acquisito di software per l’analisi del codice rispetto alle problematiche di sicurezza

Informa i produttori di software dell’importanza cruciale della sicurezza nel tuo business

Fornisci l’adeguata formazione di base ai tuoi ingegneri, progettisti e alle altre persone responsabili dei progetti

Considera la consulenza di auditor terze parti, che possa fornirti una valutazione indipendente del tuo software

Adotta la pratica nota con il nome di “responsible disclosure policy” e definisci un processo formale per gestire eventuali segnalazioni di vulnerabilità’ nei tuoi prodotti

49

RIFERIMENTI

PROGETTI OWASP

OWASP rappresenta il principale sito di riferimento per la sicurezza in ambito web.

Il sito OWASP ospita molti progetti, forum, blog, presentazioni, strumenti, e documentazione. OWASP supporta ogni anno due delle maggiori conferenze inerenti alla web application security e ha oltre 80 capitoli locali.

I seguenti progetti di OWASP sono probabilmente i più utili:

OWASP Guide to Building Secure Web Applications OWASP Testing Guide OWASP Code Review Project (in corso di sviluppo) OWASP PHP Project (in corso di sviluppo) OWASP Java Project OWASP .NET Project

LIBRI

Per ovvie ragioni, questa lista non è esaustiva. Utilizza questi riferimenti per trovare la sezione appropriata all’interno della libreria più vicina a te, e recuperare alcuni titoli (includendo potenzialmente uno o più dei seguenti):

[ALS1] Alshanetsky, I. “php|architect’s Guide to PHP Security”, ISBN 0973862106

[BAI1] Baier, D., “Developing more secure ASP.NET 2.0 Applications”, ISBN 978-0-7356-2331-6

[GAL1] Gallagher T., Landauer L., Jeffries B., “Hunting Security Bugs”, Microsoft Press, ISBN 073562187X

[GRO1] Fogie, Grossman, Hansen, Rager, “Cross Site Scripting Attacks: XSS Exploits and Defense”, ISBN 1597491543

[HOW1] Howard M., Lipner S., “The Security Development Lifecycle”, Microsoft Press, ISBN 0735622140

[SCH1] Schneier B., “Practical Cryptography”, Wiley, ISBN 047122894X

[SHI1] Shiflett, C., “Essential PHP Security”, ISBN 059600656X

[WYS1] Wysopal et al, The Art of Software Security Testing: Identifying Software Security Flaws, ISBN 0321304861

SITI WEB

OWASP, http://www.owasp.org

50

OWASP Top 10 2007

MITRE, Common Weakness Enumeration – Vulnerability Trends, http://cwe.mitre.org/documents/vuln-trends.html

Web Application Security Consortium, http://www.webappsec.org/

SANS Top 20, http://www.sans.org/top20/

PCI Security Standards Council, organismo responsabile per lo standard PCI, rilevante per tutte le organizzazioni che processano o gestiscono dati legati alle carte di credito, https://www.pcisecuritystandards.org/

PCI DSS v1.1, https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf

Build Security In, US CERT, https://buildsecurityin.us-cert.gov/daisy/bsi/home.html

51