4 ms·

"Because your server-side process never knows the real card information, it doesn't fall into PCI compliance scope." WRONG! The payment code is delivered by a

"Because your server-side process never knows the real card information, it doesn't fall into PCI compliance scope." WRONG! The payment code is delivered by a response from the server-side & as such it is in scope for at least PCI section six. As an example, if the JavaScript code or reference comes via an HTTP & not HTTPS request it can be tampered with on the wire & the code replaced with code from the attacker, thus getting in the middle of the transaction. If there's an SQLi or persistent type-2 XSS flaw on the server side an attacker could similarly modify the code there. People need to stop believing that tokenization does anything more than remove the need to protect credit-cards in memory on the server side & pay attention to their security. Since the concept of tokenization hit the scene I'm seeing worse security around card transactions than I ever have before in my reviews. Worse, people convinced that tokenization entirely clears them from PCI responsibility tend to be argumentative & resistant to what I believe to be common sense guidance. Luckily the PCI council has been made aware of these issues and provided some clarification about tokenization: https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf https://www.pcisecuritystandards.org/documents/Tokenization_...

zrail 13y ago
Thank you for the link. That sentence is wrong, I'll fix it to say something along the lines of "your PCI compliance scope is reduced to the things Stripe requires you to do on their security guidelines[1]" (edit: For what it's worth my book does not make the same mistake, and in fact has a whole chapter dedicated to PCI and HTTPS implementation.) [1]: https://support.stripe.com/questions/do-i-need-to-be-pci-compliant-what-do-i-have-to-do https://support.stripe.com/questions/do-i-need-to-be-pci-com...
- patcheudor 13y ago
  Awesome!
- pbreit 13y ago
  So do Stripe merchants have to fill out and/or file any PCI DSS compliance materials?
  - zrail 13y ago
    According to Stripe themselves, no. Honestly most of PCI is common-sense stuff that you should be doing anyway (firewalls, restricting access, etc) but the compliance audits are strictly optional with Stripe as long as you're serving over HTTPS and are using their tokenizing javascript.
    - patcheudor 13y ago
      Then Stripe might want to reconsider their guidance in light of the PCI guidance on tokenization. Reference: "2.4.2 Merchant Responsibilities" https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf https://www.pcisecuritystandards.org/documents/Tokenization_... The only way out of being responsible for PCI compliance would be to offload the entire transaction to the payment provider. This means sending the customer entirely off domain of the merchant (iFrames don't get you there) so that the entire same origin of the transaction is within the complete control of the payment provider. The second the merchant loads an iFrame or any JavaScript within their same origin, they are accountable, period.
      - deleted 13y ago
        [deleted]
      - pbreit 13y ago
        After reading the doc and paying close attention to that section, it's not clear to me what the Stripe problem is. I didn't see anywhere that the Stripe approach would not comply.
        patcheudor 13y ago
        Because the merchant is still responsible for delivering the payment form within their same origin in a secure manner which means that the merchant must secure their hosts so that the delivery of that payment form cannot be tampered.
    - patcheudor 13y ago
Silhouette 13y ago
If the PCI guys really want small businesses to be careful around tokenization, one might suggest that publishing yet another very long document about technicalities is rather self-defeating. It's the new generation of payment services like Stripe that are offering out-of-the-box forms and vaults and tokenization and so on. These services are doing well precisely because they manage to make the card payment industry dinosaur and its anachronistic practices and endless bureaucracy at least moderately competitive again for small/medium businesses. However, if the underlying card schemes and their PCI attack dog start trying to hard to throw their weight around in this sort of area, the industry is going to haemorrhage business to alternative payment methods even faster than it already is.
- patcheudor 13y ago
  The problem is when companies like Stripe provide misleading or patently false guidance in order to build their business. It's very amazing when people buy-into the idea of completely side-stepping PCI by implementing SSL & some Javascript within their same origin.
  - Silhouette 13y ago
    Where did this same origin fixation you have come from? You keep mentioning it, but stripe.js or checkout.js would normally be loaded directly from a subdomain of stripe.com over HTTPS, and the pages that load that JS, which really are coming from the vendor's own domain, are also required to be served via HTTPS according to Stripe's guidance. To compromise that set-up without compromising the communications infrastructure or Stripe itself, an attacker would need to be able to modify the files served from the vendor's system. Anyone who can do that can just as easily serve a page that puts a form up asking for card details but then simply e-mails anything submitted to the accountant of their favourite Nigerian prince, never going anywhere near Stripe. So what is it you're concerned about here and how do you think anything in PCI DSS actually makes it better?
    - patcheudor 13y ago
      The reference to the Stripe JS must come from the same origin of the merchant. Look at Stripe's own example, the form is hosted in the same origin of the merchant, therefore if there are any security flaws which would allow a bad guy to publish their own JS or markup within the merchant domain the security of the collection form is done. It doesn't matter that the JS is loaded from stripe.com because that reference can be stopped or replaced.
lsh123 13y ago
+1000 You should also mention SDLC process to make sure that a rogue developer of the merchant app doesn't send credit card numbers to a server somewhere else.

zrail 13y ago

Thank you for the link. That sentence is wrong, I'll fix it to say something along the lines of "your PCI compliance scope is reduced to the things Stripe requires you to do on their security guidelines[1]" (edit: For what it's worth my book does not make the same mistake, and in fact has a whole chapter dedicated to PCI and HTTPS implementation.) [1]: https://support.stripe.com/questions/do-i-need-to-be-pci-compliant-what-do-i-have-to-do https://support.stripe.com/questions/do-i-need-to-be-pci-com...

patcheudor 13y ago
Awesome!
pbreit 13y ago
So do Stripe merchants have to fill out and/or file any PCI DSS compliance materials?
- zrail 13y ago
  According to Stripe themselves, no. Honestly most of PCI is common-sense stuff that you should be doing anyway (firewalls, restricting access, etc) but the compliance audits are strictly optional with Stripe as long as you're serving over HTTPS and are using their tokenizing javascript.
  - patcheudor 13y ago
    Then Stripe might want to reconsider their guidance in light of the PCI guidance on tokenization. Reference: "2.4.2 Merchant Responsibilities" https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf https://www.pcisecuritystandards.org/documents/Tokenization_... The only way out of being responsible for PCI compliance would be to offload the entire transaction to the payment provider. This means sending the customer entirely off domain of the merchant (iFrames don't get you there) so that the entire same origin of the transaction is within the complete control of the payment provider. The second the merchant loads an iFrame or any JavaScript within their same origin, they are accountable, period.
    - deleted 13y ago
      [deleted]
    - pbreit 13y ago
      After reading the doc and paying close attention to that section, it's not clear to me what the Stripe problem is. I didn't see anywhere that the Stripe approach would not comply.
      - patcheudor 13y ago
        Because the merchant is still responsible for delivering the payment form within their same origin in a secure manner which means that the merchant must secure their hosts so that the delivery of that payment form cannot be tampered.
  - patcheudor 13y ago

Silhouette 13y ago

If the PCI guys really want small businesses to be careful around tokenization, one might suggest that publishing yet another very long document about technicalities is rather self-defeating. It's the new generation of payment services like Stripe that are offering out-of-the-box forms and vaults and tokenization and so on. These services are doing well precisely because they manage to make the card payment industry dinosaur and its anachronistic practices and endless bureaucracy at least moderately competitive again for small/medium businesses. However, if the underlying card schemes and their PCI attack dog start trying to hard to throw their weight around in this sort of area, the industry is going to haemorrhage business to alternative payment methods even faster than it already is.

patcheudor 13y ago
The problem is when companies like Stripe provide misleading or patently false guidance in order to build their business. It's very amazing when people buy-into the idea of completely side-stepping PCI by implementing SSL & some Javascript within their same origin.
- Silhouette 13y ago
  Where did this same origin fixation you have come from? You keep mentioning it, but stripe.js or checkout.js would normally be loaded directly from a subdomain of stripe.com over HTTPS, and the pages that load that JS, which really are coming from the vendor's own domain, are also required to be served via HTTPS according to Stripe's guidance. To compromise that set-up without compromising the communications infrastructure or Stripe itself, an attacker would need to be able to modify the files served from the vendor's system. Anyone who can do that can just as easily serve a page that puts a form up asking for card details but then simply e-mails anything submitted to the accountant of their favourite Nigerian prince, never going anywhere near Stripe. So what is it you're concerned about here and how do you think anything in PCI DSS actually makes it better?
  - patcheudor 13y ago
    The reference to the Stripe JS must come from the same origin of the merchant. Look at Stripe's own example, the form is hosted in the same origin of the merchant, therefore if there are any security flaws which would allow a bad guy to publish their own JS or markup within the merchant domain the security of the collection form is done. It doesn't matter that the JS is loaded from stripe.com because that reference can be stopped or replaced.

lsh123 13y ago

+1000 You should also mention SDLC process to make sure that a rogue developer of the merchant app doesn't send credit card numbers to a server somewhere else.