Re: Iframes and credit card security

>From a purely technological point of view - everything in the browser is
pretty much fair game if the underlying server is compromised. I have
long tried to convince folks that we would need some form of signed code
that would even protect against a fully compromised server as the
signature package itself would be signed by a release key that would not
reside on the web site in question.

Some time back I developed an appropriate solution via Firefox extension
(see attachment).

Compliance is Patrick explained, just that. A set of rules that make
"some" sense but won't address the underlying problem.

Michaela

On 08/15/2016 06:11 PM, Craig Francis wrote:
> 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
>> <mailto: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/.
>> 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/
>>
>>
>