# 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 AppSync | 8 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