Thursday, 28 April 2016

JSON Hijacking

JSON Hijacking

Today we will see that, How we can find the
JSON Hijacking vulnerability. As we know that this works on older browsers, still we should analyse it because this is a miss-understood/less known vulnerability for many security people. I hope you will like it.

What is JSON Hijacking?

JSON Hijacking is similior to CSRF(Cross Site Request Forgery) but there is just a little bit difference, In CSRF you trick the victim/user to do some malicious/unwanted activity but in JSON Hijacking you trick the user to access a crafted link which will read some data form victim account and pass it to attacker.

Who Are Affected To This?

This vulnerability is already fixed in modern browser, Like  as of now if victim is using modern browser it cannot be exploited. But still if any one is using an older browser it can be attacked.

How We Can Find JSON Hijacking Vulnerability

There are mostly 3 Factors which are required while exploiting JSON Hijacking.

1. Compatibility With Old Browser?

First we should check that, Is targeted application is compatible with Older Browsers.

2. Access Control Allow Origin Is Present Or Not?

Access Control Allow Origin header comes in the picture when we talk about modern web applications.

According To OWASP - Access-Control-Allow-Origin is a response header used by a server to indicate which domains are allowed to read the response. Based on the CORS W3 Specification it is up to the client to determine and enforce the restriction of whether the client has access to the response data based on this header.

Basically this header prevent external/third party domain to read application response/data.

If you look at below HTTP Response, You can see that there is a header called "Access Control Allow Origin " set to a domain name "", Means only this domain can access or read data from this application.
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:57:53 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Content-Length: 4
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: application/json

If the "Access Control Allow Origin" is set to a specific domain then JSON Hijacking is not possible, Because we does not have any control on that domain.

Now look again into below response, As you can see the "Access Control Allow Origin" header is exist but its configure as (star) "*", Means any domain can access his data. This can be called as miss-configured settings.
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 18:57:53 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Access-Control-Allow-Origin: *
Content-Length: 4
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: application/json

If "Access Control Allow Origin" header is not there, Then it would become more fine for us to exploit JSON Hijacking.

3. Vulnerable JSON Response!

Typical JSON Request are return some response in an array, it can be look like this.

Which kind of JSON Response Are Vulnerable?

If you observe below picture, You can see that which kind of JSON Response are vulnerable !

Vulnerable JSON Response - Click Here To See Details[/caption]


[{"object": "inside an array"}]


Not Vulnerable/Exploitable

{"object": "not inside an array"}

Also not Vulnerable/Exploitable

{"result": [{"object": "inside an array"}]}


In our case the JSON Response is like

Its kind of vulnerable JSON Response format/syntax.


[{"object": "inside an array"}]

Exploiting The JSON Hijacking!

After checking all requirements, Now its time to exploit this.

We can use a code in html format.

<html xmlns="" >
<title>Json Hijacking WebSecurityGeeks</title>
<script type="text/javascript">
Object.prototype.__defineSetter__('accountholder', function (obj) {
alert('Hijacked Account Holder Name Is  '+ obj);
<script type="text/javascript" src=""></script>

We can host this code on public server or a local server as html format according to our requirements.

If you again look into our JSON Response, You will find that there are many data object like "id" , "accountholder" , accountbalance".

If we want to hijack the details of data object "accountbalance", Then we have to specify the object name in our code at line 6 E.g.

Object.prototype.__defineSetter__('accountnbalance', function (obj) {

As we know its worked on older browser, So I set up an older version 3.0.11 of mozilla firefox.

Now to create a poc, I am logged into the application, And I am accessing a link which is sent by attacker.

As you can see the "Account Balance" is hijacked from victims account.

How To Fix This?

A well documented details are available on OWASP

Within this we can also use several things to make it secure.

1) Always return JSON with an Object on the outside

Always have the outside primitive be an object for JSON strings:


[{"object": "inside an array"}]


Not Vulnerable

{"object": "not inside an array"}

Also not Vulnerable

{"result": [{"object": "inside an array"}]}

2) Access-Control-Allow-Origin

Adding "Access-Control-Allow-Origin" will make it un-exploitable because, Out trusted domains are not in control of attacker.

But still we should care, Because attacker can abuse this functionality to exploit this.

Suppose you have added "" in "Access-Control-Allow-Origin".  But is there any upload functionality is available which allow user to upload html files, Then attacker can upload his jsonhijack code on this, Now the vulnerability can be exploited even if you have added "Access-Control-Allow-Origin".

3) Old Browsers Compatiblity

This feature can act as mitigation not the prevention,.We can create a mechanism in the application, Which will prevent the users from using our application from an older browsers.


  1. Nyc Article well defined thanks !

  2. Very well explained. Thank you Narendra.
    So since this only works with older versions of the browsers, does it mean with latest versions, this attack is impossible or no way to hijack json data.


Featured post

Indian Mutual Fund Customer Data Is On Risk | Mutual Funds Vulnerability

Image from - I...

Popular Posts