What exactly is a Payment Page?
The applicability of requirements 6.4.2 and 11.6.1 (PCI DSS 4.0)
There’s much discussion about the two new requirements in PCI DSS 4.0 that aim to prevent and detect e-commerce skimming attacks (6.4.3 and 11.6.1). These are my favourite new requirements in version 4, but what they apply to can be quite confusing based on the different ways people build their e-commerce websites and the differences between SAQs and the standard.
For a general introduction to these requirements, I’ve written about them on the Jscrambler blog, or if you prefer a video, that’s here.
In this article I’m just going to discuss the applicability of these two requirements to different acceptance scenarios and merchant levels. Please remember that everything that follows is just my opinion / interpretation of the standard and the associated documents. You should always consult your assessor or compliance accepting entity (i.e. your acquirer, or the card brands).
1. The Payment Page
The two new requirements apply to JavaScript included in the “Payment Page”. What constitutes a Payment Page seems to be the subject of much unnecessary debate because this is defined in the PCI DSS 4.0 Glossary which is in Appendix G
of the standard.
A web-based user interface containing one or more form elements intended to capture account data from a consumer or submit captured account data. The payment page can be rendered as any one of:
- A single document or instance,
- A document or component displayed in an inline frame within a non-payment page,
- Multiple documents or components each containing one or more form elements contained in multiple inline frames within a non- payment page.
The definition is quite wide to describe in general terms the ways that people interface to their payment processor / payment service provider (PSP) or acquirer. Here’s a slide taken from my Pluralsight course
that perhaps explains it better:
When the fields that collect the cardholder data are contained in an iframe, it is the contents of the iframe (which contains the form elements ) that comprise the Payment Page (in cyan), not the page that the iframe is embedded in, which I’m going to call the Parent Page (in orange).
The reason for this distinction is that JavaScript running in the Parent Page cannot generally (see 1.1 below ) access anything in the iframe.
So if the Parent Page contains skimming JavaScript, it can not get to the cardholder data entered into the form fields – but there are lots of things it can do, which I’ll come to next.
So for clarity, requirements 6.4.3 and 11.6.1 only apply to the Payment Page. And many merchants don’t have a Payment Page themselves, because they load one from a PSP embedded in an iframe, or multiple iframes (one frame per field).
1.1 JavaScript Attacks in the Parent Page
Although JavaScript running in the Parent Page is not able to access the cardholder data entered into the fields in an iframe, it can launch other attacks. The most common is what’s known as a frame-overlay attack, where the criminal overlays their own payment page over the PSP’s. The customer enters their cardholder data into the form fields generated by the criminal, which steal the data and respond with a message saying there was a problem, and that the customer should try to enter their cardholder data a second time, which will then be into the legitimate PSP Payment Page and so the transaction happens normally.
The second form of attack is similar, but here the criminal creates a fake payment form on a page before the actual Payment Page (typically the basket summary). The customer enters their data and when the transaction “fails” the legitimate payment form appears.
There’s a final type of attack that was described by Security Metrics at the 2022 PCI Community Meeting. This attack uses a compromise of the merchant’s web server and a vulnerability with the PSP’s Payment Page to defeat the browser’s same origin policy and so enable a JavaScript skimming attack.
In summary, JavaScript in the Parent Page is not as bad as JavaScript in the Payment Page, but it is a growing attack vector, which I guess is why an acknowledgement of this was made in SAQ A.
2. SAQ A and the New Requirements
If a merchant is allowed by the card brands to self-assess its PCI DSS compliance, it completes a self-assessment questionnaire (SAQ). Merchants that use a PSP’s Payment Page embedded in one or more iframes are typically eligible to complete SAQ A.
If you look at SAQ A, you will see that the two new requirements 6.4.3 and 11.6.1 are included in it. Which should give rise to some cognitive dissonance, because to be eligible for SAQ A, the merchant doesn’t have a Payment Page, just a Parent Page! And as we discovered above, these two new requirements only apply to Payment Pages, not to Parent Pages.
This dissonance is fixed by some helpful notes in SAQ A.
Firstly in the eligibility criteria on Page iii.
For this SAQ, PCI DSS Requirements that address the protection of computer systems (for example, Requirements 2, 6, 8, and 11) AND requirements that refer to the “cardholder data environment” apply to the following e-commerce merchants:
- Those that redirect customers from their website to a TPSP/payment processor for payment processing, and specifically to the merchant web server upon which the redirection mechanism is located.
- Those with a website(s) that includes a TPSP’s payment processor’s embedded payment page form (for example, an inline frame or iFrame), and specifically to the merchant web server that includes the embedded payment page/form.
These PCI DSS requirements are applicable because the above merchant websites impact how the account data is transmitted, even though the websites themselves do not receive account data.
And now looking at requirement 6.4.3 there is a note:
For SAQ A, Requirement 6.4.3 applies to a merchant’s website(s) that includes a TPSP’s payment processor’s embedded payment page form (for example, an inline frame or iFrame).
And similarly for requirement 11.6.1:
For SAQ A, Requirement 11.6.1 applies to a merchant’s website that includes a TPSP’s payment processor’s embedded payment page form (for example, an inline frame or iFrame).
So for merchants completing SAQ A, the two new requirements do apply , but to the Parent Page hosting the iframe(s).
Of course they also apply to the Payment Page delivered by the PSP, but that’s the PSP’s responsibility.
3. SAQ A-EP and the New Requirements
SAQ A-EP was designed for merchants that generate the Payment Page themselves, but the cardholder data entered by their customer is posted directly to the PSP, and doesn’t touch the merchant’s web server.
It came about (in PCI DSS 3.0) because when this architecture was developed, merchants argued that because nothing in their environment stored, processed or transmitted cardholder data, they had no applicable PCI DSS requirements. Back in 2015 when version 3 was released, it was obvious that this would lead to skimming attacks by criminals compromising a merchant’s web sever and adding skimming JavaScript to the Payment Page. So SAQ A-EP brought some requirements back to merchants using this type of architecture.
Therefore requirements 6.4.3 and 11.6.1 are included in SAQ A-EP because the merchant generates the Payment Page.
4. Merchants that need an Onsite Assessment
Large merchants, who the card brands decide
are too big to complete an SAQ, need an onsite assessment by an ISA or QSA, resulting in the production of a Report on Compliance (RoC) in which all 240 PCI DSS requirements are assessed.
And here’s where the applicability of these two new requirements gets very interesting for large merchants who use an embedded iframe or iframe(s) from a PSP.
There are two assessment options.
4.1 Option 1:
Requirements 6.4.3 and 11.6.1 are “Not Applicable”.
Requirements 6.4.3 and 11.6.1 don’t apply to the merchant’s Parent Page because it isn’t a Payment Page, and these two requirements deal with JavaScript in Payment Pages.
However, it is going to be hard to argue that the the merchant’s Parent Page and web server would entirely be out of scope of other PCI DSS requirements because although they do not store, process or transmit cardholder data, it is pretty clear that they could “impact the security of the CDE ”.
I guess that most assessors would determine that the merchant’s web server and therefore the Parent Page should be included in the scope of the assessment for applicable requirements as determined by the assessor.
What is perhaps strange here is that requirements 6.4.3 and 11.6.1 will always be not applicable because there is no Payment Page, BUT potentially all the other PCI DSS requirements will be applicable.
It would be a courageous
assessor who would agree to completely descoping the merchant environment in this scenario, determining that no PCI DSS requirements were applicable. If the argument is that the use of the iframe completely segments the cardholder data environment from the merchant’s environment that would need to be penetration tested per requirement 11.5.5.
4.2 Option 2:
Base the assessment on SAQ A
There’s a PCI SSC FAQ 1331 that allows a onsite assessment to be based on an SAQ, if:
- The merchant fully meets the eligibility criteria of the SAQ, and
- The merchant has agreed this approach with their acquirer, and
- The assessor is able to test, validate and document that the merchant meets each of the eligibility criteria.
A large merchant who uses one or more embedded iframes from a PSP could just ask their assessor to test the requirements in SAQ A if they fulfilled the above criteria. And, of course, requirements 6.4.3 and 11.6.1 would then apply to the Parent Page (because that is what SAQ A requires). In my experience this “follow SAQ A” is the approach adopted by most large merchants who use an embedded Payment Page from a PSP.
5. Summary
If the above has hurt your brain, I’m sorry. It’s not easy: if only everyone accepted payments the same way and the SAQs didn’t exist, or if the standard had also applied the new requirements to the Parent Page, rather than it being a special case described in a note in SAQ A.
I’ll try to make this simple and summarise the applicability of the two new requirements 6.4.3 and 11.6.1 to merchants and to PSPs where the merchant embeds a PSP’s Payment Page in one or more iframes in a Parent Page generated by the merchant.
5.1 PSP
Validation: RoC or SAQ D
6.4.3 & 11.6.1 apply to: Payment Page
5.2 SAQ-eligible merchant
Validation: SAQ A
6.4.3 & 11.6.1 apply to: Parent Page
5.3 SAQ-ineligible merchant
5.3.1 Option 1
QSA or ISA determines that the merchant’s website in scope because it is considered security-affecting.
Validation: RoC
6.4.3 & 11.6.1 apply to: Nothing, there is no Payment Page. They would be marked “Not Applicable” by the assessor.
5.3.2 Option 2
Merchant meets the eligibility criteria of SAQ A and follows PCI SSC FAQ 1331.
Validation: Partial RoC based on the requirements in SAQ A
6.4.3 & 11.6.1 apply to: Parent Page
6. Conclusion
I suspect that Option 2 above will be the most popular. Which means that for the vast majority of merchants it doesn’t matter whether you use a PSP’s Payment Page in an iframe, or you make your own Payment Page, these two new requirements will apply.
In most organisations I’ve looked at, client-side JavaScript is unmanaged and out of control. Getting hold of it is the first stage in being able to comply with these requirements. I’ve written about that challenge on the Jscrambler blog.