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

Harvesting credit card numbers and passwords from websites

medium.com

Post reply on HN
Print view View original

101–110 of 128 posts

Re: Harvesting credit card numbers and passwords from websites

#101

Post by adbachman »

shaneos wrote: post #77
Qerub wrote: post #66

Earlier quoted context omitted.

The attacker could inject code that replaces the Stripe integration with something that looks identical to the end-user but harvests the CCs.

True, but this is easily detected. It’d have to provide tokens to the page, which would fail 100% of the time when sent to the Stripe API. These types of attacks are really only effective when difficult to detect, and therefore allowed to run for more than a very short time

The article addressed that objection, though.

1. Only activate on sessions where it’s never activated before.

2. Only activate one in, say, seven times.

3. Sniff form once, fail to submit, show user "unexpected error, try again", allow normal behavior, success, user moves on

4. pull the numbers

It’s nice to imagine we follow up every single JS or user reported “it fails sometimes?” error, but a clever malicious script author knows we don’t check 100% of the time.

We are required to expect transient and potential errors from third party services, not even Stripe has 100% uptime. This kind of theft looks like a transient and unexplainable error.

Re: Harvesting credit card numbers and passwords from websites

#102

Post by ufmace »

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 nobody agrees on which one, so you may end up with 5 different packages that do the same thing required by various packages you use.

Two is that much of it is expected to be served to the browser, so it's minified. Who audits that the minified code is actually the same as the published Github code?

At least in Ruby and Python, the code from Rubygems/Pip should exactly match that version on Github. Not that anyone necessarily audits that either, but at least it's easier.

Re: Harvesting credit card numbers and passwords from websites

#103

Post by martin-adams »

cesarb wrote: post #43
saryant wrote: post #22

Earlier quoted context omitted.

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…

That's the same as protecting just the login page with https. What prevents code outside the form page from replacing the link which goes to the form page?

Exactly my thought. I guess that would mean it would need some intimate knowledge of the target site this reducing the scalability of the attack. But then again, thee are some clever people out there who could automate it.

Re: Harvesting credit card numbers and passwords from websites

#104

Post by martin-adams »

bo1024 wrote: post #68
Shoothe wrote: post #4

So it seems developers are in fact responsible for dependencies that they use... Who would've thought...

And anyway, what dependencies does a webpage for processing credit cards need?

Very little or none. But it’s easy to get carried away in the client with things like card number validation, detecting the card type based on number, date drop down picker for the expiry date, animation library for showing when it’s processing, etc. Let alone leaving in the standard includes like Google Analytics, tracking URLs, A/B testing tools, etc.

Re: Harvesting credit card numbers and passwords from websites

#105

Post by agumonkey »

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.

I guess it's not npm per se, but js crowdsourcing factor multiplies the attack surface by large powers of ten. In other languages, having the security libs centralized and vetted "might" (you'd need an decent amount of work to ensure that it is safe) avoid getting MITM'd so easily.

Re: Harvesting credit card numbers and passwords from websites

#106

Post by mundungus_a »

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.

The root of the problem is that a dependency can be downloaded and installed from only it's minified/obfuscated form, and without any verification that the code matches what is in the non-minified/obfuscated codebase. This is just exploited through people being dependency-happy and that no one really verifies that a package isn't doing more than what is advertised.

This same problem would exist if any server-side dependency repositories allow for code to be delivered in a pre-compiled form without any verification, similar to npmjs.

Re: Harvesting credit card numbers and passwords from websites

#107

Post by IshKebab »

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?

Because that is the symptom. The problem is that the ecosystem encourages excessive dependencies. You can say "the way the ecosystem encourages huge dependency trees" if you like.

Re: Harvesting credit card numbers and passwords from websites

#108

Post by joneil »

rollcat wrote: post #65
MollyR wrote: post #61

Wow thats a rough read. Could something similar be done to django sites ?

Yes. There are basically three steps here... 1. Use social engineering to get your package included as a dependency; 2. Use obfuscation techniques to hide the real intent of the package; 3. Capture data and send it off to a remote server. First can be pulled off, but really depends on the community / maintainers doing their job right. In case of Django, I imagine that would be pretty hard - while the codebase is gian…

One advantage Python might have is that the dependencies you use are human readable, they're not compiled, minified or obfuscated. This in theory would make auditing dependencies easier, but I imagine 99% of the time people aren't thoroughly auditing.

Re: Harvesting credit card numbers and passwords from websites

#109

Post by mkopinsky »

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.

Re: Harvesting credit card numbers and passwords from websites

#110

Post by jmadsen »

Gaelan wrote: post #85
jmadsen wrote: post #47

Earlier quoted context omitted.

but that has nothing to do with npm. that's the same for any javascript package manager - yarn or bower would be the same.

npmjs.com is the repository both yarn and npm use—this is about npmjs.com the repository, not npm the package manager per se.

that makes it a lot clearer, thanks!
Post reply on HN