Edward Wall

97% of BrowseAloud users are still vulnerable to the same attack

In February attackers injected a cryptominer into BrowseAloud's code which then ran on over 4000 websites which used the service. Three months later the vast majority of websites which were affected have not removed their vulnerability.


On 11 February Scott Helme discovered that the UK's Information Commissioner's Office was running a cryptominer on their website.

Ummm, so yeah, this is *bad*. I just had @phat_hobbit point out that @ICOnews has a cryptominer installed on their site... 😮 pic.twitter.com/xQhspR7A2f


This was the first in a string of tweets as he discovered more and more sites from all around the world. Targets included the UK's National Health Service, the USA's Courts and local government websites from multiple countries.

The issue was that attackers had compromised the BrowseAloud service and modified the source code to include a cryptominer. Because all these websites were embedding the script directly into their site they were all spreading the cryptominer.

Scott Helme wrote a really good piece on what happened.

Preventative Measures

There are two main ways in which websites can protect them: Sub Resource Integrity (SRI) and Content Security Policy (CSP).

SRI uses an integrity attribute on the script tag. The integrity attribute contains a hash of the file. When the file is loaded by the browser it hashes the file and compares the hash to the hash in the integrity attribute. If they match, the file runs. This prevents a file which has been modified from running in the browser and therefore stops this attack instantly.

HTML Script tag referencing BrowseAloud with an integrity attribute

CSP contains a whitelist of sources from which scripts may be loaded. Since the cryptominer's source would not be in the list, the script would not be loaded. This would have prevented the browser from loading the cryptominer from the third party, which is what happened in the attack.

BrowseAloud also enables you to embed specific versions of the script. The idea behind this is that you can use a specific version of the script which will never change and therefore the integrity hash will remain the same. If you do not use a specific version, then when the script is updated the script will stop working on your website.

The Analysis

Three months after the incident, I have conducted some research on the websites which are still running BrowseAloud.

I was able to get a list of 289 domains which use BrowseAloud from PublicWWW and analysed how many were using SRI and/or CSP to protect their users from this attack.

281 of the 289 websites (97%) do not use SRI or CSP and are therefore still vulnerable to the exact same attack. A further 6 websites use a CSP but no SRI which would protect them from this specific attack. While a CSP is useful against this specific attack, if the attackers upload the script to browsealoud.com then they would be able to run it, so CSP does not give full protection from an attack like this.

This means that in total, 99% of the sites I tested are vulnerable to a Cross Site Scriting attack with just 2 websites actually implementing Sub Resource Integrity to fully protect their users.

Frustratingly 29 websites (10%) used the versioned script but none of them included an integrity attribute. One key reason for having versions is that they will not change and therefore the integrity hash will remain constant and not break the site.

14 websites (4%) had implemented a CSP but 8 of them would not prevent a script loading from a third party leaving only 6 with a useful CSP as mentioned above.

According to PublicWWW there are 5020 sites using BrowseAloud. Extrapolating 97% out means that there are around 4880 websites running BrowseAloud which are vulnerable to an attack which has already happened.


The full list of results is available on GitHub.

Below is a list of domain suffixes from the list by popularity, excluding the domains which had properly protected their users from the attack.