Lab 1: 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.
Solution:
Find the search bar and simply search with an script tag with alert function.
<script>alert()</script>
Lab 2: 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.
Solution:
Go to a post and find comments section. Add a comment with the same script tag and you’re done.
Lab 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.
Solution:
First search for anything random string in search box and then inspect the page to see the rendered code after search. If you look carefully you will find a script tag related to search query with a document.write method which is using that search query to write context directly into HTML doument.
it looks like this:
<script>
function trackSearch(query) {
document.write(’<img src=”/resources/images/tracker.gif?searchTerms=’+query+’”>’);
}
var query = (new URLSearchParams(window.location.search)).get(’search’);
if(query) {
trackSearch(query);
}
</script>
In this script tag document.write method is basically putting your search word/query from search box into that query variable and then putting that query variable into the img source. Basically, anything we type in that searchbox will get reflected here in this img tag. So we can just try to breakout (complete the img tag by completing syntax) from that img tag followed by our javascript code.
Something like this:
hello” onload=”alert()
So the rendered img tag will look like this:
<img src=”/resources/images/tracker.gif?searchTerms=hello” onload=”alert()”>
Lab 4: 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.
Solution:
Lab says it used an innerHTML assignment to change content somewhere on page. Inspect the page to find out the script where it has innerHTML. You will see a section in HTML where there is a script tag having a function that is taking the search term from search box and then using document.getElementByID.innerHTML method to change the data on the page.
<section class=blog-header>
<h1><span>0 search results for ’</span><span id=”searchMessage”></span><span>’</span></h1>
<script>
function doSearchQuery(query) {
document.getElementById(’searchMessage’).innerHTML = query;
}
var query = (new URLSearchParams(window.location.search)).get(’search’);
if(query) {
doSearchQuery(query);
}
</script>
<hr>
</section>
As you can see in the code above, the html with id “searchMessage” which is getting updated is a span tag. So, whatever you search in the search box, it will get added inside this span tag. To exploit this we will add a simple img tag calling an alert function. Why img tag? Because putting a script tag inside a span tag is not supported.
<img src=blah onerror=”alert()”>
We have to use onerror event handler because we don’t have an actual image path to show on the web page, so by putting dummy path it will trigger the onerror event handler which will call the alert function and this is how we solve this lab.
Lab 5: DOM XSS in jQuery anchor href attribute sink using location.search source
Description: 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.
Solution:
Another DOM based XSS vulnerability. Inspect the page code and we can see a function in a script tag. But this time it’s using jQuery selector to find id (#backLink) of anchor tag to change its href attribute data using URLSearchParams(window.location.search). Basically its taking data from the URL itself that ends with /feedback?returnPath=/feedback.
<div class=”is-linkback”>
<a id=”backLink”>Back</a>
</div>
<script>
$(function() {
$(’#backLink’).attr(”href”, (new URLSearchParams(window.location.search)).get(’returnPath’));
});
</script>
Now just change the query parament returnPath to / followed by some random string and you’ll see it’s getting placed inside a href attribute in that anchor tag which has id=backLink. Change that returnPath to javascript:alert(document.cookie) so that it will run this alert function java script when clicked.
Basically the URL should end like this:
https://somethingsomething.web-security-academy.net/feedback?returnPath=javascript:alert(document.cookie) and hit enter which will save this new href data to that back button on the page. And finally click the button to complete the Lab.