How to protect your website from cryptojacking attacks

In the past month more than 4000 websites, including government websites in the US and UK, such as the UK’s Information Commissioner’s Office (ICO), were reported to be serving the CoinHive crypto miner to its users. CoinHive crypto miner is a JavaScript script that can be installed on any website and was designed to mine cryptocurrency at the expense of its users’ CPU power.

Clearly this was not the intention of any of the companies affected. Indeed, the ICO is an independent authority set up in the UK to uphold information rights in the public interest, promoting openness by public bodies and data privacy for individuals. This ‘cryptojacking’ assault was a direct result of a third party provider (TextHelp) used in the ICO’s website being compromised, without the knowledge of website owners nor the third party provider. This incident was initially flagged by security expert Scott Helme after a tip-off from another security expert, Ian Trump.

How the attack unfolded

The ICO website, along with all the other affected websites, were loading a file from a third party website which is where the problem started. By loading JavaScript directly from a third party like this, these websites were basically inviting injection-style attacks. This isn’t too different from the alleged attack against jQuery’s CDN that RiskIQ claims was serving an exploit kit to every user of every website loading jQuery’s directly from their CDN.

This particular approach is very appealing to attackers who are able to compromise users at scale by attacking dependencies being loaded dynamically. Even if you believe third party providers to be reliable, they can still be unknowingly compromised, effectively allowing attackers to use them as a vehicle for malicious injections.

What can be done?

One possible approach, as pointed out by Scott Helme, is to add Subresource integrity (SRI) attributes to the script elements loading the external scripts. He even suggests complementing this by employing Content Security Policy (CSP)’s to enforce the use of SRI tags.

Whilst this is a good suggestion it doesn’t work very well if the dependency script needs to be updated regularly — which seems to be the case here. CSP is helpful for restricting external JavaScript (JS) from being loaded in a website, but is not meant to assure the integrity of scripts that it expects to load.

Whitelist-based CSP is really hard to carry out and skilled attackers will probably find a way around since it does not prevent the injection of code from external sources that are in the whitelisted domains, for example. Regarding CSP, as a word of caution, any header-based web security control can be disarmed by a browser extension

Read Full: How to protect your website from cryptojacking attacks