securite des applications web

LES DOSSIERS TECHNIQUES

Scurit des applications Web Comment matriser les risques lis la scurit des applications Web ?

Septembre 2009

GT Scurit des applications Web

CLUB DE LA SECURITE DE LINFORMATION FRANAIS 30, rue Pierre Smard, 75009 PARIS

Tl. : +33 1 53 25 08 80 Fax : +33 1 53 25 08 88 e-mail : [email protected] Web : http://www.clusif.asso.fr

La loi du 11 mars 1957 n'autorisant, aux termes des alinas 2 et 3 de l'article 41, d'une part, que les copies ou reproductions strictement rserves l'usage priv du copiste et non destines une utilisation collective et, d'autre part, que les analyses et les courtes citations dans un but d'exemple et d'illustration, toute reprsentation ou reproduction intgrale, ou partielle, faite sans le consentement de l'auteur ou de ayants droit ou ayants cause est illicite (alina 1er de l'article 40) Cette reprsentation ou reproduction, par quelque procd que ce soit, constituerait donc une contrefaon sanctionne par les articles 425 et suivants du Code Pnal

Scurit des applications Web 3/20 CLUSIF 2009

REMERCIEMENTS

Le CLUSIF tient mettre ici l'honneur les personnes qui ont rendu possible la ralisation de ce document, tout particulirement :

Michel Frenkiel Mobilegov

Sbastien Gioria Groupe Y

Philippe Larue CBP

Vincent Maret Ernst & Young

Michel Maximin Crdit Logement

Enrick Moulin BT CyberNetworks

Ludovic Petit SFR

Philippe Sarafoglou PSA

Herve Schauer HSC

Arnaud Treps Accor

Patrick Vanhessche ADP

Nous remercions aussi les adhrents du CLUSIF ayant particip la relecture.


SOMMAIRE

I - Introduction ........................................................................................................................... 5 II - Les technologies Web, incontournables, mais porteuses de nouveaux risques.................... 6

II.1 - Des technologies omniprsentes................................................................................... 6 II.2 - Des environnements exposs ........................................................................................ 6 II.3 - Des rglementations et des responsabilits................................................................... 7 II.4 - Le rle du management................................................................................................. 7

III - Scurit des applications Web : mythes et ralits ............................................................. 8 III.1 - Mythe N1 Sans demande particulire, le dveloppeur me fournira une solution scurise .............................................................................................................................. 8 III.2 - Mythe N2 Seuls des gnies de linformatique savent exploiter les failles des applications Web ................................................................................................................. 8 III.3 - Mythe N3 Mon site Web est scuris puisquil est protg par SSL ................... 9 III.4 - Mythe N4 : Je suis protg contre les attaques, jai un firewall .......................... 9 III.5 - Mythe N5 : Une faille sur une application interne nest pas importante ............. 9

IV - Les principales failles de scurit des applications Web .................................................. 10 IV.1 - La gestion incorrecte de lauthentification, des habilitations et du contrle daccs 10 IV.2 - Les failles de type injection ................................................................................. 10 IV.3 - Les fuites dinformation ............................................................................................ 11

V - Quelles bonnes pratiques pour mettre en uvre une application Web scurise ?............ 12 V.1 - Formation et sensibilisation........................................................................................ 12 V.2 - Identification des besoins et apprciation des risques ................................................ 12 V.3 - Conception et implmentation.................................................................................... 13 V.4 - Recette de la scurit ............................................................................................ 13

VI - Vrification de la scurit des applications Web .............................................................. 14 VI.1 - Pourquoi vrifier ? ..................................................................................................... 14 VI.2 - Comment vrifier ?.................................................................................................... 14

VI.2.1 - Audit des spcifications ..................................................................................... 14 VI.2.2 - Audit de code ..................................................................................................... 15 VI.2.3 - Test dintrusion .................................................................................................. 15 VI.2.4 - Revue de linfrastructure dhbergement........................................................... 16

VI.3 - Automatisation........................................................................................................... 17 VI.4 - Quand vrifier la scurit dune application Web ? .................................................. 17

VII - Prise en compte des dveloppements externaliss........................................................... 18 VIII - Rfrences....................................................................................................................... 19


I - Introduction

Ce document sadresse aux managers, dcideurs et responsables mtier qui sont en charge de la mise en place et/ou du maintien en condition oprationnelle dun site Web Internet ou une application Web interne. Son but est de prsenter les risques de scurit propres aux technologies Web, et de dcrire les bonnes pratiques en terme de gestion de projet informatique et de gestion de risques qui permettent, durant le cycle de dveloppement et la vie de lapplication, de matriser ces risques.

Ce document na pas pour but de dcrire de faon dtaille les concepts, techniques ou outils de scurisation. Ces lments seront abords par un autre groupe de travail du CLUSIF, et le document rsultant compltera avantageusement le prsent document.


II - Les technologies Web, incontournables, mais porteuses de nouveaux risques

II.1 - Des technologies omniprsentes Lactivit des entreprises et administrations repose de plus en plus sur les technologies et applications Web. Leur facilit de mise en uvre et de dploiement les a rendues omniprsentes et incontournables, quil sagisse de sites de commerce en ligne, dapplications Intranet ou Extranet, ou de services Internet offerts ou utiliss par les entreprises. Les nouvelles applications sont aujourdhui presque systmatiquement dveloppes avec des technologies Web, et les anciennes applications sont souvent adaptes pour tre accdes via un navigateur Web.

II.2 - Des environnements exposs Des donnes critiques pour les entreprises et au regard de la loi sont dsormais gres par des applications Web. Or, des vols de donnes sensibles, des intrusions sur des sites Web ou des incidents lis la disponibilit des applications Web font la une de lactualit [1], [2], [3]. Des enqutes menes par des cabinets dexperts indiquent quune grande majorit des sites Web sont vulnrables des attaques. En outre, deux grandes tendances ont merg ces dernires annes sur le march de la scurit :

Lagresseur nattaque plus pour des motifs de prestige personnel, mais est m par lappt du gain, dessein de fraude ;

Les applications Web sont dsormais la cible privilgie des pirates / piratages. Le Gartner Group estime que 75% des attaques ciblent dsormais les applications.

Des sondages raliss aux tats-Unis suggrent que plus de 60 % des clients envisagent de ne plus traiter avec une entreprise en cas de menace sur leurs donnes personnelles suite une attaque informatique. Lactualit a montr rcemment limpact que peut avoir lindisponibilit dun site de commerce en ligne dans la presse. On imagine donc aisment les ventuelles consquences (financires, respect de la loi, impact sur limage, etc.) si une application web nest pas initialement conue, dveloppe, installe et exploite de faon scurise.


II.3 - Des rglementations et des responsabilits Les responsabilits des organisations face la scurit de l'information numrique sont croissantes : le lgislateur, les rglementations et les clients exigent de plus en plus de protection des donnes et de traabilit de la part des entreprises. Face laggravation des violations de scurit lies aux applications Web, laugmentation de leur nombre, et aux difficults quelles posent, la rigueur des rglementations et standards industriels sest renforce. De nouveaux rfrentiels tels que par exemple le standard de scurit des donnes de paiement PCI DSS intgrent dsormais la scurit des applications Web. Des rglementations rcentes stipulent que les entreprises doivent assurer le dveloppement et la maintenance de systmes et dapplications scuriss, et ciblent plus particulirement les vulnrabilits des applications Web. Aux Etats-Unis par exemple, ltat de Californie a promulgu le Notice of Security Breach Act 1 (Code civil de Californie 1798.821), galement connu sous le nom de Senate Bill 1386, qui impose une notification, aux partie concernes, mais aussi publique, en cas de compromission, avre ou suspecte, des donnes confidentielles dun client. Cest pourquoi on ne peut de nos jours voquer le sujet de la scurit des applications web sans parler du cadre lgal et rglementaire, tant pour une socit fournisseur de services, une socit ditrice de logiciels, un sous-traitant ou un dveloppeur que pour lentreprise utilisatrice ou le donneur dordre. En effet, la faon dont une application web est conue et dveloppe peut impacter la disponibilit, lintgrit et/ou la confidentialit des donnes. Par voie de consquence, la mise disposition dun service applicatif par une socit peut engager la responsabilit [4] - civile et/ou pnale - [5] de cette socit, tout comme celle de lditeur dun logiciel ainsi que celle du dveloppeur dune application.

II.4 - Le rle du management La scurit des applications Web ne peut donc plus tre ignore. Cest aujourdhui une question de management, qui doit tre traite spcifiquement, au-del des approches traditionnelles. Face aux risques lis des applications Web dont la complexit et lomniprsence ne cessent de crotre, les dcideurs doivent initialiser les actions permettant dassurer un niveau de scurit suffisant pour les applications Web dveloppes et/ou utilises par leur entreprise. De mme que pour la qualit, le management doit dfinir les objectifs lis la scurit, dlguer les tches de ralisation et sassurer de latteinte des objectifs. Ngliger de telles mesures reprsenterait une prise de risque consquente sur le march actuel. La scurit des applications Web doit tre prise en compte ds la conception, durant le dveloppement, lors de lintgration et durant toute la vie de lapplication. Elle doit faire partie intgrante de l'application, et non tre ajoute la fin du cycle de dveloppement. Au-del de la conception et de limplmentation, la scurit dune application Web doit en outre tre teste et vrifie avant la mise en production et lors de ses volutions. Les aspects techniques, les outils, les mthodologies sont ncessaires pour scuriser une application Web, mais il ne faut pas ngliger laspect humain. Le management doit donc sassurer que les diffrentes parties prenantes, MOA (Matrise dOuvrage), chef de projet, dveloppeurs, comprennent les enjeux, connaissent et mettent en oeuvre les bonnes pratiques.


III - Scurit des applications Web : mythes et ralits

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. En effet, les arguments avancs par certains vendeurs de solutions de scurit, la volont des acteurs du web de rassurer leurs clients, ou les efforts de vulgarisation portant sur la scurit de lInternet ont contribu nourrir plusieurs mythes nfastes.

III.1 - Mythe N1 Sans demande particulire, le dveloppeur me fournira une solution scurise La scurit dune application web nest pas inne. Au contraire, si des prcautions particulires ne sont pas prises, il est fort probable que des vulnrabilits existent dans la solution mise en place et quelles puissent impacter la confidentialit, lintgrit ou la disponibilit de lapplication et des donnes traites. Ce qui est vrai pour tout type dapplication lest encore plus pour une technologie lorigine conue pour permettre un accs totalement libre aux informations, et donc o les mcanismes dauthentification, de gestion de session et de contrle daccs ne sont pas natifs. Le donneur dordre doit donc faire en sorte que les bonnes pratiques de scurit soient comprises et appliques par le matre duvre, puis se doter des moyens de contrler le niveau de scurit de lapplication (voir ci-aprs le chapitre sur la vrification de la scurit).

III.2 - Mythe N2 Seuls des gnies de linformatique savent exploiter les failles des applications Web Au contraire, les failles de scurit au sein des applications Web sont le plus souvent faciles exploiter. Un attaquant na souvent besoin que dun simple navigateur Web pour identifier et exploiter des failles de scurit. Des outils complmentaires, comme des logiciels de proxy locaux, capables dintercepter les requtes entre le navigateur et le serveur Web sont disponibles gratuitement sur Internet. Les technologies Web reposent en outre sur un ensemble de protocoles, langages, et architectures ouverts, dont les spcifications sont librement accessibles. Nimporte qui peut donc tudier ces rfrentiels et les flux changs entre lapplication Web et le client, pour identifier des failles dimplmentation ou de conception.


III.3 - Mythe N3 Mon site Web est scuris puisquil est protg par SSL La technologie SSL a t conue pour viter que des donnes sensibles, comme des donnes de paiement, soient transmises en clair sur Internet, et les sites commerciaux arborent aujourdhui tous un logo site scuris par un certificat SSL . Lors de lexplosion du e-commerce, les medias ont expliqu quun internaute ne devait se considrer sur un site de confiance que si le fameux cadenas saffichait dans la barre dtat du navigateur Web. La drive vers le mythe du Mon site est scuris puisque il est protg par SSL sexplique donc facilement. Or, si SSL est un mcanisme de scurit ncessaire pour protger la confidentialit et lintgrit des donnes changes entre le client et le serveur, il nest pas suffisant pour protger totalement lapplication Web, notamment des attaques contenues dans le flux Web envoy par le client au serveur, qui passent donc dans le tuyau SSL .

III.4 - Mythe N4 : Je suis protg contre les attaques, jai un firewall Historiquement, les entreprises ont commenc se connecter Internet, en mettant en place des composants de scurit oprant au niveau du rseau, tels que des pare-feu rseau (firewall). Sils sont bien configurs, ces mcanismes sont et restent efficaces dans la plupart des cas pour empcher des accs non autoriss linfrastructure hbergeant les applications Web, comme les services rseau des systmes dexploitation ou des bases de donnes, et sont donc ncessaires. Malheureusement, ils sont insuffisants pour assurer la scurit dune application web, car les failles applicatives sont exploites via des canaux de communication normaux et ncessaires au bon fonctionnement de lapplication, et donc autoriss par le pare-feu.

III.5 - Mythe N5 : Une faille sur une application interne nest pas importante Une application interne, non publie sur Internet, est certes moins expose quun site Internet, accessible 24h sur 24 des centaines de millions dinternautes. Toutefois, si elle contient des failles, elle est vulnrable aux attaques menes par nimporte quelle personne, ayant accs au rseau interne, et disposant dun simple navigateur Web. En outre, lutilisation de la technologie web pour les applications internes a fait du navigateur Web un outil unique utilis la fois pour accder des ressources Web externes et internes lentreprise. Il peut donc exister des situations o un utilisateur interne accde en mme temps et partir du mme navigateur Web, une application Web interne sensible et un site Web externe, potentiellement sous le contrle dun attaquant. Or les technologies Web peuvent permettre un site Web malveillant de faire raliser par le navigateur dun utilisateur qui accde ce site des requtes sur un autre site, mme interne, et ce linsu de lutilisateur. Cest donc un moyen potentiel pour un attaquant externe dexploiter des failles sur une application Web intranet, depuis Internet, mme si un pare-feu est en place, en utilisant le navigateur Web comme un pivot de rebond.


IV - Les principales failles de scurit des applications Web

La majorit des failles de scurit que lon peut trouver dans les applications Web peut tre classe en trois grandes familles :

IV.1 - La gestion incorrecte de lauthentification, des habilitations et du contrle daccs Les paramtres dauthentification, dhabilitation et de contrle daccs soumis (par lutilisateur, ou dapplication application) sont bien souvent incorrectement pris en compte, grs ou contrls. Cette situation peut entraner des risques dusurpation didentit et daccs des fonctionnalits ou donnes illgitimes, et donc datteinte la confidentialit ou lintgrit des donnes. Le risque est exacerb par le fait que le fonctionnement par dfaut dun serveur Web est dautoriser laccs au contenu publi. Si un contenu spcifique doit tre fonctionnellement restreint certains utilisateurs seulement, le dveloppeur doit mettre explicitement en place des mcanismes dauthentification, dhabilitation et de contrle daccs pour protger chaque contenu (pages Web notamment) devant tre protg.

IV.2 - Les failles de type injection L'injection de donnes est une technique consistant insrer (i.e. Injecter) des donnes spcialement formes en entre d'une fonction, d'un programme ou d'un script afin de les dtourner de leur fonction d'origine (e.g. modification de base de donnes, rcupration dinformations sensibles, etc.). Des failles de type injection peuvent par exemple exister pour les accs en base de donnes (SQL injection), aux annuaires LDAP (LDAP injection) ou la construction de pages Web dynamiques (Cross Site Scripting) En injectant des donnes non prvues par lapplication Web, un attaquant peut influer sur le fonctionnement mme de lapplication, voire compromettre un environnement applicatif complet. Cest donc tout autant la disponibilit, que lintgrit et la confidentialit des donnes qui peuvent ne plus tre assures. Les attaques de type Injection sont facilites par la possibilit pour un attaquant dutiliser des outils de type proxy local librement disponibles sur Internet. Ces outils lui permettent dinjecter dans les champs de formulaires ou enttes HTTP des donnes spcifiquement composes pour permettre dexploiter les failles, quelles que soient les protections mises en place ct navigateur Web.


IV.3 - Les fuites dinformation Si les fonctionnalits ou composants internes une application ne sont pas suffisamment cloisonns , ou si lapplication fournit des pointeurs de rfrence des donnes non scurises, des fuites dinformations sensibles peuvent survenir (identifiants et comptes clients, types et versions de composants, requtes SQL, informations de session, donnes de saisie dans les formulaires, cookies, voire donnes applicatives.). Cette situation peut entraner un risque de perte de confidentialit. Elle peut galement fournir un attaquant des informations lui permettant de faciliter des attaques ultrieures (SQL injection par exemple).

Pour plus de prcision sur les failles de scurit des applications Web, le lecteur pourra se rfrer au Top Ten de lOWASP [6].


V - Quelles bonnes pratiques pour mettre en uvre une application Web scurise ?

Face aux risques lis la scurit des applications Web, il est primordial pour les organisations de mettre en uvre les bonnes pratiques permettant dobtenir des applications 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 :

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

V.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 [7].


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. [8]

V.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 lattaquant, une deuxime voire une troisime ligne soient 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,

une check-list qui permet de sauto-contrler et de sassurer que rien na t oubli ;

des API ou un framework 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 [9].

V.4 - Recette de la scurit A lissue de limplmentation, de mme quune recette est ralise par les utilisateurs, la scurit de lapplication doit tre vrifie, afin de valider de manire pragmatique que lapplication se comporte de manire scurise face aux attaques (voir ci-aprs le chapitre sur la vrification de la scurit).


VI - Vrification de la scurit des applications Web

VI.1 - Pourquoi vrifier ? 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.

VI.2 - Comment vrifier ? Plusieurs approches peuvent tre utilises pour vrifier la scurit dune application Web, chacune ayant ses avantages et ses inconvnients :

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


VI.2.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 ;

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 [10]

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


Lintrt du test dintrusion est de permettre :

de dceler dventuelles failles sur lapplication 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 [11]. Le CLUSIF a galement publi un document sur les tests dintrusion (non spcifique aux applications Web) [12].

VI.2.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 scurit 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.


VI.3 - Automatisation 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.

VI.4 - Quand vrifier la scurit dune application Web ? 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.


VII - Prise en compte des dveloppements externaliss

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, selon l'une des approches dcrites dans le chapitre vrification ci-avant. 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.


VIII - Rfrences

[1] http://www.lemonde.fr/technologies/article/2009/08/20/130-millions-de-cartes-bancaires-piratees-aux-etats-unis_1230199_651865.html

[2] http://www.zdnet.fr/actualites/internet/0,39020774,39703886,00.htm

[3] http://pro.01net.com/editorial/379143/une-attaque-massive-transforme-des-sites-web-en-nids-a-virus/)

[4] https://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex OWASP Secure Software Contract Annex : Cette annexe de contrat est destine aider les dveloppeurs de logiciels et leurs clients ngocier dimportantes conditions contractuelles relatives la scurit du logiciel dvelopper ou livrer. La raison en est que rien nest prvu dans la plupart des contrats, les parties ayant souvent des points de vue radicalement diffrents sur ce qui a t initialement effectivement convenu. De fait, la dfinition claire des responsabilits et limites de chacun est la meilleure faon de s'assurer que les parties puissent prendre des dcisions claires sur la faon de procder.

[5] CNIL : Loi n 2004-801 du 6 aot 2004 relative la protection des personnes physiques l'gard des traitements de donnes caractre personnel et modifiant la loi n 78-17 du 6 janvier 1978 relative l'informatique, aux fichiers et aux liberts et Article 35 - Code Pnal : Article 226-16 et Article 226-17

[6] http://www.owasp.org/index.php/OWASP_Top_Ten_Project

[7] http://www.opensamm.org/

[8] http://www.owasp.org/index.php/Threat_Risk_Modeling

[9] http://www.owasp.org/index.php/Category:OWASP_Guide_Project

[10] http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project

[11] http://www.owasp.org/index.php/Category:OWASP_Testing_Project

[12] https://www.clusif.asso.fr/fr/production/ouvrages/pdf/TestIntrusion.pdf

L E S P R I T D E L C H A N G E

CLUB DE LA SCURIT DE L'INFORMATION FRANAIS 30, rue Pierre Smard

75009 Paris 01 53 25 08 80

[email protected]

Tlchargez les productions du CLUSIF sur

www.clusif.asso.fr

securite des applications web

Documents