> 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/cache-poisoning/cache-poisoning-via-unindexed-query-parameter.md).
# Cache-Poisoning über einen nicht indizierten Query-Parameter
Notizen zum Cache-Poisoning über einen nicht indizierten Query-Parameter für die Labs der PortSwigger Web Security Academy, einschließlich Ausnutzungsablauf, Payload-Tests, Burp-Suite-Validierung und Behebungskontext.
### Web-Cache-Poisoning über einen nicht in den Cache-Schlüssel aufgenommenen Query-Parameter
Dieses Lab ist anfällig für einen Web-Cache-Poisoning-Angriff, da ein Query-Parameter nicht im Cache-Schlüssel enthalten ist. / Ein Benutzer besucht regelmäßig die Startseite der Website mit Chrome. / Das Ziel ist es, den Cache zu vergiften, sodass die Startseite eine Antwort ausliefert, die ausgeführt wird `alert(1)` im Browser des Opfers ausführt.
**Erste Analyse**
* Beim Abfangen der Antwort der Startseite wird ein **kanonisch** Link beobachtet.
* Wenn Sie die URL mit einem beliebigen Parameter aufrufen, zum Beispiel `/?hello`, wird der Wert in der Antwort gut reflektiert
Beim Einfügen einer Payload wie:
```bash
/?test'/>
```
* HTML-Code wird in der Antwort interpretiert, aber auf der Opferseite werden keine Alarme ausgelöst.
**Identifiziertes Problem**
Der Cache betrachtet jede Variante des `?test` Parameters als neue Eingabe. / Daher wird der Cache bei jeder Wertänderung neu generiert und die Vergiftung bleibt nicht bestehen.
Einige Parameter werden jedoch **vollständig ignoriert** vom Cache-Schlüssel:
* Ihr Name und Wert werden nicht berücksichtigt.
* Die zwischengespeicherte Antwort bleibt gleich, selbst wenn sich ihr Wert ändert.
**Identifizierung des nicht indizierten Parameters**
Verwendung von **Param Miner** (Funktion zum Erraten von Query-Parametern), der `utm_content` Parameter wird identifiziert.
* Durch das Testen verschiedener Werte für diesen Parameter stellen wir fest, dass der Cache unverändert bleibt, was bestätigt, dass er nicht im Cache-Schlüssel enthalten ist.
/?utm_content=test
**Ausnutzung**
Die bösartige Payload wird dann in diesen nicht indizierten Parameter injiziert:
```bash
/?utm_content='/>
```
Die vergiftete Antwort wird im Cache gespeichert und den folgenden Besuchern ausgeliefert.
---
# 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/cache-poisoning/cache-poisoning-via-unindexed-query-parameter.md?ask=&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.
