5 ms·

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

DASD 14y ago
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.
- bentlegen 14y ago
  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.
  - tptacek 14y ago
    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.
    - DASD 14y ago
      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.
      - tptacek 14y ago
        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.
        DASD 14y ago
        Did my comment not cover something?
    - bentlegen 14y ago
      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.
bryanlarsen 14y ago
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/ 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).
- semenko 14y ago
  > 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=84125 http://src.chromium.org/viewvc/chrome?view=rev&revision=...) and pass a Strict-Transport-Security header
  - tptacek 14y ago
    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.
tptacek 14y ago
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.
- 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 ago
    I think Thomas is saying that I'm not "some random guy".
    - DASD 14y ago
      Your name is familiar...You're the fellow that does security consulting for bingo card sites right? :)
    - tptacek 14y ago
      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.
      - 14y ago
bentlegen 14y ago
Correction: If you're going to use this, please use the generated document and host it on your own domain.

DASD 14y ago

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.

bentlegen 14y ago
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.
- tptacek 14y ago
  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.
  - DASD 14y ago
    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.
    - tptacek 14y ago
      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.
      - DASD 14y ago
        Did my comment not cover something?
  - bentlegen 14y ago
    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.

bryanlarsen 14y ago

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

semenko 14y ago
> 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=84125 http://src.chromium.org/viewvc/chrome?view=rev&revision=...) and pass a Strict-Transport-Security header
- tptacek 14y ago
  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.

tptacek 14y ago

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.

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 ago
  I think Thomas is saying that I'm not "some random guy".
  - DASD 14y ago
    Your name is familiar...You're the fellow that does security consulting for bingo card sites right? :)
  - tptacek 14y ago
    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.
    - 14y ago

bentlegen 14y ago

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