In preparing a report, someone asked me how Ajax affects Denial of Service attacks. As I said in this post XmlHttpRequest doesn't really change things, because JavaScript could already generate HTTP traffic. In fact, XmlHttpRequest (the workhorse of Ajax) can only talk to the domain it comes from. Thus, I could make a botnet of MySpace users using an XSS vuln, but with XmlHttpRequest I could only attack MySpace with it.

So yet another way for JavaScript to generate HTTP traffic doesn't really change things. Is there anything else about Ajax that could affect DoS attacks?

I think so.

I would argue the way Ajax applications can make you more open to a DoS is from all the open web services and Ajax endpoints. A flood of traffic to an Ajax endpoint is worse than a traffic flood against a random wenpage because each time you contact that webservice the server has some computation to do. Presumably moreso than the computation to simply serve a webpage. Furthermore, responses from Ajax endpoints are not typically cached by a Squid proxy or any other “website accelerator” the way web pages are. Even if they were, this wouldn't help very much. Think about how often someone requests the login webpage versus someone contacting a webservice to spell check Aardvark.

Another DoS vector I see with Ajax applications is something I'm going to call Control Logic Denial of Service. All those web services and Ajax endpoints are API calls into the application. By looking at the JavaScript code that’s pushed to the client, I can see in what order and how often these webservices are contacted, as well as what the parameters are. In essence, this is a blueprint of the steps the applications takes to function normally. However, it is also a blueprint on how to use the application incorrectly. Some webservice may allocated resources where as another one cleans it up. An attacker could simply never call the clean up functions. Or I simply call all the functions out of order. Even if the code fails gracefully, it is extremely expensive for a program to generate an Exception, even it gets caught.

A traffic flooding DoS is like throws millions of small punches hoping you take an opponent down. A Control Logic DoS is like cutting open their head and punching them a few times in the brain.

Now, before Memestreams gets a bunch of web sec people registering to bitch at me that this isn't new, you are right. I'm sure this has been done before in various situations. Could you do this attack against a web app before Ajax? Probably. If I have a three step registration process spread over three webpages, calling them out of order could have the same effect. One difference I see is that in this situtation, the only way I could know the control flow (i.e., PageA POSTs to PageB which POSTs to PageX) would be to actually walk through the web app myself. In contrast, Ajax applications typically expose their entire API in a single webpage with a mass of JavaScript which would contain the callback code. This happens more than you would think. See Alex Stamos's Blackhat presentation for more details on how Ajax apps expose their entire API.