The Life of a Stripe Charge
petekeen.net
The Life of a Stripe Charge
1–10 of 37 posts
Re: The Life of a Stripe Charge
#2"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_...
Re: The Life of a Stripe Charge
#3"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, th…
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-com...
Re: The Life of a Stripe Charge
#4"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, th…
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-com...
Awesome!
Re: The Life of a Stripe Charge
#5"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, th…
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-com...
So do Stripe merchants have to fill out and/or file any PCI DSS compliance materials?
Re: The Life of a Stripe Charge
#6Earlier quoted context omitted.
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-com...
So do Stripe merchants have to fill out and/or file any PCI DSS compliance materials?
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.
Re: The Life of a Stripe Charge
#7Earlier quoted context omitted.
So do Stripe merchants have to fill out and/or file any PCI DSS compliance materials?
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.
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_...
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.
Re: The Life of a Stripe Charge
#8"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, th…
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.
Re: The Life of a Stripe Charge
#9Earlier quoted context omitted.
So do Stripe merchants have to fill out and/or file any PCI DSS compliance materials?
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.
Wow, I just checked their guidance & they absolutely need to reconsider their guidance:
"Do I need to be PCI compliant? What do I have to do?
Anyone accepting credit card payments must be PCI compliant—but with Stripe, it's easy:
Serve your payment page over SSL, i.e., the page's web address should begin with "https", not "http".
Use Stripe.js as the only means by which you accept payment information and transmit it directly to Stripe's servers.
By taking these steps, you completely avoid handling sensitive card data, and keep your systems out of PCI scope."
So use SSL and Stripe.js and I guess you can use all default passwords, not implement anti-virus and allow XSS, SQLi, command injection, and code injection vectors to run wild on your server? After all, none of those could possibly be used to nuke Stripe.js and replace it with code of choice by an attacker?
They are providing highly suspect guidance for sure.
Re: The Life of a Stripe Charge
#10"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, th…
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…
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.