PCI SAQ

Reported 20th May 2015, published 1st August 2016.

TL;DR - Security checks should be required for websites that take payment details via an iframe.

This issue has been acknowledged by the PCI Council on the 31st January 2017 in their Best Practices for Securing E-commerce document, section 2.2:

If an attacker has compromised the merchant's website, however, they can create alternative content for the frame, which then allows completion of the payment process as well as creation of a copy of the cardholder data for the attacker. Without monitoring and alerting controls on the merchant's infrastructure, attacks of this nature might be impossible to detect.

When a website takes payments, they need to ensure the details are handled securely.

To check this, website owners are required to complete a "Self Assessment Questionnaire", otherwise known as the PCI-SAQs.

The two most common questionnaires for websites are:

  1. SAQ-A: The easy one, where the website has fully outsourced the payment processing to a PCI compliant provider. At no point does the website have access to the payment details.

  2. SAQ-A-EP: When the website processes payment details, and requires a full audit of their system.

Traditionally SAQ-A involved sending customers to a third party website to collect payment. So when a customer purchases something on example.com, they are taken to somewhere like paypal.com to complete the payment.

But there is a new technique, where the credit card details appear to be collected on the original website, but they use an iframe to the payment provider instead.

So customers believe they are providing their payment details to the website they are ordering from, but (in theory) that website never has access to these details.

The following payment providers believe this technique does not require a full PCI compliance check:

Using these providers, website owners do not need to check their software is up to date, run any kind of security test, or perform any audits.

But what happens if the server hasn't been patched in years, is running an old version of WordPress, or using "123456" for their FTP password?

Just changing or adding one line of JavaScript, and the iframe can be loaded from a malicious server instead.

So they could proxy the requests, as per this WorldPay example.

Or create a new payment form, as per this BrainTree example.

Both of these can record the payment details, and still forward them onto the payment gateway (so the order appears to go though as normal). The only complication is masking the source IP address, but they could use Tor or a Botnet to make these requests instead.

In summary, when viewing a page to enter payment details, customers are providing those details to the website shown in the address bar. This means websites using an iframe should have to perform some security checks.

Craig Francis

  1. Egor Homakov, Security Consultant: "iframes are a disaster and can be easily phished" (more info).

  2. Scott Helme, Information Security Consultant: "if the host page is compromised or not secure, you can do whatever you like, including hosting a fake payment page, proxying requests etc".

  3. Ben Gidley, Irdeto Director: "using an iFrame does not ensure you securely gather data if the parent page is compromised".

  4. Hanno Böck, Freelance journalist: "By allowing a payment page to be iframe'd you essentially always are fully vulnerable to all kinds of clickjacking and UI attacks."

  5. Anders Rundgren, WebPKI.org Principal: "Fixing IFRAMEs is unlikely to be the answer"

As an aside, when discussing this with WorldPay, they insisted that a man-in-the-middle attack was "not possible" (the example above proves this is not true), and their solution was "so secure, the webpage does not even need to use HTTPS". This is something I had to get them to repeat three times, as I couldn't believe their senior engineer said this.