Intigriti XSS Challenge February 2022

Hope you enjoy reading my writep. Have a nice day and enjoy!

Hello guys I am back. This challenge was awesome btw. So let’s start talking.

This is the description of the challenge. But however I was using FireFox and it wasn’t working for me at all. But I fixed xD. Let’s start talking.

Let’s type in name field ‘rootjkqsta’. It will say ‘Welcome Back!’, but let’s view page source.

So our input is being loaded using DOM innerHTML property. So our name is reflected in the q parameter.

Let’s type one payload and see is it gonna be executed. In this case we will use <svg/onload=alert(1)> payload.

The name-field is not sanitized and is vulnerable to DOM XSS. It didn’t gave me any alert tho. Bc it doesn’t supports FireFox latest version for some reason so I’d recommend using Chrome but however I will show solution at the ending. This is not end btw. The challenge wants us to execute alert(document.domain). You can see it in challenge’s description. But DOM innerHTML Property it doesn’t allows the execution of JavaScript thro <script> tags. Our only option is to use event handlers to achieve JavaScript execution. We tried a payload like<svg/onload=alert(document.domain)> but we got error.

Let’s check view page source again.

Yeah it limits the input to a maximum of 24 characters. But have you noticed that our input is stored in the qs variable. Now we need to craft our payload. If our input qs is limited to only 24 characters, what about uri ?

var uri = decodeURIComponent(location.href)

The uri variable is just our URL. We can inject the payload in the URL and use it in eval(). We can find short XSS payloads on github tho.

<svg/onload=eval(uri)>

Now we can inject our payload in the URL. But wait if we try to inject this payload we will get syntax error. Have you noticed that double slash from the URL is causing the payload to be a single line comment? Single comment can’t be closed with another comment. The only way to escape a single line comment is by making another line. We only control the URL. What about adding another line to the uri variable? Well, it's the vulnerability in the variable declaration. It carelessly used decodeURIComponent(). We can add a new line by URL encoding CRLF %0d%0a

Also vulnerability caused by a mistake. The only thing we need to do is add it and there should be a pop up of document.domain

<svg/onload=eval(uri)>&first=yes#%0d%0aalert(document.domain);//

So I used <style> bc svg load handler working in Chrome but not in the Firefox. So I tried <style> and it worked. This challenge about DOM XSS was amazing.

README.md

Hope you guys enjoyed this writeup, hope you learned something new, take a care and see you in a next one. Peace out.