I've gotta post the obligatory Ken Thompson hacking the compiler story
Harvesting credit card numbers and passwords from websites
51–60 of 128 posts
Re: Harvesting credit card numbers and passwords from websites
#52One 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.
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?
Re: Harvesting credit card numbers and passwords from websites
#53> 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 )
The browser’s? People do tend to keep their PC in the local timezone.
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.
Re: Harvesting credit card numbers and passwords from websites
#54There 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.
Re: Harvesting credit card numbers and passwords from websites
#55Couldn'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…
Why not host a validated version of jQuery on your server instead of relying on a CDN?
Re: Harvesting credit card numbers and passwords from websites
#56What could be the npm package the author of this article is referring to?
Literally any of them, that's the point.
Re: Harvesting credit card numbers and passwords from websites
#57Earlier quoted context omitted.
How would you exfiltrate that data?
Google Analytics has a query parameter that can be used to extract arbitrary data. So make a request to that with an ID that you control I guess? GitHub mentions it in their CSP post: https://githubengineering.com/githubs-post-csp-journey/
Related: this Analytics attack has actually happened
https://www.reddit.com/r/btc/comments/7dsmvd/my_analysis_of_...
Re: Harvesting credit card numbers and passwords from websites
#58Earlier quoted context omitted.
It's only impossibly hard to audit this kind of thing if you have an insanely large and deep tree of transitive dependencies in the first place. This seems to be a particularly bad problem in the JS world, for this and many other reasons, but most programming languages and their communities don't work that way. Auditing a small number of larger dependencies, when most of them are probably widely used and from reasona…
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 risk in any dependency (cf. Reflections on Trusting Trust) the level of risk is on an entirely different scale in this sort of situation compared to what much of the JS world does every day.
Re: Harvesting credit card numbers and passwords from websites
#59I recently had a problem with a package that doesn't have its npm releases tagged in git. It surprised me how hard it was to figure out which git revisions corresponded to specific npm releases. I had tracked down the npm version of the package that introduced the bug I was trying to fix, but without getting in and doing some real diffing, I couldn't figure out which commit introduced the bug.
At the time, I'd never added anything to npm, but since then, I have. It dawns on me that npm versions aren't tied to git revisions at all!
Re: Harvesting credit card numbers and passwords from websites
#60The 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).
Worse than that, I think. You can claim the npm account that published the package has zero relation to your github page that hosts the untainted source.
The amount of times I've gone to npmjs.com, looked for the "official" version of a package only to get lost in a web of conflicting version and ownership "signals" is staggering. And yet... if it's on npmjs.com, then it's going into your package.json. No one audits that thing. Unless there is an obvious bloat issue. And dependencies of dependencies? NEVER. We have something like 400MB of shit in our node_modules folder. There is no human on earth that could go through that. This is a few times the size of the entire Linux kernel, for context. And it's minified.