Performing DDoS attacks with HTML5 Cross Origin Requests & WebWorkers

Update: Shellex has performed detailed performance analysis of this technique.

DDoS attacks are the rage this year, atleast in the latter part of the year. There have been numerous instances of successful DDoS attacks just in the past few months. Some of the current DoS/DDoS options seem to be LOIC, HTTP POST DoS and Jester's unreleased XerXes.

This post is about a DDoS technique I spoke about at BlackHat Abu Dhabi that uses two HTML5 features - WebWorkers and Cross Origin Requests. It is a very simple yet effective technique - start a WebWorker that would fire multiple Cross Origin Requests at the target. This is possible since Cross Origin Requests that use the GET method can be sent to any website, the restriction is only on reading the response which is anyway not of interest in this case. Sending a cross domain GET request is nothing new, you can even do that by embedding a remote URL in the IMG or the SCRIPT tag but the interesting part here is performance. My tests on Safari and Chrome showed that both the browsers were able to send more than 10,000 Cross Origin Requests in one minute.

So simply by getting someone to visit a URL you can get them to send 10,000 HTTP requests/minute to a target of your choice. Now if you pick a juicy target URL, one that would make the server do some heavy processing then just 10,000 requests/minute might overwhelm it. Lets scale this a little, say 60 people visit the URL containing the DoS JavaScript, that is 10,000 requests/second at the target. With just 6000 visitors to this URL we can send around 1 million requests/second to the target. Getting 6000 Chrome and Safari users to visit a particular URL is no big deal really.

Maybe its not that simple, there are few things to consider here. When you send the first request to a particular page and the response does not contain the 'Access-Control-Allow-Origin' header with a suitable value then the browser refuses to send more requests to the same URL. This however can be easily bypassed by making every request unique by adding a dummy query-string parameter with changing values. The number of requests/minute is also a variable. The browser sends a certain number of requests and when it receives the responses for those it sends in the next set of requests and so on. So as the server slows down the browser's requests/minute rating would also slow down. The figure 10,000 requests/minute was clocked against a server located in the internal network, against a target in the Internet it would realistically be between 3000-4000 requests/minute. If the attacker is planning to target an internal server by getting the employees of that company to visit this malicious URL then the 10,000 requests/minute rating would apply.

I am not going to release any PoC as this might probably be a bad time to do that but it shouldn't be very difficult to put together something for testing once you understand how it works. It should be relatively easy to block this attack at the WAF since all Cross Origin Requests contain the 'Origin' header, that way you can differentiate between legitimate and malicious requests.