
Payment iframe - the easiest way to insert Stripe into your website - cperciva
http://www.paymentiframe.com/
======
bentlegen
Please don't use this. There is nothing stopping paymentiframe.com from taking
your customer's credit card numbers.

~~~
bryanlarsen
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
> 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=...](http://src.chromium.org/viewvc/chrome?view=rev&revision=84125))
and pass a Strict-Transport-Security header

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

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

~~~
cperciva
_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.

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

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

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

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

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

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

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

~~~
cperciva
_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.

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

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

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

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

~~~
JSadowski
No, just potentially their credit card information.

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

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

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

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

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

~~~
cperciva
_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.

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

~~~
cperciva
_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?

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

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

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

~~~
cperciva
Not based on my understanding of PCI DSS.

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

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

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

------
lsh123
<http://www.wepay.com/api>

~~~
cperciva
Yes, we know that you work for WePay.

~~~
lsh123
Thanks. Great to be popular

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

~~~
cperciva
_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. :-)

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

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

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

~~~
cperciva
I showed it to people at Stripe before announcing it.

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

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

