The OWASP Foundationhttp://www.owasp.org

Les 5 risques les plus critiques

des applications Web

Yasser ABOUKIROWASP WebGoat Project Contributor

yaboukir@gmail.com

Journée de la Sécurité Informatique – FST Tanger

2ème édition, 28 mai 2011

The OWASP Foundationhttp://www.owasp.org

|2

Plan1) OWASP, késako?

2) Les 5 risques les plus critiques des

applications Web

3) WebGoat Project

4) Nouveaux vecteurs d’attaque

The OWASP Foundationhttp://www.owasp.org

|3

1) OWASP, késako?

2) Les 5 risques les plus critiques des

applications Web

3) WebGoat Project

4) Nouveaux vecteurs d’attaque

OWASP World

OWASP is a worldwide free and open community focused on improving the security of

application software.

Our mission is to make application security visible so

that people and organizations can make

informed decisions about application security risks.

OWASP is a worldwide free and open community focused on improving the security of

application software.

Our mission is to make application security visible so

that people and organizations can make

informed decisions about application security risks.

Everyone is free to participate in OWASP and all of our materials are available

under a free and open software license.

The OWASP Foundation is a 501c3 not-for-profit

charitable organization that ensures the ongoing

availability and support for our work.

Everyone is free to participate in OWASP and all of our materials are available

under a free and open software license.

The OWASP Foundation is a 501c3 not-for-profit

charitable organization that ensures the ongoing

availability and support for our work.

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

Organisation de l’OWASPOWASP

OWASP Conferences

OWASPWiki

OWASP Tools

OWASPLists

OWASP Books

OWASP Community

OWASP Governance

OWASP Chapter Leaders

OWASP Project Leaders

OWASP Foundation (501c3)

Board of Directors

(Williams, Wichers, Brennan, Cruz, and

Deleersnyder)

Board of Advisors

Operations Director

(McNamee)

Technical Director (Casey)

7

Finances and Grants

100%

OWASP Grants

OWASP Autumn of Code 2006

$20,000 budget

OWASP Spring of Code 2007$117,500 budget

OWASP Summer of Code 2008$126,000 budget OWASP Foundation

55%

45%

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é

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

Scanners• Static Analysis

Tools• Fuzzing

Automated Security Verification

• Penetration Testing Tools

• Code Review Tools

Manual Security Verification

• ESAPI

Security Architecture

• AppSec Libraries

• ESAPI Reference Implementation

• Guards and Filters

Secure Coding

• Reporting Tools

AppSec Management

• Flawed Apps• Learning

Environments• Live CD• SiteGenerator

AppSec Education

Les publicationsToutes 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

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 »

Les Guides100% Libres!Issus de l’expérience de milliers d’experts à

travers le mondeOWASP 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 pagesOWASP Testing guide:

• Ouvrage dédié à l’audit sécurité des applications Web à l’intention des pen-testeurs principalement.

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

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

Quelques outilsOutil 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

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

Quels sont les changements ?

• Le titre devient donc : “ Les 10 risques les plus critiques des applications Web”.

On parle de risques, et non plus uniquement de vulnérabilités.

• Basée sur la méthodologie OWASP Risk Rating Methodology

La méthodologie de calcul du risque de l’OWASP Top 10

• 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

2 éléments ajoutés, 2 retirés

Mapping Top10 2007 - Top 10 2010OWASP 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 Management>

A6 – Security Misconfiguration (NEW)

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>

+

+

--

=

=

Méthode d’évaluation du risque de l’OWASP Top 10

ThreatAgent

AttackVector

Weakness Prevalence

Weakness Detectability

Technical Impact

Business Impact

?Easy Widespread Easy Severe

?Average Common Average Moderate

Difficult Uncommon Difficult Minor

2 1 1 2

1.3 * 2

2.6 Evaluation pondérée du risque

123

Exemple basé sur XSS

L’OWASP Top10 (2010 rc1)A1: Injection A2: Cross Site

Scripting (XSS)

A3: Mauvaise gestion des

sessions et de l’authentificati

on

A4:Référence directe non

sécurisée à un objet

A5: Cross Site Request

Forgery (CSRF)

A6: Mauvaise configuration

sécurité

A7: Mauvaise restriction

d’accès à une URL

A8: Redirections et transferts non validés

A9: Mauvais stockage

cryptographique

A10: Protection

insuffisante lors du

transport des donnéeshttp://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

23

Environnement typique de l’entreprise

A1 – Injection

• Envoyer à une application des données générant un comportement non attendu.

L’injection

• Utilisent les chaines et les interprètent comme des commandes• SQL, OS Shell, LDAP, XPath, Hibernate, etc…

Les Interpréteurs

• Enormément d’applications y sont sensibles• Même s’il est très simple de s’en affranchir….

L’injection SQL est toujours commune

• 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….

Impact

Exemple sur l’injection SQL

Fire

wall

Hardened OS

Web Server

App ServerFi

rew

all

Data

base

s

Legacy

Syst

em

s

Web

Serv

ices

Dir

ect

ori

es

Hum

an R

esr

cs

Bill

ing

Custom Code

APPLICATIONATTACK

Netw

ork

Layer

Applic

ati

on L

ayer

Acc

ounts

Fin

ance

Adm

inis

trati

on

Transa

ctio

ns

Com

mun

icati

on

Know

ledge M

gm

t

E-C

om

merc

e

Bus.

Funct

ion

s

HTTP request

SQL

query

DB Table

HTTP response

"SELECT * FROM accounts WHERE

acct=‘’ OR 1=1 --’"

1. L’application fourni un formulaire

2. L’attaquant envoi son attaque dans les données

du formulaire3.L’application transfère les données à la requête SQL

Account Summary

Acct:5424-6066-2134-4334Acct:4128-7574-3921-0192Acct:5424-9383-2039-4029Acct:4128-0004-1234-0293

4. Le SGBD lance la requête contenant l’attaque et renvoie les résultats à

l’application.5. L’application renvoie ce résultat à l’utilisateur

Account:

SKU:

Account:

SKU:

A1 – Comment se protégerRecommandations

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

A2 – Cross-Site Scripting (XSS)

• Des données venant d’un attaquant sont envoyées à l’innocent navigateur d’un utilisateur

Se retrouve à chaque audit/pentest

• 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, …)

Ces données peuvent être

• Essayez cela dans votre navigateur – javascript:alert(document.cookie)

Virtuellement toute application Web est vulnérable

• 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

Impact

Cross-Site Scripting Illustré

Application disposant de

faille XSS

3

2

L’attaquant découvre le script vulnérable

L’attaquant entre un script malicieux sur la page web(stocké) ou

bien utilise un lien(réfléchi)

permettant d’envoyer vers la page

1

La victime se rend sur la page

L’attaquant reçoit le cookie ou autre élément directement

Le Script s’execute sur le navigateur de la victime sans qu’il ne le sache

Custom Code

Acc

ounts

Fin

ance

Adm

inis

trati

on

Transa

ctio

ns

Com

mun

icati

on

Know

ledge

Mgm

tE-C

om

merc

e

Bus.

Funct

ion

s

Vérification des données usager (Input validation) Cross site scripting (XSS) non persistent

extract($_POST);

$req = "select * from POSTS where title = '$stitle'

Client légitime

Server Web

Search

Gagner de l’argent

Search results for Gagner de l’argent:Comment gagner de l'argent facile

et des cadeaux sur internet…L' objectif du blog est de présenter toutes les idées qui permettent d'

économiser …<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></itemize></body></html>

Vérification des données usage (Input validation) Cross site scripting (XSS) non persistent

extract($_POST);

$req = "select * from POSTS where title = '$stitle'

Server Web

Search

<u>Super</u>Search results for

Super:

No results found

<html><head></head><body>

<h1>Search results for <u>Super</u> :</h1>No results found</itemize></body></html>

Client malicieux

Vérification des données usager (Input validation) Cross site scripting (XSS) persistent

Post

Your message has been posted

Client malicieux

<script type="text/javascript">document.location.href=“http://evil.com"</script>

id message

1 Hello

2 Bien fait ...

Server BD

3 <script type="text/javascript">document.location.href=“http://evil.com"</script>

Vérification des données usager (Input validation) Cross site scripting (XSS)

32

<h1>Guestbook messages:</h1>Hello<br>Bien fait<br><script type="text/javascript">document.location.href=“http://evil.com"</script><br>...

Guestbook messages:

HelloBien fait ...

id message

1 Hello

2 Bien fait ...

3 <script type="text/javascript">document.location.href=“http://evil.com"</script>

Server BDClient

légitime

A2 – Contre mesuresRecommandations

• 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

A3 – Mauvaise gestion des sessions et de l’authentification

• Les identifiants doivent donc être passés à chaque requête.• Il faut utiliser SSL pour toute authentification

HTTP est un protocole sans état

• 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, ….

Failles dans la gestion de l’authentification

• Changement de mot de passe, se souvenir de mon passe, oubli de mot de passe, questions secrètes, logout, email, …

Attention aux portes dérobées…

• Vol de session ou compromission de comptes utilisateur

Impact

Illustration d’une mauvaise authentification

Custom Code

Accou

nts

Fin

an

ce

Ad

min

istr

ati

on

Tran

sacti

on

sC

om

mu

nic

ati

on

Kn

ow

led

ge

Mg

mt

E-C

om

merc

eB

us.

Fu

ncti

on

s

1 Utilisateur envoie ses identifiants

2Le site récrit l’URL

(i.e., mise dans l’URL de l’ID de session)

3 L’utilisateur clique sur un lien vers http://www.cracker.com dans un

forum

www.test.com?JSESSIONID=9FA1DB9EA...

4

L’attaquant regarde les logs “Referer” sur www.cracker.com

Et découvre le JSESSIONID5 L’attaquant peut

utiliser le JSESSIONID sur le site boi.com pour

son méfait

A3 – Contre MesureVé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)

A4 – Référence directe non sécurisée à un objet

• C’est une manière de renforcer les habilitations en lien avec A7 – Mauvaise restriction d’accès à une URL

Comment accéder aux données privées

• 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…

Des erreurs classiques

• Un utilisateur a accès à des données ou des fichiers normalement interdits

Impact

Référence directe non sécurisée à un objet illustrée

de la manière suivante

?acct=6066

L’attaquant visualise un autre compte.

https://www.banque.com/user?acct=6065

L’attaquant note le paramètre acct = 6065

?acct=6065

A4 – Contre MesureEliminer 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

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)

http://app?file=1Report123.xls

http://app?id=7d3J93Acct:9182374http://app?id=9182374

http://app?file=Report123.xlsAccess

ReferenceMap

A5 – Cross Site Request Forgery (CSRF)

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

Cross Site Request Forgery

• 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 ?

Imaginez

• Initiation de transactions (transfert de fonds, logoff, modification de données, …)

• Accès à des données sensibles• Changement des mots de passes/identifiants

Impact

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.

Cross-Site Request Forgery Utilisation normale (1/2)

Client légitime

Server Web

www.exemple.com

POST login.php

Redirect index.php

Set Cookie:

PHP_SESSID=vwae9pa6nw408967a123…

GET index.php

Utilisation normale (2/2)Client

légitimeServer Web

GET index.phpCookie PHP_SESSID=vwae9pa6nw408967a123…

Liste des objets:ION Drum [Acheter]AudioTek [Acheter]

Trump Sonesta [Acheter]

Page suivante | Page Precedente

<a href="index.php?action=acheter&id=1">Acheter</a>

GET =index.php?action=acheter&id=1Cookie PHP_SESSID=vwae9pa6nw408967a123…

www.exemple.com

Cross-Site Request Forgery

Cross-Site Request Forgery Attaque

Client légitime

Server Web

GET malicious.asp

www.attaque.com

<html><head></head>

<body><img

src="http://www.exemple.com/index.php?action=acheter&id=1">

</body></html>

GET =index.php?action=acheter&id=1

Cookie

PHP_SESSID=vwae9pa6nw408967a123…

Server Web

www.exemple.com

A5 – Contre MesureAjouter 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

Protection contre le Cross-Site Request Forgery Utilisation normale (1/2)

Client légitime

Server Web

www.exemple.com

POST login.php

Redirect index.php?

secureToken=431fwap8rawddf...

Set Cookie:

PHP_SESSID=vwae9pa6nw408967a123…

GET index.php

Protection contre le Cross-Site Request Forgery Utilisation normale (2/2)

Client légitime

Server Web

GET index.php?secureToken=431fwap8rawddf...Cookie PHP_SESSID=vwae9pa6nw408967a123…

Liste des objets:ION Drum [Acheter]AudioTek [Acheter]

Trump Sonesta [Acheter]

Page suivante | Page Precedente

<a href="index.php ?action=acheter&id=1&secureToken=431fwap8rawddf...">Acheter</a>

GET =index.php?action=acheter&id=1&secureToken=431fwap8rawddf...Cookie PHP_SESSID=vwae9pa6nw408967a123…

www.exemple.com

Protection contre le Cross-Site Request Forgery Attaque

Client légitime

Server Web

GET malicious.asp

www.attaque.com

<html><head></head>

<body><img

src="http://www.exemple.com/index.php?action=acheter&id=1">

</body></html>

GET =index.php?action=acheter&id=1

Cookie

PHP_SESSID=vwae9pa6nw408967a123…

Server Web

www.exemple.com

Vérification de la variable secureToken échouée.

Session fermée.

|49

1) OWASP, késako?

2) Les 5 risques les plus critiques des

applications Web

3) WebGoat Project

4) Nouveaux vecteurs d’attaque

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.

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

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

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

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

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.

58

HPPRéaction des serveurs Web à la

requête GET /target/foo?par1=val1&par1=val2

Sou

rce:

HPP:

Firs

t O

WA

SP Pa

per

by L

uca

Care

ttoni a

nd S

tefa

no d

i Pa

ola

59

HPPStatistiques sur les réponses des

serveurs WEB à une requête HTTP avec un même paramètre multiplié (pollué)

Sou

rce:

Auto

mate

d D

isco

very

of

Para

mete

r Po

lluti

on V

uln

era

bili

ties

in W

eb A

pplic

ati

ons

60

HPP pour contourner la sécurité des Web Applications Firewalls (WAF)

• ModSecurity SQL Injection filter bypass

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

Conce

pt

intr

oduit

par

Lavaku

mar

Kuppan

61

Simple PoC of HPP

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=https://www.owasp.org/index.php/Morocco

La redirection se fera vers http://www.owasp.org

ou plutôt vers http://www.yaboukir.com ?

62

Clickjackingdé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.

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.

64

Clickjacking

65

Clickjacking

Proof of ConceptVous feriez à ma page sans s’en rendre

compte :p

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.

Bypassing CSRF protections with HPP & Clickjacking

Clickjacking + HPP + Social Engineering

Bypassing CSRF token protections

HPP part of the attack

URL:Normal: http://www.example.com/updateEmail.jspAttack: http://www.example.com/updateEmail.jsp?

email=evil@attacker.mailForm:<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.1Host: www.example.comemail=&csrf-token=a0a0a0a0a0

Server Interpretation:request.parameter("email") ===> evil@attacker.mail

Clickjacking part of the attack

Hidden IFRAME URL: http://www.victim.site/udateEmail.jsp?

email=evil@attacker.mail

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)

Bypassing CSRF token protections

Proof of ConceptVotre email de login sera modifié sans que vous le

sachiez :p

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!

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