The DSS, MageCart, and the DOM – Part 1: The PCI DSS e-Commerce Rules

By David Gamey - 05 Aug 2021.

It turns out that how you implement e-commerce can have a huge impact on your compliance footprint (i.e., the number of PCI security controls assessed depend on your implementation decisions). Understanding how your e-commerce implementation fits into PCI can save you time, effort, and money when implementing, monitoring, and maintaining these base-line controls. Not understanding your e-commerce PCI can be frustrating, painful, and expensive. Beyond PCI's minimum controls, you will need to consider residual fraud and security controls.

Welcome to our multi-part series of articles on e-commerce security and compliance. In this article, we look at the current PCI DSS v3.2.1 compliance framework for shopping carts and payment pages. We explain PCI's e-commerce framework, the difference between shopping carts where the payment page is managed by the merchant or managed by a PCI compliant third-party, as well as the different compliance footprints and burden of both.

In future articles we will look at the security implications of JavaScript, and "MageCart" e-commerce skimming attacks.

Note: This article was originally published on 2021-06-10 and has been updated to better align with the rest of the series.

Typical E-commerce Scenarios and Compliance Footprints

E-commerce transactions typically process cardholder data (i.e., PAN & Expiry Date) and sensitive authentication data (e.g., the printed Card Security Verification Number). Additional fraud and security controls such as Address Verification Service (AVS) and 3 Domain Secure (3DS) may apply. These measures attempt to provide merchants with additional fraud prevention control while minimizing user friction.

There four scenarios for implementing merchant e-commerce websites within PCI DSS. Each scenario has a different "compliance footprint" (i.e., set of applicable requirements). Each scenario is described below:

  1. Payment Servers (Full PCI DSS, 367 requirements) - websites that receive cardholder and sensitive authentication data and use an API or other mechanism to send the data to the payment processor/acquirer. The server clearly sees all the data, could potentially store the data, and is fully in scope for PCI DSS.
  2. Merchant Managed Payment Pages (213 PCI DSS requirements) - websites that host or generate forms that submit data directly from cardholder browsers to a compliant third-party payment processor. This compliance footprint is slightly reduced but still quite large and requires significant effort to achieve compliance. Small merchants can validate these implementations using SAQ A-EP.
  3. Outsourced Payment Pages - (27 PCI DSS requirements) - websites that host or generate links to a compliant third-party payment page using an IFRAME or URL redirection. PCI deems these shopping cart implementations outsourced payment pages with the second smallest compliance footprint. Small merchants can validate these implementations using SAQ A.
  4. Fully Outsourced E-Commerce - organizations that outsource all aspects of e-commerce to a compliant third party have the smallest compliance footprint of all. Small merchants also validate this using SAQ A. (This straight forward scenario is included here for completeness.)

The distinction between a merchant website using a Direct Post Form or an IFRAME (i.e., Scenarios #2 vs #3) is frequently misunderstood and often creates confusion among merchants and service providers. This leads to bad advice and non-compliant implementations. A merchant implementing their e-commerce site believing they are eligible to use the smallest compliance footprint (Scenario#3) but actually implementing Scenario#2 will find themselves non-compliant, needing significant remediation, or worse - the subject of a data breach investigation. The remainder of this article looks at Scenarios #2 and #3 in detail.

Why this Distinction?

The critical guidance supporting this distinction is captured in PCI FAQ’s 1438 and 1292 (paragraphs 2, 3, and 5 can be challenging to unpack). However, the basic rationale for the distinction comes down to what happens inside the Document Object Model (DOM) of the user's browser:

  • Scenario#2 (i.e., Merchant Managed Payment Page) implementations build the shopping cart and form inside a single DOM. Even though the data collected by the form will be sent to a compliant payment processor, all the contents of the form elements are visible to everything in the DOM. This means that any JavaScript embedded within the page or included from third-party sites can hook in and see all collected data which allows sensitive data to be ex-filtrated with no visible functionality impact.
  • Scenario#3 (i.e., Outsourced Payment Page) implementations use an IFRAME or URL to a redirect data to a compliant payment processor. These techniques create a new DOM within the cardholder's browser and isolates the data collected from the merchant’s shopping cart.

Or put another way, hosting the data collection form in the DOM of the merchant shopping cart means that the third-party processor cannot properly control the collection of cardholder data. This makes the data more easily accessible to web-replay and analytics providers as well as to criminals looking to steal valuable data.

The distinguishing factor between these two scenarios hinges on the technical details of the implementation. Specifically, which DOM collects the cardholder and sensitive authentication data for the payment page. It turns out that what is rendered is more important than how it's rendered. It makes no difference if the HTML elements are hardcoded into the shopping cart or built on the fly. A scripted IFRAME is still a small 27 requirement compliance footprint, and a scripted form is still a large 213 requirement compliance footprint.

This diagram shows Scenario#2 implementing a direct post payment page:

Scenario#2 - Payment page footprint using Forms

Note: The dashed line indicates a logical flow which can be implemented via call backs, encrypted responses, or session tokens.

This diagram shows Scenario#3 implementing redirection:

Scenario#3 - Outsourced shopping cart footprint using IFRAME/Redirect

We are nearly at the end of our compliance journey, but not the security journey:

  • Ensure your service provider (e.g., payment processor) is compliant and current with their own PCI DSS validation. If they aren't, your assessment will include what they are doing on your behalf.
  • Ensure you understand what PCI DSS responsibilities your service provider does not cover (see below).
  • Be aware that payment providers are expected to have additional controls in place, such as prevent man-in-the-middle attacks, these may need to be implemented through API or call-back mechanisms in your shopping cart to prevent abuse.
  • Take steps to detect and prevent other attacks such as fraud. For instance, how does your shopping cart deal with browser side attacks like price or item modification? Your payment providers API can often help address this risk.
  • You should also be concerned about third-party JavaScript risks. We will provide more details in our next articles about MageCart attacks and JavaScript security issues.

If you've successfully minimized your compliance footprint, you should be able to focus some of the resources you saved on controlling risks to your bottom line and other risks of your choosing.

DIV's are Red Herrings

Some merchants and vendors will argue that DIV's provide protection. They do not. DIVs (division/section separators) are containers for organizing elements in the browser, applying styles, or manipulating the DOM with JavaScript. DIVs are just a distraction in security and compliance discussions. FAQ #1292 includes "Merchants and QSAs receive often conflicting advice from vendors which can be especially confusing when the difference between using an IFRAME and embedding a payment form in a <DIV> appears to be minimal. However, the difference in security is substantial: ..."

Distributed Functionality

Even if you can achieve the smallest shopping cart footprint, Scenario #3, you need to make sure that you cover all of that functionality. Many organizations split functionality across multiple on-premise systems, or outsource parts of their web content hosting across one or more providers. The controls, e.g., unique user IDs, need to be applied on all applicable systems (e.g., Magento, WordPress, GitHub, Amazon AWS, Azure, Akamai, Google GCP, GoDaddy, etc.). Additionally, don't overlook security impacting systems such as code repositories (e.g., GitHub, GitLab, Bitbucket, CodeCommit, etc.).

Outsourcing

Outsourcing does not eliminate your PCI DSS responsibilities if you have a merchant account. Even if everything is fully outsourced and hosted by a third-party, you are still responsible to comply with requirement 12.8 to ensure your provider is compliant. Failure to apply due diligence or understand any PCI responsibilities not covered by your provider means you've dropped the ball on PCI. Before you build it and sign contracts, make sure you understand what your service providers do for you and what they do not.

Review your service provider's PCI DSS responsibility matrix. This document details which PCI DSS responsibilities are on them, which are shared, and which are on you. Don't assume your provider does everything. Compliant services vary dramatically depending on the nature of the business offering. Cloud Infrastructure providers, like AWS and Azure, are compliant for infrastructure but won't cover your application as that isn't part of their service. More focused platform service providers, like Salesforce, may do more for you but often push requirements for customizations back on the merchant. Some highly focused shopping cart providers may cover more, even most, PCI responsibilities. But whatever they don't cover, you will have to. Either on your own or with additional service providers to cover things like application development and maintenance. Getting this right is critical to achieving business, compliance, and security goals.

Getting Compliance Right

You will want to be certain you understand which footprint applies to your implementation. Getting it wrong will mean you've potentially ignored up to 300+ PCI DSS requirements that apply to you. Discovering this mid-audit will be an unpleasant experience that will almost certainly result in a non-compliant assessment, significant remediation efforts, delays, and broken budgets.

Why We Expect New PCI Guidance

We have long expected the PCI council will change the PCI-DSS guidance and possibly add new requirements. Here are some of the reasons we expect the guidance on shopping carts and payment pages will change:

  • The current DSS 3.2.1 guidance has remained essentially unchanged since the introduction of DSS v3.0 in 2015.
  • MageCart and e-skimming attacks have been on the rise over the same period and are increasingly sophisticated and problematic.
  • The PCI 3DS Standard already has additional requirements (see below) on payment pages that go well beyond the DSS.
  • At the current time, PCI DSS v4.0 (a major update) is under development and is just entering a third Request for Comment (RFC) phase prior to its expected publication in late-2021. While clarifying guidance can appear at any time, new DSS versions are often a catalyst for change and the introduction of new requirements.

Summary

Merchants implementing their own e-commerce shopping carts using third party payment processors need to understand the security and compliance implications of their design choices. Scenario#2, merchant managed payment pages, have a large compliance footprint that comes with a significant cost. Scenario#3, outsourced payment pages, have a significantly smaller compliance footprint that reduces risk and has a lower cost. The difference between the two hinges on seemingly small technical details of the implementation. Specifically, in use-cases where both send cardholder and sensitive authentication data to a compliant third-party the difference will be determined by which browser DOM collects that data. While these aren't the only ways to achieve e-commerce compliance, they are the most common. Organizations that understand the compliance rules around e-commerce will be better prepared for success.

This concludes are look at e-commerce shopping cart compliance under PCI DSS 3.2.1. In our next articles we will examine (a) the trends in e-commerce skimming attacks and payment breaches, and (b) 3rd-party supply chain risks due to JavaScript risks not well addressed by current PCI guidance.

Learn More

Cybersecurity can be difficult, why not let Control Gap guide you. We are the largest dedicated PCI compliance company in Canada.
today and learn more about how we can help you: Get Compliant. Stay Compliant.