Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

5900 online stores found skimming

gwillem.github.io

Post reply on HN
Print view View original

101–104 of 104 posts

Re: 5900 online stores found skimming

#101

Post by manigandham »

mrweasel wrote: post #90
notmything wrote: post #5

Earlier quoted context omitted.

I work in ecommerce consulting - most of my clients take CC info on their site, the forms on the checkout POST (over SSL) to the PSP who then return a token to the site, all future transactions use the token. Most people don't want to bounce customers to a third party site for payment, it really hurts conversions.

>it really hurts conversions That has to be a local issue, because that is flat out wrong. The majority of all e-commerce sites does exactly that. I have yet to meet a PSP that believe send the entire credit card number, expiry and CVV was the right solution. I've talked to exactly one PSP that supported accepting credit cards in an iframe, and that was only available to existing customers, because they where discont…

> That has to be a local issue, because that is flat out wrong.

You can't declare it a possible local issue and then say it's wrong.

And it's definitely been measured (in my own testing at various companies and by many many others) that it hurts conversions to break the flow into separate redirect.

Re: 5900 online stores found skimming

#102

Post by teh_klev »

MarkMc wrote: post #74
mrweasel wrote: post #3

As the article points out, if someone can inject Javascript into your checkout page, you're most likely also having other security issues. Still, and I'm pretty much being called an idiot every time I point this out: You should NEVER have the user enter credit card information on your site. That is something that is best left to your PSP. If you're Amazon or similar size, fine, I can accept that you most likely have…

> You should NEVER have the user enter credit card information on your site My app client sends the card info to Stripe, then forwards the Stripe token to my server to charge the card each month. So far this is a standard security model. The problem is that if PayPal come along to offer me a cheaper commission on processing subscription payments, I cannot simply switch my sever to use PayPal for all my existing custo…

> "So I'm tempted to encrypt the credit card info and store it in my database in case I want to switch in future."

Seriously....just don't. The world of pain you'll be in if you mishandle this data and the symmetric encryption key will probably see you or your clients made bankrupt.

Please read up on PCI-DSS before even considering this:

https://www.pcisecuritystandards.org/document_library

Re: 5900 online stores found skimming

#103

Post by nateberkopec »

jerf wrote: post #98
nateberkopec wrote: post #67

Earlier quoted context omitted.

In this case, since the attacker has access to the source code, they could easily disable a site's Content Security Policy.

"Raises the bar", I did say. They have access but if they're only accessing it through an automated system they may miss it. Plus, I should have pointed out that CSP can be applied at higher layers, including nginx itself or a WAF, that the attacker may not be able to access or modify. I didn't think of it at the time.

Great point, I didn't think of that either.

Re: 5900 online stores found skimming

#104

Post by collinmanderson »

the_mitsuhiko wrote: post #100
zrail wrote: post #60

Earlier quoted context omitted.

Stripe Checkout is loaded in an iframe and stripe.js uses an iframe for data transmission.

I know, but the credit card information for stripe.js lives in an unprotected DOM.

Right. It's sort of a loop hole where they technically use an iframe for PCI compliance, but they don't actually get any security benefit from it.
Post reply on HN