This was formerly a private issue in the Drupal security team's issue tracker, but consensus within the team was that this could be handled separately.

Original report from Heine:

nuts and bolts: evil.com has JS that overrides the array / object constructor, tricks you into visiting a JSON returning URL on victim.org via

Attached is a PDF of the discussion on the security team list about this issue for background (sorry, I cannot figure out a time-effective way to get this info into a Drupal.org node).
CommentFileSizeAuthor
JSON hijacking | Security.pdf94.71 KBwebchick
Members fund testing for the Drupal project. Drupal Association Learn more

Comments

nod_’s picture

Issue tags: +JavaScript

tag

(edit) About the issue, JS is not a secure language, if you're worried just don't load third party JS. There is no other sane way to deal with that.

coltrane’s picture

Are we aware of any core JSON callbacks that contain possibly sensitive information? A general solution to this (in 7) might be to include a parser breaker in drupal_json_output(), such as while(1); or wrapping the JSON in comments as the whitepaper suggests. However, I've yet to exploit this on a client 7 site so I'm focusing on that first.

greggles’s picture

Title: Protect against JSON hijacking » Protect against JSON data hijacking with typical CSRF protections

re #1 - I don't think that's what this issue is about.

Here's a proposal from the pdf (from s.d.o, from Damien) of what we should do:

We add a header to every page with a CSRF token;
We build on the idea of a "Built-in support for security tokens in links and menu router" [5] and extend it to support passing the token in a
X-CSRF-Token HTTP header; (note that we have to add X-CSRF-Token to the Vary header too, to make sure that proxy servers handle that correctly)
We add a beforeSend()/ajaxPrefilter() handler to drupal.js so that all the existing Javascript code can continue to work the same way.
Because this solution is generic and should not change any API, we should be able to backport to Drupal 6, but given that this issue doesn't seem to
be dealt with properly very often, it doesn't seem critical to do so.

[5] points to #755584: Built-in support for csrf tokens in links and menu router

temaruk’s picture

According to http://capec.mitre.org/data/definitions/111.html the prerequisites of such an attack is:

  • 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 attacker's malicious code via a script tag

It is also important to note, that the issue stands only, if an array is returned in JSON format, for example: [{"I am an object":"Literal"}]
whereas the following response would not allow the attack: {"d":[{"I am an object":"Literal"}]}

The article at http://www.thespanner.co.uk/2011/05/30/json-hijacking/ explains why wrapping in object prevents the attack. Basically, the script tag receiving the JSON response interprets that case as a block statement, which is in fact, invalid, so syntax error.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.