Académique Documents
Professionnel Documents
Culture Documents
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
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
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.
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 :
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.
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 > ; , < devient < ;, 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 :
Si maintenant un attaquant saisit la chane suivante dans le champ Login : Administrateur; -La requte excute finalement sera la suivante:
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.
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.
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.
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.
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
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.
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.
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).
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 ;
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.
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].
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.
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
19