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.
> 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?
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?
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.
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.
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.
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?]
The disconnect I perceive here is that you seem to hope there's some technical solution that can factor out an unhardened storefront from a hardened payment processor. That would be nice, but I don't think it can be done today.
Fortunately for developers, PCI's response to this problem seems to be "LA LA LA I CAN'T HEAR YOU".
> The disconnect I perceive here is that you seem to hope there's some technical solution that can factor out an unhardened storefront from a hardened payment processor.
On the contrary, I don't believe that can be done effectively within the architecture we have today. I just don't believe it can be done effectively for hosted integrations that redirect to the service provider either, so I don't see that the embedding approach is any worse than what was already in widespread use.
Moreover, given that it is unrealistic not to provide hosted payment services (since the overheads of doing everything in-house are prohibitive for almost any small business), I think the only useful response is to impose some basic level of audit on any site that is integrating with an external card payment system. But now you're more into economic/commercial/legal arguments than technical ones, because you have to consider what level of oversight is reasonable (given that any fool can set up a fraudulent site regardless of what you do, how much extra burden is it really sensible to impose on legitimate merchants), how it can be enforced (particularly if the site visited by the end user has no direct legal/commercial relationship with the card services companies), and whether there is a sensible balance between functionality/security and actually being able to operate in the first place as a merchant (which is a balance that the UK currently gets absurdly wrong, though I don't think the scenario we're discussing is why).
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.
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.
> 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.
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.