Harvesting credit card numbers and passwords from websites • Hacker News Board

Re: Harvesting credit card numbers and passwords from websites

#111

Post by monokrome » Mon, Jan 08, 2018, 8:24 AM UTC

saryant wrote: post #22

fny wrote: post #16

Couldn't one circumvent CSP by sending the data to a legitimate analytics service that everyone uses like Google Analytics?

This is why, when I recently built a credit card form, we didn't include any trackers or third-party code (beyond our vendor's). No dependencies at all—our vendor also has no dependencies in the JS we use to implement the CC form. That did mean no jQuery, no Google Analytics, no NPM modules and we had to build it as a standalone page outside our React setup, but it's worth it to be able to definitively inspect every…

Here's hoping you do the same for your login form! :D

Re: Harvesting credit card numbers and passwords from websites

#112

Post by nallerooth » Mon, Jan 08, 2018, 8:26 AM UTC

jarofgreen wrote: post #14

> Our penetration testers would see it in their HTTP request monitoring tools! > What hours do they work? My code doesn’t send anything between 7am and 7pm. Which Time Zone? Hah! (Not that this one nit pick takes away from the general very well made point of the article, I just love how TimeZone problems infect everything )

One could run the site's selenium tests every hour or so and then look at the network log (use a proxy while testing). It'd then be easy to catch any request that is not white listed by you.

Of course, we all do this. /sarcasm

Re: Harvesting credit card numbers and passwords from websites

#113

Post by fps_doug » Mon, Jan 08, 2018, 9:11 AM UTC

jmadsen wrote: post #79

IshKebab wrote: post #72

Earlier quoted context omitted.

Nobody is singling out NPM. The issue is the current JavaScript ecosystem and that happens to be provided through NPM, so you can use "NPM" as a shorthand for "the way JavaScript developers these days use NPM to depend on a gazillion trivial packages with totally unknown provenance".

why not just say "excessive dependencies" and be correct, succinct and perfectly clear?

The first problem is excessive dependencies. Just one word: Left-pad. That is a library on its own, for that one simple problem. The JS ecosystem encourages that for any problem, no matter how small it is, you import some existing lib. So at the end of the day you have 100+ dependencies on a project that is only slightly larger than a "hello world" page.

The next problem is that npmjs is "free for all". Imagine anyone could easily add new packages to the debian repo. Sure, I don't expect the debian folks to audit every new addition or update to existing packages, but there is at least some chain of trust, plus there is some incentive to not have malware ridden packages in your distro because it hurts your credibility. A distro is both, an infrastructure and content provider. npmjs is just the infrastructure, so it takes some more messups for people to consider moving away from it.

Re: Harvesting credit card numbers and passwords from websites

#114

Post by altstar » Mon, Jan 08, 2018, 9:30 AM UTC

djsumdog wrote: post #15

btown wrote: post #13

One of the biggest problems here is that there is no “chain of custody” from Github source to uploaded NPM module; otherwise one of the developers using the malicious package could have audited the source code before including it in their own code. ‘npm publish’ would ideally insist on reproducible builds, enforce this by minifying or compiling packages itself, and finally encourage the community to always audit the…

Even if you had that, no one is going to inspect all that code. npm is a cluster-farkle of insane amounts of packages. The whole point of the article is you should implement CSP.

He actually has a work-around to CSP. He updated his post.

Re: Harvesting credit card numbers and passwords from websites

#115

Post by awq123 » Mon, Jan 08, 2018, 2:27 PM UTC

saryant wrote: post #22

fny wrote: post #16

Couldn't one circumvent CSP by sending the data to a legitimate analytics service that everyone uses like Google Analytics?

This is why, when I recently built a credit card form, we didn't include any trackers or third-party code (beyond our vendor's). No dependencies at all—our vendor also has no dependencies in the JS we use to implement the CC form. That did mean no jQuery, no Google Analytics, no NPM modules and we had to build it as a standalone page outside our React setup, but it's worth it to be able to definitively inspect every…

Incredible

Re: Harvesting credit card numbers and passwords from websites

#116

Post by program_whiz » Mon, Jan 08, 2018, 3:34 PM UTC

Easy Solution: on login and payment forms, go to a plain HTML page, use a standard form to submit without JS (or only JS you write). Forget client-side validation and/or write it yourself.

Re: Harvesting credit card numbers and passwords from websites

#117

Post by gcornut » Mon, Jan 08, 2018, 4:27 PM UTC

I'm sometimes frustrated by uMatrix blocking every requests to third party website and forcing me to accept each of them when needed. But when I see exploits like this I'm happy that I haven't uninstalled it :D. You still have to be vigilant when whitelisting requests in the uMatrix panel though.

Re: Harvesting credit card numbers and passwords from websites

#118

Post by aristeol2000 » Mon, Jan 08, 2018, 4:29 PM UTC

saryant wrote: post #22

fny wrote: post #16

Couldn't one circumvent CSP by sending the data to a legitimate analytics service that everyone uses like Google Analytics?

This is why, when I recently built a credit card form, we didn't include any trackers or third-party code (beyond our vendor's). No dependencies at all—our vendor also has no dependencies in the JS we use to implement the CC form. That did mean no jQuery, no Google Analytics, no NPM modules and we had to build it as a standalone page outside our React setup, but it's worth it to be able to definitively inspect every…

very interesting!

Re: Harvesting credit card numbers and passwords from websites

#119

Post by asd1 » Mon, Jan 08, 2018, 5:05 PM UTC

saryant wrote: post #22

fny wrote: post #16

Couldn't one circumvent CSP by sending the data to a legitimate analytics service that everyone uses like Google Analytics?

This is why, when I recently built a credit card form, we didn't include any trackers or third-party code (beyond our vendor's). No dependencies at all—our vendor also has no dependencies in the JS we use to implement the CC form. That did mean no jQuery, no Google Analytics, no NPM modules and we had to build it as a standalone page outside our React setup, but it's worth it to be able to definitively inspect every…

f

Re: Harvesting credit card numbers and passwords from websites

#120

Post by moreless » Tue, Jan 09, 2018, 9:19 AM UTC

gcornut wrote: post #117

I'm sometimes frustrated by uMatrix blocking every requests to third party website and forcing me to accept each of them when needed. But when I see exploits like this I'm happy that I haven't uninstalled it :D. You still have to be vigilant when whitelisting requests in the uMatrix panel though.

Note that uMatrix doesn't protect you (by default) from sending data out.

It also depends on the page you are visiting. If it's just some random post on net I actually don't care much if they do manage to post data elsewhere (the risk in that case is actually higher if I allow ajax.googleapis.com than some random non-google page), but with banking sites and credit card forms you need to be careful.