patcheudor

51 ms·

451.
by patcheudor 13y ago
Confirmed.
452.
by patcheudor 13y ago
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 co
453.
by patcheudor 13y ago
I think you just hit on a major issue that merchants face when it comes to the PCI DSS. Many merchants have been wrestling with the scope of PCI DSS compliance for years. They are looking for easy solutions where unfortunately there are v
454.
by patcheudor 13y ago
In order to get Stripe.js to execute within the same origin of the merchant environment the merchant must include code like this: <script src='//stripe.com/Stripe.js> within their HTTP response. This can be modifi
455.
by patcheudor 13y ago
Stripe's level one service provider which is independent of the merchants PCI compliance. The merchant is presenting the form for which the user enters their credit card information from within the context (same origin) of their domai
456.
by patcheudor 13y ago
I am simply pointing out that unlike what is covered in the Stripe documentation, a merchant is not absolved of PCI compliance by simply implementing Stripe.js in their HTTP response & turning on SSL/TLS. The PCI DSS and related m
457.
by patcheudor 13y ago
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
458.
by patcheudor 13y ago
Because the PCI guidance isn't factual enough? An essay could be written about the problems with broad statements like merchants only needing to worry about the inclusion of Stripe.JS and the use of HTTPS to be PCI compliant. Luckily
459.
by patcheudor 13y ago
Not ridiculously easy, rather slightly easier as the merchant still must maintain aspects of their environment covered by the PCI DSS as they are still delivering Stripe.js from their server environment. Here's a bit more information
460.
by patcheudor 13y ago
Now if Stripe could practice truth in advertising that would be great. SpecificallY: "Anyone accepting credit card payments must be PCI compliant. Stripe makes it easy to do so: Serve your payment page over SSL, i.e., the page's
461.
by patcheudor 13y ago
Right, encrypting it beforehand makes no difference whatsoever & the merchant must consider that they have PCI obligations so long as they host the form within the context of their same origin.
462.
by patcheudor 13y ago
The most probable place of attack is at the merchant where a bad guy would simply remove the Stripe JS code or modify the DOM in a way to replace the credit-card collection form within the merchant same origin. Please reference the PCI DSS
463.
by 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
464.
by patcheudor 13y ago
In reality, it doesn't matter what controls you implement in the JS including DOM resident encryption. If your network, your server, or your application is vulnerable a bad guy can simply change the payment script directly or even ent
465.
by patcheudor 13y ago
Yup, and that's just the start of the issues when it comes to trying to side-step PCI compliance through claiming tokenization takes care of it all.
466.
by 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.
467.
by patcheudor 13y ago
The PCI council has already provided the evidence for which I've already provided the link. Read the PCI guidance surrounding tokenization. It makes it very clear. Just think about this rationally for a second. If you are a merchan
468.
by 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 J
469.
by patcheudor 13y ago
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 ea
470.
by 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_...
471.
by patcheudor 13y ago
Awesome!
472.
by patcheudor 13y ago
"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
473.
by patcheudor 13y ago
My warning to you and anyone else thinking of building a thermostat for an HVAC system with a gas furnace: https://community.sparkdevices.com/t/burning-down-the-house/...
474.
by patcheudor 13y ago
Building a thermostat for a gas furnace is never worth it because someone could die: https://community.sparkdevices.com/t/burning-down-the-house/...