Jello wrote:

I know a memestreamer is writing a book on this stuff, so I'm interested in his comments on this.

This was an interesting article, and while I don't agree with it all of it, it does points out a big problem many in the web industry are guilty of: use of the word Ajax. Ajax is basically XmlHttpRequest, JavaScript, and XML. These are not insecure by themselves. End of story.

However, when most people talk about Ajax, they tend to (perhaps incorrectly) use it as a catch all when discussing web applications that exist on the client and the server that use XmlHttpRequest (XHR) to provide a rich user experience. Sounds vague, maybe I can get some VC for that! However, there are security issues that arise when an organization uses various technologies to make there websites more responsive, when creating mashups, etc. Are they new security issues? No. Does that mean talking about Ajax in the context of security is silly because it is "nothing new?" Of course not, because frankly there haven't been a "new" security issue that wasn't discussed in the godfather of security tomes: Security, Accuracy, and Privacy in Computer Systems (Martin, 1973).

There's a reason why my articles and talks have been titled "Ajax (in)security." It covers Ajax in (the context of) security as well as stupid, insecure ways people have used Ajax.

So why talk about Ajax security at all? To make sure people know about how security applies in applications that straddles the client and server. To make sure that they think twice about what the library or framework or product that makes their website prettier and more responsive actually does. To make sure people are extend their good security practices to rich interfaces. It is not Ajax's fault and it is not about finding problems with Ajax that exist no where else. It's talking about security as it applies to a new technology and that is not something to criticize or dismiss because it sounds unoriginal.

Here are my thoughts:

Does Ajax cause a larger attack surface: It depends

This really should just say “rich interface tends to increase the attack surface, Ajax included.” The article even says: “AJAX drives developers to publicly expose more functionality - which may introduce new “server-side” vulnerabilities.” Exactly, more inputs that need to be secured against traditional attacks, AKA, a larger attack surface. Is this Ajax's “fault?” Its no one's fault, just like opening a service for a Flash stock ticker to fetch prices from isn't Flash's fault. There is a cost for that rich interface, and that cost is more inputs.

It comes done to how the application is designed. Is a search engine's dialog box going to have more attack surface if the app is submitting that using XHR than a POST? No. But a search engine's dialog box that has a dynamically populated drop down box of words with a drop down like Google Suggest is.

Does Ajax make the attack surface harder to find. Yes.

Sure and so does Flash, ActiveX, Java Applets, browser helper objects, etc. Yes these objects are harder to parse by a machine. Yes a human can parse these objects. However, using richer interfaces makes it harder for both humans and machines than say a list of hyperlinks and a few FORM tags of our web apps of yore.

This whole discuss is kind of moot. Your application has an attack surface. By the very fact it has to be public, it will be found.

Can AJAX cause DoS? Possibly

I agree with the article as long as we are talking about traffic flooding. There will always be better ways. Hacking the DNS root servers would be better than a SYN flood. Using a remote code execution vuln in IOS to shutdown routers would be better. JavaScript can use a bunch of other ways to generate traffic.

As for DoS that doesn't involve traffic floods... :-) you'll see.

Does Ajax rely on client-side security: No.
I completely agree with everything said here. In fact, I think we should start a drive to raise money to have “I will not trust the client” tattooed onto every web developer's forehead!

Does Ajax lead to poor security: Sort of

Developers make stupid mistakes. My pseudo mullet in elementary school was a mistake that my mom should never have let me make, regardless of how cool MacGyver was. Ajax bridges are another place where developers can make a mistake. Its important to make sure they know that most bridges that come in frameworks don't have built in security mechanisms.

Does Ajax make XSS attacks worse: Yes.

Lets cut right to the chase. Yes, you could have a self propogating XSS worm that just uses Image objects or dynamic forms to send requests. However Samy and Yamanner both showed us that seeing the response from the server is critical. So we are down to compare iFrame remoting with XmlHttpRequest (XHR) to the same domain. With iframe remoting, an XSS payload can send and receive data from the same domain of a website without the user's knowldge. XHR can do the same thing. iFrame remoting is a dirty hack that relies on hidden frames and the grace of the same origin policy to use JavaScript to read the response. XHR was *designed* to allow the client to make HTTP requests and read the response. XHR does all the plumbing for you, lowering the barriers for people to use it. (yes, I'm sure there are nice wrapper libraies that make it transparent for the developer to use iframes too, but those aren't built into the browser). Plus, XHR does something that iFrame remoting cannot do: allows JavaScript to see the HTTP headers! Yes, Flash could do this, but XHR allows me to do it natively in JavaScript. XHR allows a XSS do more in JavaScript when talking to a same domain host than iFrame remoting. Thus XHR has increased what XSS is capable of.

Does AJAX change security best practices? No.
Does anything change security best practices? Probably not. Always establish who you are dealing with. If you don't know them or have no reason to trust them, be careful accepting sweet sweet candy from them. This goes for life, and web applications.

Myths of Myths of Myths: Ajax and security