PharmaLedger-IMI / fgt-workspace

UC3 Finished Goods Traceability
MIT License
5 stars 3 forks source link

#94 Npm-debug-2.6.9 from Npm-express-4.18.1 #95

Closed joaoluis-pdm closed 2 years ago

joaoluis-pdm commented 2 years ago

From #94

List of Packages with HIGH CVEs

Packages detected HIGH - Npm-debug-2.6.9

location: https://github.com/PharmaLedger-IMI/fgt-workspace/blob/master/fgt-api/package.json

origin: > Npm-express-4.18.1 > Npm-debug-2.6.9 > Npm-@ionic/cli-6.20.1 > Npm-leek-0.0.24 > Npm-debug-2.6.9 > Npm-swagger-ui-express-4.5.0 > Npm-express-4.18.1 > Npm-debug-2.6.9

Vulnerabilities:

(RECURRENT) Cx89601373-08db: debug before 4.3.0 has a memory leak when creating debug instances.
(RECURRENT) Cx8bc4df28-fcf5: debug accepts a regular expression from user input without escaping it. Arbitrary regular expressions could be injected to cause a denial of service attack on the user's browser.
joaoluis-pdm commented 2 years ago

Hi @bonfim-sanofi ! I opened a dedicated issue for this vulnerability, as every one of those is different.

The package debug-2.6.9 is a dependency requested by express-4.18.1 , and express-4.18.1 is already the latest one. ( https://github.com/expressjs/express/blob/4.18.1/package.json#L38 )

So putting it in simple terms, this can only be fixed upstream (at the express package).

What do you suggest ?

bonfim-sanofi commented 2 years ago

You can specify the updated version on your package.json:

npm install debug@4.3

Is there a reason why package-lock.json is not committed?

joaoluis-pdm commented 2 years ago

@pccosta-pdm any reason for the fgt-api/package-lock.json not to be commited ?

Issue qued for an experimentat to override express debug dependency.

pccosta-pdm commented 2 years ago

@pccosta-pdm any reason for the fgt-api/package-lock.json not to be commited ?

According to the git history, the package-lock.json is not committed because the fgt-workspace codebase came from a fork of the "dsu fabric" (and package-lock.json is in the .gitignore)

joaoluis-pdm commented 2 years ago

Ok, so for the fgt-api/ folder we will override .gitignore. All other folders use octopus for building, and there are no dependencies on package.json

I will assign the ticket to me, so that I will do that, and then experiment with overrides of the debug package, to check if the express functionality is broken or not.

joaoluis-pdm commented 2 years ago

The dependency has been overriden by debug-4.3.4 or higher, and has passed the automated tests for the future v0.10.3 candidate version. Although this situation is not desirable (the only "good" fix would be a fix by the upstream package express), the workaround does not seem to break so far.

@pccosta-pdm and/or @TiagoV-PDMFC , care to comment ? (See previous commit on this issue).

joaoluis-pdm commented 2 years ago

From https://github.com/PharmaLedger-IMI/fgt-workspace/issues/94#issuecomment-1216877819 Re-scan at commit https://github.com/PharmaLedger-IMI/fgt-workspace/commit/34ae845c1f29a629b5bc95f8fabfdb5e32b4bacf

List of Packages with HIGH CVEs

Packages detected HIGH - Npm-debug-4.3.4

location: fgt-api/package.json

origin: > Npm-@capacitor/cli-3.7.0 > Npm-debug-4.3.4 > Npm-express-4.18.1 > Npm-debug-4.3.4 > Npm-goodparts-1.3.0 > Npm-eslint-6.8.0 > Npm-debug-4.3.4 > Npm-@ionic/cli-6.20.1 > Npm-debug-4.3.4 > Npm-jest-27.5.1 > Npm-@jest/core-27.5.1 > Npm-@jest/reporters-27.5.1 > Npm-istanbul-lib-source-maps-4.0.1 > Npm-debug-4.3.4 > Npm-swagger-ui-express-4.5.0 > Npm-express-4.18.1 > Npm-debug-4.3.4 > Npm-workbox-cli-6.5.4 > Npm-workbox-build-6.5.4 > Npm-@babel/core-7.18.10 > Npm-debug-4.3.4

Vulnerabilities:

(RECURRENT) Cx8bc4df28-fcf5:
In NPM debug, the enable function accepts a regular expression from user input without escaping it. Arbitrary regular expressions could be injected to cause a Denial of Service attack on the user's browser, otherwise known as a ReDoS (Regular Expression Denial of Service).
joaoluis-pdm commented 2 years ago

npm-debug-4.3.4 is already the latest. The Cx8bc4df28-fcf5 is still not fixed, so it seems a no-fix.

I would say that, the express JS is not being run in debug mode, so the debug functionality is probably not exposed to user input, so the vulnerability probably does not apply. This statement is only a developer's opinion. Not a warranty statement.

In doubt, we also recommend not to expose the Swagger UI to the internet (on the production environment).