Web cache poisoning with an unkeyed header | Jan 22, 2023

Introduction

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

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

Background

This lab is vulnerable to web cache poisoning because it handles input from an unkeyed header in an unsafe way. An unsuspecting user regularly visits the site’s home page. To solve this lab, poison the cache with a response that executes alert(document.cookie) in the visitor’s browser.

Exploitation

Home page:

Burp Suite HTTP history:

In here, we see that the web server is using web cache. We can try to exploit web cache poisoning.

View source page:

<script type="text/javascript" src="//0aac000d032848eac0a590ea0070009e.web-security-academy.net/resources/js/tracking.js"></script>

In here, this imported JavaScript is weird to me, as the src attribute is referring to a domain.

After some fumbling, I found that the web application accepts unkeyed X-Forwarded-Host HTTP header:

Note: To prevent other users are being affected by our testing payload, we can use cache buster, which basically adding a random GET parameter.

We can inject anything we want to the src attribute is the imported tracking.js script file!

Armed with above information, we can inject a JavaScript that executes alert(document.cookie) in our browser!

"></script><img src=errorpls onerror=alert(document.cookie)>

Nice!

Next, we need to posion the web cache.

To do so, I’ll send the XSS payload request multiple times, until the cache is hit:

Then, we can go to /?buster=buster1 without the XSS payload:

Cool!

Now, we can really posion the home page by removing the cache buster, and repeat the previous step!

When the victim visit the home page, it’ll trigger our XSS payload!

What we’ve learned:

Web cache poisoning with an unkeyed header