Unless you’ve been living under a rock recently, you’re aware of Meltdown and Spectre — two of the most widely deployed security vulnerabilities in computer history. You may also know that this is not just limited to OS-level applications, and on the web it’s as bad as it gets:
A website can read data stored in the browser for another website, or the browser’s memory itself. — Microsoft Vulnerability Research
- Firefox 57.0.4 (released on 4th of January) fixed this.
- Microsoft released and update for IE and Edge on January 5th.
- Safari released 11.0.2 on January 8th, which supposedly protects the users against these issues.
- Chrome users have to wait until v64 (released around 23rd of January); but here is a list of what you can do now to limit the extent of the damage to your users.
Update: 2018–01–31: so far security researchers identified at least 130 malwares based on these issues: http://www.securityweek.com/malware-exploiting-spectre-meltdown-flaws-emerges
Quick notes
- Not all those updates fix all security vulnerabilities, but they are the first action point.
- Updating the browser is just the first step. You need to update your mobile/desktop operating system to protect yourself from a different but wider attack surface: auto updating apps. Please read more here.
- As we understand the scope of these vulnerabilities better, more patches will come. This story is far from over.
Now the big question for us web developers is: do we keep supporting the users with older browsers that are vulnerable, or do we demand that the users have the latest browsers?
I work at the Identity team of an international company with millions of users. No amount of work I do to secure our services can prevent the user from sharing the data on our site with a malicious or infected site open in another tab.
This might be the single most important side effect of these security vulnerabilities: we may actually have a perfectly valid reason to break the web for people with older browsers.
The history of front-end development may remember this point as when we shifted from the “hippie development era” (I support all browser versions) to the “hipster development era” (I only support the latest browser versions). ?
This is a huge shift in thinking, specially for us web developers, since we traditionally do our best to involve everyone: responsive design, progressive enhancement, and graceful degradation.
This time it’s different. In the post-Snowden era, we need to take security seriously. Supporting vulnerable browser versions is equal to promoting dangerous online life. It is our job as experts to educate the users and defend them against the bad guys. If sites don’t support the old browsers, the users have to upgrade.
This is a win-win situation:
- Developers get rid of legacy browser support for good
- The users get forced to make an important security decision (hopefully for the good).
If we don’t react quickly, the exploits of these issues will be deployed massively and the effect is beyond our control. The genie is out of the bottle.
This is the VW-scandal of processors
In 2015, Volkswagen was caught cheating on the emissions of their diesel engines. They cheated to make their cars more attractive to buyers. In this one, processor manufacturers “overlooked” some security concerns in their processors so they would have higher performance metrics.
I work at an international company building the login pages. Millions of users use our login to access the services of a wide range of companies. Naturally, my team is very concerned about security. We do our best to keep the system as secure as possible, but no amount of effort can mitigate this kind of vulnerability in browsers. For example:
- The
httpOnlycookies are no longer inaccessible from JavaScript. - The session cookie is super easy for other sites to steal (session spoofing).
- Chrome extensions that keep the passwords are now potentially leaking.
- The very HTML containing the
<script> tag is vulnerable, so XSS is a breeze.
Here’s an exercise: see how many of the OWASP top 10 vulnerabilities are now impossible to fix in versions prior to 2018 of any major browser.
Do we really want to serve users who don’t have a recent browser with the risk that the user’s data or our business will be compromised? Or do we (as professionals and experts) take a stand and educate the users about the dangers and guide them to mitigate the risk?
We need to drop support for vulnerable browsers. This will probably face a lot of resistance in a market that has traditionally been very flexible and forgiving towards the user stack (as long as they use our services, we’re good). But someone has to start the change.
The silver lining
In every crisis there is an opportunity. I argue that it’s the coolest thing that has happened to the web development community since ES2015. We all know the pain and cost of supporting old browsers (specially the browsers which are not evergreen):
- We have to bloat the code to shim features that modern browsers already have
- Debugging an older browser using its old-school debugging tools is not far from the experience of driving a car from the scrapyard after driving a modern car
- We can’t rely on browser integrity (IE, I’m looking at you), so we cannot serve some sensitive information at all to certain browsers.
- We have to deal with various CSS/SVG rendering issues
- We have to test edge cases for different browsers just because we support them! There are whole businesses developed around the idea of automating this tedious task with various success/effort ratios.
- The module system is now supported by all major browsers. Dropping support for vulnerable browsers has the side benefit of simplifying and modernizing our deployment channels. You may not need to transpile your code at all!
What does it really mean?
It means you can totally rely that async/await is available on your client browser and you don’t have to transpile. It means you can assume class is supported and generators are usable TAX FREE! It means template literals, rest params, … without transpilation, polyfill or any kind of complex toolchain! Web development is simple all of a sudden.
Hell it means you have ES6 modules NOW without Rollup, Webpack, Browserify…
This means a whole new era. I know it’s too early and every cell of your existence is screaming it’s a lie but nope! This is happening. If you want to support users with ancient browsers, do it at your own risk. If you care about your users security and your business’ integrity, you get all of that ?as a reward!
One more thing: HTTP/2 is now officially usable!
OK, it sounds like I’m some sort of hero now, but most of those stuff is already available in the majority of the browsers. It’s just that for some weird reason, many developers and product managers assumed that 2.7% of the users (who use IE) actually generate the majority of their business revenue and they should go to great length to support them. Sweat no more. Even if you want to, now there’s a huge reason not to!
How?
This essay is more about WHY rather than HOW, but here are some quick thoughts:
- Browser sniffing can be used to detect if the users are running a vulnerable browser. You can then refuse to serve critical data to the users with browsers that can’t keep them safe. Browser sniffing traditionally haven’t been very reliable.
- Show a notification bar to subtly warn the users; but who would read or react to that? In EU we got used to ignore the cookie notifications!
- Write a test code that actually tries the attack. If it succeeds, it shows a warning (I’m sure a NPM module will show up soon, if it hasn’t already ?).
Conclusion
Remember how we all reacted when React.js “mixed template and code” in JSX? Sometimes we have to unlearn “best practices,” because the alternative makes more sense. I’m not talking about breaking the web! I’m asking to protect our users before all hell breaks loose. Please give it some thought.
Update 1 (2018–01–16): Security Now #645 goes into details of Spectre and Meltdown and introduces a little handy utility (speccheck) to test system vulnerability.
Read You might not need to transpile your JavaScript, When should I use TypeScript? or Programming is the best job ever.