Home » Web Dev » Webpack Project is sitting on a vulnerability, avoid it at all costs!

About Prahlad Yeri

Prahlad Yeri
Prahlad is a freelance software developer working on web and mobile application development. He also likes to blog about programming and contribute to opensource.

Webpack Project is sitting on a vulnerability, avoid it at all costs!

The other day, I was going through this medium post which describes the kind of chaos and insecurity currently plaguing the JavaScript world, and the numero uno reason for that is the astronomical number of npm packages.

When you usually install a non-trivial library or application through a package manager, the expectation is that the number of dependencies should be as less as possible. This not only helps you in managing the disk space (very important for cloud hosting), but also makes a manageable code audit possible. For instance, the Python’s Flask package (which is a considerably large web framework, a lot more complex than Webpack which is just a JavaScript bundler) has the following four dependencies:

install_requires=[
 'Werkzeug>=0.14',
 'Jinja2>=2.10',
 'itsdangerous>=0.24',
 'click>=5.1',
],

On the other hand, this trivial Webpack package on NPM has 25 dependencies on various 3rd party packages!!

@webassemblyjs/ast
 @webassemblyjs/helper-module-context
 @webassemblyjs/wasm-edit
 @webassemblyjs/wasm-opt
 @webassemblyjs/wasm-parser
 acorn
 acorn-dynamic-import
 ajv
 ajv-keywords
 chrome-trace-event
 enhanced-resolve
 eslint-scope
 json-parse-better-errors
 loader-runner
 loader-utils
 memory-fs
 micromatch
 mkdirp
 neo-async
 node-libs-browser
 schema-utils
 tapable
 uglifyjs-webpack-plugin
 watchpack
 webpack-sources

However, your worry hasn’t even started yet, your real worry starts when you realize that the other super-trivial package mentioned in that article called is-odd  has a whopping statistics of 1.4 million downloads per week:

Now, any programmer worth his salt will know that its a one line coding effort to determine whether a given number is odd or even, even in JavaScript:

function isEven(n) {
 return n % 2 == 0;
}

function isOdd(n) {
 return Math.abs(n % 2) == 1;
}

Now, our master programmer who developed this “is-odd as a service” not only goes ahead and registers whole new npm packages called is-odd and is-even, but also makes a lot of his other packages depend on it. Can you even begin to imagine what kind of bureaucratic politician you have to be in order to do that!

Now, this in itself couldn’t have caused any problem, the real issue here is that the highly reputed and popular Webpack project is also using one of his packages (for doing a trivial regular expression check on a string) and the dependency chain is such that the following four packages are also pulled in whenever you install Webpack from npm since Webpack depends on them (and this is what explains is-odd’s 1.4 million weekly download figure):

is-odd -> nanomatch -> micromatch -> webpack

Now, even a CS undergraduate should be able to see the management nightmare, not only of burdening your hard disk space of these additional packages whenever you npm install webpack, but also the security nightmares associated with it. In future, if the developer of is-odd package clubbed some malware in his code and propagated it throughout the node-ecosystem, can you even begin to imagine the disaster its going to cause on your production machines? I agree that this applies to other packaging systems like pip and composer too, but problem here is that the number of npm packages is too large and too unmanageable.

And to top it, the developers in the ecosystem are paying no heed to this, they think this is something to be proud of and worthy of chest thumping. They should try to understand that DRY (Don’t Repeat Yourself) becomes a self-harming pattern beyond a certain extent, especially when you start releasing packages like is-odd and is-even. They get argumentative and counter you with a militant defense when you try to explain this point to them. For instance, I raised an issue on Webpack’s Github repository a few days ago for this exact problem (remove dependency from micromatch package) and they simply closed it down giving some hilarious arguments. Their arguments are really interesting, but beyond sanity for someone who values security and maintainability of production applications.

Published on Web Code Geeks with permission by Prahlad Yeri, partner at our WCG program. See the original article here: Webpack Project is sitting on a vulnerability, avoid it at all costs!

Opinions expressed by Web Code Geeks contributors are their own.

(0 rating, 0 votes)
You need to be a registered member to rate this.
1 Comment Views Tweet it!
Do you want to know how to develop your skillset to become a Web Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. Building web apps with Node.js
2. HTML5 Programming Cookbook
3. CSS Programming Cookbook
4. AngularJS Programming Cookbook
5. jQuery Programming Cookbook
6. Bootstrap Programming Cookbook
and many more ....
I agree to the Terms and Privacy Policy

1
Leave a Reply

avatar
1 Comment threads
0 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
1 Comment authors
Mor Recent comment authors

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  Subscribe  
newest oldest most voted
Notify of
Mor
Guest
Mor

That’s why you put pre-built apps/bundles on production systems. Is anyone really that light-headed to run the building/assembly/packing process on a production system? Node, NPM and related tools are a foreign concept on ours. I can’t even begin to imagine what kind of punishment we would face from security if we did as the author suggests in the article (really? running NPM in production? REALLY?). And we don’t have to worry about those billions of packages on a production system either.