CAPEC-111 - JSON Hijacking (aka JavaScript Hijacking)

An attacker targets a system that uses JavaScript Object Notation (JSON) as a transport mechanism between the client and the server (common in Web 2.0 systems using AJAX) to steal possibly confidential information transmitted from the server back to the client inside the JSON object by taking advantage of the loophole in the browser's Same Origin Policy that does not prohibit JavaScript from one website to be included and executed in the context of another website.

An attacker gets the victim to visit his or her malicious page that contains a script tag whose source points to the vulnerable system with a URL that requests a response from the server containing a JSON object with possibly confidential information. The malicious page also contains malicious code to capture the JSON object returned by the server before any other processing on it can take place, typically by overriding the JavaScript function used to create new objects. This hook allows the malicious code to get access to the creation of each object and transmit the possibly sensitive contents of the captured JSON object to the attackers' server.

There is nothing in the browser's security model to prevent the attackers' malicious JavaScript code (originating from attacker's domain) to set up an environment (as described above) to intercept a JSON object response (coming from the vulnerable target system's domain), read its contents and transmit to the attackers' controlled site. The same origin policy protects the domain object model (DOM), but not the JSON.






  • Attack Methods 3
  • Protocol Manipulation
  • Analysis
  • Spoofing
  • Purposes 1
  • Exploitation
  • Scopes 1
  • Read application data
  • Confidentiality

Medium level: Once this attack pattern is developed and understood, creating an exploit is not very complex.

JSON is used as a transport mechanism between the client and the server

The target server cannot differentiate real requests from forged requests

The JSON object returned from the server can be accessed by the attackers' malicious code via a script tag

No specialized hardware resources are required. The attacker needs to have knowledge of the URLs that need to be accessed on the target system to request the JSON objects.

Examine the typical asynchronous requests and responses between an AJAX client and the server to see how JSON objects are requested and what is returned.

Do not pass confidential information in JSON objects

Step 1 - Understand How to Request JSON Responses from the Target System

An attacker first explores the target system to understand what URLs need to be provided to it in order to retrieve JSON objects that contain information of interest to the attacker..

Tecnique ID: 1 - Environment(s) env-Web

An attacker creates an account with the target system and observes requests and the corresponding JSON responses from the server. Understanding how to properly elicit responses from the server is crucial to the attackers' ability to craft the exploit.

Indicator ID: 1 - Environment(s) env-Web

Type: Positive

Targeted application leverages JSON in its architecture.

Step 1 - Craft a malicious website

The attacker crafts a malicious website to which he plans to lure the victim who is using the vulnerable target system. The malicious website does two things:.

Step 1 - Launch JSON hijack

An attacker lures the victim to the malicious website or leverages other means to get his malicious code executing in the victim's browser. Once that happens, the malicious code makes a request to the victim target system to retrieve a JSON object with sensitive information. The request includes the victim's session cookie if the victim is logged in..

Tecnique ID: 1 - Environment(s) env-Web

An attacker employs a myriad of standard techniques to get the victim to visit his or her malicious site or by some other means get the attackers' malicious code executing in the victim's browser.

Outcome ID: 1

Type: Success

The sensitive contents of captured JSON objects are readable by the attacker.

Ensure that a mechanism is in place for the server side code to differentiate between legitimate requests and forged requests

On the client side, ensure that the returned JavaScript from the server can only be evaluated locally after being assigned to a variable and not via a script tag

Ensure that URLs used to request server responses that pass the JSON objects back to the client are hard to guess and are unique per user session

Ensure that server side code can differentiate between legitimate requests and forged requests. The solution is similar to protection against Cross Site Request Forger (CSRF), which is to use a hard to guess random nonce (that is unique to the victim's session with the server) that the attacker has no way of knowing (at least in the absence of other weaknesses). Each request from the client to the server should contain this nonce and the server should reject all requests that do not contain the nonce.

On the client side, the system's design could make it difficult to get access to the JSON object content via the script tag. Since the JSON object is never assigned locally to a variable, it cannot be readily modified by the attacker before being used by a script tag. For instance, if while(1) was added to the beginning of the JavaScript returned by the server, trying to access it with a script tag would result in an infinite loop. On the other hand, legitimate client side code can remove the while(1) statement after which the JavaScript can be evaluated. A similar result can be achieved by surrounding the returned JavaScript with comment tags, or using other similar techniques (e.g. wrapping the JavaScript with HTML tags).

Make the URLs in the system used to retrieve JSON objects unpredictable and unique for each user session.

Ensure that to the extent possible, no sensitive data is passed from the server to the client via JSON objects. JavaScript was never intended to play that role, hence the same origin policy does not adequate address this scenario.