There is no denying the role that JavaScript has played in turning web applications into the slick, interactive online experience we know and love today.
This powerful scripting language has brought interactivity and animation to the web.
But with great power comes great responsibility.
Cross-site scripting (XSS) remains a consistent mainstay in the OWASP top 10.
Malicious JavaScript hidden in the DOM is all it takes to compromise user data and avoid traditional server-side (XSS). scanning methods.
Content
- What is DOM based XSS?
- DOM-based cross-site scripting
- Example
- Sanation
- Conclusion
What is DOM based XSS?
The Document Object Model (DOM) allows web developers to dictate through HTML source code how a user’s web browser should display a web page.
DOM-based XSS attacks aim to exploit the DOM in two simple steps:
- Create a source. Inject a malicious script into a property that is considered susceptible to DOM-based XSS attacks. Common embedding vectors include document.url, document.location, and document.referrer objects.
- Sink usage: The sink is the point in the data flow at which the browser executes malicious JavaScript hidden in the DOM. Common receivers include document.write, setTimeout, and setInterval.
For a typical example of how a DOM-based XSS attack is performed, it is suggested to read DOM XSS: DOM-based cross-site scripting explained.
DOM-based cross-site scripting
DOM-based cross-site scripting (now referred to as DOM XSS) is a very specific variant of the cross-site script family, and in web application development it is generally considered to be a combination of the following:
- Document Object Model (DOM) − It acts as a standard way of representing HTML objects (i.e. <div></div>) in a hierarchical form.
- Cross-site scripting (XSS) is a specific web application vulnerability.
That being said, DOM XSS uses the DOM to consume XSS, relying on insecure handling of user input in a static or dynamic HTML page.
This is especially common when applications use common JavaScript function calls such as:
document.baseURI
To build some part of the page without sanitizing the return value.
However, the purpose of this article is not to fully explain DOM XSS, but how to defend against it.
Example
There is a DOM XSS vulnerability in one of our HTML5 test applications that can be exploited with the following payload:
http://testhtml5.vulnweb.com/#/redir?url=javascript:alert("DOM XSS on: " + document.domain)
The above is pretty trivial, but it’s an easy way to prove our point.
The payload is embedded in the URI and can therefore be easily included in a phishing campaign.
Payloads can be manipulated to remove the target application using the prompt “Your session has expired. Please enter your password to update your session.”
A simple yet effective way to collect passwords.
If we dig deeper, we find that the #redir route is being executed by another file called redir.html.
If you view the source code of the page, the gist of the code is as follows:
<script>
var redirUrl = decodeURIComponent(window.location.hash.slice(window.location.hash.indexOf("?url=")+5));
if (redirUrl) window.location = redirUrl;
</script>
Essentially, we’re using the window.location.hash source, which is evaluated in the HTML element receiver.
Sanation
DOM XSS detection is difficult with purely server-side detection (like HTTP requests), which is why providers like Acunetix use DeepScan for this.
These payloads are never sent to the server due to the fact that they are behind the HTML fragment (everything behind the # character).
As a result, the main problem lies in the code (such as JavaScript) that is on the page.
This means that you should always sanitize user input, whether or not it’s on the client side.
If you need to use user input at any point in time on your page, always use it in the context of literal “text” and not as potential code.
Avoid methods such as:
document.innerHTML
And instead, use safer functions when using user input, like so:
document.innerText document.textContent
This will refer to the previous payload we showed as just text and nothing else.
Also, avoid using user input.
The three properties above can manipulate the DOM, leading to these vulnerabilities.
Remember that DOM XSS and XSS are not mutually exclusive
This means that your application may be most vulnerable to both XSS and DOM XSS, even if XSS is usually on dynamic pages and DOM XSS is on static pages.
The good news is that if user input is treated properly as a base layer (like your structure), then you should be able to mitigate all XSS based vulnerabilities.
For a great cheat sheet on how to completely prevent DOM XSS, I highly recommend checking out the OWASP DOM Based XSS Prevention Cheat Sheet.
Conclusion
Finally, using a web application scanner like Acunetix’s DeepScan will greatly improve the speed and accuracy with which developers and security professionals can detect and fix vulnerabilities like DOM XSS and fix them, as well as thousands of others.