A Story of DOM XSS

1 year ago 100

BOOK THIS SPACE FOR AD

ARTICLE AD

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.