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(?)
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.
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".
Among other, one of the main benefits of using Stripe is actually freeing users (developers) from the burden of having to get PCI complaint.
Once you have a "payment token", there is no need whatsoever to POST ALL the form data back to "your" server (along with the appended token attribute). At this point all you need is the payment token (and the last 4 digits of the cc for having a weak reference (though enough) to the cc currently being used). This would potential mislead a few users out there who have no idea about the security implications of such action.
To recap, a good Stripe example shall not include any assumptions about having server being PCI complaint. Also, in regards to this example (and the form example in the Stripe docs), there is no mention about the implications of POSTing the form data safely (and not in plain text as one would assumed from the code) e.g. using SSL. Though, this might be trivial to some of you, examples should make this point clear and leave no assumptions behind.
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(?)
<form action="/plans/browserling_developer" method="POST" id="payment-form">...<input type="text" size="30" autocomplete="off" class="card-number"/>...</form>
It would be interesting to know the PCI process for such a setup.