Web Application Firewall 101

1. Naissance du Web Application Firewall

Il y a 25 ans, une équipe de physiciens du CERN [1], désireuse de partager simplement des documents numériques, nous a gratifiés d’un protocole qui allait changer à jamais notre manière d’échanger de l’information : HTTP (pour HyperText Transfert Protocol).

Quelques centaines de millions d’applications web plus tard [2], HTTP est devenu le véhicule de la plupart des données et services sensibles des entreprises et attire d’autant les convoitises. La glorieuse époque durant laquelle le Grand Kevin spoofait des adresses IP pour pénétrer un réseau protégé nous apparaît bien lointaine. Grâce au Web, tout un chacun peut injecter du SQL, du script, et autres joyeusetés à travers le plus performant des firewalls réseau.  En effet, ceux-ci n’inspectent pas le contenu des paquets qu’ils filtrent. Après tout, une attaque HTTP qui cible une application ou le serveur web qui l'héberge n’est qu’une suite de paquets TCP/IP parfaitement standards du point de vue protocolaire.

Il fut un temps où l’essentiel des investissements en sécurité des entreprises reposait sur deux piliers : le firewall et l’antivirus. Quelques mauvaises langues pourraient arguer que cela n’a guère changé depuis. Cependant, vers la fin des années 90, les entreprises ont appréhendé l'inéluctable essor du Web et puisque l’ouverture des SI allait crescendo, il fallait un compagnon au firewall capable d’analyser le trafic HTTP. Les éditeurs ont alors adopté une stratégie proche de celle de l’équipe de Tim Berners-Lee en son temps : déployer une solution de sécurité dédiée à l'analyse des contenus sans modifier l'architecture de sécurité existante. Le WAF (pour Web Application Firewall) est alors apparu, placé en aval des firewalls réseau.

Ce positionnement, à cheval entre le monde du réseau et celui des applications n’allait simplifier ni son acceptation dans l’entreprise, ni la vie de ceux qui auraient à l’administrer...

2. Plusieurs modes d'implémentation

Lorsque les premiers WAF sont déployés, les compétences pour les administrer sont rares dans les équipes de sécurité traditionnellement formées aux équipements réseau. En effet, les WAF requièrent une connaissance approfondie de technologies encore peu maîtrisées telles que la configuration des serveurs web, la gestion des flux applicatifs et, surtout, la sécurisation de ces applications. Ces nouveaux produits sont très technologiques et il est difficile alors de percevoir leur intérêt stratégique. Au début des années 2000, le volume et la criticité des données qui transitent sur Internet ne sont pas les mêmes qu'aujourd'hui. On trouve encore à cette époque nombre de lignes spécialisées et de protocoles d’échanges propriétaires. On vit les grandes heures de l’EDI, rythmées par le chant des modems...

Même si les RSSI s’accordent rapidement sur la nécessité de l’inspection des contenus à destination d’applications web qui deviennent critiques, il reste à localiser le meilleur endroit pour l’opérer. Le positionnement choisi va déterminer la responsabilité de l’équipement et donc des risques associés. Les éditeurs vont proposer à leurs clients trois types d’implémentation de la fonctionnalité de filtrage des attaques web.

2.1 Des solutions sur le serveur


Le plus célèbre exemple est mod_security qui dès 2002 vient renforcer le serveur Apache. Disponible par la suite pour Microsoft IIS et NGINX, il s’agit d’un module qu’on greffe sur le serveur web afin de filtrer le contenu des requêtes. Le serveur web reçoit la requête et la soumet au WAF pour inspection avant de la transmettre au serveur web si elle ne présente pas de critère offensif. Peu de WAF de ce type vont émerger. Leur avantage principal réside dans leur intégration simplifiée, en particulier dans la mesure où ils ne vont pas rompre la connexion SSL entre le client et le serveur. Le principal frein à leur développement sera le souhait d’épargner les performances des serveurs web, afin qu’ils se consacrent à leur tâche principale : servir des pages toujours plus complexes à générer et donc gourmandes en ressources. La nécessité d’intervenir sur les serveurs de production pour les mises à jour de ces modules conduira leurs éditeurs à les faire tous évoluer vers un mode reverse-proxy sur une plateforme dédiée (cf. infra).


2.2 Des appliances dédiées

Les plus anciens acteurs du secteur (NetContinuum, KaVaDo, MagniFire, Teros, etc.) proposent à leurs clients, essentiellement outre-Atlantique, des solutions dès le début des années 2000. Toutes ces sociétés ont été acquises entre 2004 et 2005 par des géants de la sécurité (respectivement Barracuda, Protegrity, F5 et Citrix). L’Europe et la France en particulier ne sont pas en reste avec un grand nombre d’acteurs. 
Les WAF sous forme d’appliances sont placés en coupure du trafic Web qu’ils peuvent intercepter de différentes manières :

2.2.1 Reverse-proxy

La plus commune est le reverse proxy ou serveur mandataire, qui se fait passer aux yeux des clients pour le serveur web et termine l’échange avant d’analyser les requêtes et les transmettre en tant que client cette fois au serveur « réel. » Ce dernier n’est plus obligatoirement exposé en DMZ. Seul le reverse proxy est visible depuis l’extérieur.

2.2.2 L2/L3

Une autre méthode d’implémentation du WAF est le pont L2 ou le transparent proxy L3. Le WAF n’est plus en coupure. Il « écoute » le trafic et ne filtre que ce qui le concerne, à savoir le trafic web. Ce type d'implémentation a pour avantages de ne pas modifier l’architecture existante et d’autoriser des performances très importantes, mais ne permet pas l’utilisation des fonctionnalités additionnelles d’altération du trafic comme la réécriture d’URL par exemple et limite l’utilisation de SSL.

L’implémentation du WAF sous forme d’appliances a fortement contribué à son essor. Disposer d’un équipement dédié à la sécurité des flux web a permis d’isoler ces fonctionnalités des serveurs web pour les confier aux équipes de sécurité qui peuvent intervenir sans interférer dans le cycle de vie des applications. L’inverse n’étant pas forcément vrai à tel point que l’évolution de la nature des applications entraîne une remise en question des WAF (cf. « Forces et Limitations »).


On a aussi profité de ce positionnement en amont pour déporter sur les WAF certaines fonctionnalités des serveurs web comme la compression HTTP ou la terminaison SSL. Les architectes les plus fortunés avaient déjà externalisé ces optimisations sur des équipements dédiés. D’autres fonctions typiquement applicatives vont elles aussi être confiées aux WAF, avec plus ou moins de pertinence : la réécriture d’URL, le contrôle d’accès,le Web Single Sign On, etc. Ces fonctionnalités sont très éloignées du rôle du filtrage d'attaques, mais il est devenu fréquent de les trouver dans les appels d’offres pour ces produits. Certaines d’entre elles font même partie de la grille d’évaluation standard des WAF [3].



2.3 Des modules d’équipements réseau


Pressentant les vulnérabilités liées aux couches OSI supérieures, les acteurs du réseau ont aussi naturellement voulu compenser cette lacune et s’approprier la sécurité applicative. La plupart des éditeurs de firewalls réseaux se sont essayés à l’exercice, mais rares sont les implémentations qui ont survécu, tant le métier du réseau et celui de l’application sont différents. Les ressources requises sur ces équipements de sécurité ne sont pas les mêmes et leurs administrateurs n’ont ni les mêmes formations ni les mêmes contraintes.


Ce sont les fournisseurs de répartiteurs de charge (« load balancers »), naturellement plus proches des couches applicatives qui ont le mieux réussi la transformation de leur métier et valorisé leurs investissements pour fournir des solutions matures à leurs clients. La plupart des répartiteurs du marché proposaient déjà la terminaison SSL et l’optimisation du trafic web. Ils ajoutent désormais un WAF intégré sous forme de module, ainsi que toutes les fonctionnalités héritées de ces produits.


Ces solutions bénéficient de la puissance de ces plateformes, voire parfois des accélérateurs matériels embarqués, pour proposer des performances sans égales. Déployés devant les fermes de serveurs et bénéficiant des compétences existantes des administrateurs, les WAF embarqués sur des répartiteurs de charge n’ont comme seule contrainte que la nécessité d’un équipement de ce type. Seules les entreprises qui hébergent de nombreux serveurs en interne requièrent ces équipements et peuvent s’offrir les WAF associés.

À noter que tout comme les appliances dédiées, les répartiteurs de charge sont maintenant disponibles pour la plupart sous forme de machines virtuelles ou de services de plateforme Cloud, permettant ainsi de protéger des infrastructures virtuelles ou Cloud.



2.4 Des solutions SAAS


Afin de limiter les coûts et les temps de déploiement des WAF, et surtout face à l’augmentation exponentielle du nombre d’applications web éphémères à protéger, certains éditeurs proposent à leurs clients des solutions scalables qui ne requièrent aucune modification de leurs architectures. Les WAF adoptent le modèle CDN (Content Delivery Network) et permettent à leurs clients de rediriger tout ou partie du trafic vers une plateforme distante qui va inspecter le trafic en plus de toutes les optimisations attendues d’un CDN.


Un changement de DNS suffit à leur mise en œuvre. Le trafic à destination des applications est alors orienté vers le CDN qui effectue l’analyse et ne soumet que le trafic sain vers les serveurs. Ces services sont généralement facturés au volume de données traité et offrent un jeu de fonctionnalités réduit, mais ne requièrent quasiment aucun paramétrage. Les fournisseurs offrent généralement un service d’administration dédié aux clients qui souhaitent un paramétrage plus avancé des WAF as a Service avec notamment une personnalisation de l’analyse en fonction des applications cibles.

3.Plusieurs méthodes de détections

3.1 Listes noires


Les WAF ont tous en commun la capacité à détecter des éléments dangereux (script, commandes SQL ou système, etc.). Ce qui les différencie concrètement, c’est l’aptitude des fournisseurs à maintenir cette liste à jour et surtout à pondérer le résultat de cette détection. Une détection basique de ces motifs suspects risque d’entraîner un très grand nombre d’alertes liées au « bruit » des scripts qui attaquent aveuglément des plages entières d’IP sur Internet. On attend d’un WAF qu’il sache mettre en évidence une attaque construite en pondérant correctement la présence de critères offensifs. Sans cette catégorisation des alertes, l’administrateur est submergé d’alertes et risque de négliger une attaque réelle et ciblée perdue dans la masse. Pour ce faire, les WAF utilisent des mécanismes hiérarchisés à base de règles. Que ce soit à l’aide d’expressions rationnelles (« RegExp ») ou d’un système de catégorisation, les moteurs de sécurité des WAF peuvent reconnaître une attaque correctement constituée et donc potentiellement nocive et la signaler comme telle. 

Les listes noires sont particulièrement efficaces contre les injections (SQL, commandes, cookies, etc.). Ces attaques occupent la première place du Top 10 que propose l’OWASP [4]. C’est aussi le cas du Cross-Site Scripting, une attaque qui, à base d’injection de script, va cibler non plus l’application elle-même, mais ses utilisateurs, en leur faisant par exemple envoyer à leur insu leurs identifiants de session vers un site extérieur lors d’un clic ou d’un mouvement de souris (clickjacking).

3.2 Listes blanches


Afin de faire face au problème des faux-positifs, les fournisseurs de WAF ont complété cette méthode de détection par le mécanisme inverse, dit de « liste blanche ». Ce principe consiste non plus à détecter des attaques, mais à n’autoriser que ce qui est explicitement autorisé : le trafic « sain ». On va donc décrire exhaustivement des URL et paramètres dans une utilisation normale de l’application et interdire ce qui déroge à cette règle. Ce principe est éprouvé et gouverne la grande majorité des équipements de sécurité. Malheureusement, il est difficile, voire impossible à mettre en œuvre devant des applications web. En effet, celles-ci sont par essence dynamiques et il est très difficile de figer un format de requêtes et très coûteux en temps de suivre les évolutions des applications. C’est aussi supposer que le dialogue entre les développeurs et les administrateurs du WAF existe dans la durée…
 

3.3 Virtual Patching


Le virtual patching est en quelque sorte la seconde jeunesse des listes blanches. Faute de pouvoir les appliquer globalement sur une application, on va appliquer cette sélection positive sur une URL ou un paramètre qu’on sait vulnérable. Le virtual patching intervient après qu’une faille ait été découverte par un scanner ou un audit de l’application. On va modéliser dans le WAF le format attendu et ainsi se prémunir contre toute tentative d’exploitation de la vulnérabilité. Par exemple, si un paramètre de l’application s’avère être interprété sans validation par l’application, on va fixer dans le WAF ses valeurs possibles et ainsi écarter toute tentative d’injection de commande ou de script par son travers. Le principal intérêt du virtual patching dans un WAF est qu’il permet de déployer instantanément un patch efficace devant toutes les applications vulnérables, sans coupure de la production, et ainsi de donner à l’équipe de développement le temps de corriger la vulnérabilité sur les applications sans avoir à agir dans l’urgence. 



3.4 Suivi de sessions


Les WAF sont pour la plupart d’entre eux dotés d’autres fonctionnalités de détections d’attaques que les simples listes noires et/ou blanches. Au premier rang de ces fonctionnalités complémentaires vient le suivi des sessions. Les applications web entretiennent avec leurs utilisateurs un contexte d’utilisation qui permet de poursuivre un échange transactionnel complet. Les applications utilisent principalement deux mécanismes de suivi : les cookies persistants et les cookies de sessions. Les premiers sont de petits fichiers entreposés par le navigateur et associés au nom de domaine visité. Ils contiennent de nombreuses informations relatives au parcours ou aux contraintes de sécurité imposées par l’application. Le second type de cookie est un identifiant volatile (un aléa plus ou moins salé) qui permet à l’application d’identifier la session d’un utilisateur sans qu’il n’ait à s’authentifier lors de chaque requête. Si quelqu’un parvient à usurper l’identifiant d’un utilisateur authentifié, il peut accéder à la session de celui-ci sans avoir à s’authentifier. On comprend aisément l’inquiétude des experts en sécurité et l’attrait des pirates pour le vol de session...


Avec des applications toujours plus riches et dynamiques, les injections de script sur les pages des serveurs (les fameux Cross Site Scripting ou XSS) sont devenues une cible prioritaire des WAF. On cherche à renforcer l’identification de session en la couplant à un user-agent, à une adresse IP, etc. [5]

Ces mêmes fonctions de suivi de session permettent aussi de prévenir les applications web contre des utilisations non souhaitées comme l’aspiration scriptée de contenu (web scraping), l’accès non authentifié à des ressources, les tentatives de vol d’identifiants par force brute, ou le déni de service applicatif.

3.5 Fuite de données

Les WAF en coupure (RP) disposent aussi de fonctionnalités de dissimulation ou de blocage d’information en sortie. Numéros de cartes bancaires, numéros de sécurité sociale, mots de passe, et autres données sensibles peuvent être interceptées dans les réponses des serveurs web afin d’empêcher la fuite d’informations.

La fuite de données est une préoccupation majeure pour les entreprises. Les pirates ne cherchent plus à défigurer un site web, mais bel et bien en extraire des données valorisables.

Une bonne pratique consiste aussi à utiliser le WAF pour dissimuler aux utilisateurs certaines informations techniques comme les versions des serveurs web, les versions des langages employés, les pages d’erreur du serveur comme de la base de données, autant d’informations précieuses pour les attaquants qui leur permettent de cibler leurs attaques plus facilement.

4. Au-delà du filtrage

De simples modules de serveur web, les WAF sont devenus des équipements très riches en fonctionnalités. Il suffit d'observer les listes de fonctionnalités des WAF du marché pour constater à quel point on attend de ces produits beaucoup plus que de bloquer des attaques. Au fil des ans, ces produits sont devenus les extensions de sécurité des applications, mais aussi les garants de l’accès à ces mêmes applications, voire parfois les relais d’authentification. Il n’est pas rare de trouver pêle-mêle dans des appels d’offres WAF des besoins de répartition de charge, de contrôle d’accès, etc.

La première des fonctionnalités « annexes » des WAF a été l’offloading SSL. Terminer la connexion SSL sur les WAF a permis non seulement d’alléger la charge des serveurs web, mais aussi d’optimiser les échanges cryptographiques en ne présentant aux clients que des algorithmes de chiffrements robustes et en nombre réduit, quand bien même les serveurs finaux ne supporteraient pas un tel paramétrage. Le WAF s’intègre aussi dans un environnement hautement sécurisé puisqu’il est capable de rechiffrer le trafic à destination des serveurs, et maintenir le chiffrement de bout en bout.

Les fonctionnalités de sécurité ont aussi évolué, moins dans leur méthode de recherche que dans la simplification de leur configuration et dans l’enrichissement des critères de blocage. Les WAF sont devenus des outils connectés. Ils font appel à des bases de connaissances externes pour « évaluer » la fiabilité des utilisateurs des applications qu’ils protègent. Tout est mis en œuvre pour réduire la quantité de trafic que doit analyser le moteur d’inspection, forcément gourmand en ressources. On va filtrer des utilisateurs sur plusieurs critères (géolocalisation, réputation d’IP, connexion au travers de proxies publics ou de réseaux d’anonymisation type TOR).

Les WAF se sont aussi adaptés à l'explosion du nombre d'applications web et mobile. L’émergence des API a conduit les WAF à savoir appréhender cette nouvelle méthode de consommation de l’information. Les WAF savent analyser des structures JSON, XML à la recherche des contenus offensifs qui n’ont pas manqué d’apparaître dans les web services. Par là même, les WAF ont appris à s’intégrer dans un dialogue de machine à machine, régi par des règles strictes, notamment en terme de temps et de qualité de réponses et respecter les SLA qui lient les différents partenaires.

Afin de faire face à la complexité de configuration des WAF, inhérente à la permissivité du protocole HTTP, sont apparus des outils de simplification de la mise en œuvre du WAF comme l’apprentissage du trafic qui va permettre de visualiser l’application protégée et simplifier la mise en place des « listes blanches » Malheureusement, la multiplication des applications dynamiques rend de plus en plus caduque cette méthode de description. Il ne fait plus guère de sens d’appliquer des critères par URL, quand toute l’application n’est présentée que comme une seule URL dynamique.

5. Forces et limitations

Il ne faut pas attendre d’un WAF qu’il protège à lui seul les applications web de l’entreprise. Rien ne remplace un code propre et robuste. Le rôle du WAF est de protéger contre l’imprévu, de palier les lacunes des développeurs, des langages, outils ou composants qu’ils utilisent. Parce qu’il reconnaît un grand nombre de formes d’attaques, un WAF va éliminer le « bruit » des attaques automatisées, des scripts qui testent aveuglément tout nouvel exploit sur tout port 80 ou 443 en écoute sur Internet.

Comme pour tout équipement de sécurité, la pertinence du WAF correspond à celle de sa configuration et de l’adaptation qui a été faite de l’outil dans son environnement. Mis en œuvre par une équipe talentueuse, le WAF éliminera la quasi-totalité des attaques qui visent les applications. Il permettra aux équipes d’experts de se consacrer aux événements importants plutôt que de perdre leur temps à chercher l’attaque ciblée au milieu de milliers de lignes de logs. 

Alors que les applications du marché (webmails, portails) sont très souvent pré-paramétrées dans les WAF sous forme de modèles de configurations, les vrais ennuis apparaissent dès lors qu’il faut protéger des applications spécifiques. L’équipe en charge du WAF doit choisir une stratégie de protection parmi celles à sa disposition (liste noire, blanche, etc.) en fonction des risques encourus et de son niveau de connaissance de l’application. C’est là que le bât blesse souvent dans les entreprises. Pour commencer, l’équipe WAF n’existe que trop rarement. On confie souvent la protection de la 7e couche ISO aux équipes existantes en oubliant de leur préciser que cette couche applicative va les occuper autant, voire plus que les six autres réunies. Ensuite, le dialogue nécessaire entre les développeurs et l’équipe de sécurité est rare et rendu difficile, car les discours, les priorités et la temporalité sont différents entre ces entités. 

Paradoxalement, la richesse fonctionnelle des WAF du marché est aussi un risque pour les entreprises qui ont tendance à déporter trop de contrôles de sécurité sur ces outils, au détriment du code sécurisé. S’il est confié à une équipe mature, s’il est pris en compte dès les premières étapes du cycle de développement des applications, le déploiement du WAF est rapide et ses résultats sont probants.

Que ce soit pour protéger, pour dissimuler ou pour patcher, le WAF n’a actuellement pas d’équivalent sur le marché. Parce qu’il n’est pas adhérent à la technologie employée pour développer les applications, parce qu’il permet de protéger celles-ci ainsi que les serveurs web qui les hébergent sans intervenir sur les serveurs de production, et qu’il est un équipement devenu aussi indispensable que le firewall réseau.

L’opposer au développement sécurisé ou au durcissement des serveurs serait simpliste. Au contraire, ils participent d’une démarche de sécurité des applications qui n’est efficace que si elle est appréhendée à différents endroits et différents moments du cycle de vie de l’application. Le WAF est une assurance supplémentaire qu’il convient d’associer au travail des développeurs afin qu’il ne soit pas perçu comme un frein, mais comme un facilitateur de sécurité.

6. Demain

L'enjeu actuel des WAF est de faire face au nombre grandissant d’applications web et mobiles. Quand on protégeait trois applications en 2005, on en protège aujourd’hui plusieurs milliers, dont une grande part d’applications éphémères. Dans les entreprises, les équipes en charge de la sécurité n’ont pas suivi la même croissance. Il n’est plus possible de configurer un WAF, application par application. On attend de ce type de produits un minimum d’automatisation, que ce soit dans la découverte de son environnement applicatif ou dans les moyens de déploiement.

Ces déploiements massifs entraînent aussi une évolution de la demande. Les entreprises identifient plus facilement des besoins fonctionnels unitaires et s’orientent vers des services à la demande plutôt que des produits « usines à gaz » hors de prix. Que ce soit de la validation de code ou du test de vulnérabilité, on intègre ces services avec des API, au plus tôt dans le cycle de vie des applications.

La sécurité des applications web n’échappe pas à cette évolution du marché. Il est anachronique de commencer à se soucier de la sécurité d’une application lorsque celle-ci est en production ou sur le point de l’être. Désormais, la sécurité de l’application est prise en compte dès les premières étapes de son cycle de vie et doit être automatisable. On lie désormais développement, déploiement et sécurité dans un effort continu. Le DevOpsix a permis de créer des passerelles dont l’efficacité n’est plus à prouver. Il convient maintenant d’intégrer la sécurité à ce mouvement, et que les produits le permettent. Cela signifie que les fournisseurs de WAF doivent s’adresser aussi aux développeurs et plus seulement aux RSSI pour faire évoluer leurs produits. L’intégration de composants de sécurité dans les environnements de développement est un premier pas que plusieurs éditeurs ont déjà franchi.

Le déploiement d’un WAF représente un investissement important. Bien au-delà du coût d’acquisition du produit, c’est un investissement organisationnel qui est réalisé. C’est l’engagement de créer un lien entre ceux qui conçoivent les applications et ceux qui les protègent au quotidien. On peut imaginer que la fonctionnalité de filtrage du trafic applicatif va évoluer vers une meilleure intégration des données d’infrastructure. La difficulté du processus décisionnel du WAF est sa méconnaissance de l’environnement dans lequel il évolue. Au mieux, on renseigne le WAF sur le type d’application qu’il protège (PHP, Java, etc.). On peut supposer que s’il connaissait l’ensemble des composants de l’application (base de données, connecteurs d’annuaire, etc.) la pertinence de sa détection et de sa pondération en serait grandie. 

Conclusion

Plus que jamais, le WAF apparaît comme un maillon de la chaîne applicative qui se doit d’interagir avec l’ensemble de l’écosystème dans lequel il évolue. Il est à l'heure actuelle le seul équipement de sécurité capable de protéger efficacement tout type d'applications web sans exposer directement les serveurs.

La complexité et la richesse des applications web, mobiles et demain de l’Internet des bidules requièrent désormais une réponse à laquelle un équipement centralisé, même intelligent ne saurait répondre. Le WAF de demain sera distribué et communiquera sans doute avec les environnements de développement, les analyseurs de code, les scanners de vulnérabilités, les serveurs web, les firewalls… C’est le prix de son intégration définitive dans le cycle de vie des applications.

Remerciements

Je tiens à remercier Renaud Bidou, Matthieu Estrade, Raphaël Leblanc, Pierrick Prévert et Jérôme Saiz pour leur relecture patiente et leurs précieux commentaires.

Références

[1] https://home.cern/fr/topics/birth-web

[2] http://www.internetlivestats.com/total-number-of-websites

[3] http://projects.webappsec.org/w/page/13246985/Web%20Application%20Firewall%20Evaluation%20Criteria

[4] https://www.owasp.org/index.php/Top_10_2013-Top_10

[5] http://www.xss-payloads.com