I got 18 vulnerabilities by giving npm audit , then i went for the one which is labeled as high.
here is its detail,
High Denial-of-Service Memory Exhaustion
Package qs
Patched in >= 1.x
Dependency of google-search-scraper
Path google-search-scraper > request > qs
More info https://nodesecurity.io/advisories/29
it seems like we need to update request package , so by >npm i request
i have installed it.
now what next, the audit command is giving same results again
please help ,
Thank you
EDIT
Moderate Prototype pollution
Package hoek
Patched in > 4.2.0 < 5.0.0 || >= 5.0.3
Dependency of botkit
Path botkit > botbuilder > jsonwebtoken > joi > hoek
More info https://nodesecurity.io/advisories/566
As the report says, qs vulnerability has been fixed in 1.x. It's not a problem for latest request versions. google-search-scraper has request#~2.33.0 dependency that depends on qs#~0.6.0. Regardless of which request version is installed in the project, google-search-scraper will continue to use 2.33.x version that contains vulnerability.
google-search-scraper should be forked and used instead of original package, request dependency version should be updated in a fork, e.g. to request#^2.33.0. Additionally, an issue can be opened in package repository and supplemented with a PR.
A solution that has worked for me is by initially creating JSON file which will be the manifest. Before installing the npm package start with the followingnpm init -y
that way you agree to all the details that will be added by the JSON file, you can edit them afterwards.
Then proceed with npm install <package name>
Related
react-dev-utils#11.0.4 installing a vulnerable version of browserlist, browserslist#4.14.2, although we have updated package on github. https://github.com/facebook/create-react-app/blob/main/packages/react-dev-utils/package.json#L57
[to test out, you may simple create any folder and do npm i react-dev-utils and then check it using npm ls browserlist]
I dont get, what all are the constraint for this. (I dont see any package-lock.json for this package, which could be a potential reason for the vuln). older version has reported vulnerability CVE-2021-23364.
react-dev-utils#11.0.4 installing a vulnerable version of browserlist, browserslist#4.14.2, although we have updated package on github
This is because that package.json file resides in the default branch which usually contains the latest or development code. At the time you posted the question, that change was not published to the npm registry.
react-dev-utils#11.0.4 has browserslist#4.14.2 listed in its package so that's the version that will be installed. Reference: https://cdn.jsdelivr.net/npm/react-dev-utils#11.0.4/package.json
You need atleast react-dev-utils#12.0.0 to fix that vulnerability. See the versions tab.
[to test out, you may simple create any folder and do npm i react-dev-utils and then check it using npm ls browserlist]
Running that command will install the latest version of react-dev-utils, which now has no vulnerability. So it will fix your issue.
I dont see any package-lock.json for this package, which could be a potential reason for the vuln
package-lock.json cannot be published to registry, only the top level lock file is respected. Reference: Should package-lock.json also be published?
this may be an example package, but how in general we update to latest package? have tried npm update as well.
npm update respects the semver range that you've set in your package.json. If its like "react-dev-utils": "11.0.4" that command won't do anything. If its "react-dev-utils": "^11.0.4", it will try to update to the latest 11.x.x version which you are already on, so again it won't do anything. Reference: npm update does not do anything
In general if you want to upgrade every direct dependency to latest version you can use npm-check-updates before running npm update. Refer https://nodejs.dev/learn/update-all-the-nodejs-dependencies-to-their-latest-version for detailed guide. Related: How to update each dependency in package.json to the latest version?
Now, if it is not a direct dependency, as was in your case, you can force resolutions. This is natively supported in Yarn and NPM v8.3.0 and above. In older NPM versions you need to use a dependency like npm-force-resolutions. Related thread: npm equivalent of yarn resolutions?
There are much more related threads that you can easily find by searching on the web.
I am working on a react project and I am using various npm packages. Now there were 1002 vulnerable packages when I started fixing/updating my old packages. And at last this only 20 vulnerable packages were remained which were also very low priority.
But now again after 3 months the vulnerability has increase to 925 vulnerable packages. So my question is, when I am using packages.lock.json for installing a specific package version only. Then how the vulnerabilities increased. I mean is there any mechanism which npm follow before telling "this package is vulnerable." I want to know how npm check if this package is vulnerable or not. Even when it was fine before and I am using same package version with same node version as well.
npm as a package manager runs audit of the installed/installing dependencies to check for the vulnerabilities posted/reported on that particular NPM package you installed/installing. It list them out to notify/warn you about the problem you might encounter, using such packages.
It will be an API call from npm to the registry. Read further: docs.npmjs.com/cli/audit#description
One can manually audit its dependencies as well. using the following command:
npm audit
Make sure you are running this command in the same directory where your package-lock.json exists.
If you are using yarn as a package manager, you can run:
yarn audit
Here is a great explanation on npm vulnerability.
https://snyk.io/blog/understanding-filesystem-takeover-vulnerabilities-in-npm-javascript-package-manager/
NPM vulnerability check mainly depends on the version and last publish date of each packages.
After running npm audit I have (this is just one of) a moderate warning
Moderate │ Prototype pollution
Package │ hoek
Patched in │ > 4.2.0 < 5.0.0 || >= 5.0.3
Dependency of │ karma
Path | karma > log4js > loggly > request > hawk > sntp > hoek
I can see that hoek is a dependency of karma (further down the chain). Looking at the Karma repo on GitHub I can see that this has been raised but no immediate fix has been prioritised.
Is this something that we just have to accept for now until they have updated their dependencies or can we tell our application to use a more recent version of hoek and apply to all packages?
You can npm install the fixed version of the dependency from a pull request or a commit.
E.g.
npm install github:winstonjs/node-loggly#pull/79/head
Then delete the added line in package.json e.g. "loggly": "github:winstonjs/node-loggly#pull/79/head"
In package-lock.json search for loggly and where it shows "version": "<some git url>", delete the url and replace it with the appropriate version number e.g "1.1.1".
The problem is that loggly hasn't be updated for a long time and is hard-coded to request version that uses hoek version with specified vulnerability. There is open issue.
Considering a role of hoek package here, it's unlikely that it causes real security issue.
From a user's perspective, it's possible to fix security issue by using a branch where this dependency is fixed, e.g. this pull request:
"karma": "^2.0.2",
"loggly": "github:winstonjs/node-loggly#pull/79/head"
Since loggly branch version matches constraints in log4js, this replaces original loggly with fixed one (possibly requires to purge node_modules to take effect).
This causes
400 Bad Request - POST https://registry.npmjs.org/-/npm/v1/security/audits
error for npm audit, so it likely should be left as is for now.
When I download "Intermediate - Advanced users" version of polymer starter kit from github here and on the 4th step of these instructions here I always getting these WARNs:
$ sudo npm install
npm WARN deprecated gulp-minify-css#1.2.4: Please use gulp-clean-css
npm WARN deprecated graceful-fs#3.0.8: graceful-fs version 3 and before will fail on newer node releases. Please update to graceful-fs#^4.0.0 as soon as possible.
npm WARN engine launchpad#0.5.1: wanted: {"node":"^0.12"} (current: {"node":"4.4.2","npm":"2.15.0"})
npm WARN deprecated lodash#1.0.2: lodash#<3.0.0 is no longer maintained. Upgrade to lodash#^4.0.0.
npm WARN optional dep failed, continuing fsevents#1.0.11
npm WARN deprecated graceful-fs#1.2.3: graceful-fs version 3 and before will fail on newer node releases. Please update to graceful-fs#^4.0.0 as soon as possible.
npm WARN deprecated jade#0.26.3: Jade has been renamed to pug, please install the latest version of pug instead of jade
No matter what OS I'm using: tried both Ubuntu and Windows (git bash).
I have npm, bower, gulp installed globally but there's always those WARNs.
I think that maybe it's a dependencies problem or it's because of some code in some of polymer starter kit files, but I'm not a pro developer, so I can't find what is causing the problem
It's all seems to work though when I deploy the project, but I'm new to web dev and not sure if I have to just close my eyes on these WARNs
Nothing to worry about with those warnings. Those come from the npm packages that are set as dependencies in the package.json file. When you run npm install it will install all packages set in the package.json. Every single package has their own package.json that also has some dependenices. Each package install their own needed version of that package and sometimes they use older versions of those packages. Only way to get rid of those warnings would be to get the package creators to update their packages.
Only package that you can update yourself is the gulp-minify-css. You can uninstall that package npm remove gulp-minify-css --save-dev and install the newer non-deprecated version gulp-clean-css. npm install gulp-clean-css --save-dev. If you do that you need to update the gulpfile.js for the project to use the new package.
Find the styleTask for the starter-kit in the gulpfile.js:
var styleTask = function(stylesPath, srcs) {
return gulp.src(srcs.map(function(src) {
return path.join('app', stylesPath, src);
}))
.pipe($.changed(stylesPath, {extension: '.css'}))
.pipe($.autoprefixer(AUTOPREFIXER_BROWSERS))
.pipe(gulp.dest('.tmp/' + stylesPath))
.pipe($.minifyCss())
.pipe(gulp.dest(dist(stylesPath)))
.pipe($.size({title: stylesPath}));
};
and change the .pipe($.minifyCss()) row to be .pipe($.cleanCss({compatibility: 'ie10'}))
Now you have managed to update the starter-kit to use newer non-deprecated package.
Many packages in the npm package manager have some deprecated packages or cause other warnings while installing but most of the time there is no need to worry.
No need to worry about those warnings in this case. They shouldn't cause the problems that you allude to. I verified the PSK guide you mentioned (the page completely appears and functions without error in Chrome Version 49.0.2623.112 on OSX El Capitan).
npm displays deprecation warnings when a dependency being installed has been deprecated by the dependency's package owner/maintainer usually in favor of another package/version that has significant improvements. Packages can be deprecated/undeprecated at will and long after your app has been deployed.
For example, in January, you release an app that depends on gulp-minify-css#1.2.4. The owner of gulp-minify-css no longer has time to maintain the package, so he decides in March to deprecate it in favor of the actively maintained gulp-clean-css. Now, users who npm install your app (which also installs gulp-minify-css) see this deprecation warning, but your app still functions normally. The deprecation does not invalidate your app or cause errors.
While normally one might try to upgrade the dependencies to remove the warnings, that is not recommended for PSK due to package incompatibilities as recently discovered in a pull request:
So I just took this for a spin and I ran into some issues :( although
the current gulp plugins are deprecated they are working for the
community! This PR represents a "high risk" change, that we have found
to be breaking in several odd ways. For that reason I am going to
close this PR for now. That said let's revisit this PR in a few months
and see if things have stabilized more.
I am installing a module globally
$ npm install -g X
and NPM says
"npm WARN deprecated lodash#1.0.2: lodash#<3.0.0 is no longer
maintained. Upgrade to lodash#^4.0.0"
how can I find out which module has an dependency on this old version of lodash?
The warning message from NPM doesn't seem to give me any clue which module references this old version (I believe that the module X does not have a direct dependency on this old version of lodash.).
I got an answer for the similar question: https://stackoverflow.com/a/36335866/1115187
Briefly:
npm outdated --depth=3
This command will analyze installed NPM-packages and their versions. The report will contain:
package name
latest version
current version
dependency path (down to depth level)
Hope, this information could help you to gather info about outdated packages.
Next step - get in touch with maintainers of the appropriate package, and ask them to update the package (maybe, you would like to send a pull request).
UPD: npm-check
There is a great npm package: npm-check, that allows checking outdated dependencies. Probably
My favorite feature: Interactive Update — run npm-check -u in the project folder. An interactive menu shows all required information about dependencies in the current folder and allows to update all dependencies in 3 seconds.
npm la <package-name>
also works, and will give you the most details about the dependency graph of a dependency.
npm ls <package-name>, does something similar but gives you less details
Use npm list. It will print out all of the packages your module depends on as well as your dependencies dependencies and so forth. Maybe redirect output to a file or grep it so you can search it more easily.
use this
sudo npm install --unsafe-perm -g expo-cli
You could search through all the package.json files under node_modules and see which ones are dependent on lodash 1.0.2.
For deprecated files you should use the "npm i [package]" syntax, in this case you should use: npm i X and it will fetch all necessary packages, including deprecated ones, but which are required for your installation.
Npm documentation link: https://docs.npmjs.com/using-deprecated-packages