Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Payment iframe - the easiest way to insert Stripe into your website

paymentiframe.com

Post reply on HN
Print view View original

51–60 of 84 posts

Re: Payment iframe - the easiest way to insert Stripe into your website

#51

Post by bentlegen »

tptacek wrote: post #47
bentlegen wrote: post #42

Earlier quoted context omitted.

> 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 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 fro…

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.

Re: Payment iframe - the easiest way to insert Stripe into your website

#52

Post by tptacek »

JSadowski wrote: post #50
tptacek wrote: post #38

Earlier quoted context omitted.

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 us…

No, just potentially their credit card information.

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.

Re: Payment iframe - the easiest way to insert Stripe into your website

#53

Post by tptacek »

bentlegen wrote: post #51
tptacek wrote: post #47

Earlier quoted context omitted.

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 fro…

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 if…

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.

Re: Payment iframe - the easiest way to insert Stripe into your website

#54

Post by bentlegen »

bentlegen wrote: post #16

Please don't use this. There is nothing stopping paymentiframe.com from taking your customer's credit card numbers.

Correction: If you're going to use this, please use the generated document and host it on your own domain.

Re: Payment iframe - the easiest way to insert Stripe into your website

#55

Post by tptacek »

cperciva wrote: post #43
bentlegen wrote: post #42

Earlier quoted context omitted.

> 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.

I think Thomas is saying that I'm not "some random guy".

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.

Re: Payment iframe - the easiest way to insert Stripe into your website

#56

Post by bentlegen »

bentlegen wrote: post #51
tptacek wrote: post #47

Earlier quoted context omitted.

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 fro…

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 if…

@tctapek - re: fetching another URL, just use a subdomain exclusive for processing payments (i.e. http://payments.yourdomain.com).

Re: Payment iframe - the easiest way to insert Stripe into your website

#57

Post by cperciva »

tptacek wrote: post #47
bentlegen wrote: post #42

Earlier quoted context omitted.

> 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 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 fro…

Sourcing static content from a static web server

Technically, the iframe is dynamic content, seeing as it's generated by a CGI script based on the parameters in the URL. :-)

Re: Payment iframe - the easiest way to insert Stripe into your website

#58

Post by cperciva »

tptacek wrote: post #55
cperciva wrote: post #43

Earlier quoted context omitted.

I think Thomas is saying that I'm not "some random guy".

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…

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.)

Re: Payment iframe - the easiest way to insert Stripe into your website

#59

Post by cperciva »

bentlegen wrote: post #56
bentlegen wrote: post #51

Earlier quoted context omitted.

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 if…

@tctapek - re: fetching another URL, just use a subdomain exclusive for processing payments (i.e. http://payments.yourdomain.com ).

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.

Re: Payment iframe - the easiest way to insert Stripe into your website

#60

Post by bentlegen »

bentlegen wrote: post #56
bentlegen wrote: post #51

Earlier quoted context omitted.

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 if…

@tctapek - re: fetching another URL, just use a subdomain exclusive for processing payments (i.e. http://payments.yourdomain.com ).

@cperciva – wrong. Both pages have to opt into the same domain for that to work.

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?

Post reply on HN