Web cache poisoning via ambiguous requests | Dec 28, 2022

Introduction

Welcome to my another writeup! In this Portswigger Labs lab, you’ll learn: Web cache poisoning via ambiguous requests! Without further ado, let’s dive in.

Overall difficulty for me (From 1-10 stars): ★★★☆☆☆☆☆☆☆

Background

This lab is vulnerable to web cache poisoning due to discrepancies in how the cache and the back-end application handle ambiguous requests. An unsuspecting user regularly visits the site’s home page.

To solve the lab, poison the cache so the home page executes alert(document.cookie) in the victim’s browser.

Exploitation

Home page:

In the previous labs, we found that the back-end application will handle Host HTTP header.

Let’s send the / GET request to Burp Repeater:

Then, we can try to modify the Host header. For example, we can try to input any domain:

As you can see, it responses a HTTP status 504 Gateway Timeout, and our input is being reflected.

Also, after testing it, I found that our requests had been cached:

Let’s add an arbitrary query parameter to your requests to serve as a cache buster:

If we want a fresh response from the back-end server, we can just change that parameter.

After some testing, I found that when we add another Host header with any domain, something weird happend:

Our second Host header domain is reflected in an absolute URL used to import a script from /resources/js/tracking.js!

Let’s repeat the same process until we generate a new cache:

Now, what if I remove the second Host header and send the request again using the same cache buster?

It’s still there!

Armed with above information, we can go to the exploit server, and create a file at /resources/js/tracking.js containing the payload alert(document.cookie)!

Now, we can send request multiple times, and test it works or not:

It worked!

Now, we can remove the GET parameter in Burp Repeater, and then send request multiple times:

We did it!

What we’ve learned:

Web cache poisoning via ambiguous requests