1. BA had 3rd party JS on its payment page
   <script src="https://example.com/whatever.js"></script>
2. The 3rd party's site was hacked, and the JS was changed.
3. BA's customers ran the script, which then harvested their credit card details as they were typed in.

This should have been a wake-up call to the industry. Don't load unauthenticated code on your website - and especially not on your payments page.

If you absolutely have to load someone else's code, check to see if it has been altered. This is done using SubResource Integrity (SRI).

SRI tells the user's browser to check that the code hasn't been changed since the website was published. It looks like this:

<script src="https://example.com/whatever.js"
        integrity="sha384-eP2mZH+CLyffr1fGYsgMUWJFzVwB9mkUplpx9Y2Y3egTeRlmzD9suNR+56UHKr7v" 
        crossorigin="anonymous"></script>

If even a single bit of the code has changed since it was added to the page, the browser refuses to run it.

Who isn't using this

Deliveroo

Gig-economy food flingers add in code from CDNJS.

What's especially annoying about this, is that the CDNJS website has a "one-click copy" for SRI.

Spotify

Their payment page loads code from live.adyen.com Adyen are their payment provider - so if they get hacked, credit card details are going to get compromised. But how much easier is it for an attacker to subtly change their JavaScript than to hack their entire mainframe?

The Guardian

Despite being a tofu-knitting member of the bourgeoisie, I am yet to subscribe to teh Gruan. If I did, I'd risk their affiliate tracker going rogue and stealing my organic credit card details. Bonus points for leaving a handy pointer to their internal Google docs...

Fanduel

Sports betting site running unverified scripts from external sources. They've also got external style-sheets

<link rel="stylesheet" href="//d2avoc1xjbdrch.cloudfront.net/6.26.0/styles/desktop.css">

If an attacker can change the JS or CSS, they could compromise users of the site.

EasyJet

I feel a bit conflicted about this one. You can probably trust Google not to get hacked. Right?

Google supports SRI - but doesn't mention it anywhere on their Hosted Libraries site.

British Airways!

Yup! They've not learned their lesson. Three pieces of unverified code running on the payment page.

• Maxymiser is an A/B testing and analytics tool. Run by Oracle now. Most ad-blockers prevent it loading.
• Google's reCAPTCHA. If that gets hacked, half the planet is compromised.
• SiteSeal "proves" your site is secure by displaying a image. No, I don't understand that either.

This does not make the site magically secure.

All three of them are highly trustworthy. But if you're BA and you've already been bitten by bad security practices, doesn't it make sense to go full "belt-and-braces"?

...and more?

These are just a small sample of the sites I've found. SRI has been available for two years and it still isn't being used enough.

Responsible Disclosure

I've reported this issue to a few sites by using responsible-disclosure aggregator HackerOne.

Typically, my warning goes unheeded with a response like:

Based on your initial description, there do not appear to be any security implications as a direct result of this behavior, this is an Informational issue at best, unless you can prove those third-party domains can be compromised in any way.

or

This appears to be more of a risk acceptance rather than a vulnerability. Although there is no PoC for this report, I will forward the information to the customer and see where to go from there.

That's fair enough. I'm not expecting a huge payout and it is only an informative report; I can't prove that the external sites are vulnerable. But there really ought to be a concerted effort to make payment sites as secure as possible.

This needs to be taken seriously. If you're handling users' details, you need to take every possible step to keep them secure.

The website loads internally hosted scripts using SRI (SubResource Integrity). Why?

Does your work require you to swipe an ID card to access the building? That seems pretty normal.

Does your work also remind you to keep your badge visible, and to challenge people who aren't wearing theirs? That also seems pretty normal. Sometimes security is breached, so we have multiple layers to keep us safe.

In Sony's case, they may know that many people have write access to the /assets/ directory, but very few can write to the product templates. So they add a further check even on code which they serve themselves.

This is defence in depth. But is it sensible?

If you're running a simple site, there's probably no benefit to this. If someone has the ability to maliciously alter a single JS file on your server, they probably have the ability to change the SRI hashes you're embedding.

But if you have a large and complicated infrastructure, it makes sense to double-check everything.

If you think I'm wrong - stick a comment in the box below.

Definitions

Suppose I want my website to have the latest version of the jQuery library. I might use a Content Delivery Network (CDN) to serve the code for me.

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>

If an attacker were to get access to that CDN, they could inject code into my site and compromise my users' privacy.

This is not a theoretical problem. This is how British Airways and others were compromised. An attacker poisoned the external JS they were using and stole credit card details.

This is where SubResource Integrity (SRI) comes in. Rather than just linking to an external script, I will also take a cryptographic snapshot of it (a hash). If the code changes, it will no longer match that hash, and the browser will refuse to run the external code.

This is what it looks like:

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js" 
   integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8="
   crossorigin="anonymous"></script>

So far, so good.

Dynamic Resources

But not all external libraries are static. Take Polyfill.io - a clever service which dynamically returns code based on what browser is requesting it. I've friends who work at the company which publishes Polyfill. These are my personal thoughts. I'm picking them because they're a popular service.

For example, if I include this script on my page:

Firefox will get served the following JS:

(function(undefined) {}).call('object' === typeof window && window || 'object' === typeof self && self || 'object' === typeof global && global || {});

But Opera will get served a completely different script:

(function(undefined) {Object.defineProperty(Array.prototype,"values",{value:Array.prototype[Symbol.iterator],enumerable:!1,writable:!1});var Iterator=function(){var e=function(){return this.length=0,this},t=function(e){if("function"!=typeof e)throw new TypeError(e+" is not a function");return e},_=function(e,n){if(!(this instanceof _))r...

Because the contents are different, the SRI hashes will be different. That means we can't use the integrity attribute.

Solution?

As noted on Polyfill's GitHub page, the service...

sends a different content per User-Agent (and that's the point of the service), so for Subresource Integrity, website developers don't need a hash per URL, but per (URL, User-Agent) pair and they need to change the integrity attribute on a per UA basis

There's no sensible way to verify that the code being sent back hasn't been tampered with.

Conclusion

You should use SRI for all your external resources. If you can't, then you should either take a static copy and serve it yourself, or run your own dynamic service.

For example, The Guardian runs the Polyfill code on its own servers.

I trust the people at the Polyfill service not to act maliciously. And I trust them not to get hacked. But I shouldn't have to trust them. The same goes for any external service. Trust but verify.

Update! In 2024, Pollyfill.io was taken over and became part of a massive supply-chain attack.