〰️WAF / Filter bypass
Sites
Methodologie
Le principal défi lorsque vous essayez d'adapter un payload de contournement est de déterminer comment la charge utile est comprise par le pare-feu de l'application Web. Puisqu'un WAF ne répond qu'avec une page d'interdiction ou non, il faut avancer par petites étapes ce qui que prendre beaucoups de temps.
Considérons le simple payload suivant:
<script>
Voici un exemple de process de contournement:
<script> //bloqué
<script/x //bloqué (peut-être une regex "<script.*")
:script/x //OK (bloqué si le payload commence par "<")
<tst> //OK (bloqué si le payload commence par "<" et blacklist "script")
<%ascript> //OK (confirme que la regex fonctionne comme ceci "<[blacklist].*"
Maintenant on peut vérifier les caractères possibles dans le tag comme ceci:
%20 : espace
%3d : '
%27 : =
%28 : (
%29 : )
%09 : tab
%0a : newline
<x%20x%3dx%27x%28x%29x%09x%0a> //bloqué (l'un des caractères est bloqué)
fonctionnement par elimination: on va supprimer les caractères un par un
<x%20x%09x> //OK
<%09script> //OK (le backend ne prend pas en compte le tab donnant le résultat espéré)Template de test manuel
Cross-Site scripting
SQL injection
Local file inclusion
Mindmap de test manuel

Bypass de regex / blacklist
Lorsque vous essayez de contourner un WAF, il est très important de déterminer d'abord comment fonctionne le filtre frontend/backend avant de tenter de l'exploiter. Si l'entrée est automatiquement encodé et n'est donc pas vulnérable, à quoi bon contourner le pare-feu ?
Utiliser .%00%./file.php dans l'url.
Cloudflare
Faiblesses
Retour à la ligne qui sépare le payload
Surplus de parenthèses =>
(sleep((3)))Payloads sans espaces =>
'or-'1Blacklist faibles
Encodage base64
Akamai
Faiblesses
esRetour à la ligne qui sépare le payload
Maths pour comparer ou placer des valeurs =>
(2-10/2)Double url encoding =>
%2522Encodage base64
Fin de tag trop =>
<img/>/onload=... ou <img/>;/onload=...Espaces avant parenthèses ou quillemets =>
Payloads sans espaces =>
'or-'1
Sucuri
Fortiweb
Imperva
Cloudflare rate limit
Cible: prod.target.com
Il est parfois possible de bypass le rate limit d'un waf Cloudflare en changeant le mot prod à chaque limite atteinte si celui-ci est redirigé vers prod.target.com.
Exemple:
prod.target.com => password1 OK
prod.target.com => password2 OK
prod.target.com => password3 Blocked
crod.target.com => prod.target.com => password3 OK
PHP htmlspecialchars() bypass
PHP 7 et 8 ne filtrent pas le caractère "\":
payload: \x3cimg src=x onerror=alert(1)\x3e@x
Variables globales javascript
Encoding / Double encoding
Unicode
Commentaires
Caractères spéciaux
Junk characters
Saut de ligne
Variables non initialisées
Tabs and Line Feeds
OS injection
$0<<<$'\$(($((1<<1))#10010111))\$(($((1<<1))#10010000))'
Mutations balise <a>

XML/HTML confusion
mime type => application/xhtml+xml
Changer le content encoding
Il est parfois possible de contourner la protection du WAF en utilisant l'en-tête custom 'Content-Encoding: radomtext'.
Changer le header pour les upload de fichiers
Certaines librairies plutôt que d'utiliser le nom de l'extension du fichier pour définir son content-type utilisent son header comme "libmagic" par exemple. (#!/bin/node => content-type: application/javascript)
Multipart parser manipulation
Méthode 1: URL encoding > Multipart format
Si le WAF n'a pas de parser multipart, remplacer le body encoding par multipart/form-data peut parfois suffir à contourner la validation.
Cela peut se faire simplement sur Burp sans extension en faisant un clic droit > Change body encoding.
Méthode 2: Dédoubelement de paramètres
Dépendemment du parser utilisé, l'utilisation de deux paramètres similaires avec des valeurs différentes dans l'en-tête Content-Disposition: des requêtes multipart peuvent parfois permettre de contourner des restrictions.
Exp:
Méthode 3: Dédoublement de Content-Disposition
De la même manière, utiliser deux en-têtes Content-Disposition: dans une même partie peut parfois permettre de valider une entrée spécifique si le parser ne valide qu'une seule d'entre elles.
Exp:
Méthode 4: Casser la séquence CRLF
Beaucoup de parsers distinguent les headers du body en recherchant la séquence CRLF \r\n\r\n Dans la requête HTTP utilisé à cet effet. De ce fait, en suppriment l'un de ces caractères, certains parsers ne sont pas en capacité de différencier les headers du body et ne parviennent ainsi pas a valider correctement le contenu de la requête.
Exp:
Méthode 5: Supprimer ou remplacer les quotes des paramètres
Dans certains cas, remplacer les quotes par des single quotes ou les supprimer totalement peut permettre de faire confondre au WAF un file upload et un formulaire traditionnel ce qui peut avoir pour effet de contourner la validation de celui-ci.
Exp:
Méthode 6: Absence de ending boundary string
Traditionnellement, un format multipart valide comprend plusieurs chaînes appelées "boundary" permettant de séparer les paramètres en parties. Pour que la requête soit valide, il faut que chaque partie ai une chaîne de début ET une chaîne de fin. En PHP, Ne pas mettre de châine de fin n'a aucun effet sur le traitement de la requête ce qui peut parfois permettre de contourner la validation des WAF.
Exp:
Méthode 7: filename*utf-8=''
Selon la RFC 6266, le paramètre filename* permet d'utiliser des caractères spéciaux et encoding dans des requêtes multipart mais n'est pas supporté par tous les languages de programation (exp: PHP) ce qui en fait un outil de contournement de validation très utile pour les uploads de fichiers.
Exp:
Outils
Waf-bypass
Analyseur de WAF.
Utilisation:
$ python3 main.py --host="target.com"
ressources: https://github.com/nemesida-waf/waf-bypass
Tips SQLMap
utiliser les arguments --random-agent --level=5 --risk=3 --tamper="space2comment,between,randomcase,charencode"
Mis à jour
Ce contenu vous a-t-il été utile ?