PCI DSS v4.0 - The Most Important Changes at a Glance: Protection Against Web Skimming

22. September 2022

On March 31, 2022, the Payment Card Industry Security Standards Council (PCI SSC) released version 4.0 of the PCI DSS - the most comprehensive update to the standard since version 1.0. To help you ease the transition, in our series of posts we take a closer look at the key new features that PCI DSS v.4.0 brings. In the third part, we look at the new requirements for protection against web skimming attacks.

The risk of becoming a victim of a web skimming attack poses a major problem for companies offering goods or services in online business. As of today, such attacks already form a large proportion of all criminal attacks on payment card data on the Internet. They are relatively easy to carry out and usually remain hidden from the merchant and the cardholder. Because of this, the latest version 4.0 of the PCI DSS now includes requirements aimed at preventing and detecting these types of attacks.

What is Web Skimming?

Before we get into the details of combating web skimming threats, it is important to know what they actually are.

Let's start with traditional credit card skimming or copying. We often hear about skimming attacks on POS terminals and ATMs in the press. For these attacks, the attackers use hidden card readers and PIN pads to copy credit cards and PIN numbers. The stolen credit card data is then sold on the darknet, for example, and often used to purchase goods in web stores. Often, stolen cards are used to buy illegal products such as weapons or drugs.

Web skimming is the digital skimming of credit card data in e-commerce stores or web stores. Instead of manipulating POS terminals or ATMs, the attacker injects JavaScript skimming code directly into the web store or third-party services. Credit card information and personal data are thus intercepted, often unnoticed.

Web-Skimming – Attack Vectors

There are several variations of web skimming attacks that exploit the complexity of modern websites. Three vectors exist through which such attacks can be carried out:

First attack vector: skimming code is inserted into regular scripts directly on the web store's website.

Second attack vector: skimming code is included in third-party content and this compromised content is then loaded into the website - for example, as external scripts, libraries, or plug-ins. Third-party content are often analytics tools, supporting tools, or advertisements.

Third attack vector: Compromised scripts are included in content delivery networks. For example, script code is included in misconfigured Amazon S3 buckets with public write permissions.

Prominent Example: Web Skimming Attack on British Airways

In September 2018, British Airways announced that approximately 380,000 payment card details, including names, addresses, bank card details and CVV codes of 500,000 customers, had been compromised. This attack, which occurred between August and September 2018, was once again attributed to the notorious Magecart group, which inserted malware into the baggage check-in page on BA's website. The British Airways spokesperson also confirmed that the web skimmer used on the website was also used for the mobile app's browser. The European Union's GDPR regulators imposed a $230 million fine, attributing it to poor security measures on British Airways' website. The imposition of strict fines makes companies responsible for any data breach caused by third-party providers on their website.

Source: https://www.bbc.com/news/uk-england-london-45440850

Measures Against Web Skimming

In addition to well-known and proven safety measures, such as

  • regular updates and patches of all systems,
  • server hardening measures,
  • regular vulnerability scans
  • strong authentication,
  • Web Application Firewall (WAF)
  • and intrusion detection/prevention systems,

dealing with scripts to prevent web skimming attacks is important.

Companies should reduce or even avoid scripts on payment pages - this is especially important for scripts loaded externally.

For external script loading, companies should download third-party scripts and embed them in their website instead of just embedding script URLs. Doing so has the advantage of keeping the script under the company's own control and reducing the third-party attack vector. If, on the other hand, only the URL is used to embed the script and the third-party script is modified by an attacker, the compromised script will be loaded when the URL is called.

The handling of scripts should also be optimized. Companies should only load scripts from trusted sources and always thoroughly check the content of the script code.

To prevent unwanted script changes, scripts should be protected by file integrity monitoring (FIM). When an attacker changes a script, the FIM solution notifies of the change and organizations can respond to the tampering.

PCI DSS Requirements for Protection Against Web Skimming

Version 4.0 of the PCI DSS for the first time includes two specific requirements aimed at reducing the risk of web skimming attacks. These will initially apply as best practice when the new version of the standard comes into force. They will become mandatory as of March 31, 2025.

Requirement 6.4.3

This requirement aims to reduce the risk that web skimming scripts can be inserted into the payment page in order to read cardholder data (PANs) by attackers from the customer browser. It applies to all scripts loaded from the company's environment as well as scripts loaded from third-party vendors.

Requirement:

All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:

  • A method is implemented to confirm that each script is authorized.
  • A method is implemented to assure the integrity of each script.
  • An inventory of all scripts is maintained with written justification as to why each is necessary.

Source: PCI DSS: https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0.pdf

Requirement 11.6.1

This requirement aims to prevent web skimming attacks by enabling detection of changes or signs of malicious activity in the customer's browser. To ensure this, the Client shall periodically load the payment page and compare the current version of the HTTP header and the active content of the payment pages with previous or known versions received in the customer's browser.

Requirement:

A change- and tamper-detection mechanism is deployed as follows:

  • To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the customer browser.
  • The mechanism is configured to evaluate the received HTTP header and payment page.
  • The mechanism functions are performed as follows: - At least once every seven days OR - Periodically (at the frequency defined in the entity's targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).

Source: PCI DSS: https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0.pdf

Looking Ahead to the Future

Web skimming attacks are quite lucrative for cybercriminals. At the same time, their execution requires hardly any in-depth technical knowledge - they can easily be carried out with freely available tools adapted to all common web store platforms or commissioned directly as a service on the darknet. It is therefore only to be expected that the scope of web skimming attacks will continue to increase in the future. For companies, it is therefore crucial to protect themselves against such attacks by taking efficient security measures.

Implementing the protective measures outlined in this article and the security requirements contained in PCI DSS v4.0 already help companies to significantly reduce their risk of falling victim to a web skimming attack. Should you need support or consulting on the implementation of the measures, your PCI DSS auditor is ready to assist you with this task.

Also interesting:

DORA Deep Dive: Threat-Led Penetration Testing (TLPT)

DORA Deep Dive: Threat-Led Penetration Testing (TLPT)

The Digital Operational Resilience Act (DORA) will apply as of January 17, 2025. In addition to routine operational resilience testing, DORA will also make it mandatory for certain financial companies to carry out threat-led penetration testing (TLPT) every three...

Security Advisory on Gambio

Security Advisory on Gambio

The pentest professionals at usd HeroLab examined the online shop software Gambio during their pentests. The software offers merchants various functions that support the management of inventory and orders. Our professionals discovered a vulnerability in the password...

Categories

Categories