Re: Iframes and credit card security

Le 16/08/2016 à 01:37, Michaela Merz a écrit :
> 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.
Subresource integrity is somewhere in the middle of nothing and what 
you're describing I believe
https://w3c.github.io/webappsec-subresource-integrity/

David

>
> 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/
>>>
>>>
>>
>