Awesome WAF 
Tout sur les pare-feu applicatifs (WAFs) d'un point de vue sécurité. 🔥
Préface : Ceci était à l'origine ma collection personnelle sur les WAFs. Je la rends open-source dans l'espoir qu'elle sera utile aux pentesters et aux chercheurs. Comme le dit le proverbe, "la communauté apprend les uns des autres".
Une définition concise : Un pare-feu est un point d'application de la politique de sécurité placé entre une application web et le point de terminaison client. Cette fonctionnalité peut être implémentée sous forme logicielle ou matérielle, fonctionnant sur un appareil dédié, ou sur un serveur classique utilisant un système d'exploitation standard. Il peut s'agir d'un appareil autonome ou intégré à d'autres composants réseau. (Source : PCI DSS IS 6.6)
Un pare-feu applicatif web se situe entre un utilisateur et une application web et a pour tâche d'empêcher toute activité malveillante d'atteindre l'application. Un WAF filtre la partie malveillante de la requête ou la bloque simplement.
N'hésitez pas à contribuer.
Sommaire :
Introduction :
- En utilisant un ensemble de règles pour distinguer les requêtes normales des requêtes malveillantes.
- Parfois, ils utilisent un mode d'apprentissage pour ajouter automatiquement des règles en apprenant le comportement des utilisateurs.
Modes de fonctionnement :
- Modèle négatif (basé sur une liste noire) - Un modèle de liste noire utilise des signatures prédéfinies pour bloquer les requêtes clairement malveillantes. Les signatures des WAF fonctionnant en modèle négatif sont spécifiquement conçues pour prévenir les attaques exploitant certaines vulnérabilités des applications web. Les pare-feu applicatifs web à modèle de liste noire sont un excellent choix pour les applications web exposées à l'internet public et sont très efficaces contre les vulnérabilités majeures. Ex. : Règle pour bloquer toutes les entrées
<script>*</script> empêche les attaques XSS de base.
- Modèle positif (basé sur une liste blanche) - Un modèle de liste blanche n'autorise le trafic web que selon des critères spécifiquement configurés. Par exemple, il peut être configuré pour n'autoriser que les requêtes HTTP GET provenant de certaines adresses IP. Ce modèle peut être très efficace pour bloquer d'éventuelles attaques à grande échelle, mais bloquera également beaucoup de trafic légitime. Les pare-feu à modèle de liste blanche sont probablement les meilleurs pour les applications web sur un réseau interne conçues pour être utilisées uniquement par un groupe restreint de personnes, comme les employés.
- Modèle mixte/hybride (modèle inclusif) - Un modèle de sécurité hybride combine à la fois liste blanche et liste noire. Selon toutes sortes de spécificités de configuration, les pare-feu hybrides peuvent être le meilleur choix pour les applications web sur réseaux internes et les applications web sur l'internet public. Un bon scénario est lorsque l'application web est exposée à l'internet public (utiliser des listes noires) tandis que le panneau d'administration doit être exposé à un sous-ensemble d'utilisateurs (utiliser des listes blanches).
Méthodologie de test :
Où chercher :
- Recherchez toujours les ports courants qui exposent la présence d'un WAF, notamment les ports
80, 443, 8000, 8080 et 8888. Cependant, il est important de noter qu'un WAF peut être facilement déployé sur n'importe quel port hébergeant un service HTTP. Il est bon d'énumérer d'abord les ports de service HTTP, puis de rechercher les WAF.
- Certains WAF définissent leurs propres cookies dans les requêtes (par exemple, Citrix Netscaler, Yunsuo WAF).
- Certains s'associent à des en-têtes séparés (par exemple, Anquanbao WAF, Amazon AWS WAF).
- D'autres modifient souvent les en-têtes et brouillent les caractères pour confondre l'attaquant (par exemple, Netscaler, Big-IP).
- Certains s'exposent dans l'en-tête
Server (par exemple, Approach, WTS WAF).
- Certains WAF s'exposent dans le contenu de la réponse (par exemple, DotDefender, Armor, Sitelock).
- D'autres WAF répondent avec des codes de réponse inhabituels lors de requêtes malveillantes (par exemple, WebKnight, 360 WAF).
Techniques de détection :
Pour identifier les WAF, il faut (simuler de) provoquer.
- Faire une requête GET normale depuis un navigateur, intercepter et enregistrer les en-têtes de réponse (notamment les cookies).
- Faire une requête depuis la ligne de commande (par exemple, cURL), et tester le contenu et les en-têtes de la réponse (sans user-agent inclus).
- Faire des requêtes GET vers des ports ouverts aléatoires et récupérer les bannières qui pourraient révéler l'identité du WAF.
- Sur les pages de connexion, injecter des charges utiles courantes (facilement détectables) comme
" or 1 = 1 --.
- Injecter des charges utiles bruyantes comme
<script>alert()</script> dans les barres de recherche, les formulaires de contact et autres champs de saisie.
- Ajouter un
../../../etc/passwd factice à un paramètre aléatoire à la fin de l'URL.
- Ajouter des mots-clés accrocheurs comme
' OR SLEEP(5) OR ' à la fin des URL sur n'importe quel paramètre aléatoire.
- Faire des requêtes GET avec des protocoles obsolètes comme
HTTP/0.9 (HTTP/0.9 ne prend pas en charge les requêtes de type POST).
- Souvent, le WAF modifie l'en-tête
Server selon différents types d'interactions.
- Technique d'action Drop - Envoyer un paquet FIN/RST brut personnalisé au serveur et identifier la réponse.
Astuce : Cette méthode peut être facilement réalisée avec des outils comme HPing3 ou Scapy.
- Attaques par canal auxiliaire - Examiner le comportement temporel de la requête et du contenu de la réponse.
Astuce : Plus de détails peuvent être trouvés dans un article de blog ici.
0xinfection/awesome-waf
