Back in April 2022, I published PCI DSS 4.0; It's time to get serious on Magecart, and I was seriously impressed with the stance that the PCI SCC were taking against Magecart and other JS based threats. In this last week, PCI DSS v4.0.1 has been published with a few changes to key sections that I spoke about previously, so let's delve into what those changes are, and what the impact is.
PCI DSS v4.0
If you aren't familiar with the significant changes that came with PCI DSS v4.0, you really should read PCI DSS 4.0; It's time to get serious on Magecart. That blog post goes into detail on what the major new requirements were, and why I was so happy to see them. While we'll be referring back to the new requirements introduced in 4.0 in this blog, I will be focusing mainly on the key changes introduced in the 4.0.1 update.
PCI DSS v4.0.1
Only being a week or two old, the v4.0.1 standard is still quite fresh, but the textual changes aren't significant. As you can probably tell from the new version number, the textual changes are actually quite small, but those small changes do have a significant impact on the strength of the new requirements. I'll be focusing on changes to the 6.4.3 and 11.6.1 requirements in this post, and those requirements largely focus on mitigating Magecart and other JS based threats that exist on payment pages.
Requirement 6: Develop and Maintain Secure Systems and Software
6.4 Public-facing web applications are protected against attacks.
As one of the first major requirements that was designed to tackle the problem of Magecart and other JS based threats head on, requirement 6.4.3 was pretty strong. Here's the original text from the 4.0 version:
- 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.
This leaves little room for interpretation, but to ensure that there was no room for interpretation, the PCI SSC even defined the word "necessary", here with my own highlight.
Definitions
“Necessary” for this requirement means that the
entity’s review of each script justifies and confirms
why it is needed for the functionality of the
payment page to accept a payment transaction.
The script had to be necessary to accept a payment transaction, otherwise, it had to go. That would mean a huge reduction in the amount of JS on payment pages, and thus, a huge reduction in the amount of risk. Less JS, more better!
Now that we've summarised requirement 6.4.3 in the 4.0 document, let's take a look at what 6.4.3 looks like now in the 4.0.1 document, with the important change highlighted.
- 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 business or technical justification as to
why each is necessary.
That's a definite softening of the requirement there and this was largely based on feedback from the industry that as previously worded, we wouldn't be allowed a whole bunch of JS on the payment page that was previously allowed. We wouldn't be able to have tracking or marketing tools, or chat bots, or widgety do-hickey things that do 'stuff', leaving us only with the JS needed to process the payment. To my mind, and as stated in my previous post, this massive reduction in JS on this one page was the main benefit of the requirement. By taking such drastic measures to reduce the amount of 3P JS, we were drastically reducing the risk too.
Alongside the change to the requirement, the definition of the word "necessary" was also removed. If we look at the 'Summary of Changes' document that the PCI SSC published, they state:
Remove Definitions that explain what “necessary” means for this requirement (“needed for the functionality of the payment page to accept a payment transaction”).
It is a shame to see such a softening of the requirement based on pressure from the industry, especially when it would have been so effective at mitigating the attacks it set out to mitigate, but this is where we currently stand.
Requirement 11: Test Security of Systems and Networks Regularly
11.6 Unauthorized changes on payment pages are detected and responded to.
After being concerned about the changes to requirement 6.4.3, I was a little worried that requirement 11.6.1 might also face a similar reduction in the strength of the protections. I'm glad to say that this isn't the case and the changes here are a welcome clarification to the wording of the requirement. Looking at the text from the 4.0 document, we had:
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 consumer browser.- The mechanism is configured to evaluate the
received HTTP header and payment page.
This was clearly aimed at requiring the monitoring of a CSP header if that is the mechanism the site was using to control JS on the payment page. The problem was, the wording of the requirement didn't quite specify that and it left it open to interpretation that all HTTP headers needed to be monitored. It also sounded like the requirement had us monitoring all of the content of a payment page, rather than just the script content. In light of that, the text was updated as follows, highlight mine:
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 security-
impacting HTTP headers and the script contents
of payment pages as received by the consumer
browser.- The mechanism is configured to evaluate the
received HTTP headers and payment pages.
This is a welcome change to the wording of the requirement and now makes it much easier for me to explain to those seeking to comply with the standard that measure we had in place at Report URI were already sufficient. Using our CSP reporting service, we can already monitor the content of the CSP response header as a copy is sent with the report, but, the content of other HTTP response headers is not sent, meaning we can't monitor those!
Summary
In short, I do feel that the requirements as they stand in the v4.0.1 standard are still going to help to significantly impact the effectiveness of attacks like Magecart and others, but just not quite as much. I was a little disappointed to see that pressure from the industry has lead to a softening of 6.4.3 in terms of what JS is allowed on the payment page, and I have faced a lot of that pressure myself in my role at Report URI. When helping organisations move towards complying with 6.4.3, there was often a lot of resistance to reducing the amount of JS on the payment page. The sales and marketing teams wanted their tracking and analytics, support wanted their chat bots, and, often, the biggest issue is that all JS is just baked into all pages across the site and changing that would be a task in itself.
Still though, I feel that the payment page doesn't hugely benefit from having any of those things present, and for the sake of cleaning up the sheer amount of JS on one page of your site, we've lost the sharp edge that this requirement previously had to cut through the risk!
PCI DSS Compliance
If you'd like help with meeting the new PCI DSS v4.0.1 requirements, specifically 6.4.3 and 11.6.1, then check out Report URI and our PCI DSS Compliance page that gives all of the information on how we can help you. You can sign up for a free trial, with no commitment, and reach out to me if you need help getting started.
Links
PCI DSS v4.0.1 document
PCI DSS v4.0 -> 4.0.1 Summary of Changes document
PCI DSS v4.0 document