Stripe plans to use the iFrame "loophole" to enable Stripe.js customers to qualify under SAQ A-EP as mentioned on their website[1]:
> The new version of Stripe.js meets these criteria by performing all transmission of sensitive cardholder data within an iframe served off of a stripe.com domain controlled by Stripe.
Can someone help me understand how this is practically any more secure than the way Stripe.js currently works? It sounds like the intention of the iFrame exception[2] is to allow a payment form to be loaded, completed, and submitted to a compliant server all within a visible iFrame. From what I can tell, the "compliant" version of Stripe.js just submits the data (similar to the traditional way) via an invisible iFrame - the form is still hosted and completed on the (likely) non-compliant server.
If that's the case, then I'd expect the "loophole" to go away soon and current Stripe.js users will have to adopt a payment flow similar to Stripe Checkout; in other words, it will be obvious that Stripe (a third party) is being used because the end user will be interacting with a form (or part of a form) completely hosted on Stripe's servers.
For companies using Stripe to avoid PCI compliance with self-hosted payment forms, this essentially transforms Stripe into another PayPal checkout-style service.
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))
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.
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.
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.
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.
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.
I agree! I submitted it as separate item because this conversation was about rewriting iframes. Although hosted fields doesn't directly address the rewriting for now, we're looking at it closely.
> The new version of Stripe.js meets these criteria by performing all transmission of sensitive cardholder data within an iframe served off of a stripe.com domain controlled by Stripe.
Can someone help me understand how this is practically any more secure than the way Stripe.js currently works? It sounds like the intention of the iFrame exception[2] is to allow a payment form to be loaded, completed, and submitted to a compliant server all within a visible iFrame. From what I can tell, the "compliant" version of Stripe.js just submits the data (similar to the traditional way) via an invisible iFrame - the form is still hosted and completed on the (likely) non-compliant server.
If that's the case, then I'd expect the "loophole" to go away soon and current Stripe.js users will have to adopt a payment flow similar to Stripe Checkout; in other words, it will be obvious that Stripe (a third party) is being used because the end user will be interacting with a form (or part of a form) completely hosted on Stripe's servers.
For companies using Stripe to avoid PCI compliance with self-hosted payment forms, this essentially transforms Stripe into another PayPal checkout-style service.
[1] https://support.stripe.com/questions/what-about-pci-dss-3-0
[2] https://www.pcisecuritystandards.org/documents/Understanding...