TL/DR:
- 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.
There are a variety of threats that take advantage of scripts running on your site. There are specific tactics and techniques that make use of scripts to compromise the security of a web page and there are groups that commonly make use of these tactics and techniques. Examples of each of these threats to payment pages are formjacking and Magecart. Formjacking is a cyber-attack technique that uses malicious JavaScript code to hijack online forms, usually on ecommerce sites. When customers input their information (like credit card details) into these forms, the formjacking code secretly copies it and sends it to the cybercriminals. Magecart refers to a loose knit consortium of hackers and hacker groups whose motivations and origins may vary, but all share similar techniques. The bad guys in Magecart groups inject harmful JavaScript code into websites, specifically on payment pages. They use specialized malicious scripts injected into a payment page to skim sensitive payment information.
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. |
| Strengths |
|
|
|
| Limitations |
|
|
|
| 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.
Nate is a Manager at Security Risk Advisors and works with cybersecurity and risk management executives on modern threat-driven strategies, business alignment and senior reporting.
Nate has a large variety of clients including Fortune 500, supply chain, financial services, professional services, technology, pharmaceuticals, and health care providers. Nate’s cross-industry experience allows him to adjust recommendations and cybersecurity controls to his clients’ different risk appetites and budgets.
Nate has experience driving long-term outcomes on multi-year process transformation engagements as well as executing short-term assessments and creating strategy roadmap deliverables. Nate effectively manages multiple priorities and typically leads engagements at 3-4 clients concurrently.
Nate also has experience working with compliance and security frameworks including NIST CSF, HIPAA and PCI-DSS. Nate is certified in the RSA Archer GRC suite and Open FAIR.
Adam specializes in security assessments and audits, primarily PCI DSS. Adam has experience leading PCI scope validation and strategy engagements, performing data risk assessments, and conducting various security framework readiness assessments. He also has experience in leading vulnerability management projects and SWIFT CSP readiness assessments.
In addition to extensive experience with PCI DSS controls and remediation strategies, Adam has experience with additional frameworks such as NIST CSF and ISO 27001.
Adam has worked on projects in multiple industries but most notably healthcare organizations, insurance, and financial services institutions.
Adam’s range of skills is his strength; he can use his broad range of experiences to jump into any project and assist the client with any issue they may have.