portswigger-all-labs

Complete PortSwigger Web Security Academy Lab Writeups Detailed, categorized solutions for every lab — from APPRENTICE to EXPERT — covering all 30 vulnerability types.

View on GitHub

Labs Covered

This write-up focuses on the following EXPERT-level labs from the PortSwigger Web Security Academy related to Web Cache Poisoning:

10 Web cache poisoning to exploit a DOM vulnerability via a cache with strict cacheability criteria

This lab demonstrates how an attacker can leverage strict caching rules to poison cache responses that trigger DOM-based vulnerabilities in clients.

11 Combining web cache poisoning vulnerabilities

This lab shows how attackers can chain multiple cache poisoning vulnerabilities together to create a more reliable or severe attack.

12 Cache key injection

This lab demonstrates how injecting characters into the cache key allows attackers to manipulate which responses get cached.

13 Internal cache poisoning

This lab explores poisoning internal server-side caches that are not directly accessible to external users but influence backend behavior.

LAB 10 - Web cache poisoning to exploit a DOM vulnerability via a cache with strict cacheability criteria

Lab Description

image

Solution

First we will looK AT Normal REQUEST WE CAN SEE THAT HOST Come Inside Script in json.

image

Manipulating host header gives us error.

image

Next I have launch param Miner to brute force header and I have find X-forwarded-host I will used this to change host header

image

We can see that adding x-forwarded-host gives us the reponse website of that header

image

We have seen that /resources/js/geolocate.js we can also used network tab in console to see these request

image

The below is full code of /resources/js/geolocate.js

image

We can see that initgeolocation function taking json url and pastiung in div.

image

Reloading url and looking at network tab we can see that gelocation is requestion json file.

image

The response of above json file.

image

Now in exploit server we have done three thing

Add /resources/json/geolocate.json (because website is fetching request from this file from server) Add Access-Control-Allow-Origin:* ( So any other website request resources from over server) Add

{ "country": "<img src=1 onerror=alert(document.cookie) />" } (to genrate alert)

image

Now we have set ou exploit server we will chang x-forwarded-host to our exploit server url.

image

And we can see that json is loading from our server and it gnerate alert when any other user request from cache

image

We can see in below image now our json file of application has our xss script

image

Now lab is solved

image


LAB 11 - Combining web cache poisoning vulnerabilities

Lab Description

image

Solution

Website look like can be seen in images below we have option of changing language from english,arabic,esponal e.t.c

image

Trying manipulating header doesnot give me anything,When I look at network request and look for requests comes to us, we can see that we have translation.js and translation.json

image

Below is full code of translation.js

Notice that the website is vulnerable to DOM-XSS due to the way the initTranslations() function handles data from the JSON file for all languages except English.

image

Translation.json.

While I am changing language I notice that it take two request to change first is /setlang/en second is /?localized=1

image

When I send first request I see it is setting language in cookie

image

In second request I can see that lang=es is setting.

image

Now using param miner to identify header.

image

I have also run param miner to identify second parameter.

image

We can see below in param miner output it has identfied header

For first request it has identified X-Orignal header For secnd request it has identfied X-Forwarded-host

image

X-Original-URL can be used to change the path of the request, so you can explicitly set /setlang/es. However, you will find that this response cannot be cached because it contains the Set-Cookie header

image

Observe that the home page sometimes uses backslashes as a folder separator. Notice that the server normalizes these to forward slashes using a redirect. Therefore, X-Original-URL: /setlang\es triggers a 302 response that redirects to /setlang/es. Observe that this 302 response is cacheable and, therefore, can be used to force other users to the Spanish version of the home page.

image

Configuation of our exploit server

image

First, poison the GET /?localized=1 page using the X-Forwarded-Host header to import your malicious JSON file from the exploit server.

image

Now, while the cache is still poisoned, also poison the GET / page using X-Original-URL: /setlang\es to force all users to the Spanish page.

image

Now first we send this request so it will cache es for all the user I Have remove /setlan/es from get header because i want to change it for all the user in cache,Then after this I will send localized Request and relaod page lab is solved.

image

Looking after reloading jspon file gives us our exploit server json file so it excuted it.

image

Reload page change language to es and also generate alert and lab is solved

image

Lab is solved

image


LAB 12 - Cache key injection

Lab Description

image

Solution

After starting lab we see login Page.

image

Second Page of our lab /login

image

Intercept the first Page through burp

image

The when I click on /myaccount an intercept it through burp I see that Intercept page is redirecting us to /login

image

After redirecting we see the login page.

image

Now adding & will url encode it but ? Doesnot encode and reflected in response

image

This allows you append arbitrary unkeyed content to the lang parameter:

/login?lang=en?utm_content=anythin

image

We can see  `/js/localize.js` file in the script tag
And also0e `/js/localize.js?lang=en&cors=0` in re[ponse

image

Observe that the page at /login/ has an import from /js/localize.js. This is vulnerable to client-side parameter pollution via the lang parameter because it doesn’t URL-encode the value.We can also see that cahe is dependent on orgin from response.

image

We will send this below request first because it will craft alert in the cahe which make alert then from second requet below we call the origin to solved the lab

image

 GET /js/localize.js?lang=en?utm_content=z&cors=1&x=1 HTTP/1.1 Origin: x%0d%0aContent-Length:%208%0d%0a%0d%0aalert(1)$$$$

I am continously sending this request below

	
 GET /login?lang=en?utm_content=x%26cors=1%26x=1$$origin=x%250d%250aContent-Length:%208%250d%250a%250d%250aalert(1)$$%23 HTTP/2

Calling the the origin in baopve payload which is saved in cache to solved the lab .The reson is it is not solving is our origin o is in small letter in our header request the lower case is comply with with the HTTP/2 specification.

image

Now Make **O of Origin** in Capital letter and sending request will solved the lab

image

image


LAB 13 - Internal cache poisoning

Lab Description

image

Solution

When we open lab we see a page with exploit server

image

Intercepting above request we can see that our host is reflected in response.

image

Now use param miner in burp community to identify hidden headers

image

Below is default configuartion of the param miner

image

Pram miner doesnot identify any header

image

Now again using param miner to scan header but this time we have also Add dynamic cache buster option select.

image

Now the above configuration identify that X-Forwarded-Host is allowed.

image

Now adding X-Forwarded-Host we can see that it has overwritten the host And we can see the file link to it are also link to our exploit server File link to exploit server are :


/resources/js/analytics.js
/js/geolofcate.js?callback=loadCountry

image

After sending above request we can see in our access log we have 404 request in ou exploit server from exploit server.

image

We can see that load Country is directly coming form url.

image

Changing load country to arbitary word is reflected in reponse,So it can be affected by xss.

image

Loooking at analytics.js shows us that it is generating random id.

image

Goes to the exploit server and create a file at /js/geolocate.js containing the payload alert(document.cookie). Store the exploit.

image

Now sending request with cache buster we can se it is reflected in reponse

image

Back in Burp Repeater, disable the dynamic cache buster in the query string and re-add the X-Forwarded-Host header to point to your exploit server.

Send the request over and over until all three of the dynamic URLs in the response point to your exploit server. Keep replaying the request to keep the cache poisoned until the victim user visits the page and the lab is solved.

image

After sending above request we can see 200 gelocate.js response because we are serving it on our exploit server

image

And finally lab is solved

image