Par Philippe Léothaud, CTO de Bee Ware
Les applications déployées et mises en œuvre doivent répondre à des besoins de plus en plus stricts :
-impératif de dynamisme et de souplesse (mise à jour de l’application et/ou du contenu)
-haute disponibilité (clustering/grid/cloud, backup/restore, …)
-sécurité (des données, de l’applicatif client/serveur, des services mis à disposition).
La pratique sécuritaire préconisée par PCI-DSS définit notamment une obligation de moyens basée sur des solutions techniques. La conformité au PCI-DSS formalise les meilleures pratiques de sécurité qui se traduisent par des solutions d’ordre à la fois techniques et organisationnelles avec notamment le contrôle régulier des configurations déployées. Pour répondre aux exigences sécuritaires, trois approches techniques sont généralement employées:
-l’audit de code (tierce partie ou interne)
-les « pentests » (Tests de pénétration de systèmes, généralement réalisés par des tiers)
-le WAF (Web Application Firewall).
Toute la force de l’audit de code réside dans l’approche fine et précise de l’application. Chaque service mis à disposition par l’application doit être testé et analysé pour en déceler les failles. Si cette procédure peut être systématique elle nécessite malheureusement un effort constant (difficilement compatible avec les impératifs de dynamisme attendu pour une application Web) et requiert l’intervention d’experts (expert applicatif et sécurité).
De plus, cette approche sera réalisée de manière unitaire, Web Service par Web Service, ce qui ne permet pas toujours d’obtenir une vue globale sur le niveau de sécurité d’une application. Prenons par exemple un simple Web Service d’upload de fichier qui réaliserait une analyse sur le contenu d’un document fourni. De manière unitaire, ce Web Service peut être déclaré comme « sécurisé » à la suite d’une campagne d’audit de code.
Qu’en est-il de l’application? Si cette dernière fournit de nombreux services similaires, il devient évident que le serveur est susceptible d’être vulnérable aux attaques de type DOS (Denial Of Service) si un utilisateur demande en parallèle de multiple traitements de fichiers. Seule une approche globale de l’application peut révéler ce type d’information.
Les tests de pénétration permettent de pallier cette problématique. Que cela soit réalisé par approche « boîte noire » (application inconnue du testeur) ou par « boite blanche » (le testeur connait l’application, sa structure ou encore son code source) les tests de pénétrations seront réalisés par approche macroscopique et non plus unitaire.
Les failles testées seront celles qui mettent en œuvre plusieurs modules de l’application. Par exemple, pour détecter une faille XSS, on introduira le Javascript frauduleux dans un formulaire d’inscription, puis on testera son activation dans toutes les pages de l’application (qui semblent pourtant « inoffensives ») présentant les informations préalablement saisies.
Ces deux approches (audit/pentests) sont donc diamétralement opposées en termes de connaissance et de sécurité applicative. Le WAF permet de compléter parfaitement une politique de sécurité en palliant non seulement les carences de ces deux approches mais aussi en y apportant de nouvelles possibilités.
Au travers d’une analyse continue et transparente du trafic sur une application, le WAF est capable de consolider automatiquement sa politique de sécurité en apprenant et en comprenant le fonctionnement d’une application. Réalisé tout au long du cycle de vie d’une application Web, depuis le développement jusqu’à la mise en production, ce mécanisme d’apprentissage répond totalement aux impératifs de souplesse attendus sans pour autant nécessiter un investissement de ressources important (contrairement aux audits et aux pentests).
Ainsi, le WAF est capable de déceler de manière transparente toute utilisation frauduleuse de paramètres (XSS, XSRF, SQL injection, altération de paramètres, etc…) sans connaissance métier d’une application.Cette approche extrêmement fine peut se révéler trop unitaire dans certains cas. De manière plus macroscopique, le WAF est aussi capable de détecter des couples (clef + valeur) et d’y associer une politique de sécurité en se basant sur des informations statistiques collectées lors de l’apprentissage. On peut, par exemple, déterminer que le paramètre « id » doit être un entier positif de 1 à N pour toute l’application ou pour un ensemble de Web Services donné.
Élargissons encore l’angle de vue du WAF sur l’application. Ce dernier peut reconnaître les différents usages d’un script Web et y associer une politique de sécurité stricte. Par exemple, un script de gestion de compte utilisateur peut être utilisé pour ajouter, modifier ou encore effacer un compte. Il peut s’agir d’un seul et unique script dont le comportement (action réalisée) sera variable selon les paramètres donnés en entrée. Le WAF sera capable de déterminer chaque type d’appel et de créer une politique de sécurité différente pour chaque usage. Une création d’utilisateur avec un identifiant de compte fourni serait par exemple détecté comme une tentative d’usurpation d’identité. Inversement, une modification de compte ou un effacement sans identifiant d’utilisateur spécifié serait invalidé et traité comme une erreur.
On voit bien au travers de ces quelques exemples que le WAF permet d’atteindre une politique sécuritaire efficace et souple mais ce n’est pas le seul avantage de cette solution. En cas de détection de failles lors de l’étape de production, alors que les audits et les pentests ne permettent que de mettre en relief les failles, le WAF permettra pour sa part de sécuriser le service ou l’application (notion de patch virtuel) en attendant le prochain déploiement d’une version corrigeant la faille découverte. Plus qu’un outil passif, le WAF devient alors une part essentielle de la sécurité active d’une application.
