Email domain for NPM lib with 6m downloads a week grabbed by expert to make a point Security consultant Lance Vick recently acquired the expired domain used by the maintainer of a widely used NPM package to remind the JavaScript community that the NPM Registry still hasn't implemented adequate security. "I just noticed 'foreach' on NPM is controlled by a single maintainer," wrote Vick in a Twitter post on …
Part of the problem is that JavaScript developers often use packages that implement simple functions that are either already built into the language, like forEach, or ought to be crafted manually to avoid yet another dependency,..."
A problem I see elsewhere, like Java - the language matures, those simple functions that were missing get added to the language and dependencies can get eliminated - quite often they don't - a couple of reasons is fear of breaking things/lack of will/willingness to refactor/rework code
And you often need to be a language expert (rather than a jobbing coder) to understand the corner cases that end up coded into a function.
I've just had a look at the source:
• It's polymorphic and there is no drop in polymorphic replacement. You'd have to look at each use site to see which type it's using - assuming you can figure it out in an untyped language.
• It rejects asynchronous and generator functions whereas the builtins would gamely accept them.That shouldn't be an issue, but it wouldn't be the first time I've seen code depending on an exception being thrown to block something silly happening.
• I think object enumeration is directly equivalent to Object.entries() but I had to look it up because javascript has a kazillion different enumeration options (and if you sense some lack of confidence in my assertion, you are right).
• Enumeration of array-likes includes the holes which all the builtins would skip. You shouldn't have holes in arrays. But if you have, that could be obscure breaking change that turns up who knows where and how.
Now, having, spent twenty minutes figuring that out, I've got to do the work and test it. So why we are doing all this work...?
• Enumeration of array-likes includes the holes which all the builtins would skip. You shouldn't have holes in arrays. But if you have, that could be obscure breaking change that turns up who knows where and how.
Question: An array with holes is a "sparse array"? Or something different? I'm not sure what one would use a sparse array for as I've never used one or seen one used. But a lot of programming languages seem to support them so presumably there are valid use cases?
Holes in javascript are where arrays are missing entries. Do the following:
const array = ['a']; array[2] = 'c';
You now have an object akin to { '0': 'a', '2': 'c' } So
array.forEach( n => console.log(n) )
will print 'a' and 'c' but skip array[1]; i.e. there is a "hole" in your linear array. Whereas
for (let i = 0; i < array.length; ++i) console.log(array[i]);
will print 'a', 'undefined' and 'b'.
Checking for holes is one of the reasons forEach() is fractionally slower than a for-loop.
A sparse array would be where the missing entries are not skipped but implied to be 0. As pointed out above, that's useful for large matrices which have only a handful of non-zero values.
I would say that the problem is more that many JavaScript developers aren't really developers. Or any bloody good.
There's nothing wrong with JavaScript that simply learning the language can't mitigate. The problem is that it has (wrongly) acquired the reputation of being not serious and so a bunch of not-serious coders have jumped on board. Most of them could not function if you removed the paste operation from their code editors, or cut off access to StackOverflow and the like.
-A.
I can't speak about Javascript architecture in general, because I find modern web development and design hateful (at least for many public end users, with design that's profit led rather than user led). However, it's not unusual to find that enterprise software tends to explore more specialist and less frequently used APIs/components/platforms regardless of whether it's web based or not.
There's a lot of personally identifying information out there that could be affected, using applications with components with considerably less than a million downloads a week, and I presume the 500 dependents limit is for public packages only, so if there's a lot of private packages it could cross that threshold and no-one would know about it?
You'd hope developers would maintain a curated local repository to prevent poisoning, but I doubt it..
It is understandable that a startup might not shell out for this, but it is inexcusable for a public company to do so. What s bizarre is that vendor surveys are not asking about this. What is your plan for recovery if rubygems.org gets taken down again? (I only mention them because that's the one I know happened.)
I don't know what is worse, a public library system open for attack or a common programming language that lacks basic (high level) interfaces and needs so many external libraries for standard and obvious functionality.
Why do you need a "foreach" library? That should be basics and a built-in language construct. If you glance over the libraries in npm, then you see a horde of standard stuff that most programming languages provide in the distribution. This is where we should start looking when trying to look at the supply chain problem.
Trying to cover for browser deficiencies by using polyfills or the external import library system is never a secure solution. We already nearly force upgrades of the browser when holes are found. Maybe a fix of the supporting programming language is in order.
I haven't been professionally involved in web development for a few years now, but I sometimes end up doing some troubleshooting or a security review - and I'm genuinely horrified by some of the stuff I see.
The number one issue, of course, is the apparently random inclusion of sundry scripts from all over the place. It's not just polyfills and "frameworks" but also tracking and analytics cut and pasted, sight unseen.
Then there's all the CSS workarounds: they're (usually) less of a privacy hazard, but they can still render a website, well, unrenderable.
But it's the shear sloppiness of the general coding that's telling: static text loaded dynamically because there's some library function that adds some tags the author couldn't be bothered to write out; "class" attributes with dozens of random selectors that have either been cut-and-pasted or simply added by trial and error until the result looked right; inline scripts that presumably originated on Stackoverlow with random bits commented out. While there's clearly a technology problem - there's too much incompatibility across browsers, particularly on mobile devices - there's also an attitude problem: the job isn't done as soon as it looks right, particularly if you don't fully understand how you got to that point.
@DomDF
Writing it yourself does not preclude ACCIDENTAL security holes - so not necessarily trustable as might be exploitable .
I'm not arrogant enough to think a piece of software I write is flawless and as I'm not a full time software security specialist there may be potential exploit issues I'm innocently aware of
If I make an error in my code then bad guys might be able to exploit a weakness in my application.
If a library writer puts an error in her code than bad girls get to exploit a weakness in every application that depends upon that code.
You would think that this means that library writers are somehow better at writing error-free or otherwise unexploitable code.
Doesn't seem to be the case.
-A.
This post has been deleted by its author
So, can we say that there are npm packages around that are the programming equivalent of the flashlight app?
Other question: if I need to include a package X which in turn includes e.g. the foreach package, is there a way to eliminate the foreach dependency from X?
Simple: rewrite package X.
This has numerous benefits:
1) The code is not subject to disappearing from the internet.
2) The code is not subject to malicious modification by people outside your company.
3) The code is not subject to random "upgrades" which add features you do not need, but which increase the attack surface.
4) The code is not subject to random bugs associated with previously mentioned upgrades.
5) It is usually pretty easy to strip unneeded functionality.
Do NOT get me wrong. I've been running Linux at home for almost 25 years. But companies need to be aware of the business risks of running code without a contract.
Mostly, from what I see, you don't need to REWRITE package X. Just WRITE the functionality that you actually require, and don't (a) expect that someone else has done it for you, or (b) believe that because someone else published it then it must be better than whatever you could have created yourself.
-A.
True, especially point b.
Yet another approach is, once you're satisfied with the security of your dependencies (including deep dependencies), to clone your audited version into your own infrastructure. That and a twice yearly or so dependency review, with a view to pruning unneeded or obsolete stuff from the tree.
It's one possible compromise along a continuum to achieve the balance between security, stability, productivity, cost and performance that works for you.
This is one of the reasons the web can be so slow. Coders dynamically linking to trivial bits of code from all over the web. Worse, as per the article, $billion companies placing their crown jewels on these sandy foundations! Why can't they just download the code and statically link/embed it or, better yet, just write and test it properly, at least in the case of the big companies depending on this house of cards. Simple and basic code such as LeftPad or ForEach should never be dynamically linked. Ever.
But let's set aside the sad reality of modern JavaScript development practices for a moment to focus on the security of the NPM accounts for package maintainers.
Let's not set that aside. Copypasta 'no such thing as too many JavaScript dependencies' development practices are what amplify lax NPM account security into web-wide vulnerabilities.
But really, while this /could/ happen, it /would/ only happen if there was some nutter out there who actually had a motive to tank thousands of businesses just for the lols.
We don't know anyone like that, do we?
And certainly not anyone like that with the resources to pull it off, surely?
“But he said he didn't follow through with resetting the password on the email account tied to the "foreach" package, which is fetched nearly six million times a week."
Fetched nearly six million times a week, Why?
The code has not changed in 9 years. The last commit to the source code index.js was Aug 17, 2013. The last commit to the Master branch was the readme file 6 years ago.
The foreach method may not have been in the language when this foreach package was written, but it is now so new code should not be including it.
Even if the foreach method did not exist why would you use a package for such a simple function. Would you not just write the code, after all it is just a for loop.
So again, why is it being fetched nearly six million times a week?
it's how npm programming works
whenever you do an npm build, npm goes out to the internet and downloads any missing dependencies, so anyone who creates a new npm project (whether to quickly test something, homework or ....) will need to include some packages, most of which will include foreach
npm (at least by default) fetches fresh dependencies for each project.
Continuous integration.
A lot of CI scripts clean the build environment on every run (for better or worse) and they run on every single commit (or at least every push). On top of that, CI might be building the software multiple times on every run.
It might also be getting pulled but not actually used if the dev refactored the code but forgot to clean up package.json.
The number of actual users will be much lower than the number of downloads.
"We are all just trusting strangers on the internet to give us good candy from their truck,"
That pretty much sums up a whole load of interactions nowadays. From searching on Google to purchasing almost anything.
And in the real world, you have to trust the food from a food truck if you want to eat.
You have to trust some people to get on in life.
Yep and one reason I can't stand NPM and do my very best to avoid anything to do with it, it's an active disaster area just waiting to explode, fueled by a lot of people who call themselves developer or coder but have zero idea how to be either. What the eff? 131 depedency deep chain pulling deeper and deeper linked chains off random repo sites on the internet and people think this is considered acceptable for Enterprise use?!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
