L'OWASP Top 10, tel qu'un WAF l'applique réellement

Ce qu'est réellement le Top 10

OWASP — l'Open Worldwide Application Security Project — publie une liste classée de catégories de risque pour les applications web, révisée tous les quelques années à partir de données réelles d'incidents et de scans. La liste actuelle est menée par le contrôle d'accès défaillant, les défaillances cryptographiques et l'injection.

Deux choses découlent de la façon dont elle est construite, et les deux se perdent dans les argumentaires des fournisseurs.

Ce sont des catégories, pas des vulnérabilités. « Injection » couvre l'injection SQL, l'injection de commande, l'injection LDAP et l'injection de template. Un produit ne peut pas « prendre en charge » une catégorie ; il peut seulement détecter des techniques particulières qui en font partie.

C'est un outil de priorisation pour les personnes qui construisent l'application. Il vous dit où passer du temps de relecture. Cela n'a jamais été une checklist de conformité, et un pare-feu devant une application ne fait pas disparaître la liste.

Ce qu'est un WAF, en un paragraphe

Un pare-feu d'application web se place devant votre application et inspecte chaque requête — le chemin, la chaîne de requête, les en-têtes, les cookies et le corps — par rapport à un jeu de règles. Quand une règle correspond, la requête est bloquée, journalisée, ou les deux, avant même que votre application ne s'exécute.

Le jeu de règles ouvert sur lequel la plupart des WAF sont construits est l'OWASP Core Rule Set (CRS), un ensemble de règles de détection génériques maintenu par la même fondation. C'est le jeu de règles que nous exécutons, sur ModSecurity, en périphérie. Le CRS regroupe ses règles en familles avec des plages numériques — 941 pour le cross-site scripting, 942 pour l'injection SQL, 930 pour l'inclusion de fichier local, 931 pour l'inclusion de fichier distant, 932 pour l'exécution de commande distante, 933 pour l'injection PHP — ce qui explique pourquoi une requête bloquée peut être retracée jusqu'à un numéro de règle exact plutôt qu'à une vague « politique de sécurité ».

Catégorie par catégorie : ce que le pare-feu fait réellement

Injection — un WAF est réellement fort ici. L'injection SQL, l'injection de commande et l'injection de template laissent toutes des formes reconnaissables dans les données de la requête. C'est exactement ce pour quoi la reconnaissance de motifs est douée, et les règles attrapent d'emblée la plupart des tentatives opportunistes. Cela ne rend pas les requêtes paramétrées optionnelles ; cela vous achète du temps et arrête la majorité automatisée.

Cross-site scripting — fort, avec des réserves. Les charges utiles de script dans les paramètres sont détectables. Un XSS stocké qui arrive par un chemin que le pare-feu n'inspecte pas, ou un problème basé sur le DOM qui ne touche jamais votre serveur, est hors de portée.

Mauvaise configuration de sécurité — en partie. Un WAF peut cacher une bannière de serveur, bloquer l'accès aux fichiers .git et de sauvegarde, et refuser les méthodes dangereuses. Il ne peut pas corriger une politique CORS permissive ou un panneau d'administration avec un mot de passe par défaut.

Composants vulnérables et obsolètes — en partie, et temporairement. Quand une CVE est publique, des règles génériques attrapent souvent la forme de l'exploit publié, ce qui est toute la valeur du « virtual patching » : cela achète les jours entre la divulgation et votre fenêtre de mise à jour. Ce n'est pas un substitut à la mise à jour.

Contrôle d'accès défaillant — majoritairement pas. Si votre application laisse l'utilisateur A récupérer la facture de l'utilisateur B en changeant un ID dans l'URL, les deux requêtes paraissent identiques pour un pare-feu. Il n'a aucune idée de qui possède la facture 4711. C'est la catégorie en tête de la liste actuelle et c'est un bug d'autorisation dans votre code.

Défaillances d'identification et d'authentification — en partie. Le rate limiting sur les endpoints de connexion émousse le credential stuffing et la force brute, ce qui est réel et vaut la peine d'être mis en place. Une gestion de session faible ou un parcours de réinitialisation de mot de passe qui fuit des jetons n'est pas quelque chose qu'un pare-feu voit.

Conception non sécurisée et défaillances d'intégrité logicielle — non. Ce sont des problèmes architecturaux. Aucun motif de requête ne les exprime.

Le problème des faux positifs, et pourquoi il décide de tout

Tout jeu de règles assez agressif pour attraper l'injection va parfois bloquer un humain. Le cas classique est un éditeur de contenu qui enregistre un article contenant un exemple de code, ou un formulaire de support où quelqu'un colle un message d'erreur contenant du SQL. La requête est légitime ; elle ressemble simplement à une attaque.

C'est là que les WAF se gagnent ou se perdent sur le plan opérationnel. Si un faux positif signifie « le site est cassé pour cette personne et personne ne peut expliquer pourquoi », le WAF se retrouve coupé en moins d'un mois — ce qui est le pire résultat possible, car la protection disparaît silencieusement pendant que tout le monde croit qu'elle est active.

Ce qui rend cela vivable, c'est la traçabilité. Sur notre périphérie, une requête bloquée renvoie une page 403 personnalisée avec un identifiant de référence, et cet identifiant correspond à l'entrée du journal d'audit avec la règle qui a matché et le champ sur lequel elle a matché. Une conversation de support devient « la règle 942100 a matché le champ content sur l'URL de l'éditeur » au lieu de « le site me bloque parfois ». La correction est alors une exclusion étroite : cette règle, ce champ, ce chemin. Pas la famille de règles, et pas le site.

Les niveaux de paranoïa : le curseur que personne n'explique

Le Core Rule Set est livré avec des niveaux de paranoïa, de 1 à 4. Le niveau 1 attrape l'évident et bloque rarement un humain. Chaque niveau supplémentaire ajoute des règles plus strictes et plus sujettes aux faux positifs, jusqu'à ce qu'au niveau 4 un pare-feu refuse des choses qu'une application normale fait tous les jours.

Le conseil honnête n'a rien d'excitant. Démarrez sur le réglage par défaut, surveillez le journal pendant une semaine, et n'augmentez le niveau que si vous protégez quelque chose qui justifie le coût opérationnel — et faites-le d'abord dans un environnement de staging. La plupart des sites sont mieux servis par un niveau 1 bien réglé que par un niveau 3 que quelqu'un a désactivé en silence après la troisième plainte.

Comment évaluer la « couverture OWASP Top 10 » d'un fournisseur

Quatre questions permettent de couper court à la plupart des discours marketing.

1. Quel jeu de règles, et quelle version ? « Basé sur OWASP » peut signifier le Core Rule Set ou les règles propres d'un fournisseur avec des noms à consonance OWASP. La version compte aussi — les jeux de règles sont révisés, et en faire tourner un plus ancien est un vrai compromis plutôt qu'un détail. Nous faisons tourner le CRS et le mettons à jour délibérément, en testant contre les schémas de faux positifs que rencontrent nos propres clients, plutôt qu'en suivant automatiquement l'amont.

2. Que vois-je quand une requête est bloquée ? Si la réponse est une page d'erreur générique et un journal que vous ne pouvez pas chercher par règle, le réglage se fera à l'aveugle.

3. Comment j'exempte un champ sur un chemin ? Si la plus petite exclusion disponible est « désactiver la famille de règles pour ce site », le produit vous pousse à couper la protection.

4. Qu'est-ce qui n'est pas couvert ? Un fournisseur qui répond « le contrôle d'accès et la logique métier, c'est votre code, pas nos règles » vous dit la vérité. Celui qui revendique une couverture complète du Top 10 décrit une liste de catégories, pas une capacité.