Comments on: Fortify JavaScript Hijacking FUD

By: bob

bob — Tue, 24 Jul 2007 07:16:58 +0000

The same origin policy is not there to protect someone from themselves, but to protect them from going to a third party site and unknowingly having bad things happen. There are an infinite number of ways you could do “bad” things if you had full control over the computer in question.

By: Andrew

Andrew — Tue, 24 Jul 2007 06:28:13 +0000

While I have not researched this whole discussion in depth, I am inclined to agree with you at this point. However, I have thought about the “same origin policy” before and have a question that, again, I have not researched nor tested. If I am not mistaken, the “same origin” is based on the domain name of the resources in question. Let’s say I find a server/page that I wanted to initiate a scripting attack against (as in post 14). I also get the IP address that the domain is pointing to (for use in just a minute). Now I disconnect from the Net, create a web site on my local server with the domain name in question, add the IP address to my NIC and point it to the site on my local server. I create a page that has an iframe with the src pointing to the page I want to attack (which I have also created on my local server). The containing page (not the iframe src) has the necessary script, etc. to launch the attack and the iframe is pointing to a “same origin” resource since they both reside on my local server. I fire up my browser point to the spoofed page. The “gun is loaded” but it is “aimed” at my local server, which does not do much good. So what do I do? I take my local server offline and reconnect to the Net so that the domain and IP will resolve at the original server. Now the “gun” is aimed at the server I want to attack. I click on the “Fire” button and the script runs and launches my attack, which the browser and the server think is OK because everything is “same origin”. Since I not only spoofed the domain name but the IP as well, there is no way that either party involved (my browser nor the other server) knows that the pages actually originated elsewhere. It seems such an easy way to circumvent the “same origin” policy that I hope I am just not educated well enough to understand what would stop that. Either that, or the FBI / CIA is going to be knocking on my door in the next day or two. :-) (I swear, I have never tried this. Obviously, because if I had and was “blocked” I would know that it is not possible. Alternatively, if I knew my idea would work, do think I would be posting it in a public forum like this?)

By: bob

bob — Fri, 20 Apr 2007 16:30:51 +0000

The browser’s same origin policy guarantees it.

By: mario

mario — Fri, 20 Apr 2007 09:10:15 +0000

How json-particular is this hijacking trick? I wonder, couldn’t a similar technique be applied to a callback service that returned data in xml? If instead of using a script one where to use an iframe with an src pointing towards the service to be hijacked. The returned xml would be (let’s assume a very tolerant x/html doctype) inlined into the dom? What is then to stop the malicious page from manipulating that dom, and ajaxing the hijacked data off to another server? This *should* not work… what guarantees that it does not?

By: bob

bob — Thu, 19 Apr 2007 07:34:52 +0000

The solution is to make JSON producers warn if they’re serializing an array envelope. It’s not anything like telling developers not to code buffer overflows. It’s like telling them not to use eval.

NOTHING MochiKit can do is insecure (in this way). Whatever the client sends or decodes is irrelevant. It’s a 100% server-side issue. I added comment stripping support so that people would shut up, not because it’s useful in theory or practice.

Tricking a JS implementation to deserialize invalid JavaScript syntax (an object envelope) is just as intractable as getting one to strip comments or a while (1). It doesn’t even parse, the grammar does not allow it. I don’t care how tenacious hacker is, they would need a full text exploit vector to do it, which makes it exactly as secure as any of the other proposed solutions except it’s infinitely easier to implement since it does not require a new specification or any implementation changes.

By: fk

fk — Thu, 19 Apr 2007 07:17:28 +0000

>I offered a much simpler solution that is secure and is still valid JSON and requires no changes to any client, simply
> restricting the response to a particular (and already extremely common) subset of JSON is sufficient.

(Assuming your solution is telling users to only use plain objects)

That’s like telling developers not to code buffer overflows. We all see how well that works… As a framework provider, if you’re capable of distributing a framework that helps in making code more secure, why wouldn’t you? (Yes, I know you have patched after being nagged to death by your users.)

All too often devs that nit pick security issues are proven wrong time and time again by tenacious hackers. Error on the safe side.

By: bob

bob — Wed, 18 Apr 2007 17:38:43 +0000

Brian, are you literate? It certainly doesn’t seem like you actually read the post. I’m well aware of what secure code is and how it’s done and that’s not what bothers me about you, your paper, and the reaction to it.

Why the hell should there be security documentation in client frameworks? The security documentation should be in the web frameworks, because that’s where it needs to be implemented. Any security documentation with client frameworks would be purely supplemental.

I offered a much simpler solution that is secure and is still valid JSON and requires no changes to any client, simply restricting the response to a particular (and already extremely common) subset of JSON is sufficient.

The representation offered by Yahoo is explicitly for cross-domain use, I don’t see relevancy.

By: Brian Chess

Brian Chess — Wed, 18 Apr 2007 17:30:58 +0000

Hi Bob, I’m Brian Chess, one of the authors of the JavaScript Hijacking paper. You sound a little bitter. I can’t say I blame you. Programming is easier when you don’t have to think about security, and the Ajax community has gotten away without thinking very much about security for a few years now. Want some evidence? Go look at the documentation for any of the major frameworks that shows programmers how to use the framework in a secure way. It won’t take you long to read because there’s pretty much zero.

We’d like to get Ajax programmers having explicit conversations about security *now* so that we don’t have another mess to clean up starting in a few years after people have unknowingly written a tremendous amount of vulnerable code.

As for your critique, I think you’ve fallen into a number of common boondoggles. First, we’re talking about JavaScript Hijacking, not JSON hijacking. JSON is not the only way people are using JavaScript as a data transport format. Take a look at the JSArray representation offered by Yahoo (vulnerable) or the pre-2.0 DWR callback format (highly vulnerable).

Another common mistake is to believe that the client-side frameworks have nothing to do with the security of the server. It’s sort of like saying that your peer group has nothing to do with your behavior. If the client side frameworks continue to support dangerous practices without any warning to the programmer, they are at best complicit in the creation of vulnerable software. Used in their default configuration, some client-side frameworks (MochiKit is a prime example) actually *require* the creation of a vulnerable server.

I do think it’s reasonable to consider alternatives to the fixes that we proposed. Changing JSON so that it explicitly made provisions for security would be great. At the same time, people are using JSON as it exists today, and they deserve to understand the security risks they face.

Thanks,
Brian

By: bob

bob — Sat, 14 Apr 2007 21:25:36 +0000

You are splitting hairs… JSON is a serialized representation of a data structure too, and it’s equivalent to XML (anything you do with XML you can do with JSON and vice versa).

By: Liam Quin

Liam Quin — Sat, 14 Apr 2007 20:28:10 +0000

whopee - XML isn’t a data structure, and doesn’t define one. So they are right.

XML is a serialized representation of structured information. Since a data structure is an (non-serialized) example of structured information, you can represent arbitrary data structures in XML, with more or less work, but the resulting XML is a serialized representation of the data structure, it is not the data structure. If it sounds like I’m splitting hairs, consider the difference between a photograph of a gun and a gun :-)

Liam (W3C XML Avtivity Lead