What is the website checking about my browser to protect the website from a DDoS?

  • Some sites I visit take me to a page that says roughly, "Checking your browser before accessing example.com. DDoS attack protection by CloudFlare".

    What exactly about my browser is being checked and how will that help protect against a DDoS attack?

    Automatic DDoS protection from CloudFlare

    Could you add a link to such a site?

    @FabioTurati : No. Many websites with large organizations do this, but usually when you visit the page, you just see their normal page. e.g., if CNN does this, then the URL is simply http://cnn.com (so it's not like this is a special page that does this). I've seen this from big companies and universities. Been a while though, maybe over a year: Maybe Cloudflare learned that my IP address is likely legitimate.

  • Most Denial-Of-Service (DOS) attacks rely on some asymmetry between the resources involved on attacker side and on target side. In other words, to be successful, a DOS needs an action to require very few resources client-side (so the each clients can send a lot of requests) while involving larger resources server-side (so the server(s) will be unable to handle the load).

    Due to this, DDOS attacks (the "Distributed" version of DOS attacks) are obviously not engaged by real humans clicking on links in a browser tab, but by bots sending massive amount of parallel requests to the target. The consequence of this is that the DDOS "client" is not a real browser, but a tool which may more-or-less simulate one.

    Cloudflare DDOS protection system is quickly described on their website as follow: "an interstitial page is presented to your site’s visitors for 5 seconds while the checks are completed".

    Two things trigger my attention here:

    • The checks: the most obvious way to sort real website users from automatic DDOS bots is to check whether the HTTP client is a real browser or not. This can go through testing the client's behavior against a panel of tests (see the post "bot detection via browser fingerprinting" for instance) and compare the result with the one expected from a genuine instance of the browser the client claims to be (for instance if the client claims to be a Firefox version 52 running on a Windows 10 machine, does it present the same characteristics?).

    • 5 seconds: Executing JavaScript tests and redirecting the visitor could be a very fast and almost transparent operation, so I believe that this "5 seconds" timeout is not there by accident but is meant to revert the computational asymmetry back in favor of the server.

      • The most light version of such principle would simply be to ask the client to wait (sleep) 5 seconds before resubmitting the same request (with a unique identifier stored in a cookie, as described on Cloudflare page). This would force the DDOS client to somehow handle a queue of pending redirections, and would finally make the overall DDOS process less effective.

      • A more brutal alternative would be to request the browser to solve some mathematical challenge which would require a few seconds to be solved on an average home system. In such a case, attackers would have no other choice than spend computational power to solve these challenges if they would like to proceed, but doing so will completely void the asymmetry since all the attacker's resource will be busy in solving challenges instead of sending requests, finally "DOSing" the attacker's system instead of the target's one.

    Couple points - a) this only works because cloud flare can absorb the attack. Part of how cloudflare works is by being big, big enough to be bigger than the DDoS attacker. And b) theoretically, because this is a DDoS, the attacker can just get more machines, so that those 5 seconds spent waiting matter less. Of course this costs more, but i gather cloudflare were involved in a different massive attack?

    Sometimes DDoS *are* done by humans clicking a link... for example when a big news story happens which directly/indirectly relates to a small website. The sudden increase in (genuine) load on the server can have the same characteristics of a "machine DDoS".

    @Bakuriu That's not technically a DDoS. It may have the same effect, but a DDoS usually refers to a malicious attack intended to prevent users from accessing a website.

    @WhiteWinterWolf Your last point about the equation, is this something you just thought of? Or do you have a link/reference where an explanation and real world usage is documented? (If you thought of it: That is an awesome idea :D!)

    @Tim: Cloudflare is precisely playing this game, both telling customers they are safe and potential attackers that they would need so many machines to attack them it would not be practical. Their capacity is also in constant raise, the French version of this page hasn't been updated yet and still mentions an 8 Tbps capacity as 20 times the largest recorded DDOS attack, the English version shows they upgraded to 10 Tbps being now 10 times the largest DDOS.

    @Wealot: This is not really a new idea, I inspired myself from a DOS issue affecting SSL handshakes caused by the fact that they often require far more computational power on server-side than on client-side (see this and that for instance). There is some research on how to invert or at least balance the scales, for instance by using new algorithms such as Elliptic Curves and ChaCha20.

    @Wealot This is known as a proof of work system.

    @Bakuriu we always called that the slashdot effect ;)

    @MichealJohnson Well, you could post a piece of "fake news" that goes viral and add a link to a target. In this case it *is* a DDoS. The only difference is that instead of hacking a machine to perform the requests for you directly, you hack (i.e. social engineer) real people to make their machines perform those requests. So: slashdot + social engineering === DDoS by humans.

    @Bakuriu Yes that is, technically, a DDoS. But a genuine popular article that links to a website hosted on a low-powered server is not a DDoS; it's just an ability for other users to access a website as a result of high load on the server. The difference is the intention.

    A proof of work system in a browser would be woefully inefficient. JavaScript, even with JIT, is incredibly slow compared to optimized assembly, or even C. A low-end laptop could likely compute in seconds what would take dozens of browsers many minutes.

    @forest Inefficiency doesn't stop sites from installing Coinhive's Monero miner and making its use a condition of access.

    @DamianYerrick That's true, and I forgot about WebAssembly too... So I take back that comment.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM