Proxy / WAF Protections Bypass
Contournement des règles ACL Nginx avec la manipulation des noms de chemin
Techniques de cette recherche.
Exemple de règle Nginx :
Pour éviter les contournements, Nginx effectue une normalisation des chemins avant de les vérifier. Cependant, si le serveur backend effectue une normalisation différente (suppression de caractères que Nginx ne supprime pas), il pourrait être possible de contourner cette défense.
NodeJS - Express
Version Nginx | Caractères de contournement Node.js |
1.22.0 |
|
1.21.6 |
|
1.20.2 |
|
1.18.0 |
|
1.16.1 |
|
Flask
Version Nginx | Caractères de contournement Flask |
1.22.0 |
|
1.21.6 |
|
1.20.2 |
|
1.18.0 |
|
1.16.1 |
|
Spring Boot
Version Nginx | Caractères de contournement Spring Boot |
1.22.0 |
|
1.21.6 |
|
1.20.2 |
|
1.18.0 |
|
1.16.1 |
|
PHP-FPM
Configuration FPM Nginx :
Nginx est configuré pour bloquer l'accès à /admin.php
mais il est possible de contourner cela en accédant à /admin.php/index.php
.
Comment prévenir
Contourner les règles de sécurité de Mod Security
Confusion de chemin
Dans ce post, il est expliqué que ModSecurity v3 (jusqu'à 3.0.12) a mal implémenté la variable REQUEST_FILENAME
qui était censée contenir le chemin d'accès (jusqu'au début des paramètres). Cela est dû au fait qu'il effectuait un décodage d'URL pour obtenir le chemin.
Par conséquent, une requête comme http://example.com/foo%3f';alert(1);foo=
dans ModSecurity supposera que le chemin est simplement /foo
car %3f
est transformé en ?
terminant le chemin de l'URL, mais en réalité le chemin que le serveur recevra sera /foo%3f';alert(1);foo=
.
Les variables REQUEST_BASENAME
et PATH_INFO
ont également été affectées par ce bogue.
Quelque chose de similaire s'est produit dans la version 2 de Mod Security qui permettait de contourner une protection empêchant l'utilisateur d'accéder à des fichiers avec des extensions spécifiques liées aux fichiers de sauvegarde (comme .bak
) simplement en envoyant le point encodé en URL en %2e
, par exemple : https://example.com/backup%2ebak
.
Contourner les ACL AWS WAF
En-tête malformée
Cette recherche mentionne qu'il était possible de contourner les règles AWS WAF appliquées aux en-têtes HTTP en envoyant un en-tête "malformé" qui n'était pas correctement analysé par AWS mais l'était par le serveur backend.
Par exemple, en envoyant la requête suivante avec une injection SQL dans l'en-tête X-Query :
Il était possible de contourner AWS WAF car il ne comprenait pas que la ligne suivante faisait partie de la valeur de l'en-tête alors que le serveur NODEJS le faisait (ce problème a été corrigé).
Références
Last updated