- From: Ben Gidley <ben@gidley.co.uk>
- Date: Tue, 16 Aug 2016 08:40:13 +0000
- To: WebAppSec WG <public-webappsec@w3.org>
- Message-ID: <CALM79eKVTG7wLoCakCd9mZeUrtzEzoFmRhuwEYSf_Oo6ma+vWw@mail.gmail.com>
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 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) 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> 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/ > > -- Ben Gidley ben@gidley.co.uk
Received on Tuesday, 16 August 2016 08:40:55 UTC