- This post focuses on the new Payment Card Industry Data Security Standard version 4 (PCI DSS v4) and its impact on scripting within your environment.
- We discuss the key role scripts play in online shopping and payments, and the security threats they may pose if not properly secured.
- Two major controls introduced in PCI DSS v4 to combat these threats are Control 6.4.3 and Control 11.6.1, which require businesses to track and validate authorized scripts, and to alert about unauthorized changes to HTTP headers.
- We compare solutions including developer tools, in-house parsing tools, third-party software, Content Security Policies (CSP), and Sub Resource Integrity (SRI).
The Secret Life of Scripts
We recently attended the PCI Community Meeting in Portland, Oregon. A special focus was on the new scripting controls introduced in PCI DSS v4. Before we delve into these changes, let’s spend a moment talking about web scripts. These are like the engine running behind the scenes of modern websites, controlling specific tasks on a webpage. They’re the magic that turns static, dull pages into lively, interactive platforms. From displaying the current date and time to generating interactive maps in real-time, scripts do it all.
In the world of online shopping and payments, scripts are the unsung heroes. They make sure things run smoothly, processing inputs from users and ensuring a seamless navigation experience. They help validate data and secure information entered by users and they bridge the gap between different services, like integrating payment processing services.
As great as scripts are, they need to be handled with care; if they are not properly secured, they can become easy targets for cyber attackers.
These threats highlight the crucial need for robust security measures. To tackle these threats head-on, PCI DSS v4 introduces two major controls. Control 6.4.3 requires businesses to keep track of authorized scripts, validate their integrity, and justify each script that will load in the user’s browser. This also applies to third and fourth-party scripts loaded on the page. Although it is best practice to implement this control now, it is not in scope for assessments until March 31, 2025, so there is time to adapt.
The second control, 11.6.1, requires businesses to have measures in place to alert about any unauthorized changes to HTTP headers and contents of the payment page, and to check received headers and payment pages at least every seven days. Like 6.4.3, this control will be in scope starting March 31, 2025.
The Power and Peril of Automation
If you have been relying on iFrames (inline frames) to reduce your PCI DSS scope, these new controls might change that. iFrames are HTML documents embedded within other HTML documents, often used for embedding externally hosted payment forms. With the new v4 controls, iFrames will not be enough to remove the rest of the payment page from scope. If there are any scripts running on the page alongside the iFrame, these new requirements would apply and bring those into scope.
There are several ways to address the new requirements which can lean on manual or automated processes – or a combination of both:
- Developer tools in modern browsers: These can give you insights into scripts loading in the user’s browser. Using developer tools is a time-consuming, manual process and is probably not be enough to meet the new requirements on its own.
- Home-grown parsing tool: Creating an in-house tool for pulling, parsing, and auditing scripts is another option. But remember, this requires specialized skills and expertise, and could potentially increase your scope and add new security risks.
- Third-party software: Third-party tools are available to perform some, most, or even all of the required tasks. But they might require you to add their code to your page. This could increase your security risks. Not to mention the associated cost.
- Content Security Policies (CSP): CSP helps organizations comply with PCI DSS v4 by enabling inventory management, authorization and integrity checks, and anomaly detection. CSP does have its limitations and potential weaknesses; it can be complex to implement, may disrupt the functionality of existing websites or applications, and may not be fully supported by some older browsers. Additionally, writing and fine-tuning CSP policies can be tricky, especially for larger and more complex websites. Misconfigurations might inadvertently block necessary resources or create security gaps. And CSP’s violation reporting mechanisms can generate a significant volume of data, potentially adding reporting overhead and requiring effective data management.
- Sub Resource Integrity (SRI): SRI is a security feature that ensures the integrity of fetched resources such as scripts or stylesheets, particularly from a Content Delivery Network (CDN). It checks an accompanying cryptographic hash against the fetched resource to ensure the resource hasn’t been tampered with. Strengths of SRI include maintaining resource integrity, enhancing security, and working well with CDNs. However, it has weaknesses such as lack of support in some browsers, the need for correct and maintained hashes, no provision for partial integrity checks, and potential performance overhead due to the process of computing and verifying hashes.
The Tale of CSP, SRI, and Third-party software
|What it Does||Provides an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks.||Ensures the integrity of fetched resources such as scripts or stylesheets by checking a cryptographic hash.||Specifically developed to address the new requirements in PCI DSS v4.|
|Use Cases||Used to define the browser behavior with regards to executing scripts, loading resources, and reporting violations.||Mostly used when including resources from external sources, particularly CDNs.||When looking for either a compliment, or an alternative to, CSP and SRI and cost is not a significant factor.|
While these changes in PCI Version 4 may seem intimidating at first, they’re actually a perfect opportunity to modernize your security controls for one of the biggest attack surfaces – ecommerce. With careful implementation, these controls can act as a powerful shield against the ever-evolving threats in the online payment landscape. The key is to understand, adapt, and stay one step ahead – a critical strategy in today’s digital world. If you’d like some help navigating these new requirements and their impact on your PCI footprint and compliance obligations, SRA’s QSA Team is here to help. Learn more about our PCI Services here. We specialize in assisting organizations to assess and reduce their PCI scope, as well as understand their audit readiness.