4 ms·
> 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 b
by bentlegen 14y ago
> 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.
- cperciva 14y agoI think Thomas is saying that I'm not "some random guy".
- DASD 14y agoYour name is familiar...You're the fellow that does security consulting for bingo card sites right? :)
- tptacek 14y agoI 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.
- cperciva 14y agoAgreed, 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.)
- cpach 14y agoGreat article! (The URL is http://www.daemonology.net/blog/2011-09-01-Iran-forged-the-wrong-SSL-certificate.html http://www.daemonology.net/blog/2011-09-01-Iran-forged-the-w... in case anyone wonders.) It surely gives food for thought.
- tptacek 14y agoSourcing 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.
- bentlegen 14y agoHow 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.
- tptacek 14y agoAgain: "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.
- bentlegen 14y ago@tctapek - re: fetching another URL, just use a subdomain exclusive for processing payments (i.e. http://payments.yourdomain.com http://payments.yourdomain.com).
- cperciva 14y agoExcept 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.