Myself, I'd place a lot of trust on cperciva, the former FreeBSD security officer, a guy who has written papers on security flaws in Pentium 4 processors. (http://www.daemonology.net/hyperthreading-considered-harmful...)
[edit] paymentiframe.com's FAQ now includes this:
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).
Sure, but you can just compare the two sites' external measures of security, and they're not even close.
Stripe domains:
- Pass optional HTTP security headers (like X-Frame-Options on manage.stripe.com)
- Are pinned to Chrome's HSTS list (http://src.chromium.org/viewvc/chrome?view=rev&revision=...) and pass a Strict-Transport-Security header
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.
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.
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?
I disagree.
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.
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.
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.
As in, even if the "evil script" set it's domain to yourdomain.com, unless your pages on yourdomain.com ALSO do
document.domain = 'yourdomain.com';
The script on the subdomain can't access that content.
[EDIT] Whoever is downvoting this, can you demonstrate otherwise?
It's also crazy enough that I wouldn't want to trust that every browser in the world will always share that same behaviour.
http://www.whatwg.org/specs/web-apps/current-work/multipage/...
Listen, if you don't trust Stripe's JavaScript, just use their HTTP API instead from your server: https://stripe.com/docs/api
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.
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.
Technically, the iframe is dynamic content, seeing as it's generated by a CGI script based on the parameters in the URL. :-)
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.
It surely gives food for thought.
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.
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.