[matthewarkin]

I'm actually working on a blog post about this, basically the argument is whether or not you use Stripe.js and the invisible iframe and Stripe Checkout is that as soon as you have some malicious JS in your DOM all bets are off, and while stealing credit card info from Stripe Checkout may be harder than just doing $("#credit-card-number").value, its not /that/ much harder.

(As part of my blog post, I actually use some malicious js on the merchant site to steal card info from a Braintree iframe (the drop in))

[aethr]

Very interested to see your blog post. I was under the impression that if the data is collected in an iframe with a same-origin policy, that malicious JS in the containing page wouldn't have access to form elements (or anything) inside the iframe.

Of course if you have malicious JS in your DOM, there's nothing stopping it from rendering it's own legit-looking credit card form that simply passes data off to an external URL.

[matthewarkin]

Thats basically the concept, once you have malicious js you can replace the iframe with a malicious one that looks the same. You can even have it still create a legitimate card token, so in theory the website would never know they are hacked. The other PCI SAQ A scenario is linking off site. So while malicious JS could change the link you redirect to customers to it would be noticed because the customer may see a sketchy url and the merchant would see a decrease in sales.

[chinathrow]

So where's the news then? Malicious JS is known to be bad.

Would the next step be to turn of JS at all? Or go back to hosted cc forms only?

[matthewarkin]

Historically, the thought has been that the iframe and a redirect could both be treated as SAQ A (the easiest form of compliance), was because if you changed the iframe that was displayed or the page the customer was linked to it would be extremely difficult to steal customer information in a silent way.

So if a merchant links to paypal.com/merchant, and I inject js to change it to paypal.com/matthewarkin. The merchant would immediately know something was wrong because they are no longer receiving money. The issue with how Stripe, Braintree, and others have implemented their javascript and iframe implementations is that is pretty easy to replace the iframe with a malicious url (paypal.com/matthewarkin) but still allow the merchant to receive their funds.

A simple fix for this would be the api keys used to instantiate the iframe only be usable from the iframe and could not be used to call the create token api directly.

[jtdowney]

At Braintree, we have been working on the approach you mentioned. We’ll soon update our iframe products to allow a merchant to opt-in to only ever receiving cardholder data via the Braintree iframe. With this change, we could actively block malicious JavaScript from rewriting the merchant form by rejecting data not from the Braintree iframe. Things like this aren't a panacea though which is why it’s important for merchants to use technologies like Content Security Policy and leverage as much of the browser security model as possible.

[matthewarkin]

I think more awesome, was the hosted fields you just launched, so that I can have a custom, stylized form where each credit card input is its own iframe.

https://www.braintreepayments.com/features/hosted-fields