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 …
FUD & Fear Mongering
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.
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.
A couple of points...
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.
should exempt asp.net ajax
asp.net ajax is vulnerable
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!
- Facebook offshores HUGE WAD OF CASH to Caymans - via Ireland
- Mexican Cobalt-60 robbers are DEAD MEN, say authorities
- Apple's spamtastic iBeacon retail alerts launch with Frisco FAIL
- Submerged Navy submarine successfully launches drone from missile tubes
- Apple sends in the bulldozers as Fruit Loop construction begins