By using this, you're saying that you trust cperciva more than you trust Stripe. I'm confident that neither are going to try and deliberately steal your credit card numbers. But furthermore, you are saying that cperciva is going to protect paymentiframe.com from hacks better than stripe is going to protect theirs.
Why should I trust you with my credit card entry form?
You probably shouldn't. This is more of a proof of concept — but you might also want to use the CGI script to generate an iframe which you download (along with the bits it links to) and serve up as a static file from a server you run (but make sure you get a separate domain name for it).
Aren't you comparing Colin's iframe with a level of security unobtainable to normal Stripe developers? If you just use Stripe's JS interface the way they tell you to, you're not strictly speaking benefiting from Stripe's HSTS or XFO; your site still needs to defend against clickjacking and SSL stripping.
I feel like Colin built this little thingy to solve a real problem --- that by adding Stripe to his site, he was giving Stripe control over his site, and his site hosts information more sensitive than credit cards --- and people are piling on because his solution to his little problem doesn't solve every other imaginable security problem.
This would be less galling if the kinds of sites using Stripe today weren't almost uniformly rife with application security flaws that defeat most of the good intentions that Stripe has.
Do you use Typekit? Google Analytics? Mixpanel? Olark? Do those services get used anywhere in the path your users might take from your front page to the page in your app where you take credit cards? Then all those services can take your customer's credit cards too.
I frankly trust Colin Percival a lot more than I trust Olark. And I like Olark.
Your point is something Colin should address in his FAQ, and so it was good of you to make it, but it's also trivially knocked down.
> Your point is something Colin should address in his FAQ, and so it was good of you to make it, but it's also trivially knocked down.
So, you're saying that because Google Analytics could conceivably touch credit card information (using Stripe's JS), it's perfectly fine for some random guy with a suspect domain-name to?
Sourcing dynamically-generated Javascript from some opaque randomized URL that plugs into an entire giant Rails application that nobody has ever assessed and that sees an "agile" deployment once every three hours, solely in order to get "dynamic A/B testing metrics" or "live chat": JUST FINE.
Sourcing static content from a static web server run by a security expert in order to segregate your application's secrets from those of Stripe: TOTALLY IRRESPONSIBLE.
How can I be sure that it is static? And if it is static today, who's to say it won't be static tomorrow? What if the website's domain expires, and somebody snaps it up and puts something in its place? What if cperciva sells the domain to someone else?
I am not endorsing the use of third-party JavaScript on someone's payment page. I am also not endorsing the use of serving your payment form inside of a third-party iframe hosted on paymentiframe.com. I am not sure why you consider this opinion to be false.
Again: "payment page" is besides the point. The JS bug just has to happen anywhere in the path a user would take to get to the payment page.
It sure does make the argument simpler to pretend that you can just keep the Olark and Typekit and Optimizer bugs off your payments page and call it a day, but that doesn't actually do anything to protect most sites. Engage instead with my actual argument, which is that for virtually every app using these services, bugging your front page with Olark is even more unsafe than this iframe is.
Any Javascript you inject into the front page of your app owns the customer experience entirely. It does not matter that you set up a subdomain to send people to for payments; malicious Javascript is just going to "send" users to an extremely authentic looking facsimile of that domain.
Except that the evil javascript will set its domain to yourdomain.com (you're allowed to strip components) and then it can tamper with anything else from yourdomain.com.
bentlegen _is_ an expert in third party javascript, and is correct that both domains need to opt in to a `document.domain` even if they would match with only one changing. This is to prevent this exact security exploit.
This part of the discussion is a bit of a sideshow, isn't it? PAYMENTS.YOURDOMAIN.COM is not in fact a real mitigation for malicious Javascript on WWW.YOURDOMAIN.COM.
You can't do that without incurring a PCI Audit, can you?
The best answer is "don't link to Javascript URLs that you don't control and audit on your website". Nobody likes that answer, but that doesn't make the second-best answer any more meaningful.
You can't do that without incurring a PCI Audit, can you?
Exactly. There's no way I would be serving up third party javascript to a logged-in Tarsnap user, even inside an iframe, if it weren't for the fact that dealing with PCI auditing would irreparably damage my sanity.
I think highly of you, but my irritation here has more to do with being shouted down about getting crazy third party JS services off banking applications than it does with who runs this particular static iframe.
I think this issue is LITERALLY this simple: people are accustomed to third-party applications that work by "just copy this tiny snippet of JS code into your layout template", and all the cool kids do it, so it's not up for discussion. But static content hosting a form in an iframe? THAT'S CRAZY TALK.
Agreed, people are far too casual about dropping random javascript into their web sites. (I tried to make this point last year when I blogged about how Iran should have forged an SSL certificate for ssl.google-analytics.com instead of *.google.com, but that blog post didn't get much attention sadly.)
Ben, Are you going to be addressing this in your book, Third Party Javascript? Would love to hear your recommendations for how to handle payment processing such as this.
That doesn't make any sense, because the whole point of PAYMENTIFRAME.COM is that you don't trust Stripe.
Colin implemented this because besides credit card numbers, he was unwilling to give Stripe control over his website. Colin's users trust him with things that are much more sensitive than credit card numbers.
People trust Stripe. I think the issue here is Javascript and origin-policy and relinquishing control. When Stripe releases their version of STRIPEPAYMENTIFRAME.COM as an iframe solution then this can go away. I believe Colin mentioned a need for this now rather than waiting for Stripe.
Interesting side note: Yes I know it's only meant to be a demonstration site but PAYMENTIFRAME.COM is using Google Analytics. Oh HAI GA...what's my Security Code again? Just needed a nice chuckle before I head back from lunch.
Colin trusts Stripe to collect credit cards. He does not trust them for anything else. Embedding the form on a page on TARSNAP.COM trusts them for everything that can happen on any web application on the same domain.
That's great for Colin. But he should describe the steps he took to host his own iframed Stripe form. Not encourage others to blindly copy/paste an <iframe> tag pointing to his domain onto their website.
> one of the basic principles of security is to avoid trusting people unnecessarily
And asking customers to enter their CC details on your domain doesn't break this rule?
> a form will be submitted to your server with a stripe_token for you to process
I'm assuming it just sends the Stripe token, and not CC info? If it does send CC info, I assume it's compliant with all the laws and regulations in every country?
> It is a reason why other Stripe users might want to think twice before using the iframe I host, of course.
Well that's the point really. You say that a "basic principle of security" is to "avoid trusting people unnecessarily" which is exactly what this service you have created is asking people to do.
Do you not think the way you have presented it is encouraging people to use it?
I love Stripe, I love people hacking and creating new cool things but an emerging trend I'm seeing with Stripe is that people are really not taking the security of the CC numbers their customers have entrusted to them as cautiously and as securely as they should.
It's available for people to use if they want, sure. I expect Stripe to offer a similar service soon too (at which point that issue goes away, since people are already trusting Stripe with their card details).
I'm trusting people to decide which risks they want to take -- I'm providing tools, not dictating policy.
Maybe the FAQ should include a "Q: Why should I trust your domain to host this for me? A: You shouldn't. This is a sample, you should implement it yourself for security."
I think it's obvious to most people here, but Stripe's targeted at essentially everyone. It's quite possible that someone'd stumble across your site who just learned PHP and goes "sounds good, I'll drop it in".
It's quite possible that someone'd stumble across your site who just learned PHP and goes "sounds good, I'll drop it in".
I'm not sure that someone would be automatically wrong to do that. People should be aware that using paymentiframe.com means trusting me to not steal their customers' credit cards and trusting me to keep the site secure, but if someone makes an informed decision to place that trust in me, I can't say that they're necessarily wrong to do so.
Stripe is meant for developers, and it is quite easy to integrate using their javascript api. If you can code a form you write basic javascript you can integrate stripe.
By including their JS, you give them full access to all of the contents of your payment page and depending on how you have configured your session cookie or depending on the browser, full access to the users session. Now in general, you can probably trust them, but what if they are compromised?
By using an iframe you make sure that they do not get access to any information on your page - much less the users session cookie.
That is true, but the point is that the only thing that is going to be compromised is the data that would be going to Stripe.
I know it is shocking to many of you to hear this, but the data Stripe collects is not really the most sensitive information on the Internet.
The point of the iframe is to contain the damage from any possible compromise. If PAYMENTIFRAME.COM is insecure (heh), you still aren't going to lose user sessions to your actual application.
Again: that is not always the most sensitive things users have. I give my credit card to random people who work at gas stations. I do not give them passwords.
Exactly. Stripe is probably one of the easiest integrations I've ever done.
In fact, their tutorials are so well written and their signup so frictionless that I'd say that any interested website creator should have little trouble setting up a form actually using stripe instead of an iframe.
The whole point of the iframe is that it prevents the code from inside the iframe (ie the payment handling code that sends data to stripe) from having access to the parent page's data. Sometimes the CC info isn't the most sensitive info a user has given that website (particularly for a service that manages your online backups).
> Every key press the browser user makes in the example.com frame, while trying to log into example.com, can be captured by the attacker, and reported back to evil.com.
But this is irrelevant - user can't verify if the domain of the iframe is trusted. If the attacker can modify the parent frame javascript he can just replace the iframe with a phishing page.
This is a lovely form. Ideally, Stripe would offer something like this as a way to quickly generate a nice cc entry form with the intention that site owners would put the generated code directly on their site, or that stripe would host the service themselves. After all, you're already trusting them to run the service, might as well trust them to run the form too.
Not that it's terribly hard to build a stripe-compatible form...
Yeah, I guess that misses the point of isolating the javascript, doesn't it? So, the idea is good, but has to be offered by Stripe to really minimize any exposure.
Merchants are either required to be PCI DSS compliant themselves or outsource their card-handling only to third-party entities who are PCI DSS compliant themselves.
So, one of two things is true:
-- Paymentiframe/tarsnap is a PCI DSS compliant third party
-- the merchant is intentionally violating the PCI DSS rules by sending credit card data to you
I have to agree with everyone here that this doesn't make sense. I'm currently working on integrating Stripe into my application to create a subscription system. By far the easiest part has been payment form. In their tutorial they have a basic form that you can plug into a .html file and create test customers within minutes. It's laid out in 3 well documented steps in that link he calls "daunting".
Ignoring all those extra fees and charges unrelated to a single payment, Authorize.net charges 2.19% + $0.27 in the best case (qualified domestic Visa). In the worst case (non-qualified international MasterCard), they charge 4.49% + $0.2685.
Even only considering the best case, Stripe's 2.9% + $0.30 doesn't seem 'ripoff' to me.
If I was Stripe I'd be politely asking you to take this down. It's using their trademark (presumably) without permission and encouraging their users to do something very inadvisable.
Offering to host this seems like a really bad idea.
I know you're well meaning and trustworthy, but this shouldn't be run by a third party. For long term reliability reasons as much as security.
