If you've ever taken a credit card as payment for anything, then you've probably heard of the Payment Card Industry Data Security Standard (PCI DSS). This defines a set of requirements for merchants and service providers to protect their customers' payment card data. The importance of PCI DSS lies in the fact that it helps to protect sensitive data which could have huge ramifications should it fall into the wrong hands. This includes information such as credit card numbers, names, addresses, and other personally identifiable information.
PCI DSS compliance is mandatory for all merchants that accept credit card payments, and failure to comply can result in fines, legal liability, and damage to a company's reputation. Therefore, companies need to understand the requirements of the standard and take the necessary steps to ensure compliance. The PCI Security Standards Council periodically updates the standard to keep up with the changing threat landscape and technological advancements.
This blog post will focus on a particular change regarding scripts on payment pages that has been introduced as a requirement in PCI version 4.0.
What is ASV Scanning?
ASV scanning stands for "Approved Scanning Vendor" scanning. It is a cybersecurity process used by organisations to ensure that their network and web applications are secure and compliant with industry standards such as the Payment Card Industry Data Security Standard (PCI DSS).
This involves conducting initial scans to identify any weaknesses in external systems, networks, and web applications, followed by quarterly scans to ensure ongoing compliance. These scans must be carried out by an approved scanning vendor (ASV), as outlined in requirement 11.3.2 of version 4.0 of the PCI DSS Requirements and Testing Procedures documentation.
This requirement specifies that all internet-facing components you own or utilise as part of your cardholder data environment (CDE), as well as any externally facing system components that may provide access to the CDE, must be scanned via IP addresses and any relevant Fully Qualified Domain Names (FQDN).
In other words, organisations must ensure that their externally facing devices are regularly scanned by an ASV provider for weaknesses, and any vulnerabilities must be patched or remediated to protect the host. Depending on the scope in question, engagements are typically conducted in one day, and reports follow shortly after.
Significant Change for PCI 4.0
The latest ASV Program guide (4.0) was released in June 2022 and contained a new requirement (6.4.3) that payment page scripts that are loaded and executed in the consumer’s browser must now be scanned. This regulation is intended to ensure unauthorised code cannot be present on the payment page of your web application as it is rendered. Whilst these changes are currently recommended as security best practice, they will become mandatory from 31st March 2024.
All payment page scripts that are loaded and executed in the consumer’s browser must be managed as follows:
- A method is implemented to confirm that each script is authorised.
- 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.
Payment Page Scripts Management and their Purpose
Online shopping has become a way of life for many people around the world. As such, online stores must ensure their payment pages are secure and easy to use. This is where payment page scripts come in.
Payment page scripts are essential for managing and securing the payment process on a website. They are responsible for facilitating secure transactions between buyers and sellers by encrypting sensitive information such as credit card details. These scripts also help to streamline the payment process, making it quick and easy for customers to complete their transactions. They also enhance the user experience by providing useful features like dropdown menus and autocomplete fields, reducing the need for repetitive tasks like form filling. Although these external scripts may seem harmless, they can be exploited by attackers to load malicious scripts that could potentially steal sensitive information.
For businesses without a dedicated IT team, managing payment page scripts can be challenging. That is why it's important to understand the purpose of these scripts and how to manage them effectively.
Taking an Inventory - Steps to Manage Payment Page Scripts
Part of the process of managing the scripts relevant to your payment page is to take an inventory. The following steps are recommended:
- Identify all of the scripts that are currently in use: This can be done by speaking with team members, checking version control or file systems, and reviewing any documentation that might exist.
- Categorise scripts by type and purpose: Determine the types of scripts that exist (e.g., data processing, automation, monitoring, etc.) and then categorise them based on their purpose (e.g., production vs. development, critical vs. non-critical, etc.).
- Assign ownership: Determine who is responsible for each script and ensure that they are aware of their responsibilities.
- Document scripts: Ensure that each script has a clear description of its purpose and instructions for use. This documentation should be kept up-to-date as scripts evolve. This is also specifically mentioned in the requirements.
- Regularly review scripts: Establish a regular review process to ensure that scripts remain relevant, effective, and secure. This should include updating documentation and ensuring that scripts are still meeting their intended purpose.
Best Practice when Mitigating the Risk of Being Non-Compliant
To mitigate the risk of attacks, it is crucial to ensure that the functionality of all scripts used in the payment page is fully understood. By doing so, the number of scripts that could potentially be tampered with is reduced. Additionally, it is important to ensure that all scripts used in the payment page are explicitly authorised and that any unnecessary scripts are not added without proper management approval.
The following mechanisms can help ensure that scripts used on payment pages are not tampered with and are not used to steal sensitive payment information.
What is Sub-resource integrity?
Sub-resource integrity (SRI) is a security feature that allows the browser to verify that the content of a script or other resource has not been tampered with. This is done by generating a cryptographic hash of the resource and embedding it in the HTML code that references it. When the resource is loaded, the browser can verify that the hash matches the expected value, ensuring that the resource has not been modified in transit. SRI can be used to enforce the integrity of scripts used on payment pages, ensuring that any scripts loaded on the page have not been tampered with.
What is Content Security Policy?
Content Security Policy (CSP) is another mechanism that can be used to enforce the integrity of scripts used on payment pages. CSP allows website administrators to specify which sources of content are allowed to be loaded and executed on a web page. This includes scripts, stylesheets, images, and other resources. By limiting the sources from which scripts can be loaded, CSP can help prevent malicious scripts from being loaded and executed on payment pages. This can also prevent attacks like cross-site scripting (XSS) and data exfiltration.
Proprietary script or tag-management systems
Proprietary script or tag-management systems can also be used to enforce the integrity of scripts used on payment pages. These systems allow website administrators to manage and control the scripts and tags that are loaded on their web pages. They can prevent unauthorised scripts from being loaded and can also provide real-time monitoring and alerts for any suspicious activity. These systems can help prevent attacks like code injection and data exfiltration and can also provide additional visibility into the security posture of the payment page.
How can LRQA help with ASV Scanning?
LRQA is an approved scanning vendor that boasts a team of highly qualified ASV professionals. We are equipped with the best tools and technologies to perform thorough scans that meet the Payment Card Industry Security Standards Council (PCI SSC) ASV program baseline requirements. One of the key advantages of working with LRQA is that we provide real-world remediation advice and guidance to help you achieve compliance, particularly in cases of failed scans.
We have observed issues with third-party software that, whilst not a failure today, would not be compliant when PCI 4.0 goes into effect. This includes software provided by some of the largest tech and e-commerce companies within the industry. Getting a head start now on documenting and working with vendors should put you in a much better position before the changes come into effect.
LRQA's approach goes beyond the standard requirements of the ASV program, with a manual validation process ensuring that any failing vulnerabilities are thoroughly checked and verified.
Additionally, we work closely with clients to establish any false positives before generating the final report.