Major sites running unauthenticated JavaScript on their payment pages &#8211...

Major sites running unauthenticated JavaScript on their payment pages – Terence Eden’s BlogTerence Eden’s Blog

A few months ago, British Airways’ customers had their credit card details stolen. How was this possible? The best guess goes something like this:

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.

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.

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.