# Proxy / WAF Protections Bypass {% hint style="success" %} Apprenez et pratiquez le hacking AWS :[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\ Apprenez et pratiquez le hacking GCP : [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Soutenir HackTricks * Consultez les [**plans d'abonnement**](https://github.com/sponsors/carlospolop) ! * **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** nous sur **Twitter** 🐩 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.** * **Partagez des astuces de hacking en soumettant des PRs aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dĂ©pĂŽts github.
{% endhint %}
{% embed url="https://websec.nl/" %} ## Bypass des rĂšgles ACL Nginx avec manipulation de chemin Techniques [de cette recherche](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies). Exemple de rĂšgle Nginx : ```plaintext location = /admin { deny all; } location = /admin/ { deny all; } ``` 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 (en supprimant des 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 | `\xA0` | | 1.21.6 | `\xA0` | | 1.20.2 | `\xA0`, `\x09`, `\x0C` | | 1.18.0 | `\xA0`, `\x09`, `\x0C` | | 1.16.1 | `\xA0`, `\x09`, `\x0C` | ### **Flask** | Version Nginx | **CaractĂšres de contournement Flask** | | ------------- | --------------------------------------------------------------- | | 1.22.0 | `\x85`, `\xA0` | | 1.21.6 | `\x85`, `\xA0` | | 1.20.2 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` | | 1.18.0 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` | | 1.16.1 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` | ### **Spring Boot** | Version Nginx | **CaractĂšres de contournement Spring Boot** | | ------------- | -------------------------------------------- | | 1.22.0 | `;` | | 1.21.6 | `;` | | 1.20.2 | `\x09`, `;` | | 1.18.0 | `\x09`, `;` | | 1.16.1 | `\x09`, `;` | ### **PHP-FPM** Configuration FPM Nginx : ```plaintext location = /admin.php { deny all; } location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.1-fpm.sock; } ``` 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 ```plaintext location ~* ^/admin { deny all; } ``` ## Bypass Mod Security Rules ### Path Confusion [**Dans cet article**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) 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 accĂ©dĂ© (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 mod security supposera que le chemin est juste `/foo` parce que `%3f` est transformĂ© en `?` terminant le chemin 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 bug. Quelque chose de similaire s'est produit dans la version 2 de Mod Security qui a permis 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 `%2e`, par exemple : `https://example.com/backup%2ebak`. ## Bypass AWS WAF ACL ### Malformed Header [Cette recherche](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) mentionne qu'il Ă©tait possible de contourner les rĂšgles AWS WAF appliquĂ©es sur les 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 : ```http GET / HTTP/1.1\r\n Host: target.com\r\n X-Query: Value\r\n \t' or '1'='1' -- \r\n Connection: close\r\n \r\n ``` 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 tandis que le serveur NODEJS le faisait (cela a Ă©tĂ© corrigĂ©). ## Contournements gĂ©nĂ©riques de WAF ### Limites de taille de requĂȘte Les WAF ont gĂ©nĂ©ralement une certaine limite de longueur des requĂȘtes Ă  vĂ©rifier et si une requĂȘte POST/PUT/PATCH dĂ©passe cette limite, le WAF ne vĂ©rifiera pas la requĂȘte. * Pour AWS WAF, vous pouvez [**vĂ©rifier la documentation**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**
Taille maximale d'un corps de requĂȘte web pouvant ĂȘtre inspectĂ© pour les protections Application Load Balancer et AWS AppSync8 Ko
Taille maximale d'un corps de requĂȘte web pouvant ĂȘtre inspectĂ© pour les protections CloudFront, API Gateway, Amazon Cognito, App Runner et Verified Access**64 Ko
* D'aprĂšs [**la documentation Azure**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:** Les anciens pare-feu d'application web avec le Core Rule Set 3.1 (ou infĂ©rieur) permettent des messages plus grands que **128 Ko** en dĂ©sactivant l'inspection du corps de la requĂȘte, mais ces messages ne seront pas vĂ©rifiĂ©s pour des vulnĂ©rabilitĂ©s. Pour les versions plus rĂ©centes (Core Rule Set 3.2 ou plus rĂ©centes), la mĂȘme chose peut ĂȘtre faite en dĂ©sactivant la limite maximale du corps de la requĂȘte. Lorsqu'une requĂȘte dĂ©passe la limite de taille : Si **mode de prĂ©vention** : Journalise et bloque la requĂȘte.\ Si **mode de dĂ©tection** : Inspecte jusqu'Ă  la limite, ignore le reste et journalise si le `Content-Length` dĂ©passe la limite. * D'aprĂšs [**Akamai**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:** Par dĂ©faut, le WAF inspecte seulement les premiers 8 Ko d'une requĂȘte. Il peut augmenter la limite jusqu'Ă  128 Ko en ajoutant des mĂ©tadonnĂ©es avancĂ©es. * D'aprĂšs [**Cloudflare**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:** Jusqu'Ă  128 Ko. ### Obfuscation ```bash # IIS, ASP Clasic <%s%cr%u0131pt> == #changing the case of the tag < #prepending an additional "<" #using backticks instead of parenetheses java%0ascript:alert(1) #using encoded newline characters