News stories about hacking and malware are depressingly common these days. Here in the UK I think we've not really dealt with all the fall-out from last May when parts of our health service (along with many other businesses) were hit by the "Wannacry" ransomware worm. Yet another security incident happened the other day which will get less press coverage (since it's nowhere near as dramatic) but has bigger implications for us as web develelopers...
Since the insane financial bubble around Bitcoin started impinging on the mainstream media, a new online attack has surfaced: Injecting cryptocurrency mining software into people's web browsers. The theory is pretty simple: If you can push the code into as many web browsers as possible, you stand a better chance of receiving coins in return. So there have been a spate of script-injection attacks against websites with vulnerabilities that allow for XSS to succeed.
But this weekend we saw a new scale of attack. Security researcher Scott Helme pointed out that a huge swathe of websites had been hit, including a variety of UK government sites. It caught my attention because Manchester City Council was on the list, and I walk past their town hall on my way in to UNRVLD's offices:
Why is this bad, you might ask? Yes, some bad people made some free money but no personal data was compromised?
Just stop for a minute and think about what might have happened if the black-hats involved in this had done something subtler instead. Mining cryptocurrency is kind of obvious – it chews up lots of CPU. Your PC's fans spin up and the CPU usage bar in Task Manager jumps up high. So it's pretty easy to spot.
The time has come people: You need to learn about Content Security Policy.
There's now reasonable cross-browser support for technology aimed at mitigating exactly this sort of script-editing or injecting attack. Yes, it makes your life a bit more complex as a developer, but as this hack shows, the results are well worth your effort.
When you serve pages from your website you can send headers (or metadata elements) to the browser which define a security policy for external resources like scripts. The security has different levels, but broadly you have the choice of:
(Troy also has a good write-up of this whole hack issue that you probably want to read too)
Edited to add: In the comments below, Scott reminds me of the other thing that you need to think about here: Paying attention to what's happening as a result of setting up your CSP. Wouldn't it be great to know what's happening out in the real world when the internet's browsers hit your site? The magic you need here are the browser events around `SecurityPolicyViolation`. These get raised when your CSP finds something that violates the policy you defined. Your browser can be set up to do stuff with this data data, but one of the easiest things to do is notify a service called Report URI when events are raised. That's a tool Scott has built to let you see details of the data collected, so you can spot any mistakes you may have made in your setup that trigger voliations by accident, as well as any attempted security violations that occur because of stuff going on out on the internet. The basic tier of the service is free, so it's well worth talking a look at to see if it can help you.
Next time you're working on a website, have a think about what damage could be done to your site's reputation by issues like this. Take the time to consider CSP, and the risks it can mitigate for you. These attacks will only become more common I suspect ** .
And, if you've not done so already, have a read of Bas Lijten‘s post about CSPs in Sitecore. If you're working with SXA you can also take a look at Michael West‘s extension to let you use hashes when you reference scripts on CDNs.
Edited to add: :↑ Back to top
** I wrote that statement above, and then later the same day I saw this tweet where Troy Hunt links to a thread about another significant attack in the same style as the one described above:
And we'll only see more...