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

91–100 of 128 posts

Re: Harvesting credit card numbers and passwords from websites

#91

Post by dmitriid »

Silhouette wrote: post #58
dmitriid wrote: post #49

Earlier quoted context omitted.

The other languages have the same problem. It's only spread over different places. For example, JS doesn't have a standard library. Many languages do. So when JS downloads loads of transitive dependencies, many are there because there's no stdlib. Have you audited your C++, or Java, or Ruby, or... stdlib lately? Especially those that come preinstalled with your OS of choice? Same goes for anything that you download v…

Those standard libraries are typically widely used. In many cases, the source can be examined. In most cases, there's a large professional team at a reasonably reputable organisation responsible for maintaining them. In almost all cases, there are no transitive dependencies not managed by the same people. Once installed on your system, they generally don't change unless you actively change them. While there is some r…

> In many cases, the source can be examined.

Have you examined them, though? ;) And yes, I was thinking about Reflections on Trusting Trust as well :)

> In almost all cases, there are no transitive dependencies not managed by the same people.

That's why I said the risk is spread very differently compared to JS :)

Re: Harvesting credit card numbers and passwords from websites

#92

Post by swyx »

milesvp wrote: post #42
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.

What makes npm particularly bad, is that JS has such a teribad stdlib. When you need to write your own lpad() at some point its easier to include a stupid little package that has dealt with all the edge cases you don't want to care about. So you end up with way more third party deps than a kitchen sink type language. Otherwise, yes this is a fundamental dependency issue.

could we actually take a snapshot of npm’s top used but relatively inert libraries every 6 months or so and freeze them? (call it UserlandJS 2018a, 2018b, etc) and then have a separate dependency manager that only downloads those frozen libraries we include. Userland Package Manager or something. this would approach a stdlib without much effort and we would have more of a chance to catch up on malicious security stuff since there are commonly agreed upon frozen versions that everyone can pore over.

im a total noob at security, please attack/modify this idea if it has any value?

Re: Harvesting credit card numbers and passwords from websites

#93

Post by ehsankia »

jarofgreen wrote: post #21
nikanj wrote: post #17

Earlier quoted context omitted.

The browser’s? People do tend to keep their PC in the local timezone.

I wonder how much pen testing is done by hand and how much by automatic tools? Anyway, I'm being pedantic. There are a lot of great points in this article.

Sure, the night build fails, then in the morning the engineer comes in, looks at it, can't replicate, marks as fixed.

Re: Harvesting credit card numbers and passwords from websites

#94

Post by ehsankia »

spiznnx wrote: post #3

The best part is when you get caught, you can just play dumb and say your npm credentials were compromised (assuming precautions were taken in not using a collection domain tied to you).

In this example situation, the author states:

> I’ve now made several hundred PRs (various user accounts, no, none of them as “David Gilbertson”).

Also

> I go through all the passwords and credit card numbers I’ve collected and bundle them up to be sold on the dark web.

So if you get caught, you don't actually exist and you've already sold it all without any traces.

Re: Harvesting credit card numbers and passwords from websites

#95

Post by swyx »

swyx wrote: post #92
milesvp wrote: post #42

Earlier quoted context omitted.

What makes npm particularly bad, is that JS has such a teribad stdlib. When you need to write your own lpad() at some point its easier to include a stupid little package that has dealt with all the edge cases you don't want to care about. So you end up with way more third party deps than a kitchen sink type language. Otherwise, yes this is a fundamental dependency issue.

could we actually take a snapshot of npm’s top used but relatively inert libraries every 6 months or so and freeze them? (call it UserlandJS 2018a, 2018b, etc) and then have a separate dependency manager that only downloads those frozen libraries we include. Userland Package Manager or something. this would approach a stdlib without much effort and we would have more of a chance to catch up on malicious security stuf…

discussing on twitter here https://twitter.com/swyx/status/949946224043610112

Re: Harvesting credit card numbers and passwords from websites

#96

Post by [deleted] »

saryant wrote: post #28
danschumann wrote: post #26

What 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.

[deleted]

Re: Harvesting credit card numbers and passwords from websites

#97

Post by tlrobinson »

bubble_boi wrote: post #67
danschumann wrote: post #26

What 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…

Author here. Someone in a comment pointed out that you if you could get your code in express middleware (or something depended on by express middleware or similar) you could potentially alter any CSP header in the responses (if it's set in middleware before your's in the chain).

Indeed. Then the middleware could also inject exfiltration JavaScript in `text/html` or `application/javascript` responses, which would work even if the app doesn’t use npm modules on the frontend.

This applies to almost any backend web framework and package manager, but the culture of micro packages in npm suits itself well to this attack.

Re: Harvesting credit card numbers and passwords from websites

#98

Post by tlrobinson »

tlrobinson wrote: post #97
bubble_boi wrote: post #67

Earlier quoted context omitted.

Author here. Someone in a comment pointed out that you if you could get your code in express middleware (or something depended on by express middleware or similar) you could potentially alter any CSP header in the responses (if it's set in middleware before your's in the chain).

Indeed. Then the middleware could also inject exfiltration JavaScript in `text/html` or `application/javascript` responses, which would work even if the app doesn’t use npm modules on the frontend. This applies to almost any backend web framework and package manager, but the culture of micro packages in npm suits itself well to this attack.

Clearly what we need is cryptographically-signed JavaScript and CSP pinning.

(I’m only half joking)

EDIT: oh, CSP pinning is actually a thing that’s been proposed https://www.w3.org/TR/csp-pinning/

Re: Harvesting credit card numbers and passwords from websites

#99

Post by wahnfrieden »

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 Stripe frames are set up by JS. What’s stopping an attacker from wrapping it in their own form, collecting, and having it still submit the details to Stripe?

Re: Harvesting credit card numbers and passwords from websites

#100

Post by antsar »

wahnfrieden wrote: post #99
shaneos wrote: post #77

Earlier quoted context omitted.

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 Stripe frames are set up by JS. What’s stopping an attacker from wrapping it in their own form, collecting, and having it still submit the details to Stripe?

The attacker's code isn't hosted on Stripe's domain. It could render the real Stripe iframe, but could not interact with it (ie. populate form values and submit).

An attacker could try to POST the values directly to Stripe instead, but Stripe presumably uses CSRF-prevention techniques (eg. a token in the form) to stop this as well.

Post reply on HN