January 24, 2023

The battle for payment card data is taking place in your browser

By John Elliott | 4 min read

Millions of people shop online every day using payment cards. The move to e-commerce was accelerated by the pandemic, particularly in companies and areas where an online transactional presence was not originally seen as a priority. And, despite some early turbulence, we all now mostly trust e-commerce. Shopping online is generally safe, but under the surface, there’s a war going on to keep our payment card data secure.

The Evolution in Where Criminals Attack

When criminals first realized that they could steal cardholder data to make fraudulent transactions, their focus was stealing data from internet-connected point-of-sale (POS) systems. The industry reacted by creating the Payment Card Industry (PCI) Data Security Standard (DSS) that described the security measures that should be taken to protect payment card data from criminals.

As merchants put in place measures to protect their POS systems from internet attacks, the criminals moved to attack locations where cardholder data was stored or consolidated. Over-time companies removed legacy data stores and adopted the technical controls specified in PCI DSS to protect the locations where they stored, processed, or transmitted payment card data, making life harder for criminals.

The war between criminals and the payment industry has continued ever since. As security architecture and industry standards evolved, criminals found new ways to attack. In e-commerce, criminals have moved from attacking a merchant’s own e-commerce infrastructure to skimming payment card data from the consumer browser.

This is because they either found the merchant well protected (the general standard of cybersecurity has changed massively in the past ten years) or because the e-commerce merchant, like brick-and-mortar retailers before them, had decided that there’s no value in touching payment card data, and so a cardholder’s details are sent straight from the customer’s own browser to the payment processor, bypassing the merchant’s own systems.

This leaves the only remaining place of attack being the consumer’s own browser. The criminals’ aim is to capture the cardholder data at the same time as it is entered into the merchant’s webpage checkout.

Such attacks are invisible to both the cardholder and the merchant – the transaction happens as it is supposed to: the merchant gets the funds, the customer receives the goods or services they ordered, and the criminals get the customer’s payment card data.

When these attacks first happened, they made the news. NewEgg, Macy’s, Ticketmaster and British Airways are some that you may remember, or where you were notified that your own cardholder data was stolen. Just because these attacks are no longer newsworthy, doesn’t mean that they are not occurring – these so-called e-commerce skimming attacks represent the majority of attacks against payment card data.

The criminals’ methodology

Most webpages today are a mixture of words, images, video, layout information, and crucially a scripting language called JavaScript. JavaScript is what has enabled the web to evolve from its initial incarnation of an information-centric, display-only medium to the interactive experience we enjoy today.

While JavaScript allows websites to have the functionality of an interactive application, it also enables that interactivity to be malicious. So to skim data from the consumer’s web browser, all the criminal has to accomplish is to get the consumer’s browser to load and execute their own, malicious, JavaScript.

Once the criminal’s JavaScript is running in a webpage it has access to everything that the consumer enters, so it can read payment card data from the form fields where it is entered by the consumer, and silently send it to a criminal server located anywhere on the internet.

You may be wondering then how the criminal accomplishes this – to have their JavaScript loaded into the consumer’s browser simultaneously with all the legitimate content and components that make up the merchant’s website?

All the criminal needs to do is tamper with any of the legitimate JavaScript that the browser is going to load and add their malicious payload. They can do this in two ways, by attacking the infrastructure of the merchant themselves or by compromising any one of the third parties that the merchant relies on to provide JavaScript to the consumer browser.

On average, Jscrambler found that a merchant’s website will contain 148 scripts, and 58% of these are supplied by third-party companies. This is a function of how modern websites are built – and while that’s great for functionality, it exposes many places for the criminal to attack. The criminal just needs to compromise one of these locations and add their malicious payload to the JavaScript which will be loaded by the browser of their target merchant’s customer.

The power of standards

Although some merchants have worked out how to best defend against these attacks, many others remain unaware. Luckily the payment card industry has a well-respected security standard that’s a contractual baseline for anyone that wants to accept payment cards – the Payment Card Industry (PCI) Data Security Standard (DSS). First released in 2006 the standard is revised every few years to take account of changes in technology and changes in the ways that criminals attack.

The newest iteration – version 4 – was released in March 2022 and will become applicable in 2024. And in this new version, the PCI SSC has included two requirements that aim to stop the rise in skimming attacks and provide the weapons that the merchants need to win the battle against the criminals. Each time a new version of the standard is released, and the industry adopts the requirements contained in it, classes of criminal attacks are significantly reduced. It is hoped that this trajectory continues!

The first new requirement aims to reduce the number of places that a criminal could attack to add their malicious scripts. It does this by requiring merchants to specifically authorize and minimize the number of individual scripts that are loaded on payment pages, with this information recorded in an inventory.

The second requirement is detective rather than preventative and wants to make sure that merchants are alerted when it is detected that new or changed scripts are present on the page where the consumer enters their cardholder data, allowing the merchant to validate the integrity of the new or changed script.

As merchants throughout the world transition to the new version of PCI DSS and implement these two new requirements, the advantage in the battle against criminals will shift in the merchants’ favor.

Author
John ElliottSecurity Advisor at Jscrambler, John Elliott specializes in payment security standards and data protection regulations. He contributed to many of the PCI standards including PCI DSS v4.
View All Posts

Subscribe to our weekly newsletter

Learn more about new security threats and technologies.

I agree to receive these emails and accept the Privacy Policy.
Projeto Co-Financiado por (Mais info)Norte 2020, Portugal 2020, FEDR