Re: Iframes and credit card security

Thanks for the detailed reply Ben,

And yes, it's the allowance of iframes in SAQ-A that I think is wrong, and I'd like to be changed.

I must admit, I am intrigued by Cloaked.JS...

I don't think it will work to solve this particular issue, as websites that can't afford to do a full PCI check are the ones using iframes (personally I think they should go back to forwarding the customer to the PCI checked website for payment, where the customer will see that URL in the address bar, and know their payment details are going to that company).

But from a cross check point of view, for a website to get a heads up on things being changed or tampered with, I kind of like the idea (as you point out, the Kerckhoffs' Principle worries me a bit), but for an extra warning level, it's interesting.

Anyway, I'd like to get some other names on to that web page before I go to the PCI Council (again), would you mind if I added something like...

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

Not to worry if not, it's really just to show that I'm not making it up.

Craig




> On 15 Aug 2016, at 15:44, Ben Gidley <ben@gidley.co.uk> wrote:
> 
> Hi,
> 
> I believe you are correct, using an iFrame does not ensure you securely gather data if the parent page is compromised. I believe in PCI this is a known issue. I don't think most of gateways really deny this is a possibility (your example excepted), it's just not something PCI focuses on (rightly or wrongly).
> 
> PCI allows the SAQ-A for iframes - see https://www.visaeurope.com/media/images/processing%20e-commerce%20payments%20guide-73-17337.pdf <https://www.visaeurope.com/media/images/processing%20e-commerce%20payments%20guide-73-17337.pdf> for a nice write up. I (personally) would love it if they accepted iframes on their own was not enough for SAQ-A but it's the established position.
> 
> In terms of genuine security (as opposed to just passing PCI) you can make some progress on this issue (disclaimer/shameless plug: Irdeto who I work for make a product for this irdeto.com/cloakedjs <http://irdeto.com/cloakedjs>) by
> - Signing the entire iframe
> - Using whitebox cryptography to create a secret in the JavaScript in the iFrame
> - Use that secret to root an integrity verification system for the iframe (this is possible for a whole page but really hard as people tend to do things like using embedded javascript from google).
> - Use that IV combined with another whitebox to encrypt the coms back to the API (nice side effect this sidesteps SSL MITM attacks)
> - Add a challenge/response protocol on to the messaging
> - Ensure the API only talks to valid clients
> 
> This then leaves us with
> - A form the hacker cannot replace and make it work as they can't sign the messages back to the API in a valid way. 
> - Strong tamper detection on the form that the server knows about
> - A secondary layer of (AES) encryption inside the TLS dealing with MITM attacks
> 
> There are still concerns about calling page 'seeing' into the form via the DOM - same origin helps here, but you can try and mirror the protected code, however that's quite hard as we diversify it and had out specific variants to specific clients making it very tricky to get the 'right' one to continue a conversation.
> 
> This approach raises the bar and if the merchant website is compromised, it becomes a lot harder for someone to replace the form and make payments still work. They can replace it and make them not work, but then customers tend to notice (as does the merchant). In addition the PSP can add automated checks that load the merchant website with something like Selenium, submit test transactions and see if they appear on your backend.
> 
> 
> 
> On Mon, 15 Aug 2016 at 14:14 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/>
> 
> -- 
> Ben Gidley
> ben@gidley.co.uk <mailto:ben@gidley.co.uk>