Payment Iframes Now Proven Susceptible to Silent Skimming

Recently, Turaco Labs detailed a silent skimming attack that used a proxy to silently skim payment card data from Stripe’s iframe solution. Theirs is a great analysis of the attack, and I'd encourage you to read it.

The tl;dr is that the attackers:

1. Compromised the merchant's website.

2. Replaced the call to load stripe.js from stripe.com to instead load stripe.js from the attacker’s domain.

3. Hosted a version of stripe.js on their domain that created the iframes in the consumer browser as normal, but also loaded a modified version of Stripe’s code inside the iframe to capture the payment card data, which posted the data to the attacker’s API instead of stripe.com.

4. When the attacker’s API received the payment card data, it silently took a copy and then posted the data to Stripe’s API, forging the headers so it looked to have come from an iframe created by Stripe’s original JavaScript.

Although this class of attack has been threat modelled and talked about in PCI-circles this is the first time it’s been reported in the wild, and it lays bare the conceit that just using an iframe to collect payment data isolates the merchant’s website from attacks.

The benefit of using an iframe from an e-commerce payment service provider / payment gateway / payment processor (referred to herein as an ECPG) is that it mostly isolates the merchant’s web server and allows the merchant to use SAQ A to validate their compliance with PCI DSS. We say “mostly isolates” because there are always attacks against an iframe.

Watch the on-demand webinar: Iframe Integrity: Empowering PSPs to Secure Payment Iframes Against Skimming Attacks with Zero Hassle

Double-entry skimming attacks

The attacker can compromise the merchant’s server or any third-party JavaScript present on the page to put up a fake payment page, which accepts the consumer’s cardholder data, only for it to steal the data and display “an error has occurred” message. The consumer is then invited to enter their data again (hence double-entry), but this time into the real payment fields from the ECPG, and the transaction happens normally. Double-entry attacks are generally detected because they interfere with the merchant’s desired payment flow.

Silent skimming attacks

In a silent skimming attack, the attacker’s aim is to silently take a copy of the cardholder data without interfering with the payment flow. Typically, this is done by tampering with the ECPG’s iframe or by overlaying a fake iframe above the real one, but then posting the data to the payment provider’s API endpoint. 

These types of skimming attacks can be detected and prevented by the ECPG — although our experience is that not all do a very good job.

This proxy attack is a new form of silent skimming. And although technically we agree with Turaco Lab’s observation that:

“This is not a bug in Stripe; it’s the consequence of local code tampering on the merchant’s site, plus a high-fidelity relay that keeps the rest of the contract intact.”

Our view is that preventing this attack is Stripe’s responsibility.

Sure, there isn’t a bug in Stripe’s code.

However, Stripe could have deployed measures such as code hardening and anti-tampering techniques to the code that created the iframe, as well as to their code that runs inside the iframe. They could have threat-modeled this type of attack and implemented some defences to ensure that cardholder data only came from their code, with an attestation that it was loaded from their domains by their JavaScript. Security techniques, along with code hardening and anti-tampering, would have defeated this type of attack.

The Emperor's New Clothes Problem with PCI DSS SAQ A

Given that there are attacker techniques that can silently skim cardholder data from ECPG iframe solutions, you’d assume that a merchant’s compliance with PCI DSS would be designed to prevent such attacks. That’s not a safe assumption.

Merchants who use an iframe solution from an ECPG can validate their compliance using SAQ A, as all “account data functions completely outsourced to PCI DSS validated and compliant third parties”. 

However, for e-commerce merchants, the PCI SSC implicitly acknowledges that the security of the merchant’s web server that generates the page that includes the ECPG’s iframes could affect the security of cardholder data. So SAQ A contains some minimal controls/requirements relating to the merchant web server, such as default account management, patching, access controls, and vulnerability scanning. The assumption is that the attack surface is minimal and the ECPG’s solution sufficiently isolates the merchant’s web server.

When PCI DSS 4.0 was released, SAQ A also included two new requirements applicable to e-commerce merchants, designed to counter these types of skimming attacks: requirements 6.4.3 and 11.6.1. 

However, before these requirements became mandatory, for some reason best known to the PCI SSC, they were removed from SAQ A and replaced with a new eligibility criterion that the merchant had to fulfil to remain eligible to use SAQ A (or, following FAQ 1331, base their QSA assessment on just the requirements contained in SAQ A):

“The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”

Further guidance was provided in FAQ 1588 as to how a merchant would be able to provide such a confirmation. These are:

“Using techniques such as, but not limited to, those detailed in PCI DSS Requirements 6.4.3 and 11.6.1 to protect the merchant’s webpage from scripts targeting account data. These techniques may be deployed by the merchant or a third party.

Or

Obtaining confirmation from the merchant’s PCI DSS compliant TPSP/payment processor providing the embedded payment page/form(s) that, when implemented according to the TPSP’s/payment processor’s instructions, the TPSP’s/payment processor’s solution includes techniques that protect the merchant’s payment page from script attacks.”

Most merchants take the second approach and rely on the confirmation (or the implied confirmation) from their ECPG. However, in the case of this attack against Stripe’s iframe implementation and, in our experience, many others’, this confirmation is hollow.

• Some ECPGs suggest their compliance with PCI DSS meets this criterion, but PCI DSS doesn’t include any requirements that would support this assertion.

• Many ECPGs have no protection against iframe tampering and overlay attacks, even though there are some simple things they can do.

• We are aware of only a limited number of ECPGs that have implemented techniques such as code hardening and tamper detection, which would protect against this proxy attack.

We’re constantly surprised that merchants are receiving such confirmation of protection and how they, in turn, are able to meet the SAQ A eligibility criteria when their site is unfortunately susceptible to attacks from scripts that could affect the merchant’s e-commerce system.

It is fair to observe that our surprise is amplified because our core products, Code Integrity, Iframe Integrity, and Webpage Integrity, would stop these attacks. However, the JavaScript and engineering principles in our products are not secrets; ECPGs could conduct their own threat modeling and develop their own defences and techniques: they just haven’t.

Fixing the Problem

Small e-commerce merchants without their own cybersecurity teams should be able to accept payment card transactions safely: they should be able to buy solutions that allow them to safely accept card-based payment transactions online.

Using an iframe from a validated PCI DSS compliant ECPG should be the answer. However, currently it isn’t the answer because there’s no assurance that the ECPG’s solutions are robust against known types of criminal attacks, let alone new ones that may have been threat-modeled but not yet seen in the wild.

What’s required is that these ECPG iframe solutions should be separately and independently evaluated to validate that they are not susceptible to known and threat-modeled script attacks. 

Such a validation should test for code hardening, tamper resistance, and incorporate some form of attestation-and-monitoring between the ECPG’s code running in the parent page, in the iframe, and the ECPG’s back end. As this proxy attack demonstrated, it’s no use just relying on the server checking origins and referers.

Today, customer-present merchants can select validated payment solutions via approved P2PE solutions (and for mobile acceptance, MPOC solutions), which minimise the risk of a compromise of cardholder data.

There has to be the same for e-commerce:  a PCI SSC validation and listing program for e-commerce payment gateway solutions so merchants could attest that their payment processing was wholly outsourced, and that their site wasn’t susceptible to script attacks.

This program could take advantage of the current PCI Secure Software Standard. 

All it would take is for the brands to clarify that an ECPG solution consisting of the:

• JavaScript in the parent page that creates the payment page

• JavaScript in the iframe, which is the payment page

• Back-end code for the API that accepts the payment card data 

Together are “Payment Software” which, according to brand rules, must comply with the Secure Software Standard, be validated by an independent PCI SSC Secure Software Standard accredited assessor, and be listed on the PCI SSC’s website.

Ideally, the eligibility criteria for SAQ A for e-commerce would be that the software provided by the ECPG that the merchant embeds in their website is validated to the Secure Software Standard and is listed on the PCI SSC website as such. 

Until that time most merchants who think they qualify for SAQ A should really take a look at SAQ A-EP because until the SSC and the industry catches up with how criminals attack iframes, no merchant using the majority of ECPG’s iframe solutions can honestly attest that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s). 

Is this really a problem?

Ideally, there would be no compromises of payment card data when such compromised data can still be used to make a fraudulent transaction. Eliminating all compromises and fraud isn’t the goal — it’s reducing the volume to one that maintains the integrity of the payment ecosystem.

So, if a few small SAQ A eligible merchants have compromises where criminals obtain small volumes of payment card data, is this a problem? Should the ecosystem worry about the conceit that an iframe and SAQ A adequately protect cardholder data?

It won’t be a surprise that our view is that the industry should care about this, for two reasons:

1. Once perfected, these are systemic attacks; it isn’t one small merchant that’s affected, but multiple merchants using the same ECPG or system.

2. Large level 1 and level 2 merchants continue to utilize the provisions of FAQ 1331 to limit their QSA assessment to just the requirements in SAQ A. Some such merchants deploy technical solutions like Jscrambler’s Webpage Integrity or our competitors’ solutions to minimize the susceptibility of their e-commerce systems to script attacks. But many do not, relying on implied assurances from their ECPG or an optimistic assumption.

Until there’s an independent evaluation and validation program for ECPG solutions that matches what is available with P2PE for face-to-face solutions and MPoC for mobile, the online retailer isn’t being helped by the ecosystem. It’s time that changed.