Comments on: Securing your JSON

By: Diego Perini

Diego Perini — Sat, 14 Apr 2007 14:18:47 +0000

A new IFRAME also means a new “window” and a new “document” apart new fresh constructors for Array, Object and Function etc…
Think to the IFRAME as a completely new and different scope, and a namespace. Seen this, it seems to me a little more “secure” if your application is loaded and executed in a newly created IFRAME instead of trying to do the opposite and “fishing” fresh methods and object from it.
You can still allow/disallow comunication between IFRAMEs, and the browser should implement at a minimum it’s domain restriction policies.
This is not 100% secure, I also have come to know…, but who cares, the Internet itself is not a secure place…so things are matching well :-)

By: stefan

stefan — Fri, 13 Apr 2007 18:15:07 +0000

it’s not a bad solution, but keep in mind that document.createElement and a multitude of other native objects/functions can be overwritten to get around this in a variety of ways. the only real solution is to parse any and all data which comes from outside sources. we also need real namespaces in javascript so that external sources can provide executable code without any possibility of access to the global and other private namespaces…

By: morganusvitus

morganusvitus — Thu, 05 Apr 2007 13:38:22 +0000

The site looks great ! Thanks for all your help ( past, present and future !)

By: Ajax Girl

Ajax Girl — Fri, 23 Mar 2007 20:14:22 +0000

[...] insecurity of JSON and put two and two together with Dean Edwards Array hack to provide an idea on securing your JSON. PLAIN TEXT [...]

By: Simon Willison

Simon Willison — Fri, 16 Mar 2007 22:10:48 +0000

I’m not too happy about being called ignorant. The exploit I explained in my comment is NOT the same as the one you talked about as “The downside” – you had suggested that your method could work provided you applied the fix at exactly the right moment, whereas I was pointing out that the attacker could modify document.createElement to prevent your fix from working no matter when it was applied.

By: kourge

kourge — Thu, 15 Mar 2007 14:52:25 +0000

If you issue a delete x; statement, the Array object will be restored to its prestige state, at least in Firefox.

By: Bas

Bas — Wed, 14 Mar 2007 15:24:32 +0000

It’s very ignorant when people don’t read the article and comments very well. If you read the chapter ‘The downside’ and my previous comment you can see you’re almost rephrasing me.. Now I’m definitely going to update this article because the fix I wrote about is not a fool proof way to secure json from being read by Mr. Evil. Just like Joe told us, using unpredictable urls is the best security one can have right now.

Cheers

By: Simon Willison

Simon Willison — Wed, 14 Mar 2007 14:51:15 +0000

Your applyArrayFix() function can be easily disabled by an attacker simply redefining document.createElement before your function is called. You’re putting yourself in an arms race with an attacker, but the attacker has the advantage of knowing exactly how your code works (you on the other hand don’t know the details of theirs). As such, your solution can’t work.

By: Bas

Bas — Wed, 14 Mar 2007 11:49:03 +0000

I completely agree with you that unpredictable urls are the best security one can have right now. We can’t control what happens on the clientside. In example, when MR. Evil changes the iframe Array object before we apply our fix we’re doomed too… What’s described on this page is just a way one can improve security, not making a app invulnerable to data theft… Maybe I should update the article about this…

By: Joe Walker

Joe Walker — Wed, 14 Mar 2007 11:01:10 +0000

I hate to be a pain, but I think you are fighting a losing battle. For example, the follow-up was to steal data from Objects too. In the end you can't trust the environment that you are sending the data to, so you should only send data to people you trust, and that means having URLs that are not predictable.