Security Sense: The Web is Held Together with Sticky Tape

I’ve been increasingly of this mind over recent years, especially as we’ve tried to do more and more with what is ultimately the same underlying WWW implementation as we’ve had for the last couple of decades. The Dyn DDoS situation of last week has pretty much cemented that view in my mind and the more I tug at the thread of this idea, the more it feels like the whole thing quickly unravels.

Take authentication, for example. HTTP does many excellent things that has allowed the web to grow to what it is today based on a spec defined in the 90s but because it’s stateless, we almost exclusively use cookies to be able to identify who’s who (the primary exception being bearer tokens for more API-centric apps). But auth cookies have left us with a whole raft of other problems…

One of the joys of cookies is that they’re sent automatically by the browser when they’re valid for the resource being requested but equally, this is one of the pains. Cross site request forgery (CSRF) attacks allow malicious parties to trick the user’s browser into making requests that are performed under the victim’s identity because the auth cookie is automatically sent to the target resource. We mitigate this risk by using the kludge that is anti-forgery tokens consisting of another cookie and a hidden form field to allow the server to reject requests the browser never should have made. Yet time and time again, we see insecure devices such as home routers compromised by CSRF attacks changing DNS servers which leads to another problem…

The nature of DNS is that we rely on servers to resolve host names to IP addresses, at least when DNS servers can respond and they aren’t DDoS’d off the planet like Dyn was for a while there. But name resolution can be compromised not just by a client being tricked into using malicious resolvers, but by an attacker managing to gain control of where a target website’s name servers point to. Bad credentials, socially engineered domain registrars and CSRF again have all played parts here so one of the ways we try and fix this is with SSL…

Except we’re not meant to say SSL anymore because it’s meant to be TLS now. But we can’t get rid of the name; there’s SSL Labs which remains an excellent resource for testing TLS (try going to tlslabs.com and see how far you get), there’s the Bad SSL site which shows how the browser behaves with all sorts of TLS implementations and if you want ASP.NET’s forms authentication to use TLS, you set the RequireSSL property. And that’s just the name, wait until you get onto the implementation…

Because of things like the Diginotar attack, you can’t always be sure the certificate you’re served is the correct one for the host even if it technically checks out. So, we have public key pinning which in the browser world is referred to as HPKP… but it doesn’t work in Microsoft’s or Apple’s browsers. And even if it did, it’s only implemented by 0.04% of the top million websites anyway. Then there’s other acronyms that are unbeknownst to most such as CAA and DANE that also try to tackle inherit risks within the whole certificate space, a space which only exists to try and solve other underlying problems with the web.

The browsers themselves try to save unsuspecting users from attacks the server can’t always detect so we have features like HPKP which I just mentioned, but also XFO, CSP, HSTS, CORS and a raft of other acronyms. Some of them are supported by some browsers, some of them have serious glitches when they are supported and all of them exist not as features to build richer, more functional websites, but rather to try and stop the ones we have from being continually compromised by increasingly innovative attacks. And even after all of that, some of the world’s largest websites were still taken down by an army of cheap Chinese webcams. We’re gonna need a lot more sticky tape…