W3C home > Mailing lists > Public > public-webappsec@w3.org > August 2016

Re: Iframes and credit card security

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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:21 UTC