.svg){kind=icon}
.svg)
Executive Summary
Redirecting to a hosted payment page is an evolution of payment security employed by many merchants to reduce risk to card data and their PCI DSS assessment scope . PCI DSS v4.0 brings many changes associated with this method of payment processing. To prepare for full PCI DSS v4.0 compliance, e-commerce merchants are urged to work with their web and payment providers to confirm the following:
- Payment pages only load the scripts necessary for their operation.
- Payment pages restrict the scripts that load, such as CSP.
- Payment pages check the integrity of scripts, for example, with Sub-resource Integrity (SRI).
- The HTTP headers and active content of payment pages, as received by the consumer browser, are monitored, and personnel are alerted to unauthorized modifications (including known indicators of compromise, changes, additions, and deletions). For example, with CSP reporting.
PCI DSS major upgrades can be daunting for merchants and can place additional demands on already busy IT and security departments. VikingCloud has helped clients transition to all versions of PCI DSS, and our PCI experts are ready to answer your questions.
Introduction
Historically, the payment brands considered the risks of using redirects to a hosted payment page and said, We've got bigger fish to fry, and they did. Nearly all e-commerce merchants have moved away from managing the payment phase and are redirecting cardholders to hosted payment pages or iFrames. The criminals have followed the money, or in this case, the change to how sensitive data is handled, and have started to attack the redirect and iFrame implementations.
Version 4.0 of the PCI DSS Self-Assessment Questionnaires (SAQs) was released in April 2022 and had an additional update in December 2022. With those releases, a major update was made to SAQ A, which applies to merchants that are utilizing URL redirects to a PCI DSS compliant payment service provider's (PSP's) hosted payment page (see illustration below left) or that embed an iFrame(s) of the PSP's hosted payment form (or hosted fields) as part of their card not present, e-commerce payment acceptance channel.
2014's SAQ A v3.0 did not include any technical security measures to protect merchant e-commerce websites from the types of attacks being perpetrated against merchant websites utilizing URL redirects or iFrames (see illustration above right). However, each subsequent version of SAQ A has included some technical controls for the protection of the merchant website , in recognition of the increasing prevalence of attacks against merchant websites that outsource all capture and processing of account data.
With the advent of PCI DSS v4.0, five additional technical requirements related to vulnerability management and the protection of redirect/iFrame scripts and payment headers received by the cardholders browser, as well as further access control measures to protect the merchant webserver, have been added to SAQ A. These requirements have been added based on the most common attack vectors used that have led to breaches in these types of environments.
Recently Released Revisions to the SAQ A v4.0 further clarified the applicability of these additional requirements, with updates in the Merchant Eligibility Criteria section and the Notes and Completion Guidance.
SAQ A Applicability Notes
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 do not receive account data.
According to the SAQ A applicability notes, the controls are focused on the system hosting the iFrame or redirect mechanism or providing the scripts for the iFrame or redirect to the cardholder's browser. One of the identified challenges is that a third party usually manages these systems, and the merchant will have to ensure these third parties implement the controls and- /or get their permission to implement the applicable controls.
Attacks have been made against web-redirection servers, where the systems have had exploitable vulnerabilities that the merchant has not noted due to gaps in the vulnerability management program. Once compromised, the payment page scripts have been amended or replaced, and cardholder data entered by the consumer has been directed outside of the PSP's Cardholder Data Environment (CDE) and ultimately back to the attacker (as illustrated in the URL redirect attack above).
Attacks have also been performed by modifying the iFrame scripts running in the client browser (illustrated below). Instead of loading scripts from the PSP's domain, the client browser loads scripts from an attacker-controlled domain. The attacker still allows for the loading of an iFrame displaying the PSP's payment form/fields but with an additional attacker skimmer script running in the same iFrame context, giving the script access to the entered card data.
Vulnerability Management
With the v4.0 changes, SAQ A eligible merchants now need to ensure that security vulnerabilities are proactively being identified and managed through a process of risk ranking vulnerabilities to prioritize addressing the highest risk items affecting their website(s)/webserver(s) (6.3.1). SAQ A already expected the merchant's e-commerce system components and software to be protected from known vulnerabilities by installing applicable critical or high security patches/updates to address known vulnerabilities (6.3.3).
As a part of, and as a mechanism to monitor the effectiveness of, vulnerability management, merchants also need to perform external vulnerability scanning as follows:
- External vulnerability scans performed by a PCI Approved Scanning Vendor (ASV) are completed at least once every three months (11.3.2).
- External vulnerability scans are performed after any significant change (11.3.2.1).
The PCI DSS section 7 now provides a definition of significant change that will trigger the requirement to complete additional external vulnerability scans. Significant changes can include replacement or major upgrades of hardware and software or changes to third-party vendors/service providers (or the services provided). The scans required by 11.3.2.1 must be performed by qualified personnel with organizational independence (i.e., they are not involved in managing the system being scanned) and do not require the use of a Qualified Security Assessor (QSA) or an Approved Scanning Vendor (ASV).
Requirements 6.3.1, 11.3.2, and 11.3.2.1 are not new to the PCI DSS and are applicable as soon as an SAQ A eligible e-commerce merchant performs validation using PCI DSS v4.0. However, merchants undertaking their first SAQ A v4.0 self-assessment are not expected to have completed four passing ASV scans in the preceding 12 months, as long as the most recent scan result was passing. The merchant will need to have policies and procedures in place to ensure scanning is completed in the required timeframes, such that for subsequent assessments, they can report that passing ASV scans have occurred at least once every three months.
The targets for the external vulnerability scans need to include the web redirection servers, i.e., those servers that host the redirection mechanism or iFrame integration. These controls previously only applied to the hosted payment pages provided by the acquirer or the internet payment service provider (iPSP) / Hosted Payment Pages Provider. The challenge VikingCloud has seen is that most merchants outsource their e-commerce websites and their management to a third party that is not PCI DSS compliant and will need to rely on these third parties to achieve the required passing ASV scans and related vulnerability management processes, including them in the merchant assessment.
The intent of 11.3.2 is to achieve a passing ASV scan at least once every 90 to 92 days (or on the nth day of each third month), and this can be achieved by performing an initial scan that is passing or an initial scan that is failing, and then a re-scan that shows that any findings assigned a CVSS base score of 4.0 or higher in the initial scan are remediated.
When Do You Need to Start?
The recommendation is to enhance the vulnerability identification and management process and start to perform ASV scans as early as possible.
Ensure that the process to perform ASV scans and handle the outcome is started on or before March 31, 2024, at the latest.
Next Steps:
- Work with your third-party providers, IT department, and QSA to define the scope of the external vulnerability scans. Confirm the scope as a part of the attestation that needs to be performed with your ASV scan provider.
- The minimum requirement is to run these scans at least once every three months, and this will meet the minimum intent. The challenge is that it reduces the time to remediate high and critical findings. The recommendation is to run the scans monthly. As a merchant, you should find a vendor that includes monthly and on-demand scanning as needed.
- Ensure that you have a process where the outcome of the scans is reviewed and, when needed, remediated and that the process includes your third-party providers and IT department as needed.
- Define the policy and procedures to include the cadence of the scans, which should be set to a maximum of 90 days apart. Also, ensure that the procedures require that discovered vulnerabilities are remediated, and re-scans are performed as needed.
- Define the policy and procedures to ensure that upon completion of a significant change, the applicable in-scope systems are scanned for external vulnerabilities, with identified vulnerabilities with a CVSS score of 4.0 or higher resolved and re-scans performed.
Note: If you are setting up ASV scans to run against your third-party service provider (TPSP) systems, you must check that you are allowed to do so.
Inventory and Integrity of Payment Page Scripts
In recent years, we have seen the successful compromise of redirect and iFrame implementations, and during these compromises, the payment page scripts have been changed or additional scripts have been added. Â The criminals succeed in skimming the submitted cardholder data for many months at a time, as these compromises are often completely transparent to both merchants and cardholders, with transactions still being processed and purchases completed. The risk and ease of detection are now considered and are reflected in the v4.0 SAQ A. Â Revisions of the SAQ A since its original release confirm applicability as websites that use iFrame integrations, as these types of attacks are harder to detect on embedded iFrames rather than URL redirects. The new controls focus on reducing the risk of these types of compromises by preventing the loading and execution of unauthorized scripts on the payment page.
Comparing the SAQ A April 2022 release and the December 2022 release applicability notes:
- April 2022: For SAQ A, Requirement 6.4.3 applies to the page(s) on the merchant's website(s) that provides the address (the URL) of the TPSP's payment page/form to the merchant's customers.
- 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).
Based on this update, it is evident that the focus is reducing risk on iFrame implementations. Payment page scripts for e-commerce websites that use iFrames need to be managed as follows (6.4.3):
- Only utilize authorized scripts on the payment page.
- Ensure that the integrity of the scripts is maintained.
- Maintain an inventory of the approved payment page scripts with a justification on why they are needed for the functionality of the merchant's payment page.
The scope of this requirement includes all scripts loaded from the merchant's e-commerce environment and scripts loaded from third and fourth parties (such as scripts for ads, analytics, social media sharing buttons, chat functions, etc.).
This requirement is considered best practice until March 31, 2025, after which it must be fully implemented for an entity that is maintaining compliance with PCI DSS and if it is applicable to the merchant e-commerce environment.
Next Steps:
- Perform an inventory of the payment page scripts in use. This can be done remotely or by retrieving data from the local system.
- Create a process whereby all payment page scripts are authorized upon implementation to ensure that scripts cannot be added to payment pages without the relevant approval
- Check the integrity of the scripts using a local FIM or by checking the integrity remotely.
The type of solution to be implemented depends on what payment page scripts are loaded. If third-party scripts are loaded, they need to be covered as well. Both commercial and open-source tools are available.
Detect and respond to unauthorized changes on payment pages
For iFrame implementations where the hosted payment page (or hosted fields) is integrated into the e-commerce site, it's hard for the end user/cardholder to detect malicious behavior. Traditional change detection mechanisms are ineffective for modern, dynamic websites that heavily rely on externally hosted code and third/fourth-party scripts, especially when client-side code often changes as the web page is constructed and JavaScript is interpreted by the consumer browser. This is why iFrame implementations are also subject to the additional controls of requirement 11.6.1 for a change- and tamper-detection mechanism for payment pages to:
- Alert personnel to unauthorized modification of HTTP headers and the contents of payment pages as received by the consumer browser.
- Evaluate the received HTTP header and payment page.
- That is performed at least once every seven days, at a minimum, or as per a frequency determined by a targeted risk analysis.
These requirements are considered best practice until March 31, 2025, after which it must be fully implemented for an entity that is maintaining compliance with PCI DSS and if it is applicable to the merchant e-commerce environment.
Although SAQ A does not require it, it is recommended that merchants update their incident response plans (per requirement 12.10.5) to include monitoring for and responding to alerts from the change- and tamper-detection mechanism for payment pages.
There are multiple ways to implement controls to mitigate client-side risks associated with unauthorized changes on payment pages and meet the intent of the requirement. Note that intent of requirement 11.6.1 is utilization of tools and techniques to detect and alert on unauthorized modification to the HTTP headers and to the contents of payment pages as received by the consumer browser; this does not mean installing software on the consumer's system or browser.
Next Steps:
- Consider the implementation of Content Security Policies (CSP) on the relevant payment pages.
- Monitor the received pages and analyze them to detect if there have been any changes performed.
- Consider other technologies such as implementation of tamper-detection scripts on the payment page, external monitoring, reverse proxies, etc.
For more information and guidance on ensuring your organization is PCI compliant read more here or contact our team for more information.
.webp)
