Live data from Hacker News

The Life of a Stripe Charge

petekeen.net

31–37 of 37 posts

Re: The Life of a Stripe Charge

#31

Earlier quoted context omitted.

From the article: > Stripe POSTs at a /tokens API endpoint over https, which means everything is encrypted including the query params

It's still a little unclear: It says that it is a POST, but the URL in the box above contains the card details. Further, the bit of text you quote goes on to say: > ...including the query params. These params include the card number, expiration date, and CVC The URL they give as an example is: &card[number]=4242+4242+4242+4242&card[cvc]=123" rel="nofollow">https://api.stripe.com/v1/tokens?email=foo%40example.com&pay.…

No, the output in the box is from the web console, which uses the GET-style URL as a concise way of showing POST requests.

Re: The Life of a Stripe Charge

#32

Earlier quoted context omitted.

It's still a little unclear: It says that it is a POST, but the URL in the box above contains the card details. Further, the bit of text you quote goes on to say: > ...including the query params. These params include the card number, expiration date, and CVC The URL they give as an example is: &card[number]=4242+4242+4242+4242&card[cvc]=123" rel="nofollow">https://api.stripe.com/v1/tokens?email=foo%40example.com&pay.…

No, the output in the box is from the web console, which uses the GET-style URL as a concise way of showing POST requests.

Ah, I see. Thanks for the clarification!

Re: The Life of a Stripe Charge

#33

Earlier quoted context omitted.

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.

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 infrastr…

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.

Re: The Life of a Stripe Charge

#34
post #24

Earlier quoted context omitted.

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 entirely overwrite the DOM with their code. When it comes to PCI compliance companies are responsible for securing the end to end payment path which includes the security surrounding the de…

Sure, encrypting in Javascript would not affect the security of my server and network. But it would increase security of the system as whole, wouldn't it? That is, an attack on Stripe's servers would be less likely to reveal credit card information.

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. It states that the controls outlined in that document apply to all processing components. A merchant website calling the Stripe JS within the same origin of their domain eg., http://my.ecommercesite.com/payment is a payment component, period. The only way to remove PCI responsibility would be to load the payment page at stripe.com so that the browser URL shows https://stripe.com/...

https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pd...

Re: The Life of a Stripe Charge

#35

Earlier quoted context omitted.

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 infrastr…

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 c…

So what would you have everyone do instead, in your world where complying with overheads imposed by PCI and the like don't matter?

Sure, you could mandate that every legitimate small business collecting credit card information be subject to heavyweight audit processes and be compelled to institute enterprise-grade everything.

If you could actually get away with that, then most small businesses would either switch to charging via other mechanisms and/or fail. It still wouldn't stop fraudsters who don't care what you or PCI or anyone else says from putting convincing-looking forms on their convincing-looking sites and exploiting anyone who is willing to put their numbers in.

In practice, I doubt you actually would get away with that kind of clamp down today. If the card industry really decided to cause serious harm in a part of the economy that generally drives growth and recovery by enforcing its antiquated rules against small businesses, sooner or later it could wind up facing anything up to primary legislation to put it back in its place as governments acted to protect their national interests. Not only would that make economic sense, it would also probably be a big win for just about any politician to do it, given the current anti-bank sentiment almost everywhere.

Of course this is all absurdly hypothetical, because in reality as long as small businesses are being reasonable and using common sense when it comes to securing their facilities, it is very unlikely the card schemes have anything to gain by hassling them or the modern payment services they use. I imagine they're more worried about national chain stores losing card details by the hundreds of thousands or millions.

Re: The Life of a Stripe Charge

#36
post #24

Earlier quoted context omitted.

Sure, encrypting in Javascript would not affect the security of my server and network. But it would increase security of the system as whole, wouldn't it? That is, an attack on Stripe's servers would be less likely to reveal credit card information.

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. It states that the controls outlined in that document apply to all processing components. A merchant website calling the Stripe JS within the same origin of their domain eg., http…

I agree with everything you say. I agree that the most likely point of attack is the merchant's website. I agree encrypting the credit card number in javascript would not remove PCI responsibility from the merchant.

But I don't see how that affects the question of whether the merchant should encrypt the credit card number before sending it to Stripe. Are you saying that such a practice would not improve the overall security of the system? Or that there is no need to improve security if the system is already PCI compliant?

Re: The Life of a Stripe Charge

#37
post #36

Earlier quoted context omitted.

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. It states that the controls outlined in that document apply to all processing components. A merchant website calling the Stripe JS within the same origin of their domain eg., http…

I agree with everything you say. I agree that the most likely point of attack is the merchant's website. I agree encrypting the credit card number in javascript would not remove PCI responsibility from the merchant. But I don't see how that affects the question of whether the merchant should encrypt the credit card number before sending it to Stripe. Are you saying that such a practice would not improve the overall s…

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.
Post reply on HN