1. Introduction to DOM Based Cross-Site Scripting
DOM Based XSS is an attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser. These modifications are usually performed by client side scripts.
In the case of a DOM XSS vulnerability the HTTP response sent by the server is not different from the normal execution of the application, but the payload injected from the attacker executes only in the browser of the victim.
This behavior is different from other XSS attacks (Stored or Reflected), where the attack payload is contained in the response page (due to a server side flaw).
In the following example of OWASP code, "document.location.href" or "document.write" may appear not to be harmful, but depending on their use, they can lead to a DOM XSS vulnerability.
[..] Select your language: [..]Indeed, the "document.location.href" property is a Source because it can be controlled by the user through the input in the GET request (lang=[user-controlled-input]). On the opposite side, "document.write" is considered a Sink, because this is a function that could be abused to cause security issues. This kind of flow in the code can generate a DOM related vulnerability.
Using the following request it is possible to exploit the above DOMXSS:
http://www.example.tld/page.html?lang=<script>alert(document.cookie)</script>
When the victim clicks on this link, the browser sends a request for:
/page.html?lang=<script>alert(document.cookie)</script>The server replies with the page containing the above JavaScript code.
The browser creates a DOM object for the page, in which the document.location object contains the string:
http://www.example.tld/page.html?lang=<script>alert(document.cookie)</script>
The original JavaScript code in the page does not expect the “lang” parameter to contain HTML markup, and therefore it simply echoes it into the page (DOM) at runtime.
The browser then renders the resulting page and executes the attacker’s script:
alert(document.cookie)Note that the HTTP response sent from the server does not contain the attacker’s payload, because the payload itself is executed only at the Client-side level.
2. BlueClosure Detection of DOM Based Cross-Site Scripting
The BlueClosure BCDetect product (https://www.blueclosure.com) can easily detect DOM HTML Injection vulnerability in web pages.
In this part of the article we are going to see how it is possible to use BCDetect in order to identify a DOM XSS vulnerability and perform a detailed analysis of it.
Let’s begin with a simple example (in the next articles we will explain the Detection and Exploiting phases of much more complex examples aimed toward more advanced readers).
Once BCDetect instance has started, we can visit the website domxss.com (this service is hosted from MindedSecurity in order to practice DOM related vulnerabilties. It offers various sections with different kinds of vulnerabilities). When opening the following page (http://www.domxss.com/domxss/01_Basics/00_simple_noHead.html) with BCDetect, the user is prompted with a pop-up window showing a potential vulnerability in the JavaScript code of the page as shown in the following screenshots:
The popup alerts the user with the Summary view which includes alerts, warning and informational issues found in the page; Clicking on an issue it shows the specific data of the vulnerability through the dedicated BCDetect browser window, as shown in the following screenshot:
This window can be considered as a "point of reference" which shows all the possible issues, warnings or information previously found while browsing the target website.
Looking at the vulnerability pane, we can infer that the issue is categorized as an Alert and it could be a potential High Risk vulnerability (BCDetect makes a great effort to minimize False-positives, but this will be the subject for a later article). So let's examine the HTML Injection previously pointed out.
The following snippet shows the source code of the page that BCDetect analyzed at runtime:
In order to better investigate the vulnerability, we can simply click on the related box and a detailed "history" window will appear below it. This window will contain all the information that led to the discover of the vulnerability itself.
Looking at the vulnerability pane, we can infer that the issue is categorized as an Alert and it could be a potential High Risk vulnerability (BCDetect makes a great effort to minimize False-positives, but this will be the subject for a later article). So let's examine the HTML Injection previously pointed out.
The following snippet shows the source code of the page that BCDetect analyzed at runtime:
<script>
var pos = document.URL.indexOf("name=") + 5;
var r = '' +
document.URL.substring(pos, document.URL.length) +
''
document.write(unescape(r));
</script>
As shown above, the string is retrieved from the "name=" parameter which is not filtered in any way, nor in input via document.URI neither in output via document.write.
In order to better investigate the vulnerability, we can simply click on the related box and a detailed "history" window will appear below it. This window will contain all the information that led to the discover of the vulnerability itself.
As shown in the above image, the window contains the categorization of the vulnerability, it shows if the issue is Exploitable or not, if the data is Encoded or Not Encoded. It also highlights the user's controllable value and the vulnerable code, identified by the engine of BCDetect.
By clicking the link "Show operations", there are a couple of features that give us the ability to have more information about the vulnerability going through the specific low-level information (Inside the box History -> Flow #N and Show Operations).
For instance:
By clicking the link "Show operations", there are a couple of features that give us the ability to have more information about the vulnerability going through the specific low-level information (Inside the box History -> Flow #N and Show Operations).
For instance:
These are the main points to understand how to perform the Detection phase with BCDetect and conduct a smart analysis of the issue.
In the previous section we saw how BCDetect was able to identify an HTML injection issue in real-time and how to exploit it (in the user's client context).
Let 's consider the example we were using in the detection phase and type the following request in our browser:
http://www.domxss.com/domxss/01_Basics/00_simple_noHead.html?#name=<script>alert(document.cookie)</script>
We will see that the page shows an alert popup containing the user's cookie values as shown in the following screenshot.
2.1 BlueClosure Exploiting a DOM Based Cross-Site Scripting
In the previous section we saw how BCDetect was able to identify an HTML injection issue in real-time and how to exploit it (in the user's client context).
Let 's consider the example we were using in the detection phase and type the following request in our browser:
http://www.domxss.com/domxss/01_Basics/00_simple_noHead.html?#name=<script>alert(document.cookie)</script>
We will see that the page shows an alert popup containing the user's cookie values as shown in the following screenshot.
Using more advanced payloads, an attacker can steal the cookies and try to impersonate the victim.
Even during the exploiting phase, BCDetect will report us through the popup notifications which as usual contains the type of vulnerability and the information about it, as can be seen in the the following screenshot:
Even during the exploiting phase, BCDetect will report us through the popup notifications which as usual contains the type of vulnerability and the information about it, as can be seen in the the following screenshot:
