11

In reading about how to avoid json hijacking I've come across various methods including POSTing everything or prepending responses so they are not valid JavaScript.

The most common way to prepend seems to be to add {} && in front of your object or array. Angular suggests prepending with )]}',\n.

Why does angular not use the more standard {} && approach? Is one not totally secure? Is one more difficult to use in JavaScript? Angular aside, is there a good reason for taking the less popular approach?

Bhargav Rao
  • 50,140
  • 28
  • 121
  • 140
Planky
  • 3,185
  • 3
  • 29
  • 39
  • Sending JSON as a `{}` collection itself makes it not a valid JS program, as long as you have more than one key. I don't know why it matters which approach is taken as long as it doesn't execute as a script. Could be any invalid code at the start. There doesn't need to be conformity on this. – cookie monster Feb 24 '14 at 21:44
  • 4
    there is no such thing as json hijacking. firefox3 has a way to exploit the Array constructor, but that was a long time ago. there's no good reason to not serve plain json. besides, anyone with a php script can vacuum up all the content anyway, you're only protecting against zombie js clients, and they don't need such protection anymore. Since old IE is fine, and new stuff is fine, there's barely any vector in the wild for such hijinks. – dandavis Feb 24 '14 at 21:52
  • 2
    @dandavis is right. This was an issue in very, very old browsers. Apparently even IE6 is immune from this attack. But as to your question, you're basically asking if it's better to throw a wrench into the gears or a crowbar. It just doesn't matter. – cookie monster Feb 24 '14 at 21:53
  • @dandavis: Just link to [Is JSON Hijacking still an issue in modern browsers?](http://stackoverflow.com/q/16289894/1048572) :-) – Bergi Feb 24 '14 at 21:55
  • the simpler and more important point is not to serve sensitive info un-encrypted and un-authorized, regardless of the flavor. – dandavis Feb 24 '14 at 22:04
  • 2
    @dandavis As an aside, if the resource is not secured with authentication then someone can just get the data with a php script as you mentioned, but the exploit we're talking about utilizes the client's auth as part of the tactic, so authenticating the user does not avoid the problem. I may be wrong, but I think encryption would fail for the same reason. – Planky Feb 25 '14 at 02:45

1 Answers1

2

Anything that stops the JSON response being parsed as a JavaScript object or array will prevent this method of JSON Hijacking.

See this post for some methods of making your JSON secure.

However, as this answer states, it is not really an issue since Firefox 3.

Google uses an "unparseable [cruft]" 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.

At the time of writing Google appear to prepend )]}' to their responses from Gmail.

Community
  • 1
  • 1
SilverlightFox
  • 32,436
  • 11
  • 76
  • 145
  • To the point of whether it's worth protecting against, 3 out of 10,000 request to wikimedia pages identify as coming from Firefox 2 and there are similar numbers for other obsolete browsers. See [Wikimedia Traffic Analysis Report from Jan 1-31 2014](http://stats.wikimedia.org/archive/squid_reports/2014-01/SquidReportClients.htm) – Planky Feb 25 '14 at 14:12