4 ms·

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 inf

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. :)
Silhouette 15y ago
I'm not disagreeing with your example, but isn't that a much wider problem? After all, any business or individual can set up a web site, stick an official-looking form on it, and harvest card details. They don't need any sort of payment processing infrastructure to do that, and clearly nothing PCI DSS says can protect against all malicious strategies for compromising card details. My understanding was that the parts of PCI DSS we're considering were intended to cover carelessness where a legitimate business collects customer details but then leaves them vulnerable due to internal security failings. If the details don't hit the internal network, those failings can't happen, so it is reasonable to exclude them from the scope of the corresponding parts of PCI DSS. Beyond that, I'm not sure I see any difference between the embedding scenario and the common practice of redirecting to a payment service's own web pages when a customer reaches a certain point in the order process. If you're exposing a vulnerability that lets an attacker compromise the embedding, they can almost certainly compromise the redirect in the equivalent case as well, and in reality it is unlikely that most customers would notice even if there were clues to give away the attack in some cases. I'm also not sure what you mean by keeping your main environment outside the scope of a PCI audit. For the payment gateways we've been looking at that offer both hosted and embedded integrations, it is common that the hosted one has minimal audit requirements but the embedded one comes with certain audit obligations for your web site even if you're relying entirely on their system to handle the card details. Now, if this isn't a mandated practice in PCI DSS, then I do see your point; I've always assumed it is, since everyone we've looked into seems to do it, but in fairness I haven't just looked it up today. However, if that is part of PCI DSS then in fact sites using the embedding strategy are subject to more rigorous scrutiny than those that simply redirect, even though essentially the same attack vectors are probably available for both.
- tptacek 15y ago
  If you're a single XSS vulnerability away from transparently capturing credit card vulnerabilities, but there is no requirement anywhere in PCI DSS that your application be in any way hardened against XSS vulnerabilities, all PCI DSS has done is move the target slightly.
  - boucher 15y ago
    Though to be fair, if you've got an XSS vulnerability, you can also just change the URL of the off site payment page to a phishing site, which most people will probably fall for.
    - jtheory 15y ago
      All of these things fall into the same boat, security-wise -- so by my interpretation, the PCI rules make sense here. If the attacker can insert their own code that says "hi there, we may have to close the site unless we can get some donations ASAP - please help!" followed by a form for CC data, that's that. It doesn't matter if they normally accept payments by redirecting to PayPal, or if they use an iFrame, or the Stripe JavaScript approach. It's all the same at that point, security-wise. So let this be Bucket A, for websites where CC info doesn't touch their servers -- this is their risk profile. If a site in Bucket A is compromised and it takes a month before the complaints add up and the host shuts them down, that's a month's worth of stolen credit cards (this is not "worst case", but let's assume the thieves aren't terribly patient and start selling card info soon after stealing it). Bucket B is for sites where the CC info DOES touch their servers. For them, CC data may be recorded on the server (intentionally into a data store, or even accidentally into log files of some kind). This is a different security risk. A site in this category could be compromised, and in half an hour 10 years worth of their credit card info could be stolen. To steal 10 years worth of CC data from a site in Bucket A is naturally much more difficult. If you've got to draw a line somewhere, that's a reasonable one.
  - Silhouette 15y ago
    I completely agree, I'm just wondering how that's any different to any other hosted integration. Perhaps I misunderstood your original point as being too specific to the embedding situation. Would you apply the same criticisms to the other common integration strategy based on redirects? If your intended point was that any legitimate business taking credit card details via their web site should be subject to at least some basic level of audit, then I think we are probably in agreement (though I do have a thing about card companies imposing security rules on merchants but then trying to leave merchants with all responsibility for any fraud anyway, which is a totally one-sided deal). [Edit: As an aside, I'm not sure how this would work in a case where the merchant is using an end-to-end solution, which Stripe seems to be, and has no direct relationship with any other financial services. Presumably the responsibility then has to fall on the payment service, which would have to impose some sort of reasonable audit procedure on all of its clients?]
dminor 15y ago
> 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. Which it is! What is really needed isn't a better PCI, but a better credit card system - one where a breach has little impact on credit card holders.

tptacek 15y ago

What he said. :)

Silhouette 15y ago

I'm not disagreeing with your example, but isn't that a much wider problem? After all, any business or individual can set up a web site, stick an official-looking form on it, and harvest card details. They don't need any sort of payment processing infrastructure to do that, and clearly nothing PCI DSS says can protect against all malicious strategies for compromising card details. My understanding was that the parts of PCI DSS we're considering were intended to cover carelessness where a legitimate business collects customer details but then leaves them vulnerable due to internal security failings. If the details don't hit the internal network, those failings can't happen, so it is reasonable to exclude them from the scope of the corresponding parts of PCI DSS. Beyond that, I'm not sure I see any difference between the embedding scenario and the common practice of redirecting to a payment service's own web pages when a customer reaches a certain point in the order process. If you're exposing a vulnerability that lets an attacker compromise the embedding, they can almost certainly compromise the redirect in the equivalent case as well, and in reality it is unlikely that most customers would notice even if there were clues to give away the attack in some cases. I'm also not sure what you mean by keeping your main environment outside the scope of a PCI audit. For the payment gateways we've been looking at that offer both hosted and embedded integrations, it is common that the hosted one has minimal audit requirements but the embedded one comes with certain audit obligations for your web site even if you're relying entirely on their system to handle the card details. Now, if this isn't a mandated practice in PCI DSS, then I do see your point; I've always assumed it is, since everyone we've looked into seems to do it, but in fairness I haven't just looked it up today. However, if that is part of PCI DSS then in fact sites using the embedding strategy are subject to more rigorous scrutiny than those that simply redirect, even though essentially the same attack vectors are probably available for both.

tptacek 15y ago
If you're a single XSS vulnerability away from transparently capturing credit card vulnerabilities, but there is no requirement anywhere in PCI DSS that your application be in any way hardened against XSS vulnerabilities, all PCI DSS has done is move the target slightly.
- boucher 15y ago
  Though to be fair, if you've got an XSS vulnerability, you can also just change the URL of the off site payment page to a phishing site, which most people will probably fall for.
  - jtheory 15y ago
    All of these things fall into the same boat, security-wise -- so by my interpretation, the PCI rules make sense here. If the attacker can insert their own code that says "hi there, we may have to close the site unless we can get some donations ASAP - please help!" followed by a form for CC data, that's that. It doesn't matter if they normally accept payments by redirecting to PayPal, or if they use an iFrame, or the Stripe JavaScript approach. It's all the same at that point, security-wise. So let this be Bucket A, for websites where CC info doesn't touch their servers -- this is their risk profile. If a site in Bucket A is compromised and it takes a month before the complaints add up and the host shuts them down, that's a month's worth of stolen credit cards (this is not "worst case", but let's assume the thieves aren't terribly patient and start selling card info soon after stealing it). Bucket B is for sites where the CC info DOES touch their servers. For them, CC data may be recorded on the server (intentionally into a data store, or even accidentally into log files of some kind). This is a different security risk. A site in this category could be compromised, and in half an hour 10 years worth of their credit card info could be stolen. To steal 10 years worth of CC data from a site in Bucket A is naturally much more difficult. If you've got to draw a line somewhere, that's a reasonable one.
- Silhouette 15y ago
  I completely agree, I'm just wondering how that's any different to any other hosted integration. Perhaps I misunderstood your original point as being too specific to the embedding situation. Would you apply the same criticisms to the other common integration strategy based on redirects? If your intended point was that any legitimate business taking credit card details via their web site should be subject to at least some basic level of audit, then I think we are probably in agreement (though I do have a thing about card companies imposing security rules on merchants but then trying to leave merchants with all responsibility for any fraud anyway, which is a totally one-sided deal). [Edit: As an aside, I'm not sure how this would work in a case where the merchant is using an end-to-end solution, which Stripe seems to be, and has no direct relationship with any other financial services. Presumably the responsibility then has to fall on the payment service, which would have to impose some sort of reasonable audit procedure on all of its clients?]

dminor 15y ago

> 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. Which it is! What is really needed isn't a better PCI, but a better credit card system - one where a breach has little impact on credit card holders.