TLDR:
The 2022 PCI Community was in person for the first time in three years.
Every few years a new risk theme develops as threats change and evolve, and this year was no different: the rise of malicious JavaScript code being deployed on compromised web servers to perform “eSkimming” on payment pages.
As a reminder PCI v4 is not required until March 2024, with some “Future Dated” requirements not required until March 2025. Time flies though, so ensure you use 2023 to at least understand what impact the new PCI v4 may have on your organization.
Introduction
After 3-years of the conference being exclusively virtual, the 2022 PCI Community Meeting was in person and took place in the beautiful city of Toronto. It was an exciting opportunity to finally connect with payment professionals around the globe face to face and discuss the recently released PCI v4 and emerging threats seen in the payment landscape.
Every few years new technologies and risks create a theme of the conference. Six years ago, it was the rise of point-to-point encryption (P2PE) and tokenization to reduce the scope of your cardholder data environment. Three years ago, protecting call centers became a major talking point, especially after the PCI SSC made it very clear VoIP networks handling cardholder data are in-scope for PCI. This year a combination of real-world breaches as well as a PCI v4 Requirement pushed a new narrative – JavaScript Integrity checking mechanisms are critical to preventing eSkimming attacks resulting in cardholder data breaches.
JavaScript is a popular method to accept cardholder data over the Internet via a customer’s browser. A significant PCI benefit is that JavaScript prevents cardholder data from being processed on an organization’s web server because the cardholder data is sent directly from the customer’s browser to a third-party payment gateway. This subsequently reduces the PCI requirements an organization needs to apply to that web server significantly. While this is a great start to reducing risk, over time it is becoming clear that just because the web server doesn’t handle cardholder data, it does not mean the risk of a compromise disappears.
A quick reminder on how JavaScript works.
JavaScript is a client-side scripting language. The JavaScript code sits on a webserver. When a client browser loads a web page hosted on the web server the browser has a built-in functionality that reads the JavaScript code it finds on the page and runs it.
One of the most popular use cases for JavaScript is to allow users to interact with web pages including inputting data (such as cardholder data!).
Over time use cases of JavaScript have expanded to enabling rich web applications, mobile applications, games, search engine optimization, marketing, and customer service. This is most often done through multiple JavaScript code libraries including code served through external third parties. This further increases the complexity and risk of JavaScript code being compromised.
Imagine an eCommerce merchant who leverages a third-party hosted JavaScript that provides a customer support chat bot. The customer support chat bot appears on the payment page in case the customer has any questions about products.
The third-party web server hosting the chatbot JavaScript is compromised and malicious JavaScript code is inserted in the customer support chat bot. Now the attacker runs the malicious JavaScript code on the customer’s browser during the checkout process when the customer support chat bot appears. The attacker now has the ability to eSkim cardholder data as it is entered into a payment form, sending it to both the attacker and the intended destination. Neither the customer is aware nor is an alert triggered.
So, what can we do to prevent this? Enter JavaScript Integrity Checking.
There are three common methods to perform JavaScript Integrity Checking:
- Sub-resource Integrity (SRI)
- Content Security Policy (CSP)
- Third Party Tooling
These methods could each be blog posts unto themselves we would like to cover in the future; however, for now let’s cover all three at a high level.
Sub-resource Integrity (SRI)
SRI leverages cryptography and hash values to validate that any JavaScript code called by a web server has not been tampered or manipulated. SRI does this by creating a hash value of the known good JavaScript. When the web server calls the JavaScript hosted on the web server a new hash value is generated and compared to the “known good” hash value. If the two values are different it can be concluded the JavaScript code has been changed or tampered with in some way.
These integrity checks can be inserted directly into JavaScript code and free resources exist to generate SRI Hash’s including https://www.srihash.org/.
Content Security Policy (CSP)
CSP leverages source allow lists to determine whether a source is trusted or untrusted before launching JavaScript code on an end user browser. In the example above we discussed JavaScript code being served from a third party to provide customer support chat bot functionality. Let’s assume this functionality was being provided by http://goodbot.com/bot.js. If an attacker compromised the third-party web server and tampered with code to instead call on http://evilbot.com/bot.js, the CSP policy would prevent this action if that source is not on the allow list.
Third Party Tooling
I saw 3-4 vendors at the PCI Community Meeting who would fall in this space and provided presentations at the conference. I thought they all did a good job and provided some demonstrations at their booth. They use combinations of SRI and CSP bundled into clean user interfaces as well as checklist of obfuscation and run-time validation techniques. Third party tools are not necessary to perform JavaScript integrity checking; however, they can assist organizations who are looking at more advanced methods or are at a very high-risk exposure due to their business use cases or architecture.
Closing Remarks
PCI v4 Requirement 6.4.3 is a new control and will require organizations to re-think JavaScript Integrity Checking for payment pages. Although this new requirement is only best practice until March 31, 2025, I highly encourage organizations to start implementing some basic JavaScript Integrity Checking controls even if you are not required for compliance reasons.
Learn more about SRA’s PCI Services here.
Carl Angeloff
Carl specializes in designing and implementing Cybersecurity programs that incorporate risk reduction strategies aligned to industry standards while minimizing business operational disruptions.
Carl has acted as the interim CISO for multiple healthcare organizations, in which responsibilities include developing cybersecurity strategies that incorporate Key Performance Indicators (KPI), overseeing and executing the implementation of cybersecurity tooling, and managing the day to day operations and personnel of the team.
Carl is a subject matter expert in Payment Card Industry Data Security Standards (PCI DSS). Carl has performed multiple cybersecurity risk assessments against industry leading frameworks including NIST CSF, ISO 27001, PCI DSS, and FFIEC.
Carl regularly presents to executive management to communicate cybersecurity risks and strategy. He oversees a consulting division of ~40 personnel and acts as Chief Compliance Officer for Security Risk Advisors.
You must be logged in to post a comment.