Editor's Note 3/25/20: This is an excellent post to reacquaint yourself with in light of coronavirus/COVID-19 and retailers' focus on online sales.
Cyber Crime Moving from Physical to Online Retail
Physical retailers have long been warned of the dangers of card skimmers and shimmers, physical devices that thieves attach onto or insert into card capture equipment to quietly capture card information. These devices have indeed become quite advanced, allowing them to avoid detection and even transmit card numbers back to the attacker using cellular or Bluetooth technology.
These days, a new exploit known as e-commerce skimming is making the rounds. The Payment Card Industry Security Standards Council (PCI SSC) recently released a blog warning of the growing threat of digital skimming, followed immediately by a bulletin from Visa warning of the same. Both publications warn that multiple vendors providing services to e-commerce sites have been compromised by a suite of hacking tools called Magecart, and that their embedded services have been acting as e-commerce skimmers, intercepting and compromising credit cards entered by unsuspecting consumers.
How E-Commerce Skimming Works
The attack vector for e-commerce skimming is not unlike that of physical skimmers. Many e-commerce sites utilize third-party code, usually inserted as JavaScript snippets. These snippets perform beneficial functions such as website analytics or customer service chat; however, the actual code may be from sources that are not maintained according to the PCI Data Security Standard (DSS).
Bad actors have been able to compromise these insecure third-party systems and insert malicious code that acts as a sniffer or digital skimmer. When the customer’s browser executes the seemingly innocuous script, it then detects card information entered elsewhere on the page, and transmits it to the attacker.
Protect Your Website from E-Commerce Skimming
There are three important areas to consider that will help protect your website from e-commerce skimming:
- In order to be eligible for reduced PCI DSS scope (including SAQ A), “all elements…delivered to the customer’s browser” on any payment page must “originate only and directly from a PCI DSS validated third-party service provider” (PCI DSS v3.2.1 SAQ A, Rev 1.0). Where an iframe is used to house a card capture page, you should code the <iframe> tag to point directly to the service provider, rather than allowing it to be generated on-the-fly by JavaScript code, as such code could obfuscate a malicious redirect.
The PCI SSC’s Best Practices for Securing E-Commerce Special Interest Group compiled a list of best practices for securing iframes, which encourages merchants to “consider complementing their PCI DSS compliance program with additional security controls to reduce e-commerce risk, even if such controls are not stated as required by SAQ A. Hardening of servers, vulnerability management, and monitoring of server activity are effective controls for these implementations.” (p. 12)
- Four years ago, the PCI SSC introduced the SAQ A-EP, which may be suitable for your business if you host your own payment forms but do not transmit cardholder data. However, in the case of digital skimmers, the element that captures the credit card (e.g., a <form> <input> field) is only one part of the payment page.
The use of JavaScript elsewhere on the page is also in-scope for PCI DSS because this code could still impact the security of the cardholder data while it is entered into the customer’s browser window. When that code is provided in real-time by a third party (e.g., the use of a small <script source> tag), the company hosting any part of the code must be PCI DSS compliant to prevent skimming or other malicious attacks. By selecting a PCI-compliant service provider and ensuring that the service in question is listed within the company’s attestation of compliance (AOC), you can be assured that both the code and the servers housing it are protected by secure coding practices, regular penetration tests, vulnerability scans, and are otherwise protected from unauthorized modification.
When the code is a snippet dropped into the code, it immediately becomes your responsibility to maintain the security of that code. Much of PCI DSS requirement 6 remains in scope—even for SAQ A-EP merchants—and requires you to take ownership of all code including vulnerability testing, security patching, change control, secure coding practices, manual or automated protection against common coding vulnerabilities (such as a web application firewall), and documented procedures for maintaining these applications. Even if you didn’t write the snippet, you must be able to confirm that these controls have been met by all code on the page(s) in question. Therefore, if your business cannot meet these requirements, other e-commerce implementation options may be more favorable.
- The use of third-party services providers (TPSPs) is becoming increasingly prevalent across all aspects of the modern enterprise. Their potential value to deliver efficiency and improved customer experience is undisputed. However, this practice creates a significant challenge for security and compliance. It is unacceptable to turn a blind eye to the roles, permissions and capabilities third parties have within your organization. Requirement 12.8 (in scope for every SAQ type, including both SAQ A and SAQ A-EP) requires that a list be maintained of all service providers that could affect the security of cardholder data (even if they do not store, process or transmit that data), including any PCI DSS controls that their services impact.
What To Do If You Suspect a Compromise
Could your site’s payments function already be compromised? If you believe an infection has already occurred, or your site has been running without the necessary controls in place to prevent such an attack, immediate action is crucial. As with any data breach, removal of the affected vendor code may not fully resolve the issue. Our Security Consulting Services experts can help with vendor risk assessment, vulnerability scanning and penetration testing, to confirm full remediation and removal of all malicious code from affected systems.
Want to learn more about protecting the payment card data collected through your website? Check out the e-commerce articles on our PCI Compliance Guide blog.
