New vulnerability strikes heart of Web 2.0
Whatever you think of "Web 2.0" (it's really not mandatory to release everything in permanent beta) you probably thought that this generic approach to mashups, Ajax and all that good stuff didn't change the usual coding "good practice" rules much. Well, Brian Chess of Fortify Software says you're wrong. Although Web 2.0 style …
This is complete FUD.
"New vulnerability strikes heart of Web 2.0"
None of this is "new".
People in the web application security space have been talking about these type of attacks for over a year.
http://jeremiahgrossman.blogspot.com/2006/01/advanced-web-attack-techniques-using.html
As a web app developer for many years, I've found that the new breed of Web 2.0 frameworks (such as Rails) give me even more tools than ever for helping secure my application. I don't think I've ever been as confident my applications are secure (due to me screwing up rather than exploits in the framework).
Presumably as it is now easier to secure applications, sales people are resorting to this type of FUD to try and keep business coming in.
Reg - we expect better of you. If I wanted to read marketing dross I could go elsewhere.
I'll point out that I did reference Grossman in my article but thanks for the extra reference, it's interesting corroboration. I think the Fortify advisory cites the GMail example too and the comments in Grossman's blog reference Fortify. But Brian Chess's advisory adds to what's there, to my mind.
I'll also point out that the availability of tools to make applications secure is not the issue. Windows has lots of tools to make it secure and some people even write secure Windows code. Does that mean that Windows security is a "done thing"?
FUD is a danger. But so is complacency - and security awareness is always good (back when I was paid to do this stuff for real, I rated security awareness training higher than security technologies, for delivering real security).
Oh, and BTW, this isn't Reg - it's Register Developer...
Hi, I'm Jacob West, one of the paper's authors and the Manager of the security research group at Fortify. I'd like to take a moment to respond to some of your concerns about our work.
In the paper, which I hope you've had a chance to read, we reference the past work of Grossman and Walker, both of whom we have worked with in putting this paper together. What we think is new in the paper is:
1) The generalization of Grossman's attack (he said it could not be used against JSON, but we show that it can).
2) An exploration of how widespread the problem is.
3) A discussion of the possible defenses against the attack.
We absolutely agree that some aspects of modern Web technologies make it easier for programmers to get security right. For a few years now security folks like us have been making the argument that "Web 2.0" didn't change the game significantly from a security standpoint--it just introduced new ways to make the same old mistakes--and advised people building software to treat it accordingly.
JavaScript Hijacking is the first example we've seen of a vulnerability that specifically affects a technology and programming style associated with this new wave of applications. We think it's important to prompt a discussion about the vulnerability before vulnerable code becomes more widely deployed than it already is. Luckily, the banks don't use the newest technology right away, and we want to make sure they know how to mitigate the risks before they do.
Cheers,
Jacob
I don't know about pre-release versions of ASP.NET Ajax, but - pace Chess et al - the security on the release version would seem to avoid this problem. In this framework requests made by the XmlHttpRequest object set the content-type header to 'application/json', and this is verified by the server. Since there doesn't seem to be a way of forcing a script block to result in a request with such a header, Javascript Hijacking is blocked. (See http://weblogs.asp.net/scottgu/archive/2007/04/04/json-hijacking-and-how-asp-net-ajax-1-0-mitigates-these-attacks.aspx)
I'm Brian Chess, one of the authors of the original JavaScript Hijacking paper. Checking for application/json in the content-type header is not enough to prevent JavaScript hijacking. An attacker can simply request the data twice.
Here’s a two-step attack that bypasses the check:
1) The attack code uses the Adobe Flash player to request the JSON. By using Flash, the attack can set the content-type header correctly. However, it can’t directly see the response. (For more on setting http headers using flash, see http://www.securityfocus.com/archive/1/441014)
2) The attack code now generates a <script> tag and requests the data again. The second time around, the Web browser doesn’t go up to the server, it takes the data out of its cache. This time the attacker gets access to the data.
Atlas doesn’t allow HTTP GET by default, and it doesn’t instruct the web browser to cache by default, but some people recommend using GET and caching responses in order to improve application performance. Oops!
As with the rest of the frameworks we analyzed, we recommend that Atlas take active steps to prevent JavaScript Hijacking.
