12

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.

Acorn
  • 222
  • 2
  • 7
  • Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/123491/discussion-on-question-by-acorn-how-does-collecting-sensitive-data-using-iframes). – Rory Alsop Apr 27 '21 at 08:07

4 Answers4

11

... 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.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 6
    Oh, I don't think trusting the author of the iframe contents (e.g. Stripe) is the issue here. And with that kind of solution you'll be including some of their javascript to insert the iframe into the page anyway. The worry is someone manipulating the host page and being able to intercept the information that is entered into the iframe. I'm curious as to what ways an iframe limits that ability.. – Acorn Apr 22 '21 at 18:04
  • 1
    @Acorn Same Origin Policy restricts also access to another direction. You can't do much with popup especially on desktop (and mobile devices getting stricter also) – aholbreich Apr 22 '21 at 18:09
  • 3
    Aren't popups and iframes orthogonal concepts? Also what does it matter if you can't manipulate the contents of a Same Origin iframe if you can just replace it? – Acorn Apr 22 '21 at 18:17
  • 1
    A faked iframe won't be logged into your PayPal, your browser won't autofill it and it won't be able to show you your name and address even after you logged in. That's suspicious. – knallfrosch Apr 23 '21 at 09:48
  • @knallfrosch This sounds like the real reason. Can you post that as an answer, please? – Bergi Apr 23 '21 at 11:06
  • That's a good point with the autofill, and the knowledge of the customers details. Although this doesn't make any difference with something like a card details form using verygoodsecurity's "one iframe per field" solution.. – Acorn Apr 23 '21 at 17:10
  • @Acorn Using an iframe shift the access of sensitive data from the merchant to the processor (besides being the right technical way to include a full third-party page in your page. Think of library conflicts). This is what the processors are concerned about. A compromised merchant can be turned into a phishing page but that's a different attack that can't be prevented (it exploits humans). Data can't cross iframes unless in a form of intentionally pushed messages, so iframes can't be intercepted and your data can't be sniffed. – Margaret Bloom Apr 24 '21 at 13:18
  • @Acorn An evil merchant must still load the processor's iframe content or it will be too obvious it's not a real merchant. It could sniff and resell your data but the iframe prevent that. A compromised merchant doesn't even need to use iframes and not being any interaction with the processor at all it makes no sense to ask how a processor protect themself from such an attack. – Margaret Bloom Apr 24 '21 at 13:18
4

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).

reed
  • 15,398
  • 6
  • 43
  • 64
  • 1
    I guess my question is, if you can do nothing to protect data on a website if it is infected, then why go through all the trouble of writing javascript SDKs that insert iframes into a page? How much of it is because that's the PCI hoop we need to jump through, and how much does it actually protect the data? – Acorn Apr 22 '21 at 18:11
  • 1
    @Acorn The iframe approach protects against a number of bad things, including the possibility that the merchant will indefinitely store all their customers' unencrypted credit card information in a publicly accessible database, which is the sort of thing that used to happen alarmingly often. It does not protect against the case where the merchant's entire site exists to gobble up credit card information and send it to attackers (either because the site is a trojan horse or it's been compromised), but the protection of the merchant never accessing the data still reduces the attack surface. – Zach Lipton Apr 24 '21 at 02:21
  • @reed aha this is interesting. So it serves as a way to make it easier to audit what a website is doing with the data? I was looking at it from the perspective of a compromised website.. a user is very unlikely to right click on a form to check that it is in an iframe. But if we're just wanting to make it clearer that the data is only going to one destination under normal conditions, then a iframe does make that easier.. – Acorn Apr 24 '21 at 08:27
3

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.

withoutfire
  • 1,000
  • 4
  • 7
  • Interesting point about making tampering more obvious, and the idea that someone skimming details may want to avoid breaking the normal functionality of the page to avoid detection. I hadn't considered that! – Acorn Apr 27 '21 at 11:14
2

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.

Harper - Reinstate Monica
  • 3,101
  • 10
  • 17
  • That's a great answer. I guess there's two different things going on here. There's the practical civil liability issue of complying with PCI. The other side is the (questionable?) technical advantages of using an iframe instead of using your own form and sending the details directly to the vendor (no sensitive data going to your servers). Unless I'm mistaken, the two approaches mean two different levels of PCI requirements. Just trying to separate out the security reality from the security theatre. – Acorn Apr 23 '21 at 22:59
  • @Acorn My vendor isn't going to accept a "blind" form submission of CC data from a client it hasn't already interchanged cookies with. They like to ask for payment data *at the very end* after "checkout", ID/email, and shipping details are worked out. By doing it last they don't need to retain CVV. – Harper - Reinstate Monica Apr 24 '21 at 00:48
  • +1 to the suggestion that this is focused more on organisational risk than anything. I've moved payment forms to an iframe just because it would make it easier to comply with certain regulations that impact things like who has access to servers etc. – Jeroen Vannevel Apr 24 '21 at 12:04