Locking it down: A security primer for web developers

Description

It’s surprising to many developers how easy it is to interfere with the experience they’re providing to their users, particularly in an increasingly mobile environment, where phones connect to dubious free WiFi networks. Your users are almost certainly vulnerable in one way or another. Mike North explores a series of common web app security pitfalls, first demonstrating how to exploit the vulnerability and then recommending a pragmatic and effective defense against the attack. Buckle up, because Mike’s about to take some things you love and depend on and smash them to bits.

Mike begins with DNS. Most devices are set up to use and trust a public WiFi’s DNS responses. The incentive to set your phone up this way is because, in many cases, free public WiFi relies on spoofing DNS to get you to agree to terms of use. Using his own WiFi network (which you may voluntarily join), Mike shows how it’s very easy to manipulate traffic with a DNS server by redirecting all plain HTTP traffic to the Fluent Conference website to a different domain.

Mike then takes an SSL certificate he bought for a lookalike domain. Your browser will throw up a big scary warning screen, but studies have shown that up to 40% of users will click through these warnings and proceed anyway. Mike demonstrates how we can easily have domain validated for this lookalike domain, which appears and behaves exactly like another website (except we can insert some malicious code along the way).

Mike then picks on a common CDN, even one that provides built-in SSL like CloudFront, showing how we can interfere with DNS and send our own identically named payloads over the wire. Because CloudFront uses a wildcard certificate, we can set up our own subdomain, and the app is none the wiser. To defend against this attack, Mike introduces the concept of subresource integrity, where remotely hosted static assets can be hashed at build time and verified before the browser uses them.

Mike concludes by employing HSTS headers to inform browsers that they are prohibited from connecting to the domain at all over plain HTTP. Now, when there’s a certificate error, there’s no easy way for the user to proceed and ignore the problem. Mike also discusses how HSTS handles subdomains and ultimately tightens your security even further by ensuring that everything required for your app is brought in over HSTS-protected domains.