Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

What is the best defense against JSON hijacking?

Can anyone enumerate the standard defenses, and explain their strengths and weaknesses? Here are some defenses that I've seen suggested:

  1. If the JSON response contains any confidential/non-public data, only serve the response if the request is authenticated (e.g., comes with cookies that indicate an authenticated session).
  2. If the JSON data contains anything confidential or non-public, host it at a secret unguessable URL (e.g., a URL containing a 128-bit crypto-quality random number), and only share this secret URL with users/clients authorized to see the data.
  3. Put while(1); at the start of the JSON response, and have the client strip it off before parsing the JSON.
  4. Have the client send requests for JSON data as a POST (not a GET), and have the server ignore GET requests for JSON data.

Are these all secure? Are there any reasons to choose one of these over the others? Are there any other defenses I'm missing?

share|improve this question

3 Answers 3

up vote 16 down vote accepted

The first defence is to stick to the specification by using valid JSON which requires an object as top level entity. All known attacks are based on the fact that if the top level object is an array, the response is valid Java Script code that can be parsed using a <script> tag.

If the JSON response contains any confidential/non-public data, only serve the response if the request is authenticated (e.g., comes with cookies that indicate an authenticated session).

That's the pre requisite for the attack, not a mitigation. If the browser has a cookie for site A, it will include it in all requests to site A. This is true even if the request was triggered by a <script> tag on site B.

If the JSON data contains anything confidential or non-public, host it at a secret unguessable URL (e.g., a URL containing a 128-bit crypto-quality random number), and only share this secret URL with users/clients authorized to see the data.

URLs are not considered a security feature. All the common search engines have browser addons/toolbars that report any visited URL back to the search engine vendor. While they might only report URLs that are explicitly visited, I wouldn't risk this for JSON URLS either.

Have the client send requests for JSON data as a POST (not a GET), and have the server ignore GET requests for JSON data.

This will prevent the <script> include.

Put while(1); at the start of the JSON response, and have the client strip it off before parsing the JSON.

I suggest a modified version of this approach: Add </* at the beginning. while(1) is problematic for two reasons: First it is likely to trigger maleware scanner (on clients, proxies and search engine). Second it can be used for DoS attacks against the CPU of web surfers. Those attacks obviously originate from your server .

share|improve this answer
    
when it comes to authenticated data: Make sure to additionally use Challenge Tokens in your application against CSRF-attacks, this makes JSON Hijacking very hard. –  GNi33 Sep 10 '11 at 0:00
    
Is doing only 1) from this list a good protection against JSON hijacking? I read that it's possible to override behaviour of Object but I can't reproduce it in modern browsers. Is it reproducible? –  Andrey Botalov Dec 9 '11 at 21:07
1  
@AndreyBotalov, no, it is not sufficient as there is still a large number of users out there which use browsers that still allow redefining of build in functions. –  Hendrik Brummermann Dec 9 '11 at 21:57
1  
@AndreyBotalov, the first hit on google is a document from 2007 naming Firefox 2, Opera 9, and Safari 3 as being vulnerable to the array redefinition. A bit further down is an article from 2009 naming Chrome 2.0.172.31 and Firefox 3.0.11 for the Object.prototype.__defineSetter__ attack. Spending a bit more time on this is likely to return more recent articles on more recent browsers. But as those old browser are still in use, this does not make much of a difference anyway. –  Hendrik Brummermann Dec 12 '11 at 17:59
1  
The spec does allow an array as a top level object - your post suggests though that this is not valid JSON. Your answer still stands though (+1) and having a top level object is (currently) secure against hijacking. –  SilverlightFox Nov 21 '13 at 12:10

Google uses an "unparseable curft" to defend its self against this type of attack. It should be noted that this vulnerability has been fixed in firefox 3, and this vulnerability arises from how browsers impalement the json specification.

share|improve this answer

1) If the JSON response contains any confidential/non-public data, only serve the response if the request is authenticated (e.g., comes with cookies that indicate an authenticated session). 2) If the JSON data contains anything confidential or non-public, host it at a secret unguessable URL (e.g., a URL containing a 128-bit crypto-quality random number), and only share this secret URL with users/clients authorized to see the data.

There's no good reason to do both (1) and (2).

The first is ABAC and the second is ZBAC. Trying to get defense-in-depth by using multiple access-control schemes is just over-complicating things.

3) Put while(1); at the start of the JSON response, and have the client strip it off before parsing the JSON.

4) Have the client send requests for JSON data as a POST (not a GET), and have the server ignore GET requests for JSON data.

These sounds like fine ideas and do add defense in depth since it helps ensure that credentials can't be misappropriated.

Additionally,

5) Only serve JSON with sensitive data over SSL or some other secure channel.

to prevent leaking data via MITM.

share|improve this answer
    
Question - see: sitepen.com/blog/2008/09/25/security-in-ajax - a different cruft method - and, does serving the json over SSL prevent hijacking and protection of the json data? –  Jason Apr 26 '12 at 17:51

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.