The idea is not new: get a lot of users to view a given webpage, to DDoS the webserver / backend (depending where the bottlenecks are). If I recall correctly, some student asked the visitors of his website to continuously refresh the page of his university and got charged for it.
Imagine the following scenario:
- The code (a) looks up a DNS name (this makes the attack targetable) (b) launches N “threads” and starts sending requests to the given website
Such attacks would be very hard to diagnose. The requests would come intermittently from a wide range of IP addresses. Even if you could get your hands on such a computer, you couldn’t find the source of the requests easily (it’s not like the computer is infected with a malware you can find by scanning the files on the hard-disk). It can be also very sneaky, randomly executing (or not) or using geotargeting to select a subset of computers. These techniques are already in use by malicious advertisements (“malwertisements”) which are currently used to try to sell you rogue AV products. An other reason which makes finding the source hard, is the fact that AFAIK XMLHttpRequest does not send the referrer header. An other way to get rid of the referrer header is to make the request from a HTTPS site (browsers do not send referrer in this situation to avoid information leakage).
What can you do? Not very much. Prepare for the DDoS. Have a contingency plan (like a backup location in a different IP space and pointing your DNS entry there). You might be able to differentiate the requests from “normal” requests, but even so, the volume of requests can bring down the machine at the TCP level. And please, please secure your website. We have enough unsecured websites already!
Picture taken from 416style’s photostream with permission.