6 ms·

I'm not sure about avoiding PCI compliance so easily. You're embedding their JS library on your page. That page has to be secure, otherwise if someone can injec

by Erwin 15y ago

I'm not sure about avoiding PCI compliance so easily. You're embedding their JS library on your page. That page has to be secure, otherwise if someone can inject malicious Javascript they can sniff the CC data as soon as they are entered. You might not be storing the data on your servers, or transmitting the data directly, but security failures in your setup can cause the data to be leaked. Compare this to sending the user to an external website via a redirect that lets the user at least verify that they're really talking to PayPal or whoever.

boucher 15y ago
You're right, you should be using SSL on your payment pages. It's required for our users (see https://stripe.com/help/ssl https://stripe.com/help/ssl). PCI, however, doesn't actually have requirements around SSL, so it's not technically related to PCI compliance.
yahelc 15y ago
They require that you host your payments in HTTPS. https://stripe.com/help/ssl https://stripe.com/help/ssl They themselves are PCI Compliant. https://stripe.com/security https://stripe.com/security
tptacek 15y ago
PCI is absolutely schizophrenic about this point, and right now embedding your provider's form within your own same origin domain is kosher with them. You're right if you're thinking it shouldn't be.
- Silhouette 15y ago
  > You're right if you're thinking it shouldn't be. Why do you think it should not? AFAIK, doing so exempts you (legitimately) from much of PCI DSS that applies if sensitive data hits your network, but does not automatically exempt you from the rest. Are you concerned that someone will be able to compromise the page on your own server so it no longer embeds the payment service's form correctly, and then capture card data that way?
  - tptacek 15y ago
    The exemption you are talking about is not legitimate, because of the way browser security works.
    - Silhouette 15y ago
      Perhaps you could elaborate, rather than posting vague innuendo about "how browser security works"? What specific danger do you see in the embedding scenario that could not arise anyway if the host system were compromised sufficiently to interfere with the embedded material?
      - m0nastic 15y ago
        I'm obviously not tptacek, but I take his statement to mean that currently, PCI finds the following scenario acceptable: You have a site that takes payment info. Rather than process that information directly and store it you decide to use a service like this to silo out payment processing. This keeps your main environment outside of the scope of a PCI audit (as the only systems in scope for PCI are systems which either process or store payment card information). You are now not under any obligation to ensure that your application isn't riddled with security vulnerabilities, including vulnerabilities like cross-site scripting which would completely undermine the security of using a third-party javascript library to handle payment processing. This isn't some sci-fi scenario either, I see this every day in the applications I test (mostly e-commerce and online banking applications). Using the library hasn't introduced any "new" vulnerabilities into your environment, but it has given you an opt-out to actually trying to have a secure system. He seems to take exception to the fact that PCI doesn't see any problem with this. It's basically a loophole to continue to deploy hole-riddled applications that once hacked, you can say "We are PCI compliant, what are you gonna do." This gives credence to the people who argue that PCI isn't really a security standard, but just a way to shift blame after a breach.
        tptacek 15y ago
        What he said. :)
- cperciva 15y ago
  You're right if you're thinking it shouldn't be. Nonsense. That would only be true if PCI was somehow related to security. ;-)
dminor 15y ago
> I'm not sure about avoiding PCI compliance so easily. You're embedding their JS library on your page. That page has to be secure, otherwise if someone can inject malicious Javascript they can sniff the CC data as soon as they are entered. If their credit card info doesn't touch your server, then it is out of scope as far as PCI is concerned. Yes it's BS, since the risk is essentially the same, but that's how it's currently written.

by Erwin 15y ago

boucher 15y ago

You're right, you should be using SSL on your payment pages. It's required for our users (see https://stripe.com/help/ssl https://stripe.com/help/ssl). PCI, however, doesn't actually have requirements around SSL, so it's not technically related to PCI compliance.

yahelc 15y ago

They require that you host your payments in HTTPS. https://stripe.com/help/ssl https://stripe.com/help/ssl They themselves are PCI Compliant. https://stripe.com/security https://stripe.com/security

tptacek 15y ago

PCI is absolutely schizophrenic about this point, and right now embedding your provider's form within your own same origin domain is kosher with them. You're right if you're thinking it shouldn't be.

Silhouette 15y ago
> You're right if you're thinking it shouldn't be. Why do you think it should not? AFAIK, doing so exempts you (legitimately) from much of PCI DSS that applies if sensitive data hits your network, but does not automatically exempt you from the rest. Are you concerned that someone will be able to compromise the page on your own server so it no longer embeds the payment service's form correctly, and then capture card data that way?
- tptacek 15y ago
  The exemption you are talking about is not legitimate, because of the way browser security works.
  - Silhouette 15y ago
    Perhaps you could elaborate, rather than posting vague innuendo about "how browser security works"? What specific danger do you see in the embedding scenario that could not arise anyway if the host system were compromised sufficiently to interfere with the embedded material?
    - m0nastic 15y ago
      I'm obviously not tptacek, but I take his statement to mean that currently, PCI finds the following scenario acceptable: You have a site that takes payment info. Rather than process that information directly and store it you decide to use a service like this to silo out payment processing. This keeps your main environment outside of the scope of a PCI audit (as the only systems in scope for PCI are systems which either process or store payment card information). You are now not under any obligation to ensure that your application isn't riddled with security vulnerabilities, including vulnerabilities like cross-site scripting which would completely undermine the security of using a third-party javascript library to handle payment processing. This isn't some sci-fi scenario either, I see this every day in the applications I test (mostly e-commerce and online banking applications). Using the library hasn't introduced any "new" vulnerabilities into your environment, but it has given you an opt-out to actually trying to have a secure system. He seems to take exception to the fact that PCI doesn't see any problem with this. It's basically a loophole to continue to deploy hole-riddled applications that once hacked, you can say "We are PCI compliant, what are you gonna do." This gives credence to the people who argue that PCI isn't really a security standard, but just a way to shift blame after a breach.
      - tptacek 15y ago
        What he said. :)
cperciva 15y ago
You're right if you're thinking it shouldn't be. Nonsense. That would only be true if PCI was somehow related to security. ;-)

dminor 15y ago

> I'm not sure about avoiding PCI compliance so easily. You're embedding their JS library on your page. That page has to be secure, otherwise if someone can inject malicious Javascript they can sniff the CC data as soon as they are entered. If their credit card info doesn't touch your server, then it is out of scope as far as PCI is concerned. Yes it's BS, since the risk is essentially the same, but that's how it's currently written.