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.