Posted 1st August 2016, reported 20th May 2015.
TL;DR - Security checks should be required for websites that take payment details via an iframe.
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:
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.
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:
Stripe "As long as you serve your payment pages over TLS [...], Stripe automatically creates a prefilled SAQ A questionnaire for you, and you won't need to undergo a PCI audit"
BrainTree "It's equally as easy to maintain PCI compliance with Drop-in; it is eligible for SAQ A since Braintree hosts the form that captures customer payment information"
WorldPay "We recommend this method if you are not PCI compliant, and you are not willing to to fill in the SAQ A-EP form"
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?
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.
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".
Ben Gidley, Irdeto Director: "using an iFrame does not ensure you securely gather data if the parent page is compromised".
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."
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.