HTTP

While the typical operation of an HTTP session is to transfer data items between the client and the server, HTTP proxy caches provide a way that an HTTP client can manipulate a server into initiating a connection to a victim web server. Most proxies will happily attempt to fetch whatever URL you request from them. These fetches look to the victim like legitimate requests; it cannot filter them out without losing all of its legitimate clients, too.

There are three limitations/defenses against proxy reflector attacks. First, it is not clear that there are enough proxy caches (as opposed to Web servers themselves) to constitute a truly large pool of possible reflectors, though with the rise of content distribution networks (CDNs) this may change (and, as noted above, even a fairly modest number of reflectors can still serve well to complicate traceback).

Second, in principle proxies can be configured to only serve a particular set of clients. However, CDN proxies likely cannot do any such restricting, because by their nature they're meant to serve the Internet public at large. On the other hand, the proxies could be configured to only serve the pages of their customers. Anecdotally, they do not appear today to have this restriction.

Third, the connection between the slave and the reflector cannot be spoofed (unless the reflecting proxy has predictable sequence numbers), and hence monitoring or logging at the proxy will identify the slave's location.

This last is a major shortcoming. It means that the attack might be quickly traced back--all it requires to expose the slave is one alert administrator among the many off of which a slave is reflecting.

Summary: would be a significant threat were it not for the likely quick traceback due to the non-spoofed connection from the slave to the proxy. Definitely a significant threat if servers running on stacks with predictable sequence numbers are widely deployed.