How does collecting sensitive data using iframes increase security?

Question

So this approach seems to be rather popular, particularly among payment processors that provide javascript integrations.

The added layer of security that "fields in iframe" brings also supposedly reduces the level of PCI compliance required.

Verygoodsecurity, a tokenization service that also offers forms for sensitive data collection has a rather unusual approach of using a separate iframe for each field of the form, allowing the developer more control of the integration.

What I was wondering was, what added security does this approach offer and what kind of threats does it mitigate compared with just sending the data to the trusted 3rd party via a web request?

Am I wrong in thinking that if a bad actor is able to run javascript on your page, then they would be able to intercept the users actions, regardless of iframes, or is that not the case? Can keypresses be intercepted? And if not, they could just strip out the iframes..

Is it possibly just to make it a little less easy to get at the sensitive data? Maybe it would prevent a non targeted attack, like just listening for anything that looked like credit card details..

Quotes from PCI standards:

iFrame provides “sandboxing” to isolate content of the embedded frame from the parent web page, thus ensuring that information is not accessible or cannot be manipulated through various exploits by malicious individuals.

but then..

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.

Answer 1

You ask a great question and the technical reason that iframes add a layer of security is covered in many of the above answers. However, you also correctly observe that if an attacker has access to the parent page's contents and can insert their own JavaScript, then they can create a dummy payment form above the real iframe and 'trick' the customer into entering their payment card data into the attackers form, and so you asked the question of whether this is 'security theatre' (or perhaps compliance theatre).

But the case of a fake-frame, because the attacker has no access to the data in the real iframe which hopefully will contain a 'secret' token from the payment service provider (PSP) the attacker will, once they have exfiltrated the customer's payment card data, be unable to complete the transaction by posting it back to the PSP because they don't have that token. The transaction will fail, and typically the attacker generates a failed transaction message and then lets the customer interact with the 'real' iframe.

Because transactions fail, merchants are able to detect the fake-frame attack, whereas the alternative with no frames involved is much harder to detect. Using an iframe from a PSP makes it much harder for the attackers to code and allows detection because of the number of failed transactions. It is not security theatre, but it is also not perfect. However, it does make the attack harder and more detectable - reducing risk.

Personally, if I ran an e-commerce website, I'd use the option that most PSPs provide which is to entirely redirect the customer to the PSP's own payment pages. Again, not 100% secure because an attacker can always poison the redirect, but much easier to detect and so further reduces risk.

Ignoring PCI DSS compliance for the moment, the use of Content Security Policy (CSP) and Sub-resource Integrity (SRI) combined with an external synthetic-user detection service are your real friends in defeating e-commerce skimming attacks.

Answer 2

... if a bad actor is able to run javascript on your page

That's exactly the point one want to avoid. Iframes allow third-party sides including script to be part of the visible page without having access to the parts of the page outside the iframes served by this specific third party. This is much more safe than embedding a third party HTML (for the form) and script (for form control, like input checks) directly into the main page.

If the iframe and main page come from a different origin, then the Same-Origin Policy will severely limit how they can interact with each other. Contrary to that a third-party script included with the script tag has full access to the DOM and could do everything a same-origin script tag could do.

Answer 3

I'm writing this as an answer because a comment would be too long. But some time ago there was some malware that was used to infect some e-commerce websites, and the malware simulated a fake paypal popup window, or something like that. To check if the window was real or fake, they suggested trying to move the payment popup outside of the browser's window frame: if you weren't able to, then the popup was fake (simulated by malware).

So yeah, if the e-commerce website is infected, then everything in the page can be replaced, intercepted, simulated.

However there's still an advantage to having third-parties process sensitive data (as long as those third parties are trusted and secure). If you process payment data on your server, then you need to be very careful about how you store that data. If your server gets hacked, the responsibility for a data leak is going to be yours. But if you let third parties process the data (directly, via an iframe or a different window), then the sensitive data never touches your server.

In other words, I think that while nothing can protect data on a website if it is infected, third-party processors can at least help protecting past data (data that was processed before the infection, and which never touched your server).

Answer 4

I ran a small organization's e-commerce operation.

You're looking at it from an in-browser technology perspective, and presuming every organization is responsible for its own security. Small organizations are simply unable to field a competent IT security department, because the bar is pretty high - you have to be pretty big to be any good at all. It ain't gonna happen, it is not an economic reality for small business. And so many competent third parties (like Square, Quickbooks and many others) are ready to give you turnkey solutions.

This turns it into a "risk game" of a different kind. To start with, I treat our website like outdoor conduit - Electrical code requires you treat it as 100% full of water 100% of the time (and use wet rated wire)... I presume my "brochure website" is 100% hacked 100% of the time and I'll never know it.

So I know I am completely overwhelmed by technical risk. I focus on business risk - when the hack is "all over but the shouting", how will "the shouting" go for me?

The most effective way for me to deal with PCI-DSS is to never handle sensitive data on my site at all, except for services like Square which do point-to-point encryption (P2PE) between a potted device and PayPal's servers. My servers will never have any code that handles any credit card data. I would be perfectly happy sending them to <oursite>.ourvendor.com for the retail stuff, but our vendor does not support that and wants iframes. They do have an IT team, so following their professional advice is the best way for us to escape civil liability for a breach.

We take it one step further and don't even have our own merchant account, since that makes us liable for our vendor's failure to comply with PCI-DSS. The sub-1% surcharge our vendor charges for using their account is cheap insurance at our sales volumes.

So it is ultimately not about technical security: it's about civil liability.