In similar fashion to my buffer overflows article, I set my sights on Myth-Busting AJAX (In)-Security."The hype surrounding AJAX and security risks is hard to miss. Supposedly, this hot new technology responsible for compelling web-based applications like Gmail and Google Maps harbors a dark secret that opens the door to malicious hackers. Not exactly true. Even the most experienced Web application developers and security experts have a difficult time cutting through the buzzword banter to find the facts. And, the fact is most websites are insecure, but AJAX is not the culprit. Although AJAX does not make websites any less secure, it’s important to understand what does." read more...
7 comments:
Great article. I have been thinking about this subject for some time now. At this point in time, I have to agree with you - I don't think that AJAX opens anything new - the problems are the same problems, and the effect is the same.
Actually, at this point, the biggest problem with AJAX applications is that their code looks like Spaghetti from hell, and there are so many different frameworks and ways to implement it - that it almost feels like the 90's all over again.
If I had to guess where this whole things is going - I would guess that 2-3 platforms/technologies would evolve out of this, and soon enough, we will see standardization in this area. Hopefully, something more readable.
Hey Ory,
> Great article.
Thank you.
> Actually, at this point, the biggest problem with AJAX applications is that their code looks like Spaghetti from hell
Yah, it seems to me that web pages are looking a lot less like "pages" and more like fully function applications.
> 90's all over again
I'll get out my parachute pants. :)
Well written. I was most interested in the statement that you don’t believe the attack surface has increased. While I understand what you are saying, I have to say that in my analysis of many different "Web 2.0" applications, the implementation of AJAX has caused, if not an increase in the attack surface, than at least a fragmentation of the attack surface leading to increased exposure.
I think this is for three reasons:
1. More functionality (which you call out),
2. More input "locations" (not input values), and
3. Increased integrations
Let us assume the first item is a non-issue (i.e. that there is no new functionality) and that the application continues to receive 100 input values.
In days of yesteryear, we defended our castle (application) at larger gates. We had 10 gates (URLs) receiving 10 input values each. Our first task was to identify the 10 gates and then to ensure that each user provided value went through appropriate validation. This was easily accomplished. (OK. OK. In theory …) What I have found with AJAX, is that there are now 50 gates, each receiving 2 input values. The attack surface has fragmented. While you could accurately say that the attack surface has not increased, this fragmentation means it is more difficult to find all the newer and smaller gates and to ensure that each one is appropriately protected. This increase in input locations has, in my experience, caused additional issues.
To take this further, I certainly believe that developers "want" to do the right thing. They know about input validation and attempt to do this comprehensively. They have a "very high" level of coverage for textual form inputs, a "high" level of coverage for select/radio/checkbox form inputs or URL parameter inputs, a "moderately high" level of coverage for hidden fields in forms, a slightly lower coverage for cookie input, an even lower coverage for headers fields in HTTP requests … The trend is obvious. As the "input" becomes less evident, the ratio of coverage drops. Input that is generated by client-side JS tends to fall into that lower category of awareness.
The last suggestion is because I’ve seen several AJAX applications that re-use components across many areas. As integrations and re-use become more common, it’s more difficult to delineate the castle wall.
Regardless of all this, I agree with the paper. Very well written. I’m a big believer in moving away from talking about security issues and new threats. Instead, we need to recognize and report on the root causes of these problems. The root causes have not changed in 20 years.
Hey,
You have to admit that AJAX gave Web Services a great opp. for a comeback.
While the term Web Services was The Hype of the past few years, except for B2B apps, they never really justified their Hype. Now, with AJAX, it seems that web services are coming back.
Take the dust off those Web Services security whitepapers...yea baby!
> While the term Web Services was The Hype of the past few years, except for B2B apps, they never really justified their Hype. Now, with AJAX, it seems that web services are coming back.
Well, the couldn't be used through the browser, so they couldn't be adopted. Now they can.
> Take the dust off those Web Services security whitepapers...yea baby!
AHAHA.
I agree with you that Ajax does not opens any new problems, but i would like to emphasize that it does intensifies the affect of the existing vulnerabilities.
Does AJAX make Cross-Site Scripting (XSS) attacks worse? I hope not.
I have been doing some research lately on XSS and AJAX, and in my opinion, it gives XSS a new dimension. For example, with the ajax worm i demonstrated, an attacker can do an XSS attack on Page A and take control of Page C which was not vulnerable to XSS attack.
Ahh yes, that was an important point that I don't think I was clear enough on.
From website security perspect, Im saying that whether or not a site uses AJAX, its at no additional risk when it comes to XSS exploits (or other web attacks). Web worms included.
From the user standpoint, given that JavaScript Malware does in fact have access to XHR, self-propogating web worms are much easier to write and potentially more devestating.
Post a Comment