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: