Hacker News Reader

Comment by patcheudor | Hacker News Reader

That was maybe not quite the right language, but is easily salvageable. What the author was trying to convey is that the Stripe.js code is instantiated within the user browser by an HTTP response from the server infrastructure owned by the merchant. The actual credit-card form is delivered by the merchants server & therefore they own all the PCI DSS related controls surrounding ensuring that the payment form code delivered via their HTTP response is secured. If instead of referencing Stripe.js, the merchant instead sent the user directly to https://stripe.com/payment... and the user could validate they are at stripe.com by looking in their address bar & checking the SSL/TLS security by clicking on the lock then that's a different story and the merchant would have far less exposure to the requirements outlined in the PCI DSS.

View on HN

[Stripe Developer] [edited for clarification]

I appreciate your interest in the security of Stripe, I think we definitely share the same goals here (making everything as secure as possible). However, I think there's some misunderstanding in some posts (and in the blog post):

> [...] the Stripe.js code is instantiated within the user browser by an HTTP response from the server infrastructure owned by the merchant When Stripe.js is included within the user's browser by a (mandated https, not http) request, it comes directly from Stripe's servers, not from "the server infrastructure owned by the merchant."

Stripe.js isn't served from the merchant. It comes directly from Stripe. Stripe.js helps keep payment card data away from a merchants own servers.

Keeping card data away from someone's machines doesn't mean that they don't need to comply with the Payment Card Industry Data Security Standards, but it does make things quite a bit simpler.

In most cases it means that they're eligible for one of the light-weight self-assessment questionnaires.

PCI compliance, of course, shouldn't be where people stop thinking about security though. You're absolutely right that if the pointer on the merchant's site is changed to a malicious site, that's where the payment data will go. The merchant needs to keep that pointer safe in the same way that if you're redirecting to a hosted payment form or elsewhere, you need to make sure that isn't tampered with either. (A hosted form has the advantage that at least a customer can view the SSL cert but if they don't recognize the domain (or if the domain is obscure anyway), that's not much good.)

Being compliant with the PCI standards is important but it doesn't cover all of the very, very important points of web security.

We do take security very seriously, and if you happen to find a valid security issue with our service, we pay bounties[1] for properly disclosed vulnerabilities.

If you have any other questions, or would like to wax poetic about security or PCI please don't hesitate to send the security team an email at security@stripe.com or to email me personally at alex@stripe.com.

[1] https://stripe.com/help/security#rewards

My understanding by reading patcheudor's responses is that the issue isn't with Stripe's PCI compliance, but rather the fact that merchants that use Stripe's API need to be fully PCI compliant. According to him, using Stripe's API doesn't obviate the merchant's need to be fully PCI compliant, unless they do something like open up another window where the URL clearly shows that they are inputting a form from Stripe's own servers. Otherwise, the merchant needs to conform to full PCI compliance.

This is my reading of his comment too.. more specifically, that since the page comes from the merchants server, the page could be modified by an attacker to alter the form to (for example) submit credit card details to another server instead of Stripe's.

I think he has a point here. Certainly if the merchants web site is compromised, Stripe's PCI compliance won't prevent or detect the loss of credit card data (since it never reached the point where Stripe could protect it).

> I think he has a point here. Certainly if the merchants web site is compromised, Stripe's PCI compliance won't prevent or detect the loss of credit card data (since it never reached the point where Stripe could protect it).

Yes, this is certainly true. This is why we also use the dashboard to ask the relevant questions from the PCI self-assessment questionnaires. https://support.stripe.com/questions/do-i-need-to-be-pci-com... gives a brief overview, but this discussion is making me think that we need to write something longer and more definitive. There's a lot of confusion around PCI pretty much everywhere.

You're playing semantic shell games here. The user has no reasonable way of knowing that stripe.js came from stripe, and as such, there are no technical OR human controls that enforce that behavior.

In short, the fact that stripe.js is delivered from stripe DOES NOT MATTER, because the user CAN NOT reasonably validate this behavior.

I know you're not dumb over at Stripe; I have a hard time believing that you're not willfully lying. After all, "disrupting" onerous industry security standards is to your competitive advantage.

Alex, thank you for your response. I don't think my original observations about the wording of a support doc falls into a vulnerability disclosure. That doc has since been updated with enhanced guidance which addresses my original concern. As I think we all understand, the merchant must be responsible for ensuring the integrity and security of the HTTP response containing the reference to Stripe.js. After that they are absolved of the requirements surrounding the transmission, processing, and storage of the card data. As the PCI DSS states, they are ultimately responsible for their PCI compliance as the merchant.

This pretty clearly demonstrates to me the problem --- the stripe developers and management themselves don't actually understand the problem.

Patch is right, you need to be PCI compliant and Stripe (despite their recent funding) is apparently misunderstanding the problem with their approach.

And frankly, PCI compliance be damned, can ya'all not see how the "redirect to page" way is more secure.

Stripe hiding behind "our code is fine, only if you get hacked is it a problem" is, quite frankly, disgusting blame redirection.

Reply on news.ycombinator.com