1. The OWASP Foundation
http://www.owasp.org
Les 5 risques les plus critiques
des applications Web
Journée de la Sécurité Informatique – FST Tanger
2ème édition, 28 mai 2011
Yasser ABOUKIR
OWASP WebGoat Project Contributor
yaboukir@gmail.com

2. The OWASP Foundation
http://www.owasp.org
Plan
1) OWASP, késako?
2) Les 5 risques les plus critiques des applications Web
3) WebGoat Project
4) Nouveaux vecteurs d’attaque
| 2

3. The OWASP Foundation
http://www.owasp.org
1) OWASP, késako?
2) Les 5 risques les plus critiques des applications Web
3) WebGoat Project
4) Nouveaux vecteurs d’attaque
| 3

4. OWASP World
OWASP is a worldwide free and Everyone is free to participate in
open community focused on OWASP and all of our materials
improving the security of are available under a free and
application software. open software license.
Our mission is to make The OWASP Foundation is a
application security visible so 501c3 not-for-profit charitable
that people and organizations organization that ensures the
can make informed decisions ongoing availability and support
about application security risks. for our work.

5. OWASP
• OWASP : Open Web Application Security Project
• Indépendant des fournisseurs et des
gouvernements.
• Objectif principal : produire des outils, documents
et standards dédiés à la sécurité des applications
Web.
• Toutes les documentations, standards, outils sont
fournis sous le modèle de l‟open-source.
• Organisation :
• Réunion d‟experts indépendants en sécurité informatique
• Communauté mondiale (plus de 100 chapitres) réunie en une
fondation américaine pour supporter son action. L‟adhésion est
gratuite et ouverte à tous.
• Le point d‟entrée est le wiki http://www.owasp.org

6. Organisation de l‟OWASP
OWASP
OWASP
Conferences
OWASP Governance
OWASP
Wiki
OWASP
Tools
OWASP Chapter OWASP Foundation
(501c3)
Leaders
OWASP
Lists
Board of
Directors Board of Operations Technical
OWASP Books (Williams, Wichers, Advisors Director (McNamee) Director (Casey)
OWASP Project Brennan, Cruz, and
Leaders Deleersnyder)
OWASP
Community

7. Finances and Grants
OWASP Grants
100%
55%
OWASP Foundation
45%
7

8. L‟OWASP
 420 000 pages vues par mois
 15 000 téléchargements par mois
 11 335 membres sur les listes
 3 687 utilisateurs du Wiki
 1 500 MAJ du Wiki par mois
 110 chapitres mondiaux
 100 membres individuels
 48 outils/projets/documents
 38 membres entreprise
 25 projets fondés et soutenus dans
la communauté
 1 employé

9. OWASP KnowledgeBase
• 3,913 total articles
• 427 presentations
• 200 updates per day
• 179 mailing lists
• 180 blogs monitored
• 31 doc projects
• 19 deface attempts
• 12 grants

10. OWASP Tools and Technology
• Vulnerability • Penetration • ESAPI
Scanners Testing Tools
• Static Analysis • Code Review
Tools Tools
• Fuzzing
Automated Manual
Security
Security Security
Architecture
Verification Verification
• AppSec Libraries • Reporting Tools • Flawed Apps
• ESAPI Reference • Learning
Implementation Environments
• Guards and • Live CD
Filters • SiteGenerator
Secure AppSec AppSec
Coding Management Education
10

11. Les publications
Toutes les publications sont disponibles sur le site
de l‟OWASP: http://www.owasp.org
L‟ensemble des documents est régi par la licence
GFDL (GNU Free Documentation License)
Les documents sont issus de différentes
collaborations :
• Projets universitaires
• Recherche & développements des membres

12. Les publications majeures
• Le TOP 10 des vulnérabilités applicatives
• Le guide de conception d‟applications Web
sécurisées
• Le FAQ de la sécurité des applications
• Le guide « les 10 commandements sur
l‟écriture d‟une application non sécurisée »

13. Les Guides
100% Libres!
Issus de l‟expérience de milliers d’experts à travers le
monde
OWASP guide:
• Un ouvrage pour la création d‟applications Web sécurisées à l‟intention
des :
 Développeurs
 Architectes
 …
• Inclus les meilleurs pratiques dans différents langages
(PHP, Java, .Net, …)
• Plusieurs centaines de pages
OWASP Testing guide:
• Ouvrage dédié à l‟audit sécurité des applications Web à l‟intention des
pen-testeurs principalement.

14. OWASP Enterprise Security API (ESAPI)
• Un framework de sécurité pour
les développeurs
• Permettre de créer une
application Web Sécurisée
 Classes Java
 Disponible sur le site de l‟OWASP
 En cours de portage pour le SoC
2008 sur .NET et PHP

15. WebGoat - WebScarab
 WebGoat :
• Application Java serveur (JSP, JEEE) non sécurisé.
• Sert à démontrer les failles, leur principe et à éduquer.
 WebScarab :
• Application Java permettant d‟effectuer des tests de sécurité:
• Sur les applications Web
• Sur les WebServices

16. Quelques outils
 Outil de génération de données aléatoires
(Fuzzer) permettant d‟injecter des données
pour les tests
• JBroFuzz :
Fuzzer destiné à tester les applications Web
• WS Fuzz :
Fuzzer destiné à tester les WebServices.
 Sprajax
Outil destiné a tester la sécurité des applications AJAX
Et bien d‟autres :
 http://www.owasp.org/index.php/Category:OWASP_Project

17. Le Top 10
 Liste les 10 vulnérabilités des applications Web les plus
rencontrées
 Mis à jour tous les ans
 D‟importantes organisations l‟ont adoptées dans leurs référentiels
 Federal Trade Commission (US Gov)
 US Defense Information Systems Agency
 VISA (Cardholder Information Security Program) – PCI/DSS
 Le NIST
 Des opérateurs Télécoms

18. Quels sont les changements ?
On parle de risques, et non plus uniquement de vulnérabilités.
• Le titre devient donc : “ Les 10 risques les plus critiques des applications Web”.
La méthodologie de calcul du risque de l’OWASP Top 10
• Basée sur la méthodologie OWASP Risk Rating Methodology
2 éléments ajoutés, 2 retirés
• Ajout: A6 – Mauvaise configuration
• Ex-A10 du Top10 2004 : Configuration non sécurisée
• Ajout: A8 – Redirections
• Très courant et très dangereux, et mal considéré
• Retiré: A3 – Execution de fichier malveillant
• Principalement une faille PHP…
• Retiré: A6 –Mauvaise gestion des erreurs et fuite d’informations
• Une faille très courante, ne générant que rarement un risque

19. Mapping Top10 2007 - Top 10 2010
OWASP Top 10 – 2007 (Previous) OWASP Top 10 – 2010 (New)
A2 – Injection Flaws A1 – Injection
A1 – Cross Site Scripting (XSS) A2 – Cross Site Scripting (XSS)
A7 – Broken Authentication and Session Management A3 – Broken Authentication and Session Management
=
A4 – Insecure Direct Object Reference A4 – Insecure Direct Object References
=
A5 – Cross Site Request Forgery (CSRF) A5 – Cross Site Request Forgery (CSRF)
<was T10 2004 A10 – Insecure Configuration
+
A6 – Security Misconfiguration (NEW)
Management>
A10 – Failure to Restrict URL Access A7 – Failure to Restrict URL Access
<not in T10 2007>
+ A8 – Unvalidated Redirects and Forwards (NEW)
A8 – Insecure Cryptographic Storage A9 – Insecure Cryptographic Storage
A9 – Insecure Communications A10 – Insufficient Transport Layer Protection
A3 – Malicious File Execution - <dropped from T10 2010>
A6 – Information Leakage and Improper Error Handling - <dropped from T10 2010>

20. Méthode d‟évaluation du risque de l‟OWASP Top 10
Exemple basé sur XSS
Threat Attack Weakness Weakness Business
Technical Impact
Agent Vector Prevalence Detectability Impact
1 Easy Widespread Easy Severe
? 2 Average Common Average Moderate ?
Difficult Uncommon Difficult Minor
3
2 1 1 2
1.3 * 2
2.6 Evaluation pondérée du risque

21. L‟OWASP Top10 (2010 rc1)
http://www.owasp.org/index.php/Top_10

22. 1) OWASP, késako?
2) Les 5 risques les plus critiques des applications Web
3) WebGoat Project
4) Nouveaux vecteurs d’attaque
|22

23. Environnement typique de l‟entreprise
23

24. A1 – Injection
L‟injection
• Envoyer à une application des données générant un comportement non attendu.
Les Interpréteurs
• Utilisent les chaines et les interprètent comme des commandes
• SQL, OS Shell, LDAP, XPath, Hibernate, etc…
L‟injection SQL est toujours commune
• Enormément d‟applications y sont sensibles
• Même s‟il est très simple de s‟en affranchir….
Impact
• Souvent très sévère. Le plupart du temps l‟ensemble des données de la base sont
lisibles ou modifiables.
• Cela peut même aller jusqu‟au schéma de la base, les comptes ou un accès OS….

25. Exemple sur l‟injection SQL
Account Summary
Account:
"SELECT * FROM
Knowledge Mgmt
Communication
Legacy Systems
Bus. Functions
Administration
Human Resrcs
E-Commerce
Application Layer
Transactions
Web Services
SKU:
Directories
Databases
HTTP
Accounts
Acct:5424-6066-2134-4334
accounts WHERE
Finance
DB Table
Billing
HTTP response SQL  Acct:4128-7574-3921-0192
request  query acct=‘’ OR 1=1 --’"
Acct:5424-9383-2039-4029
APPLICATION

ATTACK
   Acct:4128-0004-1234-0293
Custom Code
1. L’application fourni un
formulaire
2. L’attaquant envoi son attaque
dans les données du formulaire
App Server
3.L’application transfère les
Web Server
données à la requête SQL
Hardened OS
Network Layer
4. Le SGBD lance la requête
contenant l’attaque et renvoie
les résultats à l’application.
Firewall
Firewall
5. L’application renvoie ce
résultat à l’utilisateur

26. A1 – Comment se protéger
Recommandations
1. Se passer des interpréteurs,
2. Utiliser une interface permettant de préparer les requêtes (ex,
prepared statements, or les procédures stockées),
3. Encoder toutes les données fournies par l‟utilisateur avant de les
passer à l‟interpréteur
• Toujours effectuer une validation de type “white liste” sur les données
utilisateurs.
• Minimiser les privilèges dans les bases pour limiter l‟impact de la faille.
References
• Plus de détails sur
http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

27. A2 – Cross-Site Scripting (XSS)
Se retrouve à chaque audit/pentest
• Des données venant d‟un attaquant sont envoyées à l‟innocent navigateur d‟un utilisateur
Ces données peuvent être
• Stockées en base,
• Réfléchies depuis une entrée d‟une page Web (champ de formulaire, champ caché, URL,
…)
• Envoyées directement à un client Riche (Javascript, Flash, …)
Virtuellement toute application Web est vulnérable
• Essayez cela dans votre navigateur – javascript:alert(document.cookie)
Impact
• Vol des sessions utilisateur, de données sensibles, réécriture de la page Web, redirection
vers un site d‟hameçonnage ou autre code malveillant
• De manière plus grave : installation d‟un proxy XSS permettant à un attaquant d‟observer
le poste client voire de forcer l‟utilisateur vers un site particulier

28. Cross-Site Scripting Illustré
L’attaquant découvre le script vulnérable
1
Application
disposant de faille
L’attaquant entre un script XSS
malicieux sur la page
web(stocké) ou bien
utilise un lien(réfléchi)
Knowledge Mgmt
Communication
permettant d’envoyer vers
Bus. Functions
Administration
E-Commerce
Transactions
Accounts
Finance
la page
La victime se rend sur la page
2
Custom Code
Le Script s’execute sur
le navigateur de la
victime sans qu’il ne le
sache
3 L’attaquant reçoit le cookie ou autre élément
directement

29. Vérification des données usager (Input validation)
 Cross site scripting (XSS) non persistent
Client légitime
Search results for
Gagner de l’argent
Gagner de l’argent:
Comment gagner de l'argent facile et des
Search cadeaux sur internet…
L' objectif du blog est de présenter toutes
les idées qui permettent d' économiser …
Server Web <html>
<head></head>
<body>
<h1>Search results for Gagner de l’argent :</h1>
<itemize>
<item>Comment gagner deacile et des cadeaux sur
internet…</item>
<item>L' objectif du blog est de présenter
toutes les idées qui permettent d' économiser …</item>
extract($_POST);
</itemize>
</body>
$req = "select * from POSTS
</html>
where title = '$stitle'

30. Vérification des données usage (Input validation)
 Cross site scripting (XSS) non persistent
Search results for
<u>Super</u>
Super:
Client malicieux
Search
No results found
Server Web <html>
<head></head>
<body>
<h1>Search results for <u>Super</u> :</h1>
No results found
</itemize>
</body>
extract($_POST); </html>
$req = "select * from POSTS
where title = '$stitle'

31. Vérification des données usager (Input validation)
 Cross site scripting (XSS) persistent
Server BD
Client malicieux
Post id message
1 Hello
2 Bien fait ...
3 <script
type="text/javascript
">document.location.
href=“http://evil.com
"</script>
<script type="text/javascript">document.location.href=“http://evil.com"</script>
Your message has been posted

32. Vérification des données usager (Input validation)
 Cross site scripting (XSS) Server BD
Client légitime
id message
Guestbook messages: 1 Hello
Hello
Bien fait ... 2 Bien fait ...
3 <script
<h1>Guestbook messages:</h1> type="text/javascript">d
Hello<br>
Bien fait<br> ocument.location.href=“
<script http://evil.com"</script>
type="text/javascript">document.location.hr
ef=“http://evil.com"</script><br>
...
32

33. A2 – Contre mesures
Recommandations
• Supprimer la faille 
• Ne pas inclure de contenu fourni par l‟utilisateur dans la page de sortie !!!
• Défenses possibles
1. Encoder toutes les entrées et sorties utilisateurs (utilisez l‟OWASP ESAPI pour l‟encodage
de sortie) http://www.owasp.org/index.php/ESAPI
2. Effectuer de la validation de type « white liste » pour les données utilisateurs entrantes
qui sont inclues dans une page.
3. Pour des grosses portions de code HTML fourni par un utilisateur, utiliser le filtre OWASP
Anti-Sammy de manière à nettoyer l‟HTML
Voir: http://www.owasp.org/index.php/AntiSamy
Référence
• Pour effectuer un encodage propre, se référer à http://www.owasp.org/index.php/XSS_(Cross Site
Scripting) Prevention Cheat Sheet

34. A3 – Mauvaise gestion des sessions et de l‟authentification
HTTP est un protocole sans état
• Les identifiants doivent donc être passés à chaque requête.
• Il faut utiliser SSL pour toute authentification
Failles dans la gestion de l‟authentification
• Des ID de sessions sont utilisés pour maintenir la session dans HTTP car il ne le
peut lui.
• Cela suffit à un attaquant, c‟est aussi intéressant qu‟un identifiant
• Les ID de sessions sont souvent exposés dans les sessions réseau, dans les
browsers (cookies), dans les logs, ….
Attention aux portes dérobées…
• Changement de mot de passe, se souvenir de mon passe, oubli de mot de
passe, questions secrètes, logout, email, …
Impact
• Vol de session ou compromission de comptes utilisateur

35. Illustration d‟une mauvaise authentification
1 Utilisateur envoie ses
Communication
Bus. Functions
Administration
Transactions
E-Commerce
Knowledge
identifiants
Accounts
Finance
Mgmt
www.test.com?JSESSIONID=9FA1DB9EA...
Le site récrit l’URL
Custom Code
(i.e., mise dans l’URL de 2
l’ID de session)
3 L’utilisateur clique sur un lien vers
http://www.cracker.com dans un forum
L’attaquant regarde les logs “Referer” sur
www.cracker.com 4
Et découvre le JSESSIONID
5 L’attaquant peut utiliser
le JSESSIONID sur le site
boi.com pour son méfait

36. A3 – Contre Mesure
Vérifier l‟architecture !
• L‟authentification doit être simple, centralisée et standardisée
• Utiliser le mécanisme standard de gestion des cookies du framework (ils sont globalement
fiables)
• Utiliser constamment SSL pour protéger les identifiants de connexion et de sessions
Vérifier l‟implémentation
• Oublier l‟analyse automatique
• Vérifier le certificat SSL (SSLv2, renégociation, chiffrement faible, …)
• Examiner toutes les fonctions relatives à l‟authentification
• Vérifier que la déconnexion supprime bien la session !
• Utiliser l‟OWASP WebScarab pour tester l‟implémentation (sessionID analysis)

37. A4 – Référence directe non sécurisée à un objet
Comment accéder aux données privées
• C‟est une manière de renforcer les habilitations en lien avec
A7 – Mauvaise restriction d‟accès à une URL
Des erreurs classiques
• Attendre uniquement de l‟utilisateur des accès à des objets autorisés ou
• Cacher des références à des objets dans des champs cachés
• … et ne pas renforcer les restrictions coté serveur.
• Ceci n‟est qu‟une tentative de contrôle d‟accès sur la présentation et ne
fonctionne pas !
• Un attaquant n‟a qu‟à modifier les valeurs des paramètres…
Impact
• Un utilisateur a accès à des données ou des fichiers normalement
interdits

38. Référence directe non sécurisée à un objet illustrée
https://www.banque.com L‟attaquant note le
/user?acct=6065 paramètre acct =
6065
?acct=6065
de la manière suivante
?acct=6066
L‟attaquant visualise un
autre compte.

39. A4 – Contre Mesure
Eliminer la référence directe.
• La remplacer par une valeur temporaire aléatoire (e.g. 1, 2, 3)
• L‟ESAPI fournit des fonctions pour cela
• IntegerAccessReferenceMap & RandomAccessReferenceMa
http://app?file=Report123.xls Report123.xls
Access
http://app?file=1 Reference
http://app?id=9182374 Map
Acct:9182374
http://app?id=7d3J93
Valider la référence directe à l‟objet
• Vérifier que le contenu est correctement formaté.
• Vérifier que l‟utilisateur a le droit d‟effctuer l‟accès à l‟objet.
• Vérifier que le mode d‟accès à l‟objet est autorisé (e.g., read, write, delete)

40. A5 – Cross Site Request Forgery (CSRF)
Cross Site Request Forgery
• C‟est une attaque ou le navigateur de la victime génère une requête vers une
application Web vulnérable
• Cette vulnérabilité est causée par la capacité que les navigateurs ont d‟ envoyer
automatiquement des données d‟authentification (session ID, IP adresse,
comptes de domaine Windows, ..) dans chaque requête.
Imaginez
• Que se passerait-il si un attaquant pouvait utiliser votre souris pour effectuer des
clicks sur votre site de banque en ligne à votre place.
• Que pourrait-il faire ?
Impact
• Initiation de transactions (transfert de fonds, logoff, modification de données, …)
• Accès à des données sensibles
• Changement des mots de passes/identifiants

41. CSRF démystifié
Le problème
• Les navigateurs Web incluent automatiquement la plupart des
identifiants dans chaque requête.
• Que cela soit des requêtes venant d‟un formulaire, d‟une image ou d‟un
autre site.
Tous les sites basés uniquement sur les identifiants
automatiques sont vulnérables
• Approximativement 100% des sites le sont…
C‟est quoi un identifiant automatique?
• Cookie de session
• Une entête d‟authentification HTTP
• Une adresse IP
• Les certificats SSL client
• L‟authentification de domaine Windows.

42. Cross-Site Request Forgery
 Utilisation normale (1/2)
Client légitime GET index.php Server Web
www.exemple.co
m
POST login.php

43. Cross-Site Request Forgery
 Utilisation normale (2/2)
Client légitime Server Web
www.exemple.co
m
<a href="index.php?action=acheter&id=1">Acheter</a>
Liste des objets:
ION Drum [Acheter]
AudioTek [Acheter]
Trump Sonesta [Acheter]
Page suivante | Page Precedente

44. Cross-Site Request Forgery
 Attaque
Client légitime Server Web
<html>
<head></head>
<body>
<img
src="http://www.exemple.com/index.php? www.attaque.com
action=acheter&id=1">
</body>
</html>
Server Web
www.exemple.com

45. A5 – Contre Mesure
Ajouter un jeton, non envoyé automatiquement, a toutes les requêtes sensibles.
• Cela rend impossible pour l‟attaquant de soumettre une requête valide.
• (sauf si en plus il y a une faille XSS)
• Ces jetons doivent être surs cryptographiquement.
Options
• Stocker un seul jeton dans la session et l‟ajouter à tous les formulaire et liens
• Champ caché: <input name="token" value="687965fdfaew87agrde" type="hidden"/>
• Utiliser un URL : /accounts/687965fdfaew87agrde
• Utiliser un jeton de formulaire: /accounts?auth=687965fdfaew87agrde …
• Attention a ne pas exposer le jeton dans l‟entête “referer”
• Utiliser de préférence un champ caché.
• Utiliser un jeton unique par fonction.
• Il est recommandé d‟ajouter un second niveau d‟authentification pour une transaction sensible
Ne pas laisser un attaquant stocker des attaques sur le site
• Encoder proprement les données d‟entrées
• Cela permet de limiter la majorité des interpréteurs de liens
Voir www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet pour plus de détails

46. Protection contre le Cross-Site Request Forgery
 Utilisation normale (1/2)
Client légitime GET index.php Server Web
www.exemple.com
POST login.php

47. Protection contre le Cross-Site Request Forgery
 Utilisation normale (2/2)
Client légitime Server Web
www.exemple.com
<a href="index.php
Liste des objets:
?action=acheter&id=1&secureToken=431fwap8rawddf...">Acheter</a>
ION Drum [Acheter]
AudioTek [Acheter]
Trump Sonesta [Acheter]
Page suivante | Page Precedente

48. Protection contre le Cross-Site Request Forgery
 Attaque
Client légitime Server Web
<html>
<head></head>
<body>
<img
src="http://www.exemple.com/index.php? www.attaque.com
action=acheter&id=1">
</body>
</html>
Vérification de la variable
secureToken échouée.
Session fermée.
Server Web
www.exemple.com

49. 1) OWASP, késako?
2) Les 5 risques les plus critiques des applications Web
3) WebGoat Project
4) Nouveaux vecteurs d’attaque
|49

50. WebGoat
• Plateforme de formation permettant à un
utilisateur d'apprendre à exploiter les
vulnérabilités les plus courantes sur une
application Web.
• Téléchargé plus de ~120,000 fois
• Application Web Java EE délibérément
vulnérable.
50

51. Organismes utilisant WebGoat
 Utilisé par source code analysis and web application security
scanning vendors pour les demos
 Utilisé par les universités dans le curruculum de sécurité:
• Carnegie-Mellon: WebGoat comme open source project option
• University of Denver
• ENSIAS – Morocco : Travaux Pratiques, Module « Sécurité
applicative et des données » – Option Sécurité des Systèmes
d‟Information
 OWASP Autumn 2006 and Spring of Code 2007 Projects
 Utilisé par plusieurs entreprises comme outil de formation
51

52. Origine du mot WebGoat
“ Why the name "WebGoat"? Developers should not feel bad
about not knowing security.
Even the best programmers make security errors. What they need
is a scapegoat, right?
Just blame it on the “ Goat “ ! “
WebGoat , un bouc émissaire pour les développeurs WEB
52

53. Histoire du WebGoat
• Don à OWASP par Aspect Security ~2002
• Project Lead : Bruce Mayhew
• Premières contributions externes dès 2005
• V.5 produite comme AoC
2006 project
53

54. Objectifs
• Comprendre l'interaction de haut niveau des processus au
sein d'une application WEB.
• Déterminer quelles informations au sein des données
visibles du client, pourraient être utiles dans une attaque.
• Identifier et comprendre les données et les interactions de
l'utilisateur qui pourraient exposer l‟application à une
attaque.
• Effectuer les tests contre ces interactions afin d‟exposer les
failles dans leur fonctionnement.
• Exécuter des attaques contre l'application pour démontrer
et exploiter ses vulnérabilités
54

55. Let‟s have a demo!
55

56. 1) OWASP, késako?
2) Les 5 risques les plus critiques des applications Web
3) WebGoat Project
4) Nouveaux vecteurs d’attaque
|56

57. HTTP Parameter Pollution
(HPP)
• Présentées pour la première fois en 2009 par
l'OWASP.
• Constat: les navigateurs interprétaient différemment
le fait qu'une variable soit envoyée plusieurs
fois dans la même requête.
• Certains vont ne considérer que la 1ère , d'autre la
dernière et les plus intéressants vont concaténer les
deux.
57

58. HPP
Réaction des serveurs Web à la requête
Source: HPP: First OWASP Paper by Luca Carettoni and Stefano di Paola
GET /target/foo?par1=val1&par1=val2
58

59. HPP
Source: Automated Discovery of Parameter Pollution Vulnerabilities in Web Applications
Statistiques sur les réponses des serveurs
WEB à une requête HTTP avec un même
paramètre multiplié (pollué)
59

60. HPP pour contourner la sécurité des Web
Applications Firewalls (WAF)
• ModSecurity SQL Injection filter bypass
Concept introduit par Lavakumar Kuppan
La requête suivante est proprement détectée:
/index.aspx?page=select 1,2,3 from table where id=1
En utilisant le HPP, il est possible de contourner la
protection du filtre: (Split & Join*)
/index.aspx?page=select 1&page=2,3 from table where id=1
60

61. Simple PoC of HPP
La redirection se fera vers http://www.owasp.org
ou plutôt vers http://www.yaboukir.com ?
http://www.facebook.com/l.php?u=http://www.owasp
.org&h=3e88d&u=http://www.yaboukir.com
De même si on essaie 3 valeurs pour « u »:
http://www.facebook.com/l.php?u=http://www.owasp
.org&h=3e88d&u=http://www.yaboukir.com&u=htt
ps://www.owasp.org/index.php/Morocco
61

62. Clickjacking
détournement de clic, est une
technique malveillante visant à pousser
un internaute à fournir des
informations confidentielles ou à
prendre le contrôle de son ordinateur
en le poussant à cliquer sur des pages
apparemment sûres.
62

63. Clickjacking
• Les propriétés HTML permettent de manipuler
lʼaffichage dʼune page web. Il est possible
de positionner des calques (élément HTML DIV) à
des endroits prédéfinis dʼune page, et de jouer
sur la profondeur lors de la superposition de
plusieurs calques.
• Placer un calque transparent en première position,
afin que lʼutilisateur ne visualise que le calque
en arrière-plan.
63

64. Clickjacking
64

65. Clickjacking
Proof of Concept
Vous feriez à ma page
sans s‟en rendre compte :p
65

66. Bypassing CSRF protections with HPP &
Clickjacking
Cette technique transforme une attaque par Clickjacking en
une attaque CSRF efficace par l'envoi de formulaires à travers
des domaines avec un contenu malveillant contrôlé à l'aide
des paramètres HTTP polullés (utilisant leHPP).
En JSP et Java Servlets lorsqu'un formulaire est soumis avec à
la fois la QueryString et un corps de requête contenant un
paramètre du même nom, la valeur de la QueryString est
privilégiée.
Ce problème peut être exploité en incluant la valeur du
paramètre contrôlé par attaquant dans la QueryString de l'URL
appelé à partir d'une iframe invisible.

67. Clickjacking + HPP + Social Engineering
Bypassing CSRF token protections

68. HPP part of the attack
URL:
Normal: http://www.example.com/updateEmail.jsp
Attack:
http://www.example.com/updateEmail.jsp?email=evil@attacker.mail
Form:
<form method="POST">
<input type="text" name="email" value=””></input>
<input type="hidden" name=”csrf-token” value="a0a0a0a0a0a"/>
</form>
HTTP Request:
POST /updateEmail.jsp?email=evil@attacker.mail HTTP/1.1
Host: www.example.com
email=&csrf-token=a0a0a0a0a0
Server Interpretation:
request.parameter("email") ===> evil@attacker.mail

69. Clickjacking part of the attack
How attacker’s
site looks to the
victims
(Harmless)
The form submitted
by Clickjacking
(Critical)
How the IFRAME
and the Critical form
actually overlap
(One-click CSRF)
Hidden IFRAME URL:
http://www.victim.site/udateEmail.jsp?email=evil@attacker.mail

70. Bypassing CSRF token protections
Proof of Concept
Votre email de login sera
modifié sans que vous le
sachiez :p

71. Les 5 risques les plus critiques
des applications Web
Merci pour votre aimable
attention!

72. Special thanks to
Lavakumar Kuppan
for sharing the CSRF
bypass senario with me!
72

73. References
• OWASP Top 10 - 2010 rc1: Les 10 risques les plus critiques des
applications Web. Par Sébastien GIORIA.
• Le projet OWASP, par Sébastien GIORIA @ OSSIR, Paris 08/07/2008
• OWASP WebGoat v5, par OWASP 16 April 2010
• HTTP Parameter Pollution Vulnerabilities in Web Applications, par Marco
„embyte‟ Balduzzi, @ BlackHat Europe 2011
• HTTP Parameter Pollution, par Luca Carettoni & Stefano di Paola, @
OWASP AppSec Europe 2009 - Poland
• Bypassing CSRF protections with HPP & Clickjacking, By, par Lavakumar
Kuppan
• Bypassing Web Application Firewalls with HTTP Parameter Pollution, par
Lavakumar Kuppan