Pas de WAF

Votre équipe sécurité vient de vous brosser un tableau alarmant des cybermenaces, et vous savez désormais que votre application web est un champ de mines truffé de vulnérabilités. Corriger ces failles ressemble à un chantier dont la durée se situe quelque part entre l'éternité et jamais.

WAF, pas vraiment ce que vous espériez

Mais attendez ! Il existe une solution : le Web Application Firewall (WAF), qui détecte les vulnérabilités courantes comme les attaques par injection ou les attaques par déni de service distribué (DDoS). Aucun développement n'est requis. Il vous suffit de rediriger tout le trafic web vers le WAF ; celui-ci inspecte chaque requête HTTPS et bloque les plus dangereuses.

Les WAF inspectent toutes les requêtes HTTPS adressées à votre application web et bloquent celles qui paraissent suspectes. Ils déchiffrent les requêtes HTTPS et analysent les en-têtes ainsi que le corps à la recherche de menaces potentielles, qu'ils bloquent ensuite en fonction du contenu, de l'adresse IP ou des schémas de requête.

Les WAF offrent également une protection contre les attaques DDoS en bloquant les pics soudains de trafic. Cela peut se faire à l'aide de règles simples telles que le débit de requêtes et l'adresse IP source. Ils peuvent aussi recourir à l'intelligence artificielle pour détecter les schémas d'accès typiques des attaques DDoS et les bloquer.

Ne le faites pas.

Le WAF est une erreur. Voici pourquoi :

Bloquer votre propre application

Les WAF peuvent empêcher des utilisateurs légitimes d'accéder à votre application web en confondant une activité normale avec une attaque. Il est en effet probable que votre application reçoive des entrées contenant des chaînes suspectes que les expressions régulières captureront à tort : par exemple, si votre application s'adresse à des clients techniques, vous pouvez avoir des extraits de JavaScript qui ressemblent à une attaque. Pire encore, votre application peut exiger des entrées intrinsèquement dangereuses : par exemple, si elle accepte du HTML provenant d'un éditeur de texte enrichi et le restitue tel quel, je peux vous dire ce que vous savez déjà : vous pourriez et devriez échapper les chaînes plutôt que de transmettre l'équivalent d'une attaque. Mais éliminer ces faiblesses, une fois créées, est difficile, et tant que vous ne pouvez pas y consacrer votre équipe, le WAF rendra votre application web inutilisable.

Côté protection DDoS, le WAF bloque les hausses brutales de trafic, mais cela ouvre la porte au pire type de faux positif : celui qui survient lorsque votre application devient virale et que vos visiteurs ne peuvent plus s'en servir. C'est là que le filtrage avancé du WAF, piloté par le machine learning (ML), peut aider. Imparfait, certes, mais plus efficace que les approches par motifs employées par la plupart des filtres WAF.

Bloquer des adresses IP individuelles est évidemment une maille trop fine ; l'étape suivante consiste donc à bloquer des pays entiers, excluant ainsi tous les clients d'un pays donné. Vous ne servez peut-être pas de clients dans ce pays aujourd'hui, mais avec le WAF, vous vous interdisez aussi de découvrir de nouveaux marchés potentiels.

L'approche recommandée pour gérer les faux positifs consiste à configurer le WAF en mode dry run : au lieu de bloquer, il consigne dans un journal les entrées suspectes. Vous analysez ensuite les journaux pour identifier les faux positifs et, le cas échéant, soit vous assouplissez les règles (en ignorant potentiellement de vraies attaques), soit vous corrigez votre code (mais cela fait des années que vous repoussez ce chantier). J'ai vu des organisations exécuter le WAF en dry run pendant deux ans, par crainte tout à fait légitime de saboter le bon fonctionnement de leur application. Résultat : elles ont ralenti leur application, n'ont obtenu aucun bénéfice en matière de sécurité, et ont dépensé des dizaines de milliers de dollars en frais de licence, sans le moindre gain réel.

Laisser passer les attaques

La diversité des nouvelles attaques possibles dépasse l'imagination des concepteurs de WAF et la vôtre ; mais pas celle des pirates. Vous vous retrouvez alors face à l'image miroir du faux positif : le faux négatif, c'est-à-dire de vraies attaques qui passent sans être détectées.

Les expressions régulières, qui constituent le moyen le plus courant de filtrer du texte, sont limitées dans ce qu'elles peuvent détecter. Elles doivent être prédéfinies pour des attaques précises et rester simples pour garantir un traitement rapide. Pour des raisons de performance, seuls les premiers kilooctets de l'en-tête et du corps HTTP sont analysés ; et même si vous repoussez cette limite, il en existera toujours une au-delà de laquelle les attaques passent.

Le blocage d'adresses IP est également une source de faux négatifs, car les attaquants peuvent facilement basculer vers de nouvelles adresses IP via des proxies.

La principale source d'attaques contre lesquelles les WAF ne peuvent rien faire se trouve dans la logique applicative elle-même. Si une page censée être protégée par mot de passe ne l'est pas, ou si l'autorisation permet à un utilisateur d'écrire des données alors que seule la lecture aurait dû être autorisée, c'est de votre ressort. Personne n'attend des WAF qu'ils détectent ce type de vulnérabilités, mais cela souligne que la sécurité web doit avant tout être implémentée dans votre propre code.

Flexibilité ?

Au fil des faux positifs et des faux négatifs, on est tenté d'ajuster les règles, de les personnaliser au plus près de ses besoins, voire d'en écrire de nouvelles. Ne le faites pas.

Les experts en sécurité ont déjà étudié les types d'attaques utilisés par les pirates. Ces derniers ne vont pas inventer des attaques sur mesure pour vous, et s'ils le font, vous ne le saurez pas davantage à l'avance. Les vulnérabilités de votre application sont presque certainement les mêmes que celles couvertes par les jeux de règles standards. Et si votre application présente vraiment des faiblesses si singulières qu'il faut les diagnostiquer et écrire de nouvelles règles de protection, mieux vaut consacrer ce temps de développement à l'application elle-même plutôt qu'au pansement.

Trouver l'équilibre entre précision et rappel — faux négatifs contre faux positifs — est difficile, voire impossible, même pour les experts. Ils définissent des niveaux de protection pour vous laisser arbitrer entre faux positifs et faux négatifs. Affiner cet équilibre face à des millions de requêtes web futures n'en vaut pas la peine.

Risque supplémentaire

Ces inconvénients font généralement du WAF un mauvais calcul. Mais ce n'est pas tout : le WAF lui-même peut constituer un risque de sécurité. Il doit déchiffrer le HTTPS pour inspecter les données, créant ainsi un nouveau point potentiel de fuite ; son propre code peut comporter des vulnérabilités. De plus, il peut ralentir les communications, puisque chaque requête doit transiter par lui.

Trop souvent, en dépit de tous ces éléments, les responsables décident d'ajouter un WAF malgré tout, comme palliatif, en se promettant de corriger les vulnérabilités plus tard. Mais une fois le WAF en place, l'équipe baisse la garde, les bonnes pratiques de sécurité ne sont jamais adoptées, et le code de l'application devient de moins en moins sûr. Pendant ce temps, le WAF ne procure pas la sécurité qu'on lui prête.

Malgré ces inconvénients, certaines situations peuvent justifier l'usage d'un WAF, même si vous n'en tirerez pas un grand bénéfice en matière de sécurité :

Si une exigence externe l'impose : si l'appel d'offres d'un client ou une réglementation sectorielle vous oblige à respecter une norme de sécurité formelle, alors ajoutez-le, bien sûr. Le WAF est nécessaire, mais pas pour la sécurité.

Si vous déployez une application web tierce, que vous n'avez pas développée et que vous ne pouvez pas corriger, le WAF peut être votre seul moyen d'ajouter un peu de sécurité. Vous risquez toujours de vous bercer d'illusions sur votre véritable niveau de sécurité, mais au moins, dans ce cas, vous ne vous éloignez pas davantage des bonnes pratiques de développement.

Cela dit, il existe une vraie raison de sécurité d'utiliser un WAF : la protection contre les DDoS. Lorsqu'une attaque par déni de service génère un trafic massif, votre WAF peut la détecter et la bloquer. La détection des schémas d'attaque par ML offre une bonne précision.

Pour aller plus loin dans la protection DDoS, disposer d'une équipe d'experts humains prête à intervenir, comme avec Google Cloud Armor Managed Protection et AWS Shield Advanced, en vaut la peine pour les plus grandes applications web.

Beaucoup de clients nous contactent en urgence pour acheter des services de protection DDoS, qu'il s'agisse d'un WAF ou d'équipes d'experts, une fois l'attaque déjà en cours, alors qu'il n'y a plus le temps ; mieux vaut anticiper.

Si vous décidez d'utiliser un WAF, choisissez celui proposé par votre fournisseur cloud : Google Cloud Armor ou AWS Shield. Avec les services cloud, vous payez à l'usage, plutôt que de vous engager sur un abonnement mensuel coûteux pour un produit que vous n'utiliserez peut-être jamais vraiment. Et puisque les données transitent déjà par le cloud — et que dans de nombreuses architectures, les services cloud les déchiffrent de toute façon —, opter pour le WAF de votre fournisseur cloud minimise l'impact sur les performances, la sécurité et la confidentialité.

Voir cet article de Mac Chaffee ainsi que ce fil StackExchange pour des détails techniques précieux sur ces points.