We just released our report on the first (and to our knowledge the only) type of attack that specifically targets Ajax-style web applications. The attack is called JavaScript Hijacking. The report is here.
As part of the work, we took a look at 12 Ajax frameworks, including Google's GWT, Microsoft Atlas, Yahoo! UI, and a number of open source projects. A lot of the open source projects provide only client-side JavaScript libraries. In the report we point out that almost none of the frameworks protect against JavaScript Hijacking or give programmers any indication that there's anything they need to protect against themselves.
Thus-far, nobody has questioned us on the technical aspects of the attack, and quite a few of the framework maintainers have said they plan to address the problem. But we've taken some flak for our proposed solutions from a few owners of client-side JavaScript libraries. It boils down to one sentence in the report:
"Preventing JavaScript Hijacking requires a secure server-side implementation, but it is incumbent upon the client-side libraries to promote good security practices."
Some of the client-side guys aren't so happy with that. They say that security is totally a server-side problem. Keep in mind, most of these projects don't say a thing about writing a secure server in their documentation, and worse yet, some of them actually require the server to be vulnerable unless the application programmer wants to start monkeying around in the guts of the framework. Ugh.
Now that I'm done writing the report, I can ditch the any semblance of an even or balanced tone, so let me try saying it again. Here's the deal: if you're going to write some code that you expect programmers to re-use, and if that code walks people right into creating a security cesspool, you are doing the world a disservice. Don't be surprised when I tell the world to steer clear of your stuff.
Comments (11)
How about Stefano Di Paola and Giorgio Fedon's lecture "Subverting AJAX" from 23rd Chaos Communication Congress?
http://events.ccc.de/congress/2006/Fahrplan/events/1602.en.html
It seems to use quite similar techniques, doesn't it?
Posted by Buben Razuma | April 2, 2007 9:43 AM
Posted on April 2, 2007 09:43
I have a question, you only mention JSON. Can this vulnerability be exploited if you are using XML with AJAX instead of JSON?
Posted by Jeff | April 4, 2007 7:28 AM
Posted on April 4, 2007 07:28
Hi Buben, the "Subverting Ajax" paper talks about using Ajax-style techniques to develop sophisticated exploits for cross-site scripting vulnerabilities and a few other kinds of vulnerabilities. It's a good paper.
However, JavaScript Hijacking doesn't require the presence of a cross-site scripting vulnerability. It allows an attacker to read data across domains. None of the attack code runs in the vulnerable domain. Instead, code from the vulnerable domain runs in the attacker's domain.
A few people have mentioned this paper to me, so I've added it to the JavaScript Hijacking FAQ:
http://www.fortifysoftware.com/security-resources/javascripthijacking.jsp
Posted by Brian Chess | April 5, 2007 11:56 PM
Posted on April 5, 2007 23:56
Hi Jeff, JavaScript Hijacking only works against JSON and other data transport formats that use JavaScript syntax. XML is safe.
Posted by Brian Chess | April 5, 2007 11:57 PM
Posted on April 5, 2007 23:57
Hi,
I would like to introduce you to a new technology called http://www.visualwebgui.com which provides a unique way to create AJAX applications by providing full WinForms like development including design time support. The architecture eliminates most of AJAX soft spots by simply
returning back to server based computing but still having a dynamic AJAX based UI. It also has been said by developers to boost productivity to R.A.D. levels with out limiting your options.
Guy
Posted by Guy | April 9, 2007 4:10 PM
Posted on April 9, 2007 16:10
Hey Guy, I poked around on the visualwebgui site for a little bit, but I didn't see any mention of security in the documentation. Looks like developers are just supposed to know what makes a secure application? Uh oh. Sounds like trouble.
Posted by Brian Chess | April 14, 2007 4:33 PM
Posted on April 14, 2007 16:33
Hi,
You'll be happy to hear that we've added automatic removal of security delimiters inside Prototype's latest release (http://prototypejs.org/2007/4/24/release-candidate-3).
This means that JSON data returned in the following form will be correctly escaped if it is called by an Ajax request, but will be unavailable to malicious attempts:
/* - secure -
{...}
*/
The delimiter pattern is of course configurable.
Posted by Tobie Langel | April 25, 2007 9:57 PM
Posted on April 25, 2007 21:57
I wanted to propose (and solicit comments on) another possible anti-hijacking prefix:
true? alert('Javascript hijack attempted!'):
Authorized client code then does:
eval('(!' + response + ')')
The response itself does not require modification (only the '!' prefix) and an unauthorized <script> reference generates an alert.
Posted by Brian Katzung | May 29, 2007 4:31 PM
Posted on May 29, 2007 16:31
I like it. It's short, elegant, and incurs just about the minimum imaginable runtime overhead. Whether or not to actually do an alert() is debatable--can you give the user adequate information about what's going on, or are they going to be left scared and confused? But the general technique you're proposing doesn't require you to call alert(). I think this is my favorite solution yet.
Posted by Brian Chess | June 5, 2007 4:30 PM
Posted on June 5, 2007 16:30
Hej,
I read the report. I didn't try it, but if what you write is correct, then isn't that "simply" a browser bug?
A browser should not submit any cookies in an XMLHttpRequest, to which issuing script has no access.
That is nothing that can be fixed in JavaScript.
I am very interested in comments.
Chris
Posted by Christopher Vogt | June 28, 2007 6:04 AM
Posted on June 28, 2007 06:04
Hey Chris, you're right, the browsers could fix JavaScript Hijacking, but not without breaking existing web pages and mashups that depend on the current behavior. Current Web standards and browser implementations make secure programming hard. In the short term, we have to live with what we've got and make the best of it. Long term, we need better standards and browser implementations that make it possible for mere mortal web programmers to write secure code.
Brian
Posted by Brian Chess | July 2, 2007 1:01 PM
Posted on July 2, 2007 13:01