JavaScript Dangerous Functions (Part 2) - DOM Based XSS

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:


 <script>
  document.write(""+
   document.location.href.substring(
   document.location.href.indexOf("lang=")+4)+
   "");

  document.write("English");
 </script>

[..]

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:

<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:

These are the main points to understand how to perform the Detection phase with BCDetect and conduct a smart analysis of the issue.

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:

JavaScript Dangerous Functions (Part 1) - HTML Manipulation

1. Introduction to HTML Manipulation Functions 

When a method or operation allows HTML manipulation if it is possible to control, even partially, an argument, then it is possible to manipulate, to some extent the HTML and consequently gain control of the user interface or execute JavaScript using classic Cross Site Scripting attacks. 

Data flow starts from Sources (input data that could be tainted) and ends to Sinks (functions potentially dangerous).

In software security the Sources[*] are to be considered starting points where untrusted input data is taken by an application.

There are two types of input sources: Direct and Indirect. In this next articles, we will analyze the various types of Direct/Indirect input and how malicious JavaScript code can cause damage by exploiting incorrect programming techniques.

In software security the Sinks[*] are meant to be the points in the flow where data depending from sources is used in a potentially dangerous way resulting in loss of Confidentiality, Integrity or Availability (the CIA triad).

This means that a function is a Sink if its behavior is generally safe but could be dangerous with a tainted input data.

To understand the difference between Source and tainted Source take a look to the following code:

<script>
    var name = document.URL.indexOf("name=") + 5;  <- TAINTED SOURCE
    document.write("Welcome " + 
    document.URL.substring(name, document.URL.length)); <- SINK
</script>

Source:  document.URL
Sink:      document.write()
Result:   document.write(“<script>alert(document.cookie)</script>”);

The exploit will take place when visiting the following URL:

      http://example.tld/page.html#name=<script>alert(document.cookie)</script>

* Glossary 
Sources: Sources are all the DOM Properties that can be influenced by an attacker. 
Sinks: Sinks are all the DOM Properties, JavaScript functions and other Client-side entities that can lead to or influence Client-side code execution.

1.1  Table of dangerous JavaScript functions/properties for HTML Manipulation

Here below we report a table with the principal sinks that allow HTML manipulation which likely will result JavaScript execution.

Function Name	Browser	Example
document.write	All	document.write(“<b>” + userControlledVal + “</b>”);
document.writeln	All	document.writeln("<b>" + userControlledVal + "</b>");
anyElement.innerHTML	All	divElem.innerHTML = “Hello ” + userControlledVal
anyElement.outerHTML	All	divElem.outerHTML = "<div>Hello " + userControlledVal + "</div>"
anyElement.insertAdjacentHTML	All	divElem.insertAdjacentHTML("","<b>"+ userControlledVal + "</b>");)
...

2.    Differences between document.write functions and properties like innerHTML

The document.write method: 

Let's take functions like document.write (or document.writeln) as an example to explain better the Sink and let's see the difference between this function and for example, the property innerHTML.

As we can see, the document.write goes to operate in a direct way as Sink writing (output) the malicious code entered by a user who checks the value, going, in fact, to the following URL: 

     http://example.tld/page.html#?foo=<script>alert(document.cookie)</script>

 And, by analyzing the page code:

<script>
    var pos = document.URL.indexOf("foo=") + 4; <- TAINTED SOURCE
    document.write(documemt.URL.substring(pos, document.URL.length)); <- SINK
</script>

We can see that the Sink in question, therefore, the document.write will have the task of printing screen the data value inserted into the function as an argument, and though having passed the user argument of malicious JavaScript code, then the function will only unintentionally execute writing in the DOM code in question, then:

  alert(document.cookie)

Building up the browser side, then Client-side, a popup containing the cookie values ​​of the current user session.

The innerHTML method: 

Concerning the use of the innerHTML method, and, of how this can be abused by an object controlled directly by a user, we can make a more detailed example, then let’s take the following code:

<div id="nm">John Doe</div>
<script>
    var name = window.localStorage.name; <- SOURCE
    document.getElementById("nm").innerHTML = name; 
</script>

As you can see, if we call the innerHTML method to retrieve the information, nothing happens, even in the case that instead of the name "John Doe" there has been the malicious JavaScript code; Instead let’s take another example:

<div id="nm">John Doe</div>
<script>
    var pos = document.URL.indexOf("name=") + 5;
    var name = document.URL.substring(pos, document.URL.length);  <- TAINTED

    document.getElementById("nm").innerHTML = name;  <- SINK

</script>

Following this example script and browsing its URL:

     http://example.tld/page.html?name=<script>alert(document.cookie)</script>

In this case, the browser will return us a window that is to show us that our JavaScript code passed to the URL parameter name, was executed.

2.1  Examples of vulnerable source code for the HTML Manipulation vulnerabilities

At this point we can do is give a few examples so you can see the various existing possibilities that allow you to identify and subsequently Exploiting a vulnerability in HTML Manipulation type, then:

• DOM Based Cross-Site Scripting 
• Stored DOM Based Cross-Site Scripting 
• Others

Then we will see practical examples and in the next step will explain how you can detect these types of vulnerabilities through BlueClosure BCDetect and how exploit them.

DOM Based Cross-Site Scripting (DOM XSS):

So, to explain this type of vulnerability, we can also take one of the above examples that made it very simple:
Taking the following vulnerable code:

<script>
    var pos = document.URL.indexOf("foo=") + 4;
    document.write(document.URL.substring(pos, document.URL.length));
</script>

Source:  document.URL
Sink:      document.write()
Result:   document.write(“<script>alert(document.cookie)</script>”);

The attack is possible to a Client-side level (this due to the # fragment identifier).

To exploiting this attack just go to the following URL and specify the malicious code in the “foo=” parameter:

     http://example.tld/page.html#foo=<script>alert(document.cookie)</script>

Stored DOM Based Cross-Site Scripting (Stored DOM XSS)

Let's see an example of this type of vulnerability where unlike the first, we can see that the malicious code will first be saved in the local Storage of the HTML5 (only recent browsers support Storage feature), then, browse the following URL:

     http://example.tld/store.html?name=<img src=z onerror='alert(document.cookie)' >

Below the vulnerable code of the page:

<script>
    var pos = document.URL.indexOf("name=") + 5;
    var name = document.URL.substring(pos, document.URL.length);
    decodeURI(name);
    window.localStorage.name = name;
</script>

As mentioned above, the "name" is saved in the browser Storage.

Now to exploit this type of vulnerability, let's see what happens if we go to visit (in relation to previous page) the following welcome page URL:

     http://example.tld/welcome.html

With the source code of the page:

<script>
    var element = document.getElementById("header");
    var name = window.localStorage.name;
    element.innerHTML = "Hello, " + name;
</script>

Source:   document.URL
Storage:  window.localStorage.name
Sink:       element.innerHTML
Result:    element.innerHTML = “Hello, <img src=z onerror='alert(document.cookie)' >“;

Surely we would have a nasty surprise with a popup alert which show the cookie data for the current user session.
A malicious user could retrieve the following example data to make unauthorized access by your users.

JavaScript Security Awareness - BlueClosure

1. Introduction

With a biweekly article’s publication we are going to cover as much possible of the JavaScript security theme. We’ll talk about the possible threats that a vulnerable JavaScript code could lead, the detection techniques and some real scenarios.

The logical line that we will follow starts from the “beginning” with the simplest exploitation and attack possible and, basing on that, we’ll expand the coverage to increasingly difficult attacks. Doing this we’ll show the main sources and sink tainting techniques, covering all kind of attacks documented by the OWASP Testing Guide in the Client Side Testing chapter. The purpose of the JavaScript Security Awareness is to inform the users how easily is to find some vulnerable JavaScript showing how and when an issue could occur.

Furthermore we want to present an all new tool, BlueClosure, that can automate the security analysis process testing the JavaScript.

The structure of the each article is the following: introduction to a vulnerability (of a security issue), explanation and detection of the vulnerability with BlueClosure and, in the end, a real world scenario where the particular vulnerability that we are talking about created a security breach. We have decided to start from the DOM XSS because it’s a very important issue (listed in the OWASP top 10) and XSS is the most prevalent web application security flaw.

1.1 Introduction to DOM Based XSS

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 used by the original client side script, so that the client side code runs in an “unexpected” manner.

That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.

This is in contrast to other XSS attacks (Stored or Reflected), wherein the attack payload is placed in the response page (due to a server side flaw).

In the following OWASP code example, the “document.location.href” or “document.write” aren’t malicious, as the rest of the code.

<script>
    document.write(""+
    document.location.href.substring(document.location.href.indexOf("lang=")+4)+
    "");

    document.write("English");
</script>

document.location.href and document.write are sinks because theirs behaviour is legit but with a tainted input theirs becomes malicious.
Indeed with the following input is possible to exploit a 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>

to www.some.site. The server responds 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 as such 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.
This payload manifests itself at the Client-side script at runtime, when a flawed script accesses the DOM variable "document.location" and assumes it is not malicious.

2. BlueClosure in Pills (A brief introduction to BC functionalities)

The BlueClosure platform provides the elements needed to execute the JavaScript analysis in real time (then while browsing the selected web target) and search for possible vulnerabilities such as HTML Injection, JS Execution, HTTP Parameter Pollution and others.

The main features of BlueClosure are:

• JS Frameworks supports: Where BlueClosure can analyse any codebase written with JavaScript frameworks like Angular.js, jQuery, Meteor.js, React.js and many more. 
• Realtime Dynamic Data Tainting: Where BlueClosure uses an advanced JavaScript instrumentation engine to understand the code. By leveraging our proprietary technology the BC engine can inspect any code, no matter how obfuscated it is. 
• Scanning Automation: BlueClosure technology can automatically scan an entire website. This is the fastest way to scan and analyse BIG enterprise portals with rich JavaScript content as a tester would with his browser. 
• Near-Zero False Positives: Data Validation and Context Awareness makes the use of a dynamic runtime tainting model on strings even more powerful, as it understands if a client side vulnerability is actually exploitable.

As mentioned earlier, BlueClosure provides accurate and careful analysis of the code in real time by reporting to the user the possible Findings that are categorized into Alerts, Warnings and Infos. Through these alerts, the user can quickly access the related vulnerability information by tracing the steps that led to the identification of the vulnerability in a highly detailed way.

The following example shows an issue identified by BlueClosure engine:

As you can see from the image above, BlueClosure indicates the main vulnerability information, like the Typology, the Source and finally the Sink (then, the Taint Propagation) that led to malicious code execution and its user-controlled Value (in the described case, the value is an HTML data).

The user can access more detailed information by clicking the Link in the vulnerability box, adding two more boxes.

• The first box describes the History of the vulnerability, then the user-controlable value, if the vulnerability is Exploitable, whether the data is Encoded / Not Encoded, and by clicking on Show operations you can access the list of operations JavaScript that led to vulnerability execution; 
• The second one, Vulnerable Code that will show the user the part of malicious code that was executed by exploiting the vulnerability.

The following example shows an example of History and Vulnerable Code in relation to the HTML Injection vulnerability described above: