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