A Story of DOM XSS

1 month ago 10

Good day, everyone! This is my second article, this time on DOM XSS. An open redirection vulnerability was escalated to DOM XSS. If you haven’t already, please read my previous blog about Reflected XSS.

My introduction:

I am Mohamed Dhanish, Security Researcher. I’ve been studying, practicing, and learning Bug Bounties for quite some time. I began my Bug Bounty Hunter quest by reading security writeups, HackerOne reports, and solving labs, much like every other Bug Bounty Hunter.

Without further ado, Let’s get started :)

What is DOM Cross-site scripting?

It’s a client-side vulnerability that occurs when javascript code accepts the source and mishandles it in such a way that it executes in the sink.

Let’s see and example:

<html>
<head>
<title>DOM XSS Example</title>
</head>
<body>
<script>
var x = document.location.hash.substr(1);
window.location=x;
</script>
</body>
</html>

Assume there is an HTML page that uses the code above. It basically takes what comes after the hash in the URL and uses window.location to redirect the user to it.

If the attacker enters the value javascript:alert(1) after the hash, the alert(1) function will be executed as proof of the DOM XSS vulnerability.

Exploit: http://www.victim.com/domxss.html#javascript:alert(1)

Now lets dive into real exploitation

The target’s name has been redacted. I was doing recon for the target.com. However, I was disappointed to find nothing interesting during the recon process. So I decided to test the application’s internal functionality by examining all of its functionality and usage.

Please see my earlier blog for more information on my recon method.

I came across an interesting URL with the Source.URI= parameter.

I instantly thought of checking for open redirection and set the parameter to https://evil.com.

After injecting the parameter with the payload, I checked the application’s source code, thinking I’d be redirected to the attacker domain.

My payload appears to have been injected into the page’s back button. When I returned to the app and hit the back button, I was taken to evil.com

Open Redirection

Following this, I immediately considered escalating my open redirection vulnerability to cross-site scripting.

Cool. I was able to achieve DOM XSS by using a simple payload. When looking to exploit an application, always look at the source code. :D

Thanks for your time.

I think you got something out of it. Please give me a thumbs up and subscribe for more content.

Happy Hunting!

Here is my LinkedIn handle www.linkedin.com/in/mohamed-dhanish-233b3919a . Feel free to contact me.

Read Entire Article