Bridging the Gap Between
Web Application Firewalls
and Web Applications
Seminario AVP 2007
docente A. Cortesi
A. Dal Pos - R. Marcon
Cosa vedremo
In teoria:




Introduzione
Background
Problematiche
Soluzione
In pratica:
 Soluzione proposta
 Implementazione prototipo
 Risultati e limiti
 Conclusioni
A. Dal Pos - R. Marcon
Introduzione (1)
 Sempre maggiore diffusione di web
application (e-commerce) ricche di bug.
 Introduzione dei Web Application Firewall.
 Problema: Loose Coupling tra la
configurazione del WAF e l’implementazione
dell’applicazione.
A. Dal Pos - R. Marcon
Introduzione (2)
 Obiettivo: garantire l’assenza di alcuni tipi di
comportamenti erronei tramite:
 Combinazione di verifica statica e dinamica
 Arricchimento della semantica dei contratti
 Come: costruzione di un prototipo che assicuri
che nessuna interazione c/s porti a interazioni
non volute con repository.
A. Dal Pos - R. Marcon
Background
A. Dal Pos - R. Marcon
Background – Web Application
 Applicazioni server-side invocate da un thin
client attraverso il protocollo http.
 Navigazione tramite link o URL, form.
 HTTP è un protocollo request/reply stateless,
a livello applicazione.
 Sessione utente: cookies, URL rewriting,
hidden field form.
A. Dal Pos - R. Marcon
Background – Servlet
 Servlet: forniscono meccanismi per estendere
le funzionalità di un web server.
 Container: gestisce le richieste e le processa
tramite le servlet.
 Filtri: utilizzati per processare le informazioni
contenute nelle richieste/risposte.
A. Dal Pos - R. Marcon
Background – Firewall & WAF
Firewall :
 Agisce a livello transport e network.
 Consente/nega l’accesso a risorse protette.
 Controlla a cosa si vuole accedere, ma non cosa si
vuole fare.
A. Dal Pos - R. Marcon
Background – Firewall & WAF
Web Application Firewall:
 Agiscono a livello applicazione
 Controllo degli accessi in tempo reale analizzando
URL richiesti, credenziali, parametri in input e la
history di sessione dell’utente.
A. Dal Pos - R. Marcon
WAF: Modelli di sicurezza
Negative Security Model
Concept
Advantages
Disadvantages
Positive Security Model
The WAF knows what traffic is an attack, and
allows any other traffic to go through
The WAF learns what traffic profile is legitimate,
and blocks anything else
 No need for customization
 Accurate detection
 Protection out-of-the-box
 Unknown attacks
 Simple, straight-forward
 Not dependant on updates
 Highly dependant on updates
 Need for learning process
 Not very accurate
 More prone to false positives
A. Dal Pos - R. Marcon
Il “nostro” WAF - Modello
Basato su
Modello di sicurezza positivo
Implementa lo
Strict Request Flow Enforcement:
monitorizza le singole sessioni utenti e tiene traccia
dei link già seguiti e che possono essere seguiti.
A. Dal Pos - R. Marcon
Il “nostro” WAF - Attacchi
Broken Access Control
scavalcando il controllo degli accessi è possibile accedere ad account di altri utenti,
visualizzare file sensibili ed utilizzare funzionalità non autorizzate.
Insecure ID, Path Traversal, Forceful Browsing, Client Side Caching.
Accedere direttamente a pagine web (URL), scavalcando il normale
flusso logico dell’applicazione, a cui non si potrebbe avere accesso.
Può portare ad accesso non autorizzato a risorse o comportamenti
non previsti dell’applicazione.
A. Dal Pos - R. Marcon
Problematiche:
A causa della configurazione euristica del WAF
si ha un accoppiamento lasco tra la sua configurazione
e l’implementazione dell’applicazione.
Non da garanzie verso alcuni tipi di bug implementativi.
Prototipo per garantire la
protezione attraverso verifica statica, dinamica e contratti.
A. Dal Pos - R. Marcon
Duke’s BookShop (1)
Type
String Identifier
Interaction
Conditional
A. Dal Pos - R. Marcon
Defensive
Duke’s BookShop (2)
Le interazioni con il repository della sessione condivisa impongono
delle restrizioni sul protocollo di interazione c/s.
Inizio sessione da un path diverso da /bookstore
OrderFilter chiamato prima che i valori di cart e currency siano
memorizzati nello shared repository.
NullPointerException:
Comportamento non previsto dell’applicazione
Perdita di informazioni dovuta a una scorretta gestione degli errori
Perdita dell’integrità dei dati, dovuta al salvataggio di stringhe nulle nel DB
Non esecuzione del codice di clean-up
A. Dal Pos - R. Marcon
Precondizioni (1)
 ESC/Java2
tool di analisi statica, supporta il design by
contract, utilizza il Theorem Proving
Dal codice sorgente + JML genera un set di predicati da
verificare
Predicati + modello logico elaborati per verificare
l’assenza di errori
I bug vengono segnalati all’utente
A. Dal Pos - R. Marcon
Precondizioni (2)
JML
linguaggio di specifica di programmi java. Utilizza
pre e post-condizioni ed invarianti
Sintassi: //@ <JML specification> oppure /*@ <JML specification> @*/
Keyword:
• Requires: definisce una precondizione sul metodo che segue
• Ensures: definisce una postcondizione sul metodo che segue
• Also: dichiara che il metodo eredita le condizioni dal supertipo
A. Dal Pos - R. Marcon
Soluzione proposta
A. Dal Pos - R. Marcon
Verifiche statiche e dinamiche
Verifiche statiche e dinamiche per garantire che l’interazione c/s
non porti alla violazione di alcune proprietà
Le interazioni con il repository
vengono specificate nel
componente attraverso un
contratto, per poi essere validate.
La verifica statica assicura che
il protocollo client/server
soddisfi le condizioni sul
repository.
A. Dal Pos - R. Marcon
Le politiche sono utilizzate a
runtime per garantire che solo le
richieste web che rispettano il
WAF, possano essere
processate
Specifica della verifica server side
Ogni componente viene estesa da uno specifico
contratto.
A. Dal Pos - R. Marcon
Verifica del protocollo applicazione
Specifica della politica di rinforzo del WAF
Espressione
regolare EBNF
Specifica di
un automa
A. Dal Pos - R. Marcon
Implementazione a runtime
 Per rendere operativo il protocollo di client/server
verificato, esso viene caricato (“installato”) nel WAF
A. Dal Pos - R. Marcon
Implementazione prototipo
A. Dal Pos - R. Marcon
Specifica e verifica server side
 Vogliamo implementare le assunzioni proposte al fine di
creare un prototipo, basato su DukesBook
 Specifichiamo per ogni metodo sottoposto a verifica, le
interazioni permesse, utilizzando un contratto
A. Dal Pos - R. Marcon
Verifica protocollo con check
 Per verificare staticamente che ogni interazione
client/server non violi le proprietà desiderate, viene
generato un check a partire dalla specifica del protocollo
La verifica del protocollo è ridotta alla verifica
statica del metodo check con ESC
A. Dal Pos - R. Marcon
Verifica protocollo/1
A. Dal Pos - R. Marcon
Implementazione a runtime
Caricamento specifiche nella web-app
Violazione protocollo
Blocco IP
A. Dal Pos - R. Marcon
Invalidamento
sessione
Risultati
A. Dal Pos - R. Marcon
 Overhead statico
Performance
Quantificato in base alle codeline
aggiunte. Nel prototipo al più 4
per le interazioni con il
repository.
Verifica del protocollo in
11 sec.
 Overhead a runtime
Applicazione eseguita con e senza filtro, 1000 visitatori con max
overhead di 1,3%
A. Dal Pos - R. Marcon
Limiti
Scopo: ridurre la complessità
Processo sequenziale
Assumiamo che le richieste in una
sessione web vengano
processate sequenzialmente
Aspetti di contorno
Invece di lasciare ad ESC/Java2 il
compito di verificare tutte le clausole
modifies, limitiamo la verifica alle sole
A. Dal Pos - R. Marcon
clausole realmente modificate
Limiti - Aspetti di contorno
A. Dal Pos - R. Marcon
Conclusioni
Il WAF garantisce attraverso una combinazione di verifiche
statiche e dinamiche, l’assenza di certi tipi di
errore nelle applicazioni
Soluzione accettabile in relazione alle performance del prototipo
La verifica proposta è limitata ad un certo tipo di errori, è possibile
estendere ragionevolmente la soluzione
anche ad altri tipi di attacchi?
A. Dal Pos - R. Marcon
Bibliografia








[1] OWASP Web Application Security Top Ten List
http://www.clusit.it/whitepapers/OWASPTopTen2004-ITA.pdf
[2] Web Application Firewall – Owasp
http://www.owasp.org/index.php/Web_Application_Firewall
[3] WAF Evaluation Criteria
http://www.webappsec.org/projects/wafec/
[4] The Ten Most Common Application-Level Hacker Attacks
http://whitepapers.techrepublic.com.com/whitepaper.aspx?docid=31824
[5] WAFEC, or how to choose WAF technology
http://www.webappsec.org/projects/wafec/WAFEC-by-Rafael_San_Miguel_Carrasco.ppt
[6] Why Firewalls Fail To Protect Web Sites
http://www.lockstep.com/webagain/why-firewalls-fail.pdf
[7] The Essentials of Filters, SUN,
http://java.sun.com/products/servlet/Filters.html
[8] BNF and EBNF, Lars Marius Garshol, 2003,
http://www.garshol.priv.no/download/text/bnf.html
A. Dal Pos - R. Marcon