Fait par: DJIKE TAYOU

Universite catholique d’Afrique Centrale – faculte des sciences sociales et de gestion Master ii en management des

systèmes d’information

Sommaire

Introduction.......................................................1I. Généralités sur OWASP.........................................21. Présentation générale d’OWASP...............................22. Livrables (Projets) proposés par OWASP......................3

II. Audit de sécurité avec OWASP..................................41. Les axes....................................................42. Implémentation des tests de sécurité........................5

III. Cas pratique des failles de sécurité identifiées et traitées par OWASP........................................................81. Vulnérabilités et bonnes pratiques..........................82. Récapitulatif des vulnérabilités et des moyens préventifs. .27

Conclusion........................................................30

Introduction

Le système d'information (SI) est définit comme étantl’ensemble des moyens (humains, matériels, logiciels, donnéeset organisationnels) permettant de collecter, stocker, traiteret diffuser les informations au sein d’une organisation en vuede l’atteinte des objectifs. L’enjeu du système d’informationpour les organisations n’est plus à démontrer. En effet, ilest non seulement le garant de la bonne circulation desinformations en leurs seins, mais également un catalyseur deréussite. Son importance parait d’autant plus majeure quand onsait à quel point la maitrise des informations (internes etexternes à l’organisation) constitue une richesse. Le SIapporte certes une valeur ajouté, mais il apporte égalementson lot de risques. Ce risque est davantage élevé dans lesorganisations pour les quelles toutes les opérations sontautomatisées. Ainsi dont pour le maintien de la prospérité del’organisation, il convient de sécuriser autant que faire sepeut le SI. Plusieurs méthodes et approches (à l’instar MEHARIou encore EBIOS), ont été développées pour analyser et évaluerles risques encourus par le SI, et apporter des mesuresappropriées. Dans le domaine de la sécurisation desapplications WEB, les projets proposés par OWASP (Open WebApplication Security Project) sont la référence. Dans cedocument nous présenterons les généralités sur OWASP, ensuitel’approche d’audit de sécurité selon OWASP et enfin uneimplémentation des tests de sécurité OWASP.

I. Généralités sur OWASP

1. Présentation générale d’OWASPOWASP (The Open Web Application Security Project) est une

organisation internationale à but non-lucratif créée au débutdes années 2000. Sa vocation est la production et lapromotion des outils et méthodes de sécurisation desapplications web. Elle se positionne comme une communautémondiale proposant de manière gratuite et libre des standardsde conformité logicielle, des bonnes pratiques, outils etrecommandations de sécurité à toute personne physique oumorale, intéressée par l’amélioration de la sécurité desapplications. Ainsi dont, le groupe OWASP exposeprincipalement des supports (méthodologie, outils) aidant dansla détection et l'exploitation de failles de sécurité auniveau d'applications WEB. L’objectif est de maintenir unniveau de sécurité acceptable pour ces applications. Pour sefaire elle préconise une approche sécurité des applications entant que problème de personnes, de processus et detechnologie, parce que les approches les plus efficaces pourla sécurité des applications nécessitent des améliorationsdans tous ces domaines. S’agissant de son organisation, OWASPa à son cœur une réunion d’experts et de professionnels desdomaines liés à la sécurité des systèmes d'information, maiségalement des développeurs et chefs de projet, mettant encommun leurs expériences et savoir-faire à la disposition dela communauté

2. Livrables (Projets) proposés par OWASPLes livrables/Projets proposés par OWASP sont tous

ouverts et libres. Ils permettent aussi bien de faire de laveille sécuritaire, que des audits et tests de sécuritéavancés sur n’importe quelle plateforme web. Ces Projetssont : des outils, les projets des bibliothèques de documents,et des codes. Ils sont organisés dans les catégoriessuivantes:

Projets phares: la désignation de l'OWASP phare estaccordée aux projets qui ont démontré la valeur stratégiquede l'OWASP et la sécurité de l'application dans sonensemble.

Projets de laboratoire: les projets OWASP Labs représententles projets qui ont produit un livrable examiné OWASP devaleur.

Incubateur Projets: les projets OWASP Incubateurreprésentent l'aire de jeu expérimental où les projets sontencore en cours d’être étoffés, les idées sont encoreprouvés, et le développement est toujours en cours.

Les projets OWASP les plus prisés sont detype documentation et outils applicatifs. Parmi eux nouspouvons citer :

Documents :

- Le Top 10 OWASP. le but de ce projetest de référencer lesdix failles de sécurité les plus importantes et répandues surle web. La plupart des spécialistes et organismes dans ledomaine de la sécurité (DoD, PCI Security Standard) se basentsur ce Top 10 (annese1).

Le Top 10 OWASP évolue dans le temps, certaines failles (commeles problèmes de sécurité dus à une mauvaise configuration)n’étaient plus dans le classement entre 2004 et 2010. Cetexemple montre qu’il y a de nombreux autres points à vérifier,qui ne sont pas listés dans ce classement. Même si vous pensezavoir sécurisé votre application web, vous pouvez déjà être

vulnérable face à quelque chose auquel personne n’a jamaispensé auparavant. Certaines vulnérabilités dans les articlesd’OWASP sont non-applicables au web, mais peuvent servir debase à une réflexion sur la sécurité et la création d’unréférentiel de sécurité.

- Un Guide de développement, qui est aujourd’hui assezobsolète mais est en projet de réécriture (pour les langagesPhp, .Net et Java).

- LesCheatSheets qui sont plus intéressantes et donnentplus de détails sur la détection, la prévention et lacorrection de failles de sécurité.

- OWASP Testing Guide : il s'agit d'un document deplusieurs centaines de pages proposant plusieurs tests afind’évaluer le niveau de sécurité d'une application Web(annexe2).

Les outils logiciels :

- Webscarab : un outil d’audit de sécurité - Webgoat : une application web volontairement non

sécurisée.

Par ailleurs, OWASP organise régulièrement des meetingsun peu partout dans le monde. Durant ces rendez-vous, desintervenants issus du monde de la sécurité présentent unproduit, une faille, un projet OWASP, etc.

II. Audit de sécurité avec OWASP

1. Les axesAvec OWASP l’audit de sécurité des applications web est

axé sur trois grands aspects :

a) Protection des accès aux applications : il s’agit deprotéger les documents de telle sorte que seuls lesutilisateurs autorisés y aient accès et que personne d’autre

ne puisse les consulter ; le client d’une banque devrait parexemple être le seul à consulter ses relevés de compte.

b) Protection des lieux de stockage des informations:les documents ne doivent pas être enregistrés sous des formatsou en des lieux qui peuvent être accessibles à d’autresutilisateurs que ceux autorisés ; il ne devrait par exemplepas être enregistrés dans le cache de navigateurs danslesquels ils sont accessibles par d’autres utilisateurs.

c) Sécurisation de la distribution des fichiers : ils’agit de sécuriser la livraison des documents. Elle se faiten plusieurs étapes. Premièrement le chemin d’accès au fichierest protégé et rendu non visible par l’utilisateur final aumoyen d’un script ; deuxièmement un module d’authentificationest ajouté au document et enfin le cache est sécurisé par desinstructions pour empêcher le navigateur de questionner lecache ou alors pour désactiver la mise en cache desinformations.

Pour chacun de ces axes, il s’agira d’effectuer des testsde sécurité (plus précisément de tests de pénétration) afind’identifier les vulnérabilités. Ils peuvent être réalisésmanuellement ou bien automatiquement avec des outils d'analysetels des scanners de vulnérabilités. A cette étape le documentl’OWASP testing Guide et les outilsWebgoat et Webscarab sontutiles. D’autres outils, comme les encodeurs/décodeurs ouencore des logiciels de cassage de mots de passé (base sur destables rainbow ou sur la force brute) à partir d’une formecryptée (exemple : hash) s’avèrent généralement nécessairelors des audits de sécurité.

2. Implémentation des tests de sécuritéCe sont des tests de pénétration visant à identifier les

vulnérabilités au sein d'une application. Ils peuvent êtreréalisés manuellement ou bien automatiquement avec des outilsd'analyse tels des scanners de vulnérabilités. Ci-dessous laliste des tests de sécurité des applications web tirés del’OWASP testing Guide Version 4.

Configuration and Deployment Management TestingTest Network/Infrastructure Configuration (OTG-CONFIG-001)Test Application Platform Configuration (OTG-CONFIG-002)Testing Guide Foreword - Table of contentsTest File Extensions Handling for Sensitive Information (OTG-CONFIG-003)Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004)Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)Test HTTP Methods (OTG-CONFIG-006)Test HTTP Strict Transport Security (OTG-CONFIG-007)Test RIA cross domain policy (OTG-CONFIG-008)

Identity Management TestingTest Role Definitions (OTG-IDENT-001)Test User Registration Process (OTG-IDENT-002)Test Account Provisioning Process (OTG-IDENT-003)Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)Testing for Weak or unenforced username policy (OTG-IDENT-005)

Authentication TestingTesting for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)Testing for default credentials (OTG-AUTHN-002)Testing for Weak lock out mechanism (OTG-AUTHN-003)Testing for bypassing authentication schema (OTG-AUTHN-004)Test remember password functionality (OTG-AUTHN-005)Testing for Browser cache weakness (OTG-AUTHN-006)Testing for Weak password policy (OTG-AUTHN-007)Testing for Weak security question/answer (OTG-AUTHN-008)Testing for weak password change or reset functionalities (OTG-AUTHN-009)Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)

Authorization TestingTesting Directory traversal/file include (OTG-AUTHZ-001)Testing for bypassing authorization schema (OTG-AUTHZ-002)Testing for Privilege Escalation (OTG-AUTHZ-003)Testing for Insecure Direct Object References (OTG-AUTHZ-004)

Session Management TestingTesting for Bypassing Session Management Schema (OTG-SESS-001)Testing for Cookies attributes (OTG-SESS-002)

Testing for Session Fixation (OTG-SESS-003)Testing for Exposed Session Variables (OTG-SESS-004)Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)Testing for logout functionality (OTG-SESS-006)Test Session Timeout (OTG-SESS-007)Testing for Session puzzling (OTG-SESS-008)

Input Validation TestingTesting for Reflected Cross Site Scripting (OTG-INPVAL-001)Testing for Stored Cross Site Scripting (OTG-INPVAL-002)Testing for HTTP Verb Tampering (OTG-INPVAL-003)Testing for HTTP Parameter pollution (OTG-INPVAL-004)Testing for SQL Injection (OTG-INPVAL-005)Oracle TestingMySQL TestingSQL Server TestingTesting PostgreSQL (from OWASP BSP)MS Access TestingTesting Guide Foreword - Table of contentsTesting for NoSQL injectionTesting for LDAP Injection (OTG-INPVAL-006)Testing for ORM Injection (OTG-INPVAL-007)Testing for XML Injection (OTG-INPVAL-008)Testing for SSI Injection (OTG-INPVAL-009)Testing for XPath Injection (OTG-INPVAL-010)IMAP/SMTP Injection (OTG-INPVAL-011)Testing for Code Injection (OTG-INPVAL-012)Testing for Local File InclusionTesting for Remote File InclusionTesting for Command Injection (OTG-INPVAL-013)Testing for Buffer overflow (OTG-INPVAL-014)Testing for Heap overflowTesting for Stack overflowTesting for Format stringTesting for incubated vulnerabilities (OTG-INPVAL-015)Testing for HTTP Splitting/Smuggling (OTG-INPVAL-016)

Testing for Error HandlingAnalysis of Error Codes (OTG-ERR-001)Analysis of Stack Traces (OTG-ERR-002)

Testing for weak Cryptography

Testing for Weak SSL/TLS Ciphers, Insufficient Transport LayerProtection (OTG-CRYPST-001)Testing for Padding Oracle (OTG-CRYPST-002)Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)

Business Logic TestingTest Business Logic Data Validation (OTG-BUSLOGIC-001)Test Ability to Forge Requests (OTG-BUSLOGIC-002)Test Integrity Checks (OTG-BUSLOGIC-003)Test for Process Timing (OTG-BUSLOGIC-004)Test Number of Times a Function Can be Used Limits (OTG-BUSLOGIC-005)Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006)Test Defenses Against Application Mis-use (OTG-BUSLOGIC-007)Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)Test Upload of Malicious Files (OTG-BUSLOGIC-009)

Client Side TestingTesting for DOM based Cross Site Scripting (OTG-CLIENT-001)Testing for JavaScript Execution (OTG-CLIENT-002)Testing for HTML Injection (OTG-CLIENT-003)Testing for Client Side URL Redirect (OTG-CLIENT-004)Testing for CSS Injection (OTG-CLIENT-005)Testing for Client Side Resource Manipulation (OTG-CLIENT-006)Test Cross Origin Resource Sharing (OTG-CLIENT-007)Testing for Cross Site Flashing (OTG-CLIENT-008)Testing for Clickjacking (OTG-CLIENT-009)Testing WebSockets (OTG-CLIENT-010)Test Web Messaging (OTG-CLIENT-011)Test Local Storage (OTG-CLIENT-012)

La méthodologie proposée par OWASP pour la réalisation de cesdifférents tests est la suivante:

Récolte d’informations ; Test de la gestion de la configuration ; Test de logique métier de l’application Test des processus d’authentification ou d’autorisations Tests des processus liés à la gestion des sessions Test de la bonne validation des données soumises à

l’application Test de l’utilisation de la technologie AJAX Test des WEW services utilisés par l’application

Déni de service

En fonction du type d’attaques et de l’automatisation decelles-ci, Il existe de nombreux outils appartenant àdifférentes catégories de logiciels. Le tableau ci-aprèsprésente quelques exemples d’applications.

Catégorie Logiciels disponiblesRécolte d’informations Nmap

Google dorksScanners de vulnérabilitésconnues

Nesus ( Tenable NetworkSecurity)

Nikto HP Weblnspect

Scanners d’injections SQL Sqlmap OwaspSQLiX

Scanners de certificats et deconnexions SSL

Mc AfeeFoundstone SSLDigger

OWASP O-SaftOutils bases PROXY, editiondes échanges, manipulation decookis

Burp Paros OWASP WebScarab OWASP ZAP (Zed Attack

Proxy)Data Fuzzing / Tampering OWASP JHijack

TamperData (ExtensionFirefox, Mantra)

Wfuzz (Edge Security)

Enoncés plus haut, OWASP a également conçu Webscarb etWebgoat, outils d’audit de sécurité.

Webscarab : Un outil d’audit de sécurité. Il s’agit d’unproxy disposant d’une interface graphique qui, une fois reliéà un navigateur, intercepte les requêtes/réponses HTTP entrele client et le serveur, ce qui permet de les analyser, deforger des requêtes soi-même, de tenter différentesinjections, etc... Le proxy est intercalé entre le client et

le serveur à la façon d’une attaque « Man in the middle ».Webscarab dispose de nombreux plugins permettant d’augmenterle nombre de fonctionnalités offert par l’outil (WebServices,Spider, XSS/CRLF, SessionID Analysis, etc...). Le gros défaut de cette solution est qu’elle n’est pasrégulièrement mise à jour (dernière en date : 04 Mai 2007) etn’intègre pas les dernières vulnérabilités découvertes.Son intérêt : avoir un outil qui facilite un audit applicatif.Ce logiciel ne permettra pas d’avoir une application ayant unesécurité élevée s’il est utilisé seul. D’autres tests seront àfaire pour accroitre la sécurité de l’application.

Webgoat : Il s’agit cette fois d’une application webvolontairement non sécurisée. Elle est livrée avec un tutorielet des exercices pratiques. Une fois de plus, OWASP met enavant l’aspect pédagogique de ses solutions, ayant pour butd’instruire l’intéressé sur les différentes techniquesd’exploitation de vulnérabilités. L’intérêt est de former ledéveloppeur à produire un code sûr.

D’autres outils, comme les encodeurs/décodeurs ou encoredes logiciels de cassage de mots de passé (base sur des tablesrainbow ou sur la force brute) à partir d’une forme cryptée(exemple : hash) s’avèrent généralement nécessaire lors desaudits de sécurité.

III. Cas pratique des failles de sécurité identifiées et traitées par OWASP

1. Vulnérabilités et bonnes pratiques1.1 Injection

a. Principe L’attaque par injection est évaluée par l’OWASP comme

étant la plus risquée, car la faille est assez répandue, ilest facile de l’exploiter et l’impact peut être trèsimportant. Cela va de la simple récupération de données à laprise totale de contrôle du serveur. La victime de l’attaqueest un des composants technique de l’application Web.

Pour réaliser une attaque de ce type, il faut injecterdans les zones de saisie classiques présentées à l’utilisateurdu code malicieux. Ces données seront interprétées comme desinstructions par un des composants de l’application Web. Leschamps de formulaires peuvent être protégés par Javascriptpour vérifier que les valeurs saisies correspondent à ce quiest attendu. Il est possible d’outrepasser ces vérificationsen faisant appel à un serveur proxy personnel, par exemple,qui permettra d’intercepter les requêtes pour les modifier etenvoyer le code malicieux. La difficulté de l’attaque résidefinalement dans la détection des technologies utilisées pourformuler le code d’attaque adéquat. Cependant, la plupart desapplications Web de gestion de contenu présentes sur le Websont basées sur des projets Open Source. Il est aussi faciled’identifier les technologies employées en parcourant le codesource mis à disposition. De plus, il existe des outilsd’injection automatique disponibles sur le Web, rendant lerisque plus élevé. L’exploitation de la faille devientautomatisable.

Les failles d’Injection surviennent quand une applicationenvoie des données non fiables à un interpréteur. Les faillesd’injection sont très fréquentes, surtout dans un code ancien.On les retrouve souvent en SQL, LDAP, XPath, ou NoSQL;commandes OS; parseurs XML; entêtes SMTP, arguments deprogramme, etc. Les failles d’Injection se détectentfacilement via le code, difficilement via le test. Scanners etFuzzers peuvent aider les attaquants à trouver les faillesd’Injection.

b. Exemples d’attaques L’attaque par injection SQL consiste à injecter du code

SQL qui sera interprété par le moteur de base de données. Lecode malicieux le plus répandu est d’ajouter une instructionpour faire en sorte que la requête sous-jacente soit toujourspositive. Cela permet par exemple d’usurper une identité pourse connecter à une application Web, de rendre l’applicationinutilisable ou de supprimer toutes les données de la tablevisée, voire même de la base de données complète. L’exemplesuivant va interroger une table qui contient la liste descartes bancaires enregistrées dans la base de données del’application Web d’un site marchand. Le script de création decette table est le suivant :

Figure 1 : Script SQL de création de la table « comptes »

Pour afficher le numéro de carte bancaire, l’utilisateurdoit s’authentifier. La requête SQL suivante permet devérifier que le couple utilisateur « marius»/mot de passe ducompte « leyou » est correct et si tel est le cas renvoie lenuméro de carte bancaire :

Figure 2 : Requête SQL pour l’authentification et affichage du numéro de carte

Le script PHP pour exploiter cette requête de façondynamique avec les informations fournies par l’utilisateur estle suivant :

Figure 3 : Script PHP pour l’authentification et l’affichage du numéro de carte

En remplissant le formulaire avec la valeur « ' OR 1=1 --' » pour le champ « nom » et n’importe quelle valeur pour le

mot de passe, la requête qui sera envoyée à la base de donnéesdevient :

Figure 4 : Requête SQL incluant du code frauduleux d’injection

Ainsi la condition 1=1 est toujours vérifiée et le restede la commande est mis en commentaire grâce à la chaîne decaractères « -- ». Cela permet donc de récupérer aléatoirementun numéro de carte.

L’attaque par injection de XPath suit le même principe quepour SQL. En effet, XPath est un langage de requête pour gérerles données stockées au format XML, comme le fait SQL pour lesbases de données relationnelles. XPath et Xquery, dont XPathest un sous-ensemble, souffrent donc des mêmes vulnérabilitésface à l’injection de code malicieux.

L’attaque par injection LDAP permet d’accéder à desinformations privées qui sont enregistrées dans l’annuaired’entreprise. En modifiant le comportement du filtrage dans larequête LDAP qui sera générée, il est possible de récupérer laliste exhaustive des adresses de courrier électronique d’uneentreprise pour les saturer de spam par exemple.

L’attaque par injection de commandes est surtoutprincipalement possible sur les scripts CGI écrits en Perl,PHP et Shell. Il est possible de prendre le contrôle duserveur. Il faut pour cela faire en sorte que la commandeinitiale soit exécutée sans problème et ajouter des commandesdu système d’exploitation du serveur qui seront exécutées parle serveur.

c. Bonnes pratiques

Les différentes attaques citées précédemment reposentprincipalement sur l’utilisation de caractères spécifiques quipermettent de mettre en commentaire des portions de code etd’insérer du code frauduleux. Il est cependant rare quel’application ait besoin d’accepter les caractères suivant.

Figure 5 : Caractères spéciaux communément utilisés dans lesattaques d’injection

Cependant les applications Web de gestion de contenucomme les forums doivent les accepter, notamment les forumsutilisés par les développeurs pour partager du code. Dans cecas, il faut transformer aux moins les caractères suivants encode HTML avant de les stocker dans la base de données.L’affichage de l’information ne sera pas différent pourl’utilisateur, mais les données seront plus sûres.

Bien qu’un site puisse subir différents types d’attaquespar injection, il suffit de vérifier que les caractèresutilisés sont ceux attendus. Ce contrôle doit être effectué auniveau du client grâce à JavaScript et au niveau du serveurlorsque les paramètres sont récupérés pour fermer la faille desécurité. Par exemple, le langage PHP offre une fonctionnalitéqui permet de transformer ces caractères.

Figure 6 Script PHP pour remplacer les caractères par le code HTML

De plus il faut vérifier que les valeurs sont bien dutype et du format attendu (longueur, intervalle de valeur, …).

Pour déterminer si un site est victime de ce typed’agression, il faut vérifier dans les journaux d’activité duserveur http qu’il n’y a pas d’évènement inhabituel, tel qu’unnombre de requêtes http anormalement élevé ou des requêtesayant pour paramètres des valeurs inappropriées.

1.2 Cross-site scripting (xss)

a. Principe

L’OWASP considère la vulnérabilité à XSS comme une faillecritique car elle est très répandue et facile à détecter. Lesattaques s’appuient principalement sur les formulaires des

applications Web. L’attaque XSS par réflexion (reflected XSS)s’appuie sur le fait que l’application Web affiche ce quel’utilisateur vient de saisir dans un formulaire dans une pagede résultat. Le navigateur de la victime exécute alors le codefrauduleux généré dans la page de résultat. Tous les champs deformulaire sont donc une faille de sécurité potentielle quel’attaquant peut exploiter par XSS. L’attaquant crée un liendéguisé vers l’application Web dont un des paramètres contientdu code JavaScript frauduleux. En utilisant ce lien, lavictime fait exécuter par son navigateur le code JavaScript.Le Web 2.0 et ses systèmes de gestion de contenu ontpopularisé cette attaque en permettant de publier des liensaisément et visible sur tout le Web.

Figure 7 Principe d'une attaque XSS par réflexion

L’attaque XSS stockée (stored XSS) s’appuie sur le faitque l’attaquant réussisse à stocker dans la base de données ducode frauduleux qui sera exécuté par la victime lorsqu’elletentera d’afficher la donnée malveillante. Cette attaque estplus dangereuse que la première car le code fait partieintégrante des données de l’application Web et peut atteindreplusieurs victimes.

Figure 8 : Principe d'une attaque XSS stockée

b. Exemples d’attaque

L’attaque XSS par réflexion peut être implémentée pardifférents moyens.

Le plus facile est d’utiliser un moteur de recherchevulnérable. Par exemple les outils de forum intègrent desformulaires pour recherche des messages par leur contenu. Lapage de résultat reprend généralement les mots clés saisis. Ilsuffit alors de mettre comme paramètre de recherche un codeJavaScript qui sera ensuite interprété par le navigateur de lavictime. Pour réaliser cette attaque il suffit de laisser unlien qui aura pour paramètre le code malveillant.

Figure 9 : Exemple de lien malveillant exploitant une faille XSS

En cliquant sur ce lien, la victime lancera la recherche.Puis le moteur de recherche affichera le paramètre «<script>alert(‘attaque XSS’)</script> » qui sera exécuté parle navigateur.

Des applications Web sont responsables de l’affichage descourriers électroniques : les webmails. Pour consulter soncourrier, l’utilisateur va préalablement s’authentifier et sesinformations d’identification seront stockées dans descookies. Un courrier malveillant peut intégrer du codeJavaScript qui sera interprété par le navigateur. Ce code seracapable de récupérer les cookies et envoyer les informations àl’attaquant.

L’attaque XSS stockée injecte du code malveillant dans labase de données. L’application Web suivante de type forum vapermettre d’illustrer cette attaque. La table support de ladémonstration est la suivante :

Figure 10 : Script SQL de création de la table « messages »

Le script PHP suivant est responsable de l’enregistrementd’un message. Comme une des informations saisies (le nom durédacteur) est réaffichée, cela implique que ce code estvulnérable à une attaque XSS par réflexion.

Figure 11 Script PHP pour l’insertion dans la table « messages »

En saisissant comme message un code JavaScriptmalveillant, il sera enregistré dans la base de données.

Le script PHP suivant est responsable de l’affichage del’ensemble des messages d’un sujet.

Figure 12 Script PHP pour la recherche dans la table « messages »

Lorsque des utilisateurs afficheront le fil des messages,le message frauduleux sera automatiquement envoyé auxnavigateurs et interprété créant une attaque XSS.

c. Bonnes pratiques

Les recommandations faites précédemment pour se prémunirdes risques d’injection sont valables pour XSS. Cependant,transformer les six caractères douteux suivants suffit.

Figure 13 : Caractères spéciaux à remplacer par leur code

Côté client avec JavaScript il faut vérifier les donnéessaisies par les utilisateurs. Côté serveur, il faut vérifierles données récupérer en paramètre. Il faut rejeter toutes lesdonnées qui ne sont pas conformes à ce qui est attendu.

Pour éviter le vol de cookie par du code JavaScript, ilest possible de positionner l’attribut de cookie HTTPOnly.S’il est présent, le navigateur interdit au moteur JavaScriptde lire ou écrire dans les cookies. Cet attribut est très peuutilisé par les applications Web, car tous les navigateurs nele gèrent pas. Cependant il est préférable de l’utiliser carles navigateurs les plus populaires l’implémentent, ce quidiminue les risques liés aux cookies.

Figure 14 : Script PHP pour positionner l’attribut de cookieHTTPOnly

Les navigateurs intègrent des protections contre XSS eninterdisant l’exécution de code JavaScript qui modifie unepage Web depuis une page Web ne portant pas le même nom dedomaine.

1.3 Violation de gestion d’authentification et de session

a. Principe

Cette faille de sécurité regroupe toutes lesvulnérabilités pouvant mener à une usurpation d’identité. Cespoints de faiblesse dans les applications Web peuvent ouvrir àdes attaquants des accès à des fonctionnalités desapplications Web auxquelles ils n’ont pas le droitnormalement. Cela peut donc leur permettre de voler desinformations ou d’endommager le bon fonctionnement del’application. La protection des accès à l’application reposegénéralement sur un système d’authentification. La plupart dutemps, le système d’authentification est redéveloppé pourchaque application, ce qui implique que ces systèmes nebénéficient pas de l’expérience acquise sur le développementd’autres applications.

Pour comprendre comment les attaques peuvent être menées,il faut comprendre le mécanisme d’authentification le pluscommun des applications Web :

L’utilisateur non authentifié demande l’accès à une page Web;

Le serveur renvoie une page d’authentification ; L’utilisateur rempli le formulaire en fournissant unidentifiant et un mot de passe et revoie ces informations auserveur web ;

Le serveur web fait appel à un service pour vérifier lavalidité du couple identifiant/mot de passe

Si la validité est avérée, le serveur web fournit unidentifiant de session à l’utilisateur. Comme expliquéprécédemment http est un protocole déconnecté, donc entredeux requêtes http la connexion entre le navigateur et leserveur http est coupée. Donc le serveur http ne peut pasreconnaître un utilisateur qui s’est déjà authentifié etouvert une session de travail dans l’application Web. Pourremédier à cela, la plupart des systèmes d’authentificationrepose sur un identifiant de session. Celui-ci est envoyé àchaque page entre le client et le serveur par le biais d’uncookie, d’un paramètre d’adresse ou d’un champ de formulaireinvisible pour l’utilisateur ;

L’utilisateur peut utiliser l’application Web tant que lasession est ouverte.

Les attaques pour usurper une identité peuvent êtreregroupées en deux catégories :

Les attaques contre le système d’authentification quicherchent à obtenir un droit d’accès ;

Les usurpations de session qui permettent de s’affranchirde l’étape d’authentification.

Figure 15 : Principe de détournement de session


Parmi les attaques contre les systèmesd’authentification, la plus répandue est l’utilisation de laforce brute. Pour cela l’attaquant va bombarder la paged’authentification avec des valeurs d’identifiant et de motsde passe jusqu’à ce qu’il se fasse accepter. L’attaque estfacilitée si le message d’erreur de l’échec de

l’authentification donne l’origine de l’erreur. Ainsi «l’utilisateur n’existe pas » permet à l’attaquant de ne pastenter d’entrer des mots de passe pour cet utilisateur absentde la base de compte. « Mot de passe incorrect » permet àl’attaquant de se concentrer sur cet utilisateur, ce qui luifait gagner beaucoup de temps. De même si l’application Weboffre un service pour créer un compte par lui-même et qu’aumoment de la saisie de l’identifiant ce système indique si lecompte existe déjà ou non, l’attaquant dispose d’un moyen pourtrouver des comptes attaquables. L’impact de ce type d’attaquen’est pas seulement limité à une usurpation d’identité pourl’application Web. Un internaute utilise souvent les mêmesvaleurs d’identifiant et de mot de passe pour de nombreusesapplications présentes sur le Web. L’attaquant peut donctenter d’utiliser ces valeurs sur différentes applicationsWeb.

Il est possible pour l’attaquant de chercher des couplesidentifiant/mot de passe sans faire appel à la force brute.L’attaquant va simplement tenter d’utiliser des comptesgénéralement présents dans les applications Web, comme ceuxd’administration. Ceci est surtout possible lorsque lesapplications sont basées sur des outils Open Source qui ontdes comptes créés automatiquement avec des mots de passe pardéfaut connus du domaine public. L’attaquant n’a plus qu’àconsulter le code source pour trouver une liste restreinted’identifiants/mots de passe valide.

Les pages Web qui permettent de réinitialiser les mots depasse sont une faille importante pour l’usurpation d’identité.En effet, pour s’assurer de l’identité du demandeur, laplupart d’entre elles demandent une information que seule lapersonne est censée connaître. Hors avec les réseaux sociaux,les internautes partagent leur vie privée. Ces informationspersonnelles visibles de tous peuvent être les mêmes quecelles demandées dans les pages de réinitialisation de mot depasse. Dans ce cas l’attaquant peut définir un nouveau mot depasse qu’il pourra utiliser pour se connecter à l’application.

Pour voler un identifiant de session, l’attaque par laforce brute est également possible. Dans ce cas l’attaquant va

générer des valeurs et tenter de les utiliser commeidentifiant de session. S’il réussit à trouver une valeurvalide, il pourra utiliser l’application Web sans s’êtreauthentifié. Par ailleurs, une attaque XSS peut permettre derécupérer un identifiant de session présente dans le cookie del’internaute. L’identifiant de session peut également êtredécouvert par un attaquant en écoutant la transmission dedonnées sur le réseau, en consultant les fichiers dejournalisation sur le serveur par injection de commandessystèmes par exemple.

Une autre technique consiste à fournir un identifiant desession à la victime, par hameçonnage par exemple.L’utilisateur se connecte à l’application Web ets’authentifie. La session est créée en utilisant l’identifiantfourni. L’attaquant peut alors accéder au site en fournissantl’identifiant fixé. L’identifiant peut être généré ou obtenuen émettant une requête vers l’application cible de l’attaquesi l’application retourne un identifiant de session pour touterequête avant même l’authentification de l’utilisateur.

Si l’identifiant de session n’est pas généréaléatoirement mais est un nombre incrémenté à chaque ouverturede session, par exemple, l’attaquant peut arriver à deviner unidentifiant valide.

c. Bonnes pratiques

Concernant les systèmes d’authentification, l’applicationne doit accepter que des mots de passe suffisamment forts pouréviter d’être devinés rapidement par la force brute. Unelongueur minimale de huit caractères est ce qui recommandé parl’OWASP pour les applications critiques. De plus il doitcomporter au moins un chiffre, une lettre en minuscule et unelettre en majuscule.

Le message affiché lors d’un problème de validité del’identifiant ou du mot de passe doit être générique et nedoit pas donner d’indice quant à l’origine de l’erreur.

Pour contrer les attaques de force brute, le compte ciblépar l’attaque doit être verrouillé après cinq tentatives

consécutives infructueuses de connexion. La procédure dedéverrouillage peut être automatique après un laps de tempsprédéfini ou manuelle par un administrateur de l’application.

Dans la mesure du possible il est conseillé de ne pasdévelopper son propre mécanisme d’authentification. Il estpréférable d’utiliser un système existant éprouvé.

Concernant les identifiants de session, les applicationsWeb doivent limiter la durée de vie d’une session. Une périoded’inactivité maximale doit être définie. Si l’utilisateurn’utilise pas l’application pendant ce laps de temps, lasession devient inutilisable et l’utilisateur doit sereconnecter. Une session doit également avoir une durée de viemaximale au-delà de laquelle la session expire, même si lapériode d’inactivité autorisée n’était pas dépassée. Cesprécautions permettent de limiter le temps d’action d’unattaquant.

Du côté client, du code JavaScript doit fermer la sessionlorsque l’utilisateur ferme le navigateur. Cela permet desimuler une action de l’utilisateur pour se déconnecter del’application. Pour que l’utilisateur évite de perdre dessaisies non sauvegardée, du code JavaScript peut prévenirl’utilisateur que sa session va bientôt expirer.

L’identifiant de session doit être généré automatiquementet être suffisamment long pour se prémunir des vols parprédiction.

Pour détecter des attaques de force brute, il fautrégulièrement consulter les journaux d’activité à la recherched’évènements inhabituels, comme un nombre important de requêteutilisant des identifiants de sessions invalides.

1.4 Référence directe non sécurisée a un objet

a. Principe

Cette vulnérabilité existe simplement parce que lesparamètres de requêtes ne sont pas vérifiés avant traitement.Si le paramètre vulnérable fait référence à un fichier, à une

valeur dans une base de données, il suffit de reconstruire larequête avec une valeur de paramètre normalement interditepour y avoir accès.

Cette faille peut avoir des impacts importants si unutilisateur mal intentionné obtient par ce biais des accès àdes informations et des fonctionnalités pour lesquelles il n’aaucune autorisation.


Cette faille est une des bases de la vulnérabilitéexploitée par XSS. En effet, dans les exemples d’attaquesexposés précédemment, les paramètres récupérés ne sont pasvérifiés. Par contre, si ces valeurs avaient été contrôlées,les caractères spéciaux n’auraient pas été autorisés,empêchant ainsi l’envoi de code frauduleux au navigateur.

Si les paramètres sont passés en paramètre d’un lien, unutilisateur malintentionné peut aisément modifier l’adressepour accéder à des informations auxquelles il n’aurait pas dûavoir accès. L’exemple suivant reprend la table « comptes »qui va être interrogée par un script PHP pour afficher lenuméro de carte bancaire de l’utilisateur.

Figure 16 : Script PHP pour l’affichage du numéro de carte

Si l’utilisateur malveillant saisit dans son navigateurl’adresse de cette page avec pour paramètre «nom=nom_de_la_victime », il a alors accès au numéro de cartebancaire qu’il n’aurait jamais du pouvoir voir.

c. Bonnes pratiques

Pour protéger les données les plus confidentielles ou lesfonctionnalités les plus avancées, le WASC recommande dedemander à l’utilisateur de saisir à nouveau son identifiantet son mot avant de pouvoir y accéder. Ensuite il suffit de sebaser sur ces valeurs pour construire les requêtes.

1.5 Falsification de requete inter-sites (csrf)

a. Principe

L’attaque par falsification de requête inter-sites(Cross-Site RequestForgery ou session riding ou CSRF ou XSRF)a un fonctionnement assez proche d’une attaque XSS. Laprincipale différence est que l’utilisateur au travers de sonnavigateur ne sera pas la victime mais sera celui qui vaeffectuer une action malveillante sur l’application cible. Uneattaque CSRF va exécuter du code malveillant dans uneapplication Web au travers de la session d’un utilisateurconnecté.

Figure 17 : Principe d'une attaque CSRF par réflexion

Comme pour XSS, il existe deux modes opératoires :

Dans une attaque CSRF par réflexion (reflected CSRF),l’attaquant crée une page web qui comporte un formulaireinvisible par exemple. Ce dernier contient un script caché quilance des actions de l’application. L’attaquant piègel’utilisateur en mettant un lien vers cette page dans uncourrier électronique ou sur des réseaux sociaux. Quandl’utilisateur affiche cette page, le navigateur va interpréterle code malicieux et va tenter d’exécuter une fonctionnalitéde l’application cible. Si l’utilisateur s’y est récemment

connecté, l’application va exécuter la commande sans leconsentement de l’utilisateur. Cette attaque fonctionne carles informations d’authentification qui ont préalablement étésaisies par l’utilisateur sont envoyées automatiquement par lenavigateur au serveur. L’attaquant n’a donc pas besoin de seconnecter à l’application pour exécuter des commandesfrauduleuses. Cependant l’attaque ne fonctionne pas sil’utilisateur ne s’est pas connecté.

Dans une attaque CSRF stockée (stored CSRF), c’estl’application elle-même qui présente le code malicieux àl’utilisateur. Pour ce faire l’attaquant a réussi a inséré ducode malicieux dans les données de l’application Web. Chaquefois qu’un utilisateur parcourra la page qui va présenter cecode, le navigateur va l’interpréter et par conséquent vaexécuter une commande de l’application. L’application va alorsaccepter d’exécuter cet ordre comme si la demande provenait del’utilisateur. Cette attaque a plus de chance de réussir carl’utilisateur s’est déjà connecté et utilise l’application.L’attaquant n’a pas de besoin de piéger un utilisateur.

Figure 18 Principe d'une attaque CSRF stockée

Une attaque par CSRF rend les défenses contre les attaquesXSS inopérantes.


L’exemple suivant reprend la table « messages » et lescript PHP pour l’insertion de données. Si ce script se nomme« add_message.php », le site de l’attaquant pourra utiliser lecode suivant pour le faire exécuter par l’utilisateur :

Figure 19 : Code HTML pour réaliser une attaque CSRF

L’utilisateur en parcourant la page de l’attaquant estalors automatiquement redirigé vers la page « add_message.php» avec les paramètres numsujet=6, nom=CSRF et message=actionfrauduleuse.

c. Bonnes pratiques

Bien que XSS et CSRF soit proches dans le principe, seprotéger des attaques XSS ne permet pas de se protéger desattaques CSRF. Pour se protéger, il faut utiliser uniquementdes requêtes POST. Les méthodes GET doivent être bannies.Attention toutefois, dans les servlet Java la méthode «doGet() »fait appel à la méthode « doPost() » en redirigeantl’ensemble des paramètres. Dans ce cas l’utilisation derequêtes GET fonctionne. C’est pourquoi l’utilisation de POSTn’est pas une protection suffisante. Pour les pages quimanipulent des données sensibles, il faut demander àl’utilisateur de s’authentifier à nouveau. Cela permet des’assurer que l’utilisateur est conscient de l’action etl’approuve.

L’utilisateur doit toujours vérifier que le lien surlequel il clique est bien celui de l’application qu’il veututiliser.

1.6 Mauvaise configuration de sécurité

a. Principe

Cette faille de sécurité regroupe toutes lesvulnérabilités laissées ouvertes aux différents niveaux del’architecture de l’application Web. Pour chacun des serveurs

impliqués dans l’activité de l’application, le problèmeconcerne le système d’exploitation ainsi que les outilsinstallés pour servir l’application.

Pour chacun de ces composants, des failles sont connuesdu domaine public, ce qui facilite les attaques. S’ils ne sontpas mis à jour, l’attaquant peut exploiter les failles noncorrigées.

Pour de nombreux outils, des options sont installées pardéfaut alors qu’elles ne sont pas nécessaires au bonfonctionnement de l’application. Cette situation offre plusd’opportunités pour un attaquant.

De même de nombreuses applications sont installées avecdes comptes créés avec des mots de passe par défaut. Cescomptes et mots de passe sont les cibles privilégiées desusurpations d’identité.


En 2007 une faille est découverte dans l’extension mod_jkdu serveur http Apache. Ce module permet de renvoyer lesrequêtes http reçues par le serveur http au serveur de ServletApache Tomcat pour qu’il exécute les Servlets Java. Leproblème détecté est un dépassement de mémoire tampon (bufferoverflow). Le module ne gérait pas correctement les adressestrop longues contenues dans les requêtes http. Cela permettaità un attaquant de faire ouvrir un port d’écoute spécifiqueutilisable pour prendre la main sur le serveur. Tant que lecorrectif n’était pas publié et installé, les systèmesrestaient vulnérables. Le seul moyen de se protéger était dedésactiver le module s’il n’était pas utilisé.

Les codes sources des applications Web Open Source sontdisponibles aussi bien pour les développeurs légitimes quepour les attaquants. En parcourant ces fichiers, il estpossible de lire des commentaires laissés par les développeursindiquant qu’il y a un problème dont ils ont conscience maisqu’ils traiteront plus tard. Dans ce cas l’attaquant n’a plusqu’à exploiter cette faiblesse.

Les pages d’erreurs des serveurs http contiennent pardéfaut des informations sur l’erreur et sur le serveur httplui-même. En tentant d’accéder à une page inexistante, uneerreur de type « 404 page not found » est retournée àl’attaquant, de même que la version du serveur http. Dans cecas il suffit à l’attaquant d’étudier cette version pour enconnaitre les vulnérabilités et de les exploiter.

c. bonnes pratiques

L’ANSSI et l’OWASP font les recommandations suivantes :

Il faut désactiver les options inutiles des composantsafin de diminuer le nombre de vulnérabilités potentielles quece soit au niveau du système d’exploitation, du système degestion de bases de données ou du serveur http.

Il faut mettre à jour les différents composants del’architecture autant que possible en installant lescorrectifs dès qu’ils sont publiés. De plus, à l’installationil est préférable de choisir la version anglaise plutôt qu’uneautre langue. En effet, lors du développement de correctifsc’est toujours la version anglaise qui est privilégiée, lesautres versions étant corrigées plus tardivement.

Après l’installation il faut désactiver voire supprimertous les comptes inutiles. Le mot de passe des autres comptesdoit être modifié dès que possible. Les comptesd’administration par défaut doivent être verrouillés. Il fautpréférer l’utilisation de comptes d’administration créésmanuellement.

1.7 Stockage de données cryptographiques non sécurisées

a. Principe

Cette faille de sécurité englobe toutes les faiblessesliées à la protection du stockage des données. La meilleureprotection est la mise en place du chiffrement desinformations. Le CLUSIF définit le chiffrement comme « leprocédé grâce auquel on peut rendre la compréhension d'undocument impossible à toute personne qui n'en possède pas laclé. »

La principale faille concerne les données sensibles,c’est-à-dire les données dont la divulgation ou l’altérationou la non-disponibilité peuvent porter préjudice à leurpropriétaire, telles que le mot de passe ou l’identifiant desession. Si les données sont présentes en clair ou chiffréespar un algorithme faible, il existe un risque qu’un attaquantpuisse les consulter.


Certains moteurs de bases de données font payer l’optionde chiffrement. Pour des raisons d’économies, les responsablesdécident de stocker les données en clair dans la base dedonnées. Seul les transmissions de requête http sur le réseausont chiffrées. Pour se protéger du risque d’incendie sur lesite où sont installés les serveurs, les données sauvegardéessur bande sont envoyées sur un autre site une fois par mois.Si un agresseur intercepte cette sauvegarde pendant sontransfert, il aura accès aux données en clair.

c. Bonnes pratiques

Tous les moyens de stockage de données sensibles doiventêtre chiffrés. Il faut s’assurer également que la sauvegardedu moyen de stockage ne contient pas les données en clair.

Il ne faut pas utiliser d’algorithme de chiffrement ou dehachage faible, tels que MD5 ou SHA1 ni tenter de créer sonpropre algorithme. Il faut utiliser des algorithmes reconnuset éprouvés tels AES-256, RSA et SHA-256. Pour des raisons decapacité de calcul, l’ANSSI recommande que la taille minimaledes clés symétriques utilisées jusqu’en 2020 soit de 100 bitset de 128 bits au-delà de 2020.

1.8 Défaillance dans la restriction des accès à une url

a. Principe

Cette faille permet à un utilisateur d’accéder à desfonctionnalités de l’application, voire même des fichiers etrépertoires du serveur http sans y être habilité.

L’attaque par traversée de répertoires permet d’accéder àdes fichiers du serveur http notamment ceux contenant les clésprivées de chiffrement. Les applications vulnérables ouvrentdes fichiers dont le nom est donné en paramètre de la requêtehttp.

Une autre attaque consiste à deviner l’existence defichiers ou de répertoires. En effet de nombreux outilsdisposent d’une interface d’administration dont l’adressed’accès est du type «http://www.site_vulnerable.fr/admin/admin.php ». Dans ce casmême si l’utilisateur malintentionné n’y a pas accès autravers de l’application, il peut saisir directement l’adressepour l’ouvrir. Les applications vulnérables ne demandent pasde s’authentifier avant de pouvoir l’utiliser, la seuleprotection étant qu’aucun lien n’est mis à disposition pour yaccéder, ce qui n’est pas suffisant.

Une attaque équivalente consiste à ne pas spécifier denom de fichier dans l’adresse, par exemple «http://www.site_vulnerable.fr/admin/ ». Les serveurs httpvulnérables afficheront le contenu du répertoire.


L’exemple suivant montre une portion de code vulnérable àl’attaque par traversée de chemin. L’application estconstruite pour inclure du texte en fonction de la langue dunavigateur. Dans ce cas la langue est donnée en paramètre dela requête http, la commande PHP « includelang_nom_fichier.php» permet d‘inclure le contenu du fichier concerné.

Figure 20 Script PHP vulnérable à l'attaque par traversée de chemin

Si l’attaquant envoie la requête avec le paramètre «lang=../../../../etc/passwd%00 », il aura accès au fichier desmots de passe du système et tentera de se connecter au serveurhttp avec un des comptes ainsi trouvé.

Dans cet exemple l’attaque par traversée de chemin estpossible à cause de la faille Référence directe non sécuriséeà un objet.

c. Bonnes pratiques

Pour se protéger des défaillances dans la restriction desaccès à une URL, il ne faut pas autoriser les caractèresdouteux tels que « / » et « \ ».

Pour se prémunir des attaques par traversée de chemin, ilfaut établir une liste de fichiers utilisables et refuser toutautre fichier. La correction à apporter à l’exemple ci-dessusest la suivante.

Figure 21 Script PHP non vulnérable à l'attaque par traversée de chemin

Tous les répertoires doivent contenir un fichierindex.html, ce qui évite de pouvoir accéder au répertoire lui-même. De plus, les serveurs http doivent être configurés pourne pas permettre l’affichage du contenu des répertoires.

Pour éviter les accès à des fonctionnalités sansautorisation, ces dernières doivent être protégées envérifiant que l’utilisateur a le droit de les utiliser. Ne pasafficher de lien pour y accéder n’est pas une protectionsuffisante.

1.9 Protection insuffisante de la couche transport

a. Principe

Comme évoqué pour le stockage des données sensibles,celles-ci ne doivent apparaître en clair qu’aux personnesautorisées. Sur les Internet il existe un risque qu’unerequête ou une réponse http soit interceptée. Si elle contientdes informations confidentielles transmises en clair, alorsl’attaquant pourra les exploiter facilement.

Tous les réseaux de l’architecture de l’application Websont concernés, depuis le navigateur de l’utilisateur jusqu’austockage des données, en passant par le serveur web.


L’attaque du type « Homme du milieu » (ou « Man-in-the-Middle ») est une des attaques les plus répandues pour accéderaux données d’une application. Si un attaquant réussit àcompromettre un serveur proxy, il pourra intercepter toutesles communications. Si en plus ce serveur est responsable duchiffrement des flux http, il aura accès aux données les plussensibles qui devaient être chiffrées.

Si une partie de l’application seulement est protégée parchiffrement, alors l’application complète est vulnérable.Souvent, seule la page de connexion contenant le formulaire desaisie de l’identifiant et du mot de passe est chiffrée. Sil’utilisateur après s’être authentifié retourne sur des pagesnon chiffrées, alors des informations, telles que le nom del’utilisateur ou l’identifiant de session, peuvent êtretransmises en clair de page en page, exposant ainsi toutel’application à des attaques d’usurpation d’identité.

c. Bonnes pratiques

Si une application Web manipule des données sensibles ilfaut mettre en place du chiffrement SSL pour TOUTES les pages.De plus, les mots de passe et les identifiants de session nedoivent à aucun moment transiter en clair. Pour cela, il estpossible de configurer le serveur Web pour redirigerautomatiquement toutes les requêtes http vers les pageschiffrées.

La protection de la couche « transport » vient encomplément de la protection du stockage des données. Ainsi siles données stockées sont chiffrées, il faut s’assurer quetous les moyens de communications le soient aussi. Parexemple, la politique de sécurité pour les données médicalesexige que le médecin du travail et le patient soient les seulsautorisées à consulter ces informations. Pour cela, au niveaude l’application, il faut s’assurer que l’utilisateur est soitla personne concernée, soit le praticien. De plus, lesinformations ne doivent apparaître en clair à aucun autremoment que pour l’affichage. Cela concerne les flux decommunication entre l’utilisateur et les différents composantsde l’architecture tels que le serveur http ou la base dedonnées, mais aussi les moyens de stockage tels que lesfichiers, les bases de données ou les sauvegardes de cesderniers.

1.10 Redirection et renvois non valides

a. Principe

Les redirections d’adresse sont utilisées dans lesapplications Web pour effectuer un changement de page enfonction d’un paramètre.

L’utilisation de la redirection est particulièrementutilisée pour les attaques par hameçonnage (ou phishing). Encliquant sur un lien utilisant une page de redirection,l’utilisateur est automatiquement emmené vers une autre page.Cette redirection peut être utilisée dans le cadre d’uneattaque CSRF.


Le script suivant est un exemple de page de redirectionen utilisant la redirection par code HTML.

Figure 22 Script PHP de redirection automatique

Si un attaquant a connaissance d’une page de redirectionvulnérable, il peut l’utiliser dans un lien pour fairerediriger l’utilisateur vers une page Web.

Figure 23 Lien pour rediriger l'utilisateur vers une page malveillante

Dans ce cas l’utilisateur est leurré. Le lien pointe bienvers l’application, mais va le rediriger vers une pagemalveillante.

c. Bonnes pratiques

La redirection ne doit renvoyer qu’à des pages locales.Dans ce cas les caractères spéciaux doivent être prohibés.

En cas de changement d’adresse ou de déplacement d’unepage, il vaut mieux utiliser la redirection paramétrée dans leserveur http. Par exemple avec Apache il est possible deplacer un fichier « .htaccess » pour paramétrer lesredirections automatiques.

Figure 24 Exemple de redirection automatique configurée au niveau du serveurhttp

2. Récapitulatif des vulnérabilités et des moyens préventifs

Le tableau ci – après présente un récapitulatif des vulnérabilités auxquelles sont exposées les applications web selon OWASP et les moyens de les éviter.

Vulnérabilités Moyens préventifs

A1. Injection

Valider les entrées Echapper les caractères spéciaux Séparer les données non fiables

des commandes et requêtes

A2. Violation de Gestiond’Authentification et deSession

Rendre accessible aux développeursun ensemble unique de contrôlesd'authentification et de gestionde sessions.

Vérifier que chaque page estsoumise au mécanisme de contrôled’accès (fourni par le frameworkou par une librairie)

Prévenir les failles XSS

A3. Cross-Site Scripting(XSS)

Echapper toute donnée non fiableselon le contexte HTML dans lequel

elle sera insérée (corps,attribut, javascript, CSS ou URL,etc.).

Valider positivement les données. Pour les données complexes,

considérer la libraireOWASP’sAntiSamy ou le Java HTMLSanitizer Project.

Considérer Content Security Policy(CSP) pour se protéger desattaques XSS sur l’ensemble dusite web.

A4. Références directesnon sécurisées à un objet

Implémenter des référencesindirectes par utilisateur ou parsession.

Contrôler l'accès (vérifierl’existence d’une session)

A5. Mauvaise ConfigurationSécurité

Processus de déploiement etd’information

Processus de durcissementreproductible patches appliqués

Utiliser les scans et les auditspour la détection des futuresmauvaises configurations ouabsence de correctifs.

A6. Exposition de donnéessensibles

Politique SIB (Sauvegarde,Intégrité, Backup)

Identifier les menaces contrelesquelles l’on souhaite seprotéger (exemple: menace interne,utilisateurs externes) ets’assurer que les donnéessensibles sont chiffréescorrectement lors de leur stockageet de leur transport.

Ne conserver que les donnéessensibles nécessaires.

Choisir des algorithmes éprouvéset générer des clés robustes.

Stocker les mots de passe au moyend’un algorithme adapté à cetusage, tel que bcrypt, PBKDF2, orscrypt.

Désactiver la mise en cache etl'attribut "autocomplete" dans lesformulaires collectant des donnéessensibles

A7. Manque de contrôled’accès au niveaufonctionnel

Sécurisation forte des pagesd’administration

Utilisation d’une APId’authentification et de gestiondes droits

A8. Falsification derequête intersites

(CSRF)

Associer un utilisateur (sasession) avec une action

OWASP CSRF Guard

A9. Utilisation decomposants avec desvulnérabilités connues

Identifier tous les composants etles versions utilisées, ainsi queles dépendances (ex: le plugin desversions).

Surveiller les bases de donnéespubliques, les listes de diffusiondes projets et les listes dediffusion de sécurité afin des’assurer de la sécurité de cescomposants afin de les maintenir àjour.

Établir des politiques de sécuritépour l’utilisation des composants.

Ajouter si possible des filtres desécurités autour des composantsafin de désactiver desfonctionnalités et/ou des partiescomprenant des faiblesses ou desfonctions vulnérables.

A10. Redirection etRenvois non validés

Eviter l’utilisation desredirections et des renvois.

En cas d’utilisation, ne pasutiliser de valeur de destinationdans les paramètres utilisateur.

Vérifier que la valeur est valideet autorisée pour l’utilisateur siune valeur de destination doitêtre spécifiée.

Conclusion

OWASP (Open Web Application Security Project) est unecommunauté travaillant sur la sécurité des applications Web.Sa philosophie est d'être à la fois libre et ouverte à tous.Cette communauté est aujourd'hui reconnue comme référence dansle monde de la sécurité des systèmes d'information s’agissantdes applications Web. Ses différents projets (outils,documentations et codes) regorgent d’informations utiles pourtout niveau de compétence. Le développeur non initié audomaine de la sécurité verra cet univers démystifié, l’experty verra une base de connaissances sur laquelle il pourra sereposer. Les outils proposés en l’occurrence les différentstests de sécurité en matière d’audit sont efficaces même sicertains ne sont pas assez maintenus ou accumulent un retardpar rapport à d’autres solutions Open-source. L’OWASP restetoutefois un référentiel soutenu par le milieu professionnelet amène à une réflexion intellectuelle sur le domaine de lasécurité, auquel chaque responsable de projet WEB oudéveloppeur devrait être sensibilisé.

Fait par: DJIKE TAYOU

Documents

Transcript of Fait par: DJIKE TAYOU