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

Re: Harvesting credit card numbers and passwords from websites

#121

Post by alceta » Wed, Jan 10, 2018, 8:54 AM UTC

ufmace wrote: post #102

jmadsen wrote: post #39

I'm more of a back-end dev who doesn't know all the ins and outs of the actual software used - can someone explain to me why this is an npm problem, and not an excessive dependencies problem? I thought npm was simply a package manager - I don't see anything in the article that is specific to npm, except he happens to say that word.

It's kind of an excessive dependencies problem, except exacerbated by two things. One is Javascript's poor stdlib. This means that not only are you tempted to include lots of little packages to do basic things, but so are all of the big packages that you include to do big things for you, and all of the packages they include, etc. Often there are a bunch of different packages for doing the same basic things, and nobod…

In Ruby, the exact same problem applies since you can publish gems in one version and tag them in another - in the very same fashion as the article describes.

Re: Harvesting credit card numbers and passwords from websites

#122

Post by Tomte » Wed, Jan 10, 2018, 5:05 PM UTC

JonathonW wrote: post #80

mulmen wrote: post #52

Earlier quoted context omitted.

Sure but why not implement CSP and also get your packages from somewhere trustworthy and audit the code you actually run? Just because "most people are lazy" doesn't mean you have to be. "Audit the code you run" is still good advice right?

I have a fairly simple Node project at work; it pulls in nine runtime dependencies, plus 13 development-time dependencies (most of those are babel or eslint-related). Assuming none of those are pulling shenanigans like mentioned in the article (distributing different code than in their source repositories, or deliberately obfuscating malicious code), it's not completely unreasonable for me to go through and audit my…

> I have a fairly simple Node project at work; it pulls in nine runtime dependencies, plus 13 development-time dependencies (most of those are babel or eslint-related).

A well known German blog just claimed that creating a new skeleton project using @angular/cli results in 31 direct dependencies, almost a thousand dependencies in total and 300 MB code.

That's just wow.

Re: Harvesting credit card numbers and passwords from websites

#123

Post by pmlnr » Thu, Jan 11, 2018, 10:44 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.

The trouble with the approach in the article is that by adding a npm dependency, it may as well be the script served by 1st party, buried in their react monster.

Re: Harvesting credit card numbers and passwords from websites

#124

Post by pmlnr » Thu, Jan 11, 2018, 10:46 AM UTC

program_whiz wrote: post #116

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.

Half the internet could go static html with css animations without an js and do bacis analytics from server logs. The rest could do webassembly, compiled from another language, missing and npm-dependecy-hell.

Re: Harvesting credit card numbers and passwords from websites

#125

Post by SherPahlavan » Fri, Jan 12, 2018, 9: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…

Ghbdtn rfr ltkf

Re: Harvesting credit card numbers and passwords from websites

#126

Post by [deleted] » Fri, Jan 12, 2018, 9: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…

[deleted]

Re: Harvesting credit card numbers and passwords from websites

#127

Post by slayer_birden » Tue, Jan 16, 2018, 12:37 PM UTC

mkopinsky wrote: post #109

systematical wrote: post #18

This is a problem for the PHP composer ecosystem as well. I took a look at how many vendor packages our core has and its about 20...

The difference with composer is that in most cases you're getting the exact version from github, including the full .git directory. No minification, no "the tarball doesn't match the source". And most composer packages have 0-5 dependencies, whereas most npm packages seem to have 10-20. But too-many-dependencies is a problem there too.

not exactly, actually. composer allows you to pull "dist" version - which is an archive that can be whatever really. you can of course set "prefer-source", but I think theoretically you can have a package without source provided at all.

Re: Harvesting credit card numbers and passwords from websites

#128

Post by sam_goody » Thu, Jan 18, 2018, 10:01 PM UTC

A perfect example of this is the Hot Pockets deal.

Some guy made a cookie session middleware called node-yummy, which eventually became a dependency of Express. Express has a bajillion downloads, so yummy up and brokered a deal by which on every install they tweeted a like for Hot Pockets. So, Hot Pockets really started soaring, with no one having any idea what they were tweeting by installing and updating Express, until someone ruined all the fun by posting it on Medium, and getting picked up by HN [2]

IMO the really not acceptable part is that the open souce projects are not being pulled from Github. When something claims to be open source, we should have a gaurantee from NPM that we can see the source. The current setup implies the opposite [1] https://github.com/defunctzombie/node-yummy/issues/7 [2] https://medium.com/friendship-dot-js/i-peeked-into-my-node-m...