PCI DSS v4.0: Boosting e-commerce script security to combat online skimming

The recently updated Payment Card Industry (PCI) Data Security Standard (DSS) version 4.0 (v4.0) includes several new requirements focused on e-commerce and the security of webpages involved in payment operations. In recent years, criminals have increasingly targeted e-commerce operations in attempts to steal payment card data with a technique known as web-based or online skimming.

Most notably, the hacking group Magecart has conducted broad campaigns to skim payment card data from e-commerce sites, even bypassing iframe protection that many organizations use to segment payment processes into an isolated sandbox page element. In perhaps its most notable attack, Magecart injected just 22 lines of code to breach over 380,000 payment card records from one company’s customers. Most recently, Magecart has been hijacking 404 error pages to hide skimming code in major e-commerce sites.

Overview of a web skimming attack

^{Source: https://www.microsoft.com/en-us/security/blog/2022/05/23/beneath-the-surface-uncovering-the-shift-in-web-skimming/}

PCI DSS v4.0’s impact on e-commerce

The PCI Security Standards Council (SSC) has taken note of the rising threat of online skimming, issuing guidance as early as 2019. With the introduction of PCI DSS v4.0, the PCI SSC has introduced two new requirements designed to enhance the security of cardholder data (CHD) and adapt to the evolving threat landscape in the online retail sector. Most notably, Requirement 6.4.3 requires management of all payment page scripts that are loaded and executed in the consumer’s browser, and Requirement 11.6.1 requires entities to have a change- and tamper-detection mechanism to alert necessary personnel of any modifications to HTTP headers and payment pages. These updates are included in the PCI DSS v4.0 SAQ D for Merchants, SAQ D for Service Providers, SAQ A and SAQ A-EP.

PCI DSS v4.0 payment page scripts

Payment page scripts are the primary method that attackers use to conduct online skimming. Attackers exploit vulnerable plug-ins and initiate credential stuffing and phishing attacks—or any other primary means of gaining access to the environment—to inject malicious code onto payment pages. The malicious code steals CHD when users enter it when making purchases. The information is then sent to an internet-connected server using a domain name controlled by the actor.

Third-party scripts in particular are a frequent target—including, for example, advertising and tracking scripts and tag management systems, as their functionality can be altered without the entity’s knowledge. Requirement 6.4.3 now requires organizations to confirm that each script is authorized, ensure the integrity of each script and maintain an inventory of scripts with an accompanying justification.

The requirements and testing procedures document several methods to meet these demands, suggesting either a manual or an automated approach. They provide the following examples:

• Subresource integrity (SRI), which enables consumer browser validation of scripts via cryptographic hashing
• A content security policy (CSP), which limits the locations that a consumer browser can load a script from and transmit account data to
• A proprietary script or tag management system, which can prevent malicious script execution

SRI adds a tag to each script that includes a cryptographic hash. Customer browsers check this hash against the script to be loaded and only load scripts that match the hash. Much of the challenge in this implementation stems from the volume of scripts running on many payment pages—typically dozens to over 1,000—and the difficulty of updating the configuration every time a new script version is released, especially in third-party and fourth-party integrations.

The CSP is a security standard that allows website administrators to declare the approved origins of content that land on the page so that only scripts and other elements from authorized sources will load, preventing loading from malicious domains.

The marketplace is currently growing for service providers to manage what can quickly become a labor-intensive requirement. Requirement 6.4.3 will remain a best practice until March 31, 2025, when it becomes mandatory. The extended timeline gives organizations time to inventory and implement control of their payment page scripts.

Payment page tamper detection

Requirement 11.6.1 adds the demand to deploy a change- and tamper-detection mechanism to alert on unauthorized modifications to a payment page, including any change, addition or deletion to the HTTP headers and contents of payment pages. The mechanism must evaluate HTTP headers and the payment page for changes and alert personnel to any unauthorized modifications. This action must take place once every seven days or periodically as defined by a targeted risk analysis. The requirement applies to the version of the page received by the consumer browser, focusing on webpages that rely on assembling objects and active content from multiple internet locations (e.g., through JavaScript). The requirement provides flexible options, such as the following:

• CSP violations can be reported to the entity using the “report-to” or “report-URI” directives.
• Synthetic monitoring mimics or simulates user interactions on webpages, providing a simulated external user to create and then monitor a customer-facing payment page. Organizations can then monitor this simulated checkout page for unapproved changes.
• Organizations can embed a tamperproof script in the payment page. The script can then indicate unauthorized modifications and block malicious activity.
• Reverse proxies and content delivery networks can detect and alert organizations to changes in scripts.

Again, one of the main challenges is understanding and tracking frequently updated third-party and fourth-party scripts like advertising and tracking scripts and tag management systems. The marketplace is building out tools and service provider offerings to automate this process, but a simple approach involves using an open-source tool such as Curl to perform a weekly check of webpage code for any changes. Requirement 11.6.1 will remain a best practice until March 31, 2025, when it becomes mandatory. The extended timeline gives organizations time to inventory and implement control of their payment page scripts.

The takeaway

PCI DSS v4.0 brings substantial changes to the security landscape for e-commerce businesses. While imposing stricter requirements and accountability measures, the standard ultimately aims to enhance the security of CHD in an evolving threat environment. E-commerce companies must adapt to these changes to ensure compliance, protect customer data and maintain trust in their online platforms. Achieving compliance with PCI DSS v4.0 will require significant effort and investment, but the benefits of improved security and reduced risk of data breaches make it a worthwhile endeavor.