Alors que le nombre de piratages augmente, les pare-feu applicatifs (web application firewalls) et les filtres sont de plus en plus plébiscités. Ces outils permettent de renforcer la sécurisation de vos applications web. Comment fonctionnent-ils? Quelles sont leurs différences? Voici une brève introduction sur le sujet.
Filtre ou WAF : Qui fait quoi ?
Les filtres sont le premier type de défense. Qu’ils fassent partie intégrante d’un framework de développement ou qu’il soient implémentés par les développeurs web eux-mêmes, les filtres font au final partie de l’application.
L’efficacité de ce type de protection va directement dépendre des connaissances des développeurs en matière de sécurité et de leur expérience dans le développement d’applications sécurisées.
Le second type de protection est appelé Web Application Firewall (WAF), ou pare-feu applicatif. Ce type de protection ne doit pas être confondu avec les pare-feu “classiques”, dans le sens où un WAF va analyser le traffic web et ne se limitera pas à filtrer le traffic en fonction de règles liées aux ports, adresses IP ou protocoles.
Un WAF peut être implémenté sur le serveur web physique lui-même, ou devant le serveur web (entre l’utilisateur final et le serveur web).
Les filtres
Un filtre peut être implémenté par un développeur avec un simple jeu de règles regex. Les développeurs écrivent ces regex afin de filtrer les données arrivant sur l’application web, dans le but de vérifier qu’elles correspondent bien au type de données attendu (par exemple une chaîne de caractères, un entier, un email…).
Cependant, écrire des règles regex parfaites nécessite du temps et de l’expérience. De nombreux développeurs ont l’habitude de copier/coller des exemples de regex trouvées sur les forums de développement, ou sur d’autres sites web. La qualité de cette couche filtre peut être très bonne, mais comporte généralement des failles.
L’adoption d’une librairie de filtres est souvent une solution qui s’impose, et les avantages sont nombreux :
Tout d’abord, les librairies ne sont (généralement) par le fruit d’un seul développeur. Cela signifie que l’équipe et la communauté gravitant autour de cette librairie vont fusionner leurs connaissances et leurs compétences afin de développer quelque chose de résistant.
Second bénéfice : Les bonnes librairies sont maintenues, ce qui n’est pas forcément le cas des filtres faits-maison.
Nous pouvons également ajouter le fait que ces librairies concentrent les fonctionnalités de filtrage, là où des développeurs implémenteront parfois de manière dispersée des filtres ou contrôles dans leur application.
La librairie OWASP ESAPI et les filtres Respect/Validation sont de bons exemples.
Certains frameworks de développement implémentent également leur propres filtres.
C’est par exemple de le cas de Microsoft .Net et de son système de validation de requêtes. Ce filtre s’intéresse principalement au code HTML et JavaScript présent dans les paramètres de requêtes (query strings), données postées et cookies, afin de contrecarrer certaines attaques XSS.
Quel que soit le type de filtre, celui-ci est généralement basé sur des patterns, regex, blacklisting ou whitelisting.
Pare-feu applicatifs
Un WAF est installé en série, en amont du serveur web et analyse le traffic avec avant qu’il atteigne l’application web.
L’objectif d’un WAF est de détecter et bloquer des attaques connues, comme XSS, injections SQL, vols de session, attaques brute-force, etc.
Le détail des implémentations peut changer suivant les solutions du marché, mais voici le schéma classique :
Suivant sa technologie, un WAF pourra utiliser différents moyens de détection : regex, blacklisting, whitelisting, signatures, etc.
D’un point de vue configuration, un WAF pourra opérer suivant deux modes : logging ou blocking.
Dans le mode logging, les requêtes suspectes seront enregistrées, mais pas bloquées. Ce type de configuration est généralement adopté lors de l’installation d’un WAF, pour éviter dans un premier temps les “faux positifs” et donc éviter de bloquer du traffic légitime.
Dans le mode blocking, les attaques détectées sont bloquées, et le traffic dangereux ne parvient pas à l’application web.
Exemple de pare-feu application opensource : mod security (https://www.modsecurity.org/).
Les WAF peuvent être installés comme un équipement autonome sur le réseau, comme un logiciel, ou encore connectés à partir d’un service disponible sous forme de service cloud.
Filtres vs. WAF : Lequel choisir ?
Un filtre fait partie intégrante de l’application. L’application web se protège donc d’elle même en empêchant les requêtes malveillantes d’être exécutées.
Un filtre peut être très spécifique et s’occupera de chaque morceau de données indépendamment, par exemple pour n’accepter que des entiers positifs là ou un entier positif est attendu.
L’inconvénient des filtres réside dans leur possibilité d’évolution. Appliquer des mises à jour sur un système de filtrage implique la mise à jour de l’application elle-même. De plus un filtre consomme de précieuses ressources serveur.
Les pare-feu applicatifs sont une fonction séparée, et pourront donc être maintenus et mis à jour sans mettre à jour l’application web.
Puisqu’un WAF est souvent fourni par une société tierce, spécialisée en sécurité web, nous pouvons supposer qu’il offre par ailleurs une meilleure protection, généralement plus large en termes de protection, mais aussi plus générique.
Les WAFs gérés par une entreprise tierce pourront être mis à jour de manière rapide, afin de protéger la plateforme web contre des attaques ou vulnérabilités récemment découvertes, ce qui constitue un avantage de taille.
Au final, difficile de recommander l’un plutôt que l’autre, car les deux solutions sont très complémentaires.
Filtres et WAF : Suffisants pour sécuriser une application web ?
Les web application firewalls et les filtres ajoutent une forte couche de sécurité aux applications web. Mais malgré cela, des entreprises continuent à se faire pirater. Ces défenses sont donc une couche supplémentaire que l’on vient ajouter à la sécurité mais sur laquelle on ne peut pas entièrement se reposer. Les WAF et les filtres s’apparentent à des filets de sécurité.
Filtres et WAF ont chacun des failles qui permettent de les contourner, afin d’attaquer des applications vulnérables. La meilleure protection consiste donc à assurer la qualité du code de ses applications, en considérant l’utilisation de filtres et de pare-feu applicatifs comme un complément.