Massive data breaches are now a common thing. So common that I have largely stopped writing about most of them, simply because it happens too often and has become, unfortunately, the new normal. Still I feel that the data breach of British Airways, where the credit card and payment information of reportedly 380,000 customers was stolen, deserves a special mention.

British Airways has announced the incident on its own website. The news was also covered in the news. A group of attackers was able to basically scrape the credit card and payment details of customers making transactions through the British Airways website or their mobile application between August 21 to September 5. The incident was ultimately discovered (unfortunately with a substantial delay), British Airways reported it to their customers, and the attack was analyzed by RiskIQ.

The mechanism was simple enough. The attackers injected "22 lines of Javascript code" (in fact it was minified so it was actually all on one line, a very short snippet of code) in one of the Javascript files used on the site. Those 22 lines of code then intercepted mouse clicks of the users and when the users clicked the "Purchase" button, the malicious script then sent all the contents of the completed payment forms to the attackers' website. For those of you who wish to read all the details, those are well covered by the RiskIQ report linked above.

I would like to point out a few observations:

1. There was no way for end-users to protect themselves

For anyone out there who would buy stuff online, here is the unfortunate reality: There is nothing you could have done as an end-user to guard yourself. With the traditional "skimmers" in ATM machines, you can at least inspect the machine physically, and observe if something additional is attached to the card slot. Here you cannot. Or, well, you could... You can right click on the web page and choose "inspect element" and then try to observe the code or the network queries that the site makes (obviously this would already require substantial expertise and is well beyond the abilities of most "end users"). But because of the way in which modern websites are usually developed, they would normally make 20-30 or more requests to several obscure external sites (one of my clients had 90+ external queries on the front page alone), even if you were a VERY well informed and professional end user, you could not possibly notice anything out of the ordinary.

In the case of British Airways, the skimmer script was sending the stolen information to this kind of URL:

https://baways.com/gateway/app/dataprocessing/api/

Even if you look at this as a very professional end user, this does not look like it is anything out of the ordinary. You would not easily notice that baways.com is not actually an official domain of British Airways. Unfortunately it is normal for websites and web applications to make queries to messy, complicated URLs that are not even the same address as the original site. If I was to point out such things in a code or architecture review meeting, most developers would just explain that this is "normal" and would tend to try to avoid doing anything about it.

The only way to be safe would have been to not transact online. Unfortunately. And as an IT industry, this is really not the outcome that we want. That means we have failed to do our job.

2. The whole thing happened in code running in the browser

British Airways has said that they do not store the CVV confirmation code of the payment cards on their servers. And that is a very good thing indeed. But the data wasn't even stolen from their servers, it was taken right out of the end-users' browsers. CVV was included. Whatever sophisticated encryption technologies or intrusion detection systems they may have purchased and implemented in their networks was not even a factor. The data was already stolen before it ever reached that point. It was all in the code that executed on the browser of the end user.

Now, to those who develop code that runs in the browser (web developers): Could this happen to your application? Do you actually personally know the code that you ship and deploy to production? Are you sure that it does not contain code that would leak or steal the data of your customers?

If you are a "modern Javascript developer", you should know exactly what your answer is, and you should not necessarily be very proud or happy about it. When a new React.js application template without any user code already pulls in 1,6 million lines of unknown code (try it), how can you possibly guarantee anything at all about what your program actually does?

In the Ticketmaster data breach, which was apparently very similar in nature but affected a much larger number of websites, the overall scenario was perhaps even more disturbing: In exactly the same way, a piece of malicious Javascript code would send confidential details to the attackers' servers. But in that case, the malicious code came from a third party provider whose code was embedded on the webpage. In that case it was the customer support widget in particular. You know, that little chat bubble at the bottom right corner of the window. The one that all sites nowadays have. Once again, web developers, let's look at our own sites: How many third party providers' code are you running? Do you have any idea what code they bring to your page? Do you have any idea if you are leaking the data of your customers right now while you're reading this article?

We do consultations to web developers all the time. Time and time again we tell our customers that their application has too many third party dependencies. We tell them that the app calls too many external URLs. And it integrates too many third party providers. And regardless of this, in the end the developers often end up adding more. "This is how these things are developed nowadays", a developer once explained the situation to his boss in an audit meeting. Yes they are indeed. And look at where it leads us. In the case of British Airways alone, almost half a million credit cards.... Don't you think it's time to change these ways in which these things are developed?

3. The British Airways mobile application is not a native mobile application

In the case of British Airways, it was announced that the breach included both the website and the mobile application. This is of course peculiar, because the attack was a Javascript attack deployed on the website, so why would it affect the mobile application?

Again, if you are a developer, you already know what happened: Mobile applications are increasingly also developed in Javascript. In the case of British Airways in particular, and as is the case with many mobile applications, the actual mobile application that gets installed is largely just a shell or a frame. It then embeds the website for much of the functionality. So the same Javascript code that skimmed the data on the web was also used in the mobile application.

Now if the mobile application had been a real mobile application, running native code on the device, then this would not have happened the way it did. But because of "how these things are developed nowadays", and despite the concerns that come with such an approach, developers keep on developing Javascript for mobile, cutting corners and embedding websites. And you can again see where this leads...

As mentioned, this case was just one of many. More will come. And more will keep coming, until such time that we really start taking care of our code and the quality of our programs. Companies, developers, CIOs, please seek help. We at J&E and Eqela can help. And other experts can help. But please, let us start taking this seriously. It is no longer enough to buy firewalls, antiviruses and other security add-ons. We will need to fix, monitor and maintain the actual code behind all this, there is really no other way. Otherwise this will only keep getting worse.