Scurit des applications web

ENG111 : Expos dentrainement

Auditeur : Abderrahim Jbali Anne : 2011/2012

Abderrahim Jbali - ENG111 Expos dentrainement

Table des matires :

Les fondamentaux de la scurit web. ................................................. 3 Anatomie dune application Web ......................................................... 3 Types dattaque et intrusion : ............................................................. 5 Interprtation des URLs : ................................................................ 5 Mauvais contrle des donnes entres par lutilisateur : ...................... 7 Injection SQL : .............................................................................. 8 Attaques sur les identifiants de session :......................................... 10 Cross Site Scripting (XSS): ........................................................... 11 Autres attaques : ......................................................................... 13 Dvelopper et dployer une application web scurise : ...................... 14 Formation et sensibilisation : ......................................................... 14 Identification des besoins et apprciation des risques ....................... 14 Conception et implmentation ....................................................... 15 Recette de la scurit.............................................................. 16 Vrification de la scurit des applications Web .................................. 16 Pourquoi vrifier ? ........................................................................ 16 Comment vrifier ?....................................................................... 16 1 - Audit des spcifications ........................................................ 16 2 - Audit de code...................................................................... 16 3 - Test dintrusion ................................................................... 17 4 - Revue de linfrastructure dhbergement ................................ 18 3 - Automatisation.................................................................... 18 4 - Quand vrifier la scurit dune application Web ? ................... 18 Rfrences :................................................................................... 19

Abderrahim Jbali - ENG111 Expos dentrainement

Les fondamentaux de la scurit web.

Aujourdhui, rares sont les DSI qui accepteraient de mettre en ligne une application Web sans stre assur quun minimum de scurit a t mis en place. En particulier, linstallation dun firewall, afin de protger des attaques venant dInternet une architecture Web est entre dans les murs, en tout cas dans les entreprises disposant dun budget informatique significatif. De mme, la mise en place dun certificat SSL, de faon protger la transmission dinformations sensibles (login, mots de passe, etc.), entre un navigateur web et un serveur, est de plus en plus frquente. Malheureusement, ce type de protection nest plus suffisant. Comme nous le montrerons tout au long de cet article, de nombreuses attaques, trs prjudiciables une application Web, peuvent tre ralises avec succs, mme travers un firewall correctement configur. Et linstallation dun certificat SSL nempche pas non plus ce type dattaques. Nous allons, dans cet article et aprs de brefs rappels sur le fonctionnement dune application Web et dun firewall, dtailler, exemples lappui, les principales attaques pouvant affecter une application Web. Nous traiterons galement des diffrentes manires de contrer ces attaques, nous prsenterons aussi les bonnes pratiques respecter pour la cration des applications web scurises.

Anatomie dune application Web

Une application Web est une application qui ne sappuie que sur le protocole HTTP ou HTTPS afin dtre pilote par un utilisateur distant.

Abderrahim Jbali - ENG111 Expos dentrainement

Ce dernier na besoin que dun simple navigateur Web ou dune application propritaire utilisant le protocole HTTP/HTTPS. Lavantage des applications Web est que lutilisateur peut se situer trs loin de lapplicatif et travailler travers Internet, au besoin via un VPN chiffr (type IPsec).

Remarque : contrairement une ide reue trs rpandue, lutilisation de SSL ne suffit pas protger une application Web. Le chiffrement SSL (sans utilisation de certificats clients X.509) ne concerne que la confidentialit, et ne protge pas des intrusions.

Pour permettre lutilisation dune application Web, il suffit que le firewall protgeant celle-ci ne laisse entrer que le protocole HTTP, en gnral sur le port TCP 80 (et ventuellement HTTPS sur le port TCP 443). Dans ces conditions, il semble difficile dattaquer une application Web. Pourtant, nous allons voir qu travers ce seul port 80, considr comme amical mais devenu un port fourre-tout par lequel passent de plus en plus de flux et de protocoles (DCOM, RPC, SOAP, XML, streaming sur HTTP, ), il est possible de lancer des attaques extrmement dangereuses.

Les diffrentes sortes dattaques sur les applications Web sont les suivantes : Interprtation des URLs Mauvais contrle des donnes entres par lutilisateur Injection de code SQL Attaques sur les identifiants de session Cross Site Scripting (XSS) Autres attaques

Abderrahim Jbali - ENG111 Expos dentrainement

Types dattaque et intrusion :

Interprtation des URLs :

Les URLs utilises dans le cadre dune application Web sont du type : http://www.domaine.fr/chemin/fichier.ext?param1=x&param2=y Une telle URL est compose de plusieurs parties : - http:// : protocole utilis - www.domaine.fr : adresse du serveur (FQDN) - chemin : arborescence de rpertoires sur le serveur Web - fichier.ext : fichier lu ou excut (son extension .ext est trs importante) - param1 et param2 : paramtres dexcution, interprts soit au niveau des composants mtiers, soit directement au niveau de la base de donnes. Chacune de ces parties est susceptible dtre attaque : Protocole : on peut par exemple essayer de remplacer le protocole https:// par http:// afin de dsactiver une authentification par certificat client.

Serveur : on peut le remplacer par son adresse IP ou par les noms de domaines dautres sites hbergs sur le mme serveur, afin davoir accs dautres parties du site.

Abderrahim Jbali - ENG111 Expos dentrainement

 Chemin : on peut tenter de naviguer dans larborescence pour accder des parties du site non autorises ou pour remonter dans larborescence par lutilisation de /../../ , ou en utilisant des vulnrabilits particulires (le bug Unicode dIIS, par exemple).

Exemple 2 : LURL suivante : http://www.vulnerable.com////////////////////////////////////// permettait, sur un serveur Web Apache, de rcuprer la liste des fichiers du rpertoire racine, mme sil existait un fichier par dfaut (index.html). Fichier : son extension va dterminer de quel type dexcutable il sagit : CGI, scripts ASP, HTR ou autre code excutable, etc Plusieurs types de fichiers ont connu des vulnrabilits attaches leur mode dexcution, et en particulier leur interprteur. Ainsi, cest une vulnrabilit dans le filtre ISAPI dIIS, qui interprte les fichiers .IDA/.IDQ, qui a permis la propagation du ver CodeRed. Paramtres : la manipulation des noms de paramtres et de leur contenu peut conduire des effets dangereux. Cela sera abord plus en dtail au paragraphe 2.

Les consquences de ces attaques peuvent tre la divulgation dinformations importantes, laccs au code source des scripts ou au contenu des fichiers, lexcution de commandes sur le serveur, ou mme lobtention dun shell sur le serveur, ventuellement sous un compte privilgi (SYSTEM sur Windows NT/2000/XP/2003, par exemple). Pour contrer les attaques ci-dessus, il convient de prendre en compte les recommandations suivantes :

Abderrahim Jbali - ENG111 Expos dentrainement

 Scuriser le systme dexploitation et le serveur Web (appliquer en particulier les derniers patches de scurit, chrooter le service, ) Installer larborescence Web sur une partition ddie Contrler strictement larborescence Web et supprimer les rpertoires inutiles Dsactiver le directory browsing sur lensemble du site Web Supprimer tous les filtres, interprteurs de scripts, CGI et autres excutables inutiles Supprimer tous les fichiers inutiles sur un serveur de production, notamment les pages dexemples Appliquer des permissions daccs strictes sur les fichiers au niveau du serveur Web mais aussi du systme de fichiers. En particulier, lutilisateur anonyme ne doit avoir que des permissions en lecture sur les pages statiques Utiliser un filtre dURLs (par exemple le module mod_rewrite pour Apache ou le filtre ISAPI URLScan pour IIS) et appliquer des rgles strictes afin de contrler, de rcrire ou dinterdire toutes les URLs contenant des caractres dangereux comme les caractres Unicode Installer un reverse proxy (module mod_proxy dApache, par exemple) : voir le paragraphe 6 sur le filtrage applicatif Enfin, envisager linstallation dun IDS(systme de dtection dintrusion) sur la DMZ hbergeant le serveur Web et/ou le reverse proxy, afin de dtecter les attaques classiques comme la remonte dans larborescence Web.

Mauvais contrle des donnes entres par lutilisateur :

Au cours des audits et tests dintrusion, les spcialistes en audit de scurit rencontrent encore trop souvent des applications Web o le contrle des entres par lutilisateur se fait uniquement ct client. Dans ce cas, il faut toujours considrer quun attaquant pourra outrepasser le contrle effectu de son ct et donc envoyer les donnes quil dsire au serveur, laide dun proxy intrusif par exemple. La rgle adopter est de ne jamais faire confiance du code tournant ct client, comme des applets Java par exemple. En effet, ce code pourra toujours tre dcompil, analys et modifi pour effectuer les tches voulues par un attaquant. Considrons le cas dune page Web permettant deffectuer un virement bancaire. Par prcaution, la banque limite les virements par Internet 10000 Euros. Un script JavaScript contenu dans la page HTML contrle en temps rel le montant saisi et empche toute validation avant que le montant soit correct. Dans ces conditions, il suffit de modifier le script, ou mme simplement de dsactiver JavaScript, pour pouvoir saisir le montant voulu et valider le formulaire. La recommandation qui simpose est donc de toujours contrler la validit des donnes fournies par lutilisateur au moins ct serveur. Ce contrle peut bien sr tre doubl ct client pour des raisons dergonomie, mais le contrle final devra toujours avoir lieu ct serveur.

Abderrahim Jbali - ENG111 Expos dentrainement

Dautre part, il existe des caractres spciaux dont la signification, au sein dune chane alphanumrique, peut respecter une syntaxe particulire au niveau dun langage de programmation ou dun systme dexploitation, ce qui peut conduire lexcution de commandes hostiles. Ces caractres figurent parmi les suivants : !@$%^&*()-_+`~\|[]{};:'"?/,.>< Ainsi, le caractre * est interprt sur UNIX comme lensemble des fichiers contenus dans le rpertoire courant. De mme, le caractre ; est un sparateur, les caractres < et > effectuent des redirections, % permet dentrer des caractres par leur code hexadcimal, etc Il est donc indispensable de filtrer ces caractres lintrieur des donnes fournies par lutilisateur, en les codant en leurs quivalents en HTML ( > devient &gt ; , < devient &lt ;, etc), ou en leur ajoutant un caractre dchappement ( \ par exemple), ou encore en les supprimant, ou enfin en refusant purement et simplement la transaction en demandant lutilisateur de modifier sa saisie. Pour rsumer, les recommandations ncessaires pour contrer la saisie de donnes hostiles par un utilisateur sont les suivantes : Ncessit dun double contrle ct client plus ct serveur Comptage du nombre de paramtres et de leur nom Neutralisation des caractres spciaux Contrle de la longueur des donnes Validation du type des donnes (date, chane, nombre) Contrle de lintervalle de validit des donnes (dans labsolu) Vrification de la validit relle des donnes (en relatif, dans une base de donnes) Limitation du nombre de saisies de donnes par unit de temps. Ceci permet dviter les attaques de type force brute et peut simplmenter par exemple en multipliant chaque fois le temps dattente avant la fin de la transaction par deux entre deux transactions identiques.

Injection SQL :
Linjection SQL peut tre une consquence directe dun mauvais contrle des donnes entres par lutilisateur. En effet, les caractres et ; peuvent tre utiliss pour enchaner plusieurs requtes SQL la suite lune de lautre. Considrons par exemple une page HTML comprenant un formulaire dauthentification avec un champ Login et un champ Password. La requte SQL tournant sur le serveur est la suivante :

Abderrahim Jbali - ENG111 Expos dentrainement

SELECT user FROM table_users WHERE champ_login=login AND champ_password=password

Si maintenant un attaquant saisit la chane suivante dans le champ Login : Administrateur; -La requte excute finalement sera la suivante:

SELECT user FROM table_users WHERE champ_login=Administrateur; -- AND champ_password=password

Le rsultat est un contournement de lauthentification : on se retrouve logu en tant quAdministrateur. Le cas le plus simple dinjection SQL consiste sauthentifier dans une application Web en saisissant un login existant et nimporte quel mot de passe suivi de OR 1=1 . Lauthentification tant vrifie par comparaison, le rsultat boolen de la vrification du mot de passe est toujours vrai, ce qui permet dobtenir laccs lapplication. Il faut noter que le filtrage des caractres spciaux ne suffit pas se protger contre linjection de code SQL. En effet, considrons la saisie suivante :

toto UNION ALL SELECT champ_Password FROM table_Users WHERE champ_Login LIKE admin

Aucun caractre spcial (autre que le _ utilis pour des raisons de lisibilit) nest utilis, et pourtant la requte obtenue rcupre la liste des mots de passe des administrateurs. De plus, certains gestionnaires de base de donnes offrent des fonctions supplmentaires potentiellement dangereuses. Par exemple, Microsoft SQL Server possde par dfaut un certain nombre de procdures stockes dadministration pouvant conduire des fuites dinformation et des intrusions.

Abderrahim Jbali - ENG111 Expos dentrainement

Il existe donc beaucoup de techniques dinjection de code SQL. Pour contrer ce type dattaques, il est ncessaire deffectuer un filtrage beaucoup plus prcis du contenu des donnes saisies par les utilisateurs. Il faudra en particulier interdire ou chapper les mots cls comme SELECT, INSERT, UNION, LIKE, etc Lutilisation de fonctions de substitution et dexpressions rgulires est ici trs utile. Il est prfrable dutiliser des procdures stockes, moins sujettes linjection, et ne pas laisser de requtes SQL dans les pages de script. Il est ncessaire ensuite de scuriser la configuration du service de base de donnes : Suppression des comptes inutiles crs par dfaut et cration de comptes avec des privilges rduits (tous les utilisateurs authentifis ne doivent pas utiliser le mme compte pour effectuer toutes les transactions dans la base de donnes) Suppression des procdures stockes prsentes par dfaut Application de permissions daccs en lecture, suppression, excution sur les tables, les procdures stockes et les autres objets de la base de donnes. Il convient enfin de rdiger toutes les requtes SQL de son application avec soin, en utilisant une syntaxe la plus stricte possible, avec typage systmatique (chanes entoures de par exemple) et vrifications de conformit aux diffrents stades de traitement des requtes, aussi bien au niveau des composants mtiers que des procdures stockes dans la base de donnes.

Attaques sur les identifiants de session :

Contrairement au paradigme client/serveur traditionnel, le protocole HTTP est un protocole dconnect. Cest--dire quentre deux requtes, la connexion entre le client et le serveur est coupe. Le serveur ne peut donc pas reconnatre un client qui a dj commenc une transaction dans lapplication Web. Pour remdier cela, on utilise un identifiant de session, chang chaque page entre le client et le serveur, que ce soit au niveau du cookie, de lURL ou dun champ cach de formulaire. Le serveur maintient un contexte de transaction pour chaque identifiant de session gnr. Une attaque classique consiste voler la session dun utilisateur qui vient de sauthentifier sur le systme en essayant de deviner la valeur de son identifiant de session. Si la valeur de celui-ci est dcouverte, un attaquant peut alors se faire passer pour lutilisateur lgitime en injectant lidentifiant rcupr dans sa propre session, laide dun proxy intrusif par exemple. Un identifiant de session se prsente par exemple ainsi : HTTP/1.1 200 OK Date: Mon, 17 Jun 2003 11:43:27 GMT

Abderrahim Jbali - ENG111 Expos dentrainement

10

Server: Apache/1.3.26 Set-Cookie: session=0001WVXSDWAACAB4EMYGBIB0NXI; path=/ Content-Type: text/html Si on essaie de rcuprer un grand nombre didentifiants successifs, on peut ensuite effectuer une tude statistique afin de dterminer des vulnrabilits dans la mthode de gnration de ces identifiants. On peut par exemple remarquer que le jeu de caractres utilis est faible, ou que lidentifiant de session possde des parties fixes ou variant lentement. Aprs une analyse plus pousse, on peut identifier la faon dont chaque partie de lidentifiant est construite. Il est souvent possible de dvelopper un outil qui va permettre de diminuer considrablement lespace de valeurs de cet identifiant, et qui va automatiser la recherche dune valeur valide de celui-ci. On peut ainsi augmenter les chances de trouver une bonne valeur une sur 1000 3000 parfois, ce qui est extrmement peu : quelques minutes seulement suffisent pour voler la session dun utilisateur authentifi. Il est donc indispensable de vrifier la qualit du gnrateur alatoire et ltendue de lespace de valeurs des identifiants de session de son application Web. Cette tendue doit tre suffisamment grande pour quune attaque en force brute ne puisse pas tre mene dans un dlai rduit. Il est dconseill dutiliser les fonctions de gnration didentifiants fournies en standard avec certains logiciels ou environnements de dveloppement du march. Il est parfois prfrable dcrire soi-mme une fonction de gnration des identifiants de session plus robuste, mais qui devra tre vrifie soigneusement. Il est toujours prfrable de prvoir une dure maximale de validit dune session.

Cross Site Scripting (XSS):

Le principe du Cross Site Scripting (ou XSS) est dattaquer les utilisateurs de lapplication plutt que lapplication elle-mme. Pour cela, lattaquant provoque lenvoi la victime, par le site Web lgitime, dune page hostile contenant du code malveillant. Cette page est excute sur le poste de la victime, dans le contexte du site Web dorigine (zone Internet, sites de confiance, ), et dans le contexte de scurit de lutilisateur courant. Lexemple le plus simple est celui qui consiste provoquer une erreur HTTP 404 chez les victimes. Si le site www.banque.com ne filtre pas de faon correcte les donnes envoyes par les utilisateurs, un attaquant peut saisir le texte suivant sur une page accde par dautres utilisateurs : <A HREF=http://www.banque.com/<script> alert(document.cookie)</script>">Click Here</a> Les internautes recevront la page suivante sils ont cliqu sur le lien ci-dessus : <HTML>404 Page Not Found:<script>alert(document.cookie) </script></HTML>

Abderrahim Jbali - ENG111 Expos dentrainement

11

Le script contenu dans cette page derreur 404 va provoquer laffichage des cookies relatifs au site www.banque.com. Il suffit un attaquant de les rcuprer pour se faire passer ensuite pour lutilisateur lgitime auprs du site de la banque.

Ce type de vulnrabilit est prsent sur de nombreux sites, forums et webmails qui interprtent le code JavaScript prsent dans leurs pages. De nombreuses vulnrabilits de ce genre, extrmement simples exploiter mais difficiles filtrer, ont fait les gros titres dans certaines publications. Ces annonces taient exagres, mais il est vident que la lutte contre les codes mobiles hostiles est sans fin. Les prcautions prendre sont les suivantes : Ct serveur: Maintenir le serveur Web jour (correctifs de scurit) Contrler la validit des saisies des utilisateurs, notamment les balises <script>, les incohrences du type <img src="javascript: ">, etc Ce contrle peut galement tre fait au niveau des antivirus ct serveurs effectuant galement un contrle du le flux HTTP. Ct client: Maintenir les navigateurs et clients mail jour (correctifs de scurit) ; Durcir leur configuration le plus possible.

Abderrahim Jbali - ENG111 Expos dentrainement

12

Autres attaques :
Dautres attaques traversant les firewalls peuvent tre menes contre des applications Web : Mcanismes dauthentification bass sur Java, JavaScript ou ActiveX : A viter : les applications utilisant ces technologies sont sujettes, comme nous lavons vu, des manipulations effectues ct client permettant un attaquant doutrepasser le mcanisme dauthentification. Contrle daccs bas sur le header HTTP_REFERER : A viter : la manipulation des headers laide dun proxy intrusif est facile. Manque de r-authentification : Le manque de r-authentification au niveau de certaines fonctionnalits critiques (comme le changement du mot de passe de lutilisateur, par exemple) permet souvent un attaquant de prendre le contrle dun compte. Mauvaise gestion du contexte utilisateur : La mauvaise gestion du contexte utilisateur peut permettre une augmentation progressive de privilges conduisant la prise de contrle total de lapplication par un attaquant. Il convient de contrler strictement et chaque page le contexte de scurit (lutilisateur est-il authentifi ? Quels droits possde-t-il ?). Attaques ct client: Il sagit dattaquer directement les utilisateurs de lapplication plutt que lapplication elle-mme. Ce genre dattaques est rendu possible principalement par les langages excuts ct client (VBScript, Flash, DHTML, XML, javascript, Applets Java, ActiveX, CSS, ). L encore, il est indispensable de maintenir les navigateurs et clients mail jour et de les scuriser le plus possible. Man in the middle: Une attaque dite man in the middle consiste intercepter les requtes du client et les relayer vers le serveur distant lgitime et inversement intercepter les rponses du serveur et les relayer vers le client. Il est possible au passage, si ncessaire, de modifier la vole les donnes fournies par le client et/ou les rponses du serveur. Cette attaque est possible mme si le serveur de destination utilise un chiffrement par SSL : il suffit que le serveur intercepteur possde lui aussi un certificat serveur et que le client clique sur Accepter lorsque son navigateur lui propose dutiliser ce certificat pour dialoguer avec le serveur distant lgitime. Cest ce que fera tout utilisateur peu attentif ou qui ne sera pas au fait des problmes de scurit. Il ne reste plus alors au serveur intercepteur qu dchiffrer dun ct et rechiffrer de lautre, la vole. Le seul moyen de se prmunir contre ce type dattaque est dimposer une authentification ct client par lutilisation de certificats clients X.509. Le serveur intercepteur ne pourra alors plus se faire passer pour le client auprs du serveur distant lgitime car il ne dispose pas de la cl prive du client.
Abderrahim Jbali - ENG111 Expos dentrainement 13

Dvelopper et dployer 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 ouvre 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 couts et les dlais de ralisation. En effet, plus la scurit est prise en compte tardivement dans les tapes de dveloppement, plus le cout 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 :

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

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.

Abderrahim Jbali - ENG111 Expos dentrainement

14

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

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.

Abderrahim Jbali - ENG111 Expos dentrainement

15

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

Vrification de la scurit des applications Web

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.

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

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

Abderrahim Jbali - ENG111 Expos dentrainement

16


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]

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 :

Abderrahim Jbali - ENG111 Expos dentrainement

17

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

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.

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.

4 - Quand vrifier la scurit dune application Web ?

Abderrahim Jbali - ENG111 Expos dentrainement

18

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.

Rfrences :
CLUB DE LA SECURITE DE L'INFORMATION FRANAIS : http://www.clusif.asso.fr/ The Open Web Application Security Projet https://www.owasp.org

Abderrahim Jbali - ENG111 Expos dentrainement

19