# Proxy / WAF Schutzumgehung {{#include ../banners/hacktricks-training.md}} ## Umgehung von Nginx ACL-Regeln mit Pfadmanipulation Techniken [aus dieser Forschung](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies). Beispiel für eine Nginx-Regel: ```plaintext location = /admin { deny all; } location = /admin/ { deny all; } ``` Um Umgehungen zu verhindern, führt Nginx eine Pfadnormalisierung durch, bevor es diesen überprüft. Wenn der Backend-Server jedoch eine andere Normalisierung vornimmt (Zeichen entfernt, die Nginx nicht entfernt), könnte es möglich sein, diese Verteidigung zu umgehen. ### **NodeJS - Express** | Nginx Version | **Node.js Bypass-Zeichen** | | ------------- | ----------------------------- | | 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** | Nginx Version | **Flask Bypass-Zeichen** | | ------------- | ------------------------------------------------------------ | | 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** | Nginx Version | **Spring Boot Bypass-Zeichen** | | ------------- | --------------------------------- | | 1.22.0 | `;` | | 1.21.6 | `;` | | 1.20.2 | `\x09`, `;` | | 1.18.0 | `\x09`, `;` | | 1.16.1 | `\x09`, `;` | ### **PHP-FPM** Nginx FPM-Konfiguration: ```plaintext location = /admin.php { deny all; } location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.1-fpm.sock; } ``` Nginx ist so konfiguriert, dass der Zugriff auf `/admin.php` blockiert wird, aber es ist möglich, dies zu umgehen, indem man auf `/admin.php/index.php` zugreift. ### Wie man verhindert ```plaintext location ~* ^/admin { deny all; } ``` ## Umgehung von Mod Security Regeln ### Pfadverwirrung [**In diesem Beitrag**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) wird erklärt, dass ModSecurity v3 (bis 3.0.12) **die `REQUEST_FILENAME`** Variable unsachgemäß implementiert hat, die den aufgerufenen Pfad (bis zum Beginn der Parameter) enthalten sollte. Dies liegt daran, dass eine URL-Dekodierung durchgeführt wurde, um den Pfad zu erhalten.\ Daher wird eine Anfrage wie `http://example.com/foo%3f';alert(1);foo=` in Mod Security annehmen, dass der Pfad nur `/foo` ist, da `%3f` in `?` umgewandelt wird, was den URL-Pfad beendet, aber tatsächlich wird der Pfad, den ein Server erhält, `/foo%3f';alert(1);foo=` sein. Die Variablen `REQUEST_BASENAME` und `PATH_INFO` waren ebenfalls von diesem Fehler betroffen. Etwas Ähnliches trat in Version 2 von Mod Security auf, das es ermöglichte, einen Schutz zu umgehen, der den Zugriff von Benutzern auf Dateien mit bestimmten Erweiterungen, die mit Sicherungsdateien (wie `.bak`) verbunden sind, verhinderte, indem einfach der Punkt URL-kodiert in `%2e` gesendet wurde, zum Beispiel: `https://example.com/backup%2ebak`. ## Umgehung von AWS WAF ACL ### Fehlformatierter Header [Diese Forschung](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) erwähnt, dass es möglich war, AWS WAF-Regeln, die auf HTTP-Header angewendet wurden, zu umgehen, indem ein "fehlformatierter" Header gesendet wurde, der von AWS nicht richtig analysiert, aber vom Backend-Server verarbeitet wurde. Zum Beispiel, indem die folgende Anfrage mit einer SQL-Injection im Header X-Query gesendet wird: ```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 ``` Es war möglich, AWS WAF zu umgehen, da es nicht verstand, dass die nächste Zeile Teil des Wertes des Headers ist, während der NODEJS-Server dies tat (dies wurde behoben). ## Generische WAF-Umgehungen ### Anforderungsgrößenbeschränkungen Üblicherweise haben WAFs eine bestimmte Längenbeschränkung für Anfragen, die überprüft werden, und wenn eine POST/PUT/PATCH-Anfrage darüber hinausgeht, wird die Anfrage nicht überprüft. - Für AWS WAF können Sie [**die Dokumentation überprüfen**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**
Maximale Größe eines Webanfragekörpers, der für Application Load Balancer und AWS AppSync-Schutzmaßnahmen überprüft werden kann8 KB
Maximale Größe eines Webanfragekörpers, der für CloudFront, API Gateway, Amazon Cognito, App Runner und Verified Access-Schutzmaßnahmen überprüft werden kann**64 KB
- Aus [**Azure-Dokumenten**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:** Ältere Webanwendungsfirewalls mit Core Rule Set 3.1 (oder niedriger) erlauben Nachrichten größer als **128 KB**, indem die Inspektion des Anfragekörpers deaktiviert wird, aber diese Nachrichten werden nicht auf Schwachstellen überprüft. Bei neueren Versionen (Core Rule Set 3.2 oder neuer) kann dasselbe durch Deaktivieren der maximalen Anfragekörpergrenze erreicht werden. Wenn eine Anfrage die Größenbeschränkung überschreitet: Wenn **Präventionsmodus**: Protokolliert und blockiert die Anfrage.\ Wenn **Erkennungsmodus**: Überprüft bis zur Grenze, ignoriert den Rest und protokolliert, wenn die `Content-Length` die Grenze überschreitet. - Aus [**Akamai**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:** Standardmäßig überprüft die WAF nur die ersten 8 KB einer Anfrage. Sie kann das Limit auf bis zu 128 KB erhöhen, indem sie erweiterte Metadaten hinzufügt. - Aus [**Cloudflare**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:** Bis zu 128 KB. ### Obfuskation ```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