Re: Iframes and credit card security

Thanks Patrick,

You're right about compliance, but I think there should be a little more to it, simply because merchants can be held liable for fraud (maybe it's via refunds, or it maybe the full cost of re-issuing cards + fines).

I think this other BrainTree example (Client-side Encryption) has exactly the same problem as the iframe one... the customer receives the payment form from the merchant website, in the address bar they see the merchants domain name, so when the customer is entering their credit card details, in their view, they are giving that information to the merchant.

Because of that, I think the merchants website should go though the full compliance check (SAQ-A-EP), which will at least verify they are running up to date software, not using FTP, insecure passwords, etc.

And while I know the full compliance check isn't perfect, it at least gets people to double check things.

Craig





> On 15 Aug 2016, at 18:15, Patrick Toomey <patrick.toomey@github.com> wrote:
> 
> I’ve been told by folks that live in “compliance land” that you must separate the notion of “logical” and “compliance”. Compliance is compliance and little else. The solutions might very well make a site PCI compliant, but they don’t necessarily mean much more than that. For example, some providers have supported a solution like this: https://www.braintreepayments.com/blog/client-side-encryption/ <https://www.braintreepayments.com/blog/client-side-encryption/>. In this scenario, the underlying assumption is that your application has not been compromised and can’t be tricked into encrypting the CC details using some attacker controlled public key. My understanding is that this solution was acceptable for PCI compliance for quite a while (no clue on where that stands today). In short, the best these solutions offer is prevention against accidental mishandling of plaintext card numbers. In other words, assuming you are not compromised, these kinds of solutions (iframe, client-side encrypted, etc) provide reasonable assurance that plaintext card numbers don’t get logged inside your infrastructure, etc. But, all of these solutions fundamentally assume that your application hasn’t been compromised (i.e. hasn’t been changed to just ask/log cards directly).
> 
> On Mon, Aug 15, 2016 at 11:03 AM Daniel Veditz <dveditz@mozilla.com <mailto:dveditz@mozilla.com>> wrote:
> From a very narrow definition entering your payment details into a 3rd party iframe is "secure" from the parent frame--assuming the correct iframe has been opened! Stripe etc aren't going to get hacked, so I guess they're happy. You're right that this leaves users ripe for phishing.
> 
> -Dan Veditz
> 
> On Mon, Aug 15, 2016 at 6:11 AM, Craig Francis <craig@craigfrancis.co.uk <mailto:craig@craigfrancis.co.uk>> wrote:
> Hi,
> 
> Is there a secure way to collect sensitive information (e.g. credit card numbers) though an iframe, if the parent page has been compromised?
> 
> I don't think there is, and I think Stripe, BrainTree (PayPal), WorldPay, etc are all pretending they have a secure system, when they really don't.
> 
> I've written up my notes at the following URL, but if you have any other comments/feedback, I'd really appreciate it (I'd like to contact the PCI Council again by the end of the week).
> 
> Craig
> 
> 
> 
> https://www.code-poets.co.uk/misc/security/pci-saq/ <https://www.code-poets.co.uk/misc/security/pci-saq/>
> 
>