Blog

Thursday, 14 September 2017

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:

* 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.

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:

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:

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:

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.

Tuesday, 12 September 2017

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.

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: