What are "top level JSON arrays" and why are they a security risk?
Asked Answered
Q

2

82

In the video below, at time marker 21:40, the Microsoft PDC presenter says it's important that all JSON be wrapped so it's not a top level array:

https://channel9.msdn.com/Events/PDC/PDC09/FT12

What is the risk of an unwrapped top level array?

How should I check and see if I'm vulnerable? I purchase many components from 3rd parties and have external vendors who develop my code.

Quadripartite answered 17/8, 2010 at 13:48 Comment(1)
Unfortunately the like to the talk is brokenLytton
W
54

Note: by the 2020s, this is all ancient history; there’s no longer any security risk for any JSON.


This is because a few years ago Jeremiah Grossman found a very interesting vulnerability that affects gmail. Some people have addressed this vulnerabilty by using an unparseable cruft (Mr bobince's technical description on this page is fantastic.)

The reason why Microsoft is talking about this is because they haven't patched their browser (yet). (Edit: Recent versions of Edge and IE 10/11 have addressed this issue.) Mozilla considers this to be a vulnerability in the json specification and therefore they patched it in Firefox 3. For the record I completely agree with Mozilla, and its unfortunate but each web app developer is going to have to defend them selves against this very obscure vulnerability.

Wagon answered 17/8, 2010 at 17:18 Comment(4)
Is sending sensitive information in a JSON array still a security risk in 2017?Partridge
@jrahhali that question is worthy of its own post, maybe security.stackexchange.com would be a good place for it.Wagon
By 2023, I’m content to say that you shouldn’t worry about this at all. The last browser to be vulnerable was released more than twelve years ago, and your site probably doesn’t even start to load in it (due to it only supporting up to TLS 1.0, and your site hopefully only being served over TLS 1.2+).Daydream
@ChrisMorgan Thank you for calling this to my attention - Updated.Wagon
I
17

I think it's because the Array() constructor can be redefined. However, that problem isn't really unique to arrays.

I think the attack (or one possible way) is something like this:

function Array(n) {
  var self = this;
  setTimeout(function() {
    sendToEvilHackers(self);
  }, 10);
  return this;
}

The browser (or some browsers) use that constructor for [n, n, n] array notation. A CSRF attack can therefore exploit your open session with your bank, hit a known JSON URL with a <script> tag to fetch it, and then poof you are owned.

Immortalize answered 17/8, 2010 at 13:58 Comment(4)
I don't get this - moving the array in the JSON down into a property wouldn't stop this type of attack. Returning {"d":[1,2,3]} would be just as susceptible as returning [1,2,3].Subclimax
I agree - that's what I meant when I said the problem isn't just about Arrays.Immortalize
Not true. A { at the beginning of a line in JavaScript is interpreted as a code block, not an object literal. Thus, your {"d":[1,2,3]} is not a valid script and would not be executed by the browser. Just try it :)Ambitious
follow up: haacked.com/archive/2009/06/25/json-hijacking.aspx To me it's a better explanation of the threat than the 2006 article from GrossmanBaum

© 2022 - 2024 — McMap. All rights reserved.