Payment iframe - the easiest way to insert Stripe into your website | Hacker News Reader

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

paymentiframe.com

68 pointscperciva81 comments

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

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.

The book describes techniques that Stripe could use in developing their own iframed credit card form. I'd only trust a solution from them directly.

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.

Did my comment not cover something?

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.

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.

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

> Myself, I'd place a lot of trust on cperciva

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

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?

I disagree.

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

Your name is familiar...You're the fellow that does security consulting for bingo card sites right? :)

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

Great article! (The URL is http://www.daemonology.net/blog/2011-09-01-Iran-forged-the-w... in case anyone wonders.)

It surely gives food for thought.

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.

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

@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?

My understanding is that pages from yourdomain.com would already have document.domain set to 'yourdomain.com', but I'm not a javascript expert.

@cperciva – it is and it isn't. Implicit vs explicit. This answer expands:

http://stackoverflow.com/a/3978372

This reminds me of the WAT talk.

It's also crazy enough that I wouldn't want to trust that every browser in the world will always share that same behaviour.

This document.domain behaviour is documented as part of the HTML spec:

http://www.whatwg.org/specs/web-apps/current-work/multipage/...

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.

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.

Seems like the best solution from where I'm sitting.

Listen, if you don't trust Stripe's JavaScript, just use their HTTP API instead from your server: https://stripe.com/docs/api

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.

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

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

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

asking customers to enter their CC details on your page doesn't break this rule?

It doesn't break that rule for me. It is a reason why other Stripe users might want to think twice before using the iframe I host, of course.

I'm assuming it just sends the Stripe token, and not CC info?

Yes.

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

I'm not asking anyone to use this, just making it available to people who want it and showing off a concept which people can re-implement themselves.

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

Good point, added. I thought it was obvious, but given some of the comments here, I guess it wasn't obvious enough.

Thanks!

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.

As I said: Tools, not policy.

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.

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

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.

And you can accomplish the same thing by using an iframe that you have full control over.

Instead, if you use this service, you're trusting another 3rd party site to be available and to not be compromised.

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.

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.

Just because it isn't most-sensitive doesn't mean that breaching the data isn't a problem.

I've been hanging out in the Stripe Campfire chat for the past week. There's a rather scary number of people who need something like this.

Iframes can leak key presses to an evil parent frame:

https://www.owasp.org/index.php/Cross_Frame_Scripting

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

The point of a payment iframe is to keep javascript inside the frame from doing anything evil to the site outside the frame, not vice versa.

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

site owners would put the generated code directly on their site

That would defeat the protection which the Same Origin policy gives you (since the iframe would have the same origin as the rest of your site).

or that stripe would host the service themselves

Yes, that would be much better.

I meant that they'd put it directly on their pages, no iframe needed. Agree that it'd be much better if Stripe just did it themselves.

I meant that they'd put it directly on their pages, no iframe needed.

At the expense of loading third party javascript directly into their pages, you mean?

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.

I would never ever use this. Too much of a security risk.

Would using this service affect one's PCI DSS compliance?

Not based on my understanding of PCI DSS.

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

So, which is it?

Nobody is sending credit card data to me. I'm serving up a form with javascript which sends the credit card data directly to Stripe.

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

http://www.wepay.com/api

Yes, we know that you work for WePay.

Thanks. Great to be popular

This may be even more unsecure. Who would like their user to put in their creditcard information on a unknown site?

The change for that paymentiframe.com get comprimised I see is way higher, than Stripe is getting comprimised.

The [chance] for that paymentiframe.com get compromised I see is way higher, than Stripe is getting compromised.

We'll have to agree to disagree about that. Not that there's anything wrong with Stripe's security, but I know a little bit about the subject too. :-)

Or use authorize.net's iframe module and save a ton of $ on Stripe's ripoff fees.

http://www.authorize.net/files/cybersource_pricing.pdf

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.

I showed it to people at Stripe before announcing it.

Surprising that they would okay it, but their call I suppose.

Showing it "to people at Stripe" and getting permission to use it are two different things.

I asked if it was OK; they said it was.

Reply on news.ycombinator.com