Full disclosure: I'm in private beta with a product that periodically loads production sites and compares all executed JS to the last-known-good profile (usually from CI prior to deployment), and raises warnings if anything changes. We don't run in actual users' browsers, so we won't see malicious code as early as Enchanted, but you don't have to trust us.
The type of product it sounds like you're running is a scanner and scanners have a couple problems. First, there's cloaking: if the malware can detect that it's a scanner (usually pretty easily) then the malware doesn't activate. Second, the malware comes from trusted code that you already think is trusted, and that's a problem if you overlook something because it's trusted. By contrast, Enchanted Security would see it since it runs on every users' browser all the time.
Yeah, our product could be classed a scanner, but there's no (little) risk of cloaking, as the network request or JS loaded to work out whether we're a real user is enough by itself to raise the alarm. To pull it off, the attacker would have to compromise the host of a trusted resource, determine that we were a scanner from our network request alone, and serve to us the original resource. There's a few ways to help ensure that our network requests aren't easily recognised, which is part of our "secret sauce".
Our approach does protect against the case where an attacker gets access to the client company's server and makes changes to the resources served, which can allow them to work around / selectively serve embedded snippets.
The second problem you mention isn't an issue, as we don't trust hosts, only the hash of resources (the same idea as SRI).
You can use SRI for something like a specific version of jQuery, but not for most of the products people are relying on that have more dynamic functionality.
SRI isn't practical for third party resources that are expected to change over time, which is actually a lot of third party resources. For example, a chat script like Intercom will change when someone from marketing makes a change that affects its frontend settings. This may be changing some text or coloring. So you can't pin it with SRI.
In your case, if your product tells you that some marketing script you're using changed hashes, how would you know whether that was a valid change or whether an attacker introduced malware?
Almost all bot/automated test/scanner detection relies on JS in the browser, which is too late to avoid triggering an alert with our approach. The attacker would have to identify us from our network request to load the compromised resource alone, for which we have (so far) effective mitigations.
> In your case, if your product tells you that some marketing script you're using changed hashes, how would you know whether that was a valid change or whether an attacker introduced malware?
We'll alert the client company for any resource that's changed - you can't trust that any third party resource change is okay, especially if the reputational and legal cost of a breach can exceed 10's or 100's of millions.
Most third party code from reputable companies, including tracking tagging, doesn't change that often, and client security/ops teams tend to be horrified by the ones that do. Each time some third party silently replaces code that they're serving, it introduces new opportunities for bugs, breakages, and attacks.
I really disagree with you about SRI. SRI isn't sufficient to prevent all client-side attacks, but it is very effective, and when enterprise customers demand it, third-party services almost always find a way to support it.
1. How does including a bit of JavaScript apply a CSP and block things if the CSP is not sent via HTTP headers? Are you installing a service worker and proxying every request through that so that you can apply the blocking or something? (I have not looked into this area for a while)
2. How is adding another 3rd party resource not expanding the attack surface rather than reducing it?
3. How do you know what is good/bad and should be allowed/denied?
On #3 I run a few hundred forums that have user generated content and whitelist a small number of 3rd party embeds such as YouTube, Google Maps, Strava, etc. I want those to keep working but don't wish anything not in my whitelist to work. But if I expanded the list in future to allowed embedding Twitch... how would your system know that this is a "good" action and to allow it?
For knowing what to allow/deny yes there's blacklists but also various more intelligent things as well. That's one of the problems with CSP headers is that they're too black and white today. With Enchanted Security, for example, you can configure it to say things like "allow Google Analytics but only for my tracking id UA-123456789-1" (this is because hackers have used Google Analytics as a data exfiltration mechanism where they sent data back to their hacker-controlled GA account)
Not only is the version of Modernizr used on the BA website extremely old (2.6.2 was released in 2012) but for hackers to be able to modify hosted scripts demonstrates an extreme lack of care; I wouldn't be entirely surprised if they just hadn't updated the CMS hosting the script.
Some people have been saying that anyone could be caught by this but I do think that the lack of process to allow this sort of thing to happen warrants this sort of fine.
In general, I’ve noticed that for many ecommerce sites, I have to enable some third-party script and refresh the page a number of times. Not only do you have to guess which third-party script is the one providing the functionality to complete the transaction but it’s an iterative process where the loaded third-party scripts have a further dependency on yet another third-party. Even as a technically aware user, I don’t have time to go examining whois records and TLS certificates to attempt to determine if baways.com (or baplc.com or bacdn) are genuine.
In any case, I doubt either of these extensions would protect use from “trusted” JavaScript from making a POST request to a third-party site. (BTW, I’m not arguing against the use of these browser extension as they do a great job of protecting against other threats).
I’m glad the ICO fined BA a non-trivial amount because users/customers shouldn’t have to be constantly on the alert, exercising a high degree of vigilance – and staying up-to-date with ever-changing and increasingly complex stacks of web technology.
Most sites still would have no idea if this were to happen to them today.
That’s why I’ve developed Enchanted Security (https://enchantedsecurity.com/) - a virtual content security policy that tracks the network requests and even blocks malicious ones. It’s like a firewall but running on your users’ browsers. This would’ve prevented what happened to British Airways. Get in touch if you’re interested in learning more.