Seems particularly prescient given
https://news.ycombinator.com/item?id=16087024
Harvesting credit card numbers and passwords from websites
71–80 of 128 posts
Re: Harvesting credit card numbers and passwords from websites
#72Earlier quoted context omitted.
You could arguably come up with something similar for backends. It's just a story of a malicious and sneaky dependency.
exactly. I question all these comments by people singling out npm as the root of the problem. doesn't sound to me like they fully understand the issue.
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".
Re: Harvesting credit card numbers and passwords from websites
#73What if the author snuck his code into frontend modules, and also snuck his code into backend modules? If CSP is enabled, the frontend checks to see if the backend code has opened up the particular port or route on the backend. The back-end code could sniff through require.cache to see if he could hook into the existing server instance ( same port ), or open a new port ( depending on CSP ). I suppose the CSP equivale…
He'd have to somehow make outbound requests from the server. IIRC, the default AWS VPC config would prevent this. Not sure about other cloud environments. Where I work, outbound requests must be made through proxy servers which have a whitelisted set of allowed domains, which is only allowed after a security review.
AWS default VPC config whe does not block outbound by default. Neither in the security group nor the ACL. And of the half dozen AWS hosted startups I’ve worked for nobody restricts outbound yet. “Security nice to have, not prioritized yet”
Re: Harvesting credit card numbers and passwords from websites
#74Earlier quoted context omitted.
That makes sense but then the article's claim of losing half the credit cards is only true if we assume even distribution of user activity which seems far fetched at best.
I originally wrote "about half" but there was one too many words in the sentence. Also I figure for an eCommerce site max-traffic might be 7-9pm or something so even though there's more sleeping happening outside 7am-7pm, there might be equal traffic. Anyway ... close enough.
Yeah it’s a total nitpick, the point is still made.
Re: Harvesting credit card numbers and passwords from websites
#75I'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 think the important part is that it’s a package manager commonly used for front end development, so the malicious code runs directly in the browser. It could have been bower or something else but npm is the probably the most popular choice these days.
Re: Harvesting credit card numbers and passwords from websites
#76There is this trade-off between usability and security. For example being able to load data from other domains, now with origin policy we have do fetch the data server side. One nice thing about web apps is that they do not require a server to work. But due to xxs injections we cant have nice things.
It's almost like the browser is being abused to do something it fundamentally should not be doing. If you need to do that much client side heavy lifting maybe a web browser is not the place for it? The ship has probably sailed on that line of thinking but in my opinion a lot of the pain we experience in web security today comes from people trying to do things they really should not be doing.
There's this vision for the web that we should be able to access public "data", not only web sites "guarding" it.
Re: Harvesting credit card numbers and passwords from websites
#77while this post is about the more general attack vector, its worth pointing out that if you use a modern credit card tool like Stripe Elements it is impossible to steal credit card numbers as they are embedded in an iframe and your page just gets a token that is meaningless to anyone else
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
Re: Harvesting credit card numbers and passwords from websites
#78Wow 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…
thanks!
Re: Harvesting credit card numbers and passwords from websites
#79Earlier quoted context omitted.
exactly. I question all these comments by people singling out npm as the root of the problem. doesn't sound to me like they fully understand the issue.
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?
Re: Harvesting credit card numbers and passwords from websites
#80Earlier quoted context omitted.
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.
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 direct dependencies. But, since the Javascript standard lib is crap, all of my direct dependencies have their own large pile of dependencies, which themselves depend on a bunch of stuff, and so on.
By the time it's all said and done, my "simple" Node project pulls in several hundred dependencies (I didn't go through and count, but my 'yarn.lock' on that project has ~4200 lines). I can't audit all of that code.
(This is particularly bad in Node and Javascript, but applies to other languages too. I don't think anyone's ever fully audited all of our Nuget dependencies, or Python dependencies... fortunately, those both tend to be more self-contained, so at least we know what we're getting there.)