Hacker News Reader

Comment by tomx | Hacker News Reader

In examples like this, is the web page containing the payment form within PCI scope?

I would hope you are at least required to perform PCI level security testing on the page, to ensure it doesn't contain any dodgy Javascript and the like (<script src="some-js-I-didn't-audit-which-steals-stripejs-card-data"...).

Likewise, as there's a webserver serving the page, presumably it must have some level of testing, to ensure it is unlikely to be serving compromised web pages?

As I understand the form in the example, if the user's browser has Javascript disabled, then the form submits the credit card number to the server - putting it in PCI scope(?)

It would be interesting to know the PCI process for such a setup.

View on HN

I work at Stripe.

In examples like this, is the web page containing the payment form within PCI scope?

PCI is often misunderstood, and mostly orthogonal to security itself. Overall security, and things like embedded third-party code, are obviously very important -- you can cripple your security pretty easily no matter what payment system you use if you end up having malicious JavaScript on your page -- but most of these security questions are not PCI issues. Ultimately, PCI simply tries to prevent the most common mistakes that people make when storing and transmitting card numbers.

With stripe.js, cardholder information is submitted directly to Stripe -- it never touches your server. If you use stripe.js and serve the associated form over SSL, Stripe handles PCI compliance for you -- you don't have to do anything else.

If you don't use stripe.js, and have card details traverse your server, then you're within the scope of PCI, and will probably have to fill out a PCI "self-assessment questionnaire".

The no-JavaScript point is a good one. We recommend (see https://stripe.com/docs/tutorials/forms) that you omit the "name" attribute on form elements in order to prevent them from being included if the form is submitted.

As I understand Stripe, if a user doesn't have JS enabled you shouldn't be displaying the form. The idea is that the Stripe JS SDK pulls the values out of the form and then returns a tokenized representation of the payment which is processed on the backend. Thus the server never actually handles payment credentials directly, i.e. your cc and such are not POSTed to the backend. I think this is how they get around some of the more stringent PCI compliance requirements.

In Stripe's official examples the credit card form elements don't have names so they don't submitted. According to them, the only thing you need to do for PCI compliance is use stripe.js in the browser over HTTPS.

which is actually crazy, because if I were to design a malicious ad that gets included on the page where you have your stripe form on, it would be as easy for me to extract the values the user has entered as it will be for stripe.js.

So - even if PCI compliance doesn't require it, I would make sure that the page that the form is on doesn't have any JS dependency that is hosted on a server I don't control.

Longer term, it would probably wise for stripe to host the form in an iframe.

Oh definitely, for my purposes stripe is on a separate page that only has stuff that I host within my app.

I will definitely put this script (recurly.js in my case) on a dedicated page with no third parties included.

Submission is only one part of the problem.

A malicious script included on the same page - MITMed Facebook like buttons, poorly understood copy-paste minified code, a rogue developer - could easily access those fields and make a request to a third-party server with the credit card information as URL parameters.

I'd be interested in what the PCI Council has to say about Stripe's claim that using their service absolves you of all PCI compliance requirements.

There are an effectively unlimited number of potential vulnerabilities in every possible way to accept payment over the Internet.

These are not covered as part of the PCI compliance requirements, as they're not compliance related - there's no way to effectively prove you have mitigated an "unknown unknown" (to quote Mr. Rumsfeld).

In Stripes instance, YOUR servers and systems never handle or see a CC number, and so they are outside of the scope of what PCI covers. Stripes software and servers, on the other hand, ARE covered by PCI, and it's THEIR job to be compliant, etc.

> These are not covered as part of the PCI compliance requirements, as they're not compliance related - there's no way to effectively prove you have mitigated an "unknown unknown" (to quote Mr. Rumsfeld).

PCI's reasoning behind requirements to prevent cross-site-scripting and similar attacks aren't really "unknown unknowns".

Reply on news.ycombinator.com