Why were hyperlink auditing pings used for DDoS attacks and not any other requests?
There are some potential benefits of using <a ping>
, but they are not unique to <a ping>
. It is not outside the realm of possibilities that the attackers simply chose any working method to trigger network requests.
<a ping>
works when JavaScript is disabled. But in this case the attack started with JavaScript. Even if JavaScript were to be disabled, there are many other ways to trigger a request to an external site, e.g. embedding images and stylesheets.<a ping>
requests are background requests. When the user leaves a page, the ping request will not be aborted. In this case, the attack relies on the page being around in order to send a ping every second, so this is probably not the main reason.<a ping>
requests' response body is ignored; the browser is allowed to immediately end a connection when a response body is sent by the server. This allows the attacker to carry out the attack with a low impact on the data usage, to make it less likely for the user to notice that their network is being abused.<a ping>
responses are not cached, so every ping will result in a request to the server. There are many other cache busting techniques to do so. Thefetch
API literally has an option to ignore the cache.<a ping>
requests are POST requests (and therefore not cached, see the previous point). This allows the same URL to be used. If random URLs were used (as a cache buster), then these may stand out in access logs. However, being a POST request is already somewhat unusual. Besides, these requests are uniquely identifiable by the "Ping-From" and "Ping-To" request header, as well as the more generic "Origin" header for cross-origin requests.
When I saw your question a few days ago, my first thought is "Why would there be a specific reason for doing so?". In the absence of any other probable answers, I guess that the answer is that there is no unique feature that the method provides. As said before, there are other methods with the above benefits, e.g. CSP violation reports, navigator.sendBeacon
, fetch
. There is nothing special about <a ping>
.
The reason why you think that there may be something special to it is because a security firm posted an article about it, with a catchy headline and interesting write-up. Their final paragraph also mentions that these requests can be filtered, and of course they have a product that does it:
Fortunately, web site and application operators have some control. If you are not expecting or do not need to receive ping requests to your Web server, block any Web requests that contain “Ping-To” and/or “Ping-From” HTTP headers on the edge devices (Firewall, WAF, etc.). This will stop the ping requests from ever hitting your server. (Note: Imperva DDoS Protection is already updated to prevent ping functionality abuse targeted at your sites.)