5900 online stores found skimming

Most people don't want to bounce customers to a third party site for payment, it really hurts conversions.

On sites I've been involved with, in 2016, I still have to fight tooth and nail to get SSL on the payment page at all, let alone redirect users somewhere else.

Wouldn't stripe and braintree still effectively let you handle CC on your own site? i.e. If someone can inject JS code there, they can in high likelihood grab CC details even if you're using stripe or braintree. Am I missing something?

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 customers. So I'm tempted to encrypt the credit card info and store it in my database in case I want to switch in future.

- trivial enumeration attacks that could be used to retrieve customer information (name, address, order, payment details, ...)

- XSS issues that could be exploited by sending crafted URLs to customers

In all cases, I received rather lame responses as if the person in question was completely nonchalant about the issues.

All I could do was to avoid those stores myself.

So far received one response: "We do not even accept credit cards!". Tried to explain to her why foreign code on your site might still be a problem.

Expecting many similar responses. Where possible I contacted their developers directly, maybe they will do something.

Horror stories on here range from having the 3DSecure in an iframe to having horrible "secret question" style inline enrollment

My banks implement it decently - weird third party URLs (albeit with the banks name on the EV certs), but using mobile 2FA apps or hardware card readers for the verification. One of my banks enforces 3DSecure for their debit cards (but not credit cards) since all domestic stores support it.

We would probably be much better off if we'd evolved a system where the payment authorisation step was always hosted by the customer's bank, and everyone expected that instead of putting card details or the like into some merchant's site, they would only ever deal with their own bank.

In the absence of such a system, modern 2FA schemes are trying to plug the gap, but they almost always introduce more friction in the process and consequently affect conversion rates. When not everyone is using them, that makes adopting 2FA potentially a worse option commercially than accepting the losses due to a certain level of fraud in return for better conversion rates across the board.

A few reasons:

1) Card issuers don't care because it's merchants who are on the hook for card-not-present fraud.

2) Cardholders don't care because they're never on the hook for fraud.

3) If a specific merchant enforced 3DSecure (to move fraud liability back to the issuer/network) they'd lose more money on lost sales from people that hate 3DSecure (everyone?) than they would save on fraud.

That said, I have seen 3DSecure enforced at ultra-high-fraud merchants like Bitcoin resellers.

It depends on the details, because there are also technologies where the templates are separated and you can add text to them without execution rights. But for all that people on HN may tend to prefer that, in the great big real world, thinking separation of execution and data is a requirement for a template language is a niche view. Even here you can start up a rollicking, free-wheeling debate on the topic, and I'm not even sure where I come down myself.

Unsurprisingly, the scammers use scanners that look for the soft targets first, so, statistically, I'd suspect the claim could be modified to a true statement with "If someone can inject Javascript into your site, they could have hacked your database with just a bit more effort on your site." It's easier to write something that sprays a script tag across a whole bunch of sites that can scrape off anything that gets submitted that looks like a credit card number than it is to write something to go dump databases across all those same sites, because the database is more likely to be customized or have quirky local rules that would make your automated code fail, or draw attention to itself when it froze the database for half an hour, or some other issue like that. But if someone paid personal attention to your site, they could probably grab the whole thing. At this scale, clearly personal attention is not being paid to these sites.

Cryptography does not help here. The problem is that better transaction types (3d secure) are badly implemented by banks and as such not deployed because it's seen as an unnecessary second step.

You could also prevent this problem in general with Content Security Policy, by whitelisting only the domains you know JS should come from. Then, even if they do in fact get a script tag on to your page pointing at a hostile domain, it won't execute unless they also nuke your CSP headers. You can even set up your CSP such that it notifies you upon violations. In theory a hacker could still penetrate all that in one shot by disabling your CSP and then adding their script, but it means if they miss the CSP even briefly that you have at least a chance to be notified before they square it away. It at least raises the bar.

But the real problem here is that we're not generally talking about people who know about CSP, nor is it generally reasonable to expect they would or could, at least right now. It's pretty niche stuff in general. I'm sure if I gave a quiz on CSP here, a ton of people could reply with the correct answers, some of them even without Googling, but in general if I talk to my coworkers about that I'm doing well to get a vague "Yeah, I've heard of that I think..."