Tuesday, 7 February, 2023 UTC
Summary
“I don’t have full control and visibility of third-party scripts on my website.”
That is the most common concern we heard from security and risk professionals at PCI London 2023. The event’s theme: “Unravelling PCI DSS 4.0: Making the Great Leap Forward,” was spot-on as many people we encountered wanted to understand how new requirements would impact their business. Specifically:
- Requirement 6.4.3 demands that entities manage the JavaScript in payment pages. All JavaScript must be detailed in an inventory, be necessary for the payment page, be approved, and its integrity is assured.
- Requirement 11.6.1 requires changes to scripts and page headers to be detected on payment pages, and the appropriate alerts generated.
A complete risk analysis of third-party JavaScript is essential to charting a path toward 4.0. But for most, this work can seem daunting. Client-side security (or what happens in the user’s browser) has typically been a low priority and not well understood. Our advice is to start with the fundamentals:
- Identify all third-party JavaScripts running on your websites and web apps;
- Understand what they’re doing and why, and;
- Determine which Scripts should be allowed to access data in forms on payment pages and stop ones that shouldn’t from doing so.
Why is this important? The client-side is essentially the Wild Wild West of cybersecurity – a mostly untamed frontier that presents a huge vista of risk. While network and server security has experienced much progress over the last decade, there is a certain state of lawlessness associated with the user’s browser - even though organizations can be held responsible for data leakage.
A recent survey showed that 99% of security professionals reported their website uses at least one third-party script and more than 50% believed there was some or lots of risk associated with it. Yet over 50% stated that the third-party scripts running on their web properties change four or more times every year but only 34% of respondents said they have the ability to detect changes or updates.
This supports a recent study Jscrambler conducted of 20 highly trafficked e-commerce websites in the US. One site had 249 third-party Scripts being loaded on the payment page. Another had 118 third-party domains receiving data from the payment page.
It seems impossible to imagine a world where security teams would let third-party code libraries run amok on their servers. Yet that is precisely what happens on websites every day. The attack surface has silently moved from the confines of corporate infrastructure that InfoSec teams can control into the consumer browser.
It’s time to change that, whether PCI DSS v4 is a concern or not.
Consider this: Requirements 6.4.3 and 11.6.1 won’t be enforced until April 1, 2025, but data is being stolen every day. Lots of it. A recent study showed that in Q3 2022, nearly 109M accounts were breached (a 70% increase over the prior quarter) or 14 accounts every second. Consider how much sensitive data people enter into websites every day. It’s time to stop the leakage, especially where payment data is a concern.
It can take two years or more to implement a solution that will align with the new PCI DSSv4 standards. For many large enterprises, the timeline will look like this:
- 2023 - identify gaps and analyze risk, investigate vendor solutions;
- 2024 - get the budget and resources needed, implement a solution and refine it;
- April 1, 2025 - be prepared to meet the new standards.
We suggest now is the time to start preventing skimming attacks, and other accidental forms of data leakage through the browser, so that you are ready for 4.0 but just as importantly, start reducing your risk sooner than later.
FAQs
1. What are the two new requirements to prevent and detect e-commerce skimming attacks?
1- Requirement 6.4.3 (Preventative)
The first new requirement is designed to minimize the attack surface and manage all JavaScript present on the payment page by requiring an approval process and justification for each script added to the payment page. It is designed to ensure that all JavaScript included in the payment page is actively managed. Additionally, the requirement wants a way of validating the integrity of a script to be defined, to ensure that malicious scripts are not placed on the payment page.
The first new requirement is designed to minimize the attack surface and manage all JavaScript present on the payment page by requiring an approval process and justification for each script added to the payment page. It is designed to ensure that all JavaScript included in the payment page is actively managed. Additionally, the requirement wants a way of validating the integrity of a script to be defined, to ensure that malicious scripts are not placed on the payment page.
2 - Requirement 11.6.1 (Detective)
The second new requirement aims to detect tampering or unauthorized changes to the payment page which can be indicative of a skimming-type attack. In addition to detecting changes, the requirement demands that an alert is generated when such changes are detected. There is no requirement to block changes or malicious activity, just to raise an alert.
The second new requirement aims to detect tampering or unauthorized changes to the payment page which can be indicative of a skimming-type attack. In addition to detecting changes, the requirement demands that an alert is generated when such changes are detected. There is no requirement to block changes or malicious activity, just to raise an alert.
2. How can E-commerce websites meet the new requirements?
To meet these two new requirements, e-commerce companies must focus on:
- Gaining visibility of the JavaScript that’s loaded into their webpages
- Managing the risk associated with each script: Where does it come from? What does it do?
- Having control of JavaScript, so that malicious scripts can be blocked or deactivated
3. The business impact of version 4.0 - Why should companies worry now?
Any organization that wants to accept a transaction with a payment card issued by a PCI SSC participating card brand is required to sign a contract that will contain references to the card brand’s rules which will specify that:
- The organization has to comply with PCI DSS;
- The organization has to make sure that all of their third-party service providers that can affect the security of cardholder data comply with PCI DSS.