[BUMP] Update dependency jsonwebtoken to v9 [SECURITY]

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
jsonwebtoken	8.5.1 -> 9.0.0

GitHub Vulnerability Alerts

CVE-2022-23539

Overview

Versions <=8.5.1 of jsonwebtoken library could be misconfigured so that legacy, insecure key types are used for signature verification. For example, DSA keys could be used with the RS256 algorithm.

Am I affected?

You are affected if you are using an algorithm and a key type other than the combinations mentioned below

Key type	algorithm
ec	ES256, ES384, ES512
rsa	RS256, RS384, RS512, PS256, PS384, PS512
rsa-pss	PS256, PS384, PS512

And for Elliptic Curve algorithms:

alg	Curve
ES256	prime256v1
ES384	secp384r1
ES512	secp521r1

How do I fix it?

Update to version 9.0.0. This version validates for asymmetric key type and algorithm combinations. Please refer to the above mentioned algorithm / key type combinations for the valid secure configuration. After updating to version 9.0.0, If you still intend to continue with signing or verifying tokens using invalid key type/algorithm value combinations, you’ll need to set the allowInvalidAsymmetricKeyTypes option to true in the sign() and/or verify() functions.

Will the fix impact my users?

There will be no impact, if you update to version 9.0.0 and you already use a valid secure combination of key type and algorithm. Otherwise, use the allowInvalidAsymmetricKeyTypes option to true in the sign() and verify() functions to continue usage of invalid key type/algorithm combination in 9.0.0 for legacy compatibility.

CVE-2022-23541

Overview

Versions <=8.5.1 of jsonwebtoken library can be misconfigured so that passing a poorly implemented key retrieval function (referring to the secretOrPublicKey argument from the readme link) will result in incorrect verification of tokens. There is a possibility of using a different algorithm and key combination in verification than the one that was used to sign the tokens. Specifically, tokens signed with an asymmetric public key could be verified with a symmetric HS256 algorithm. This can lead to successful validation of forged tokens.

Am I affected?

You will be affected if your application is supporting usage of both symmetric key and asymmetric key in jwt.verify() implementation with the same key retrieval function.

How do I fix it?

Update to version 9.0.0.

Will the fix impact my users?

There is no impact for end users

CVE-2022-23540

Overview

In versions <=8.5.1 of jsonwebtoken library, lack of algorithm definition and a falsy secret or key in the jwt.verify() function can lead to signature validation bypass due to defaulting to the none algorithm for signature verification.

Am I affected?

You will be affected if all the following are true in the jwt.verify() function:

• a token with no signature is received
• no algorithms are specified
• a falsy (e.g. null, false, undefined) secret or key is passed

How do I fix it?

Update to version 9.0.0 which removes the default support for the none algorithm in the jwt.verify() method.

Will the fix impact my users?

There will be no impact, if you update to version 9.0.0 and you don’t need to allow for the none algorithm. If you need 'none' algorithm, you have to explicitly specify that in jwt.verify() options.

---

Release Notes

auth0/node-jsonwebtoken (jsonwebtoken)

v9.0.0

Compare Source

Breaking changes: See Migration from v8 to v9

Breaking changes

• Removed support for Node versions 11 and below.
• The verify() function no longer accepts unsigned tokens by default. ([8345030]auth0/node-jsonwebtoken@8345030)
• RSA key size must be 2048 bits or greater. ([ecdf6cc]auth0/node-jsonwebtoken@ecdf6cc)
• Key types must be valid for the signing / verification algorithm

Security fixes

• security: fixes Arbitrary File Write via verify function - CVE-2022-23529
• security: fixes Insecure default algorithm in jwt.verify() could lead to signature validation bypass - CVE-2022-23540
• security: fixes Insecure implementation of key retrieval function could lead to Forgeable Public/Private Tokens from RSA to HMAC - CVE-2022-23541
• security: fixes Unrestricted key type could lead to legacy keys usage - CVE-2022-23539

---

Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Never, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[pix-bot-github]

Une fois les applications déployées, elles seront accessibles via les liens suivants :

• App (.fr)
• App (.org)
• Orga (.fr)
• Orga (.org)
• Certif (.fr)
• Certif (.org)
• Junior
• Admin
• API
• Audit Logger

Les variables d'environnement seront accessibles via les liens suivants :

• scalingo front
• scalingo api
• scalingo audit-logger

[yaf]

C'est une vieille PR d'août... Nous en faisons quoi ? On peut la fermer, renovate reviendra sur le dessus de la pile ?

[lego-technix]

C'est une vieille PR d'août... Nous en faisons quoi ? On peut la fermer, renovate reviendra sur le dessus de la pile ?

J'ai investigué sur cette PR en aprem-tech mais sans pouvoir finir et sans pouvoir présenter le résultat de mes investigations.

Alors voici les résultats :

• La mise à jour du paquet jsonwebtoken de cette PR porte sur l'utilisation de ce paquet dans les tests e2e, exclusivement, dans high-level-tests/e2e/package.json . C'est un environnement « client » donc.
• Le paquet jsonwebtoken est un paquet nécessitant Node.js, comme on peut le voir rapidement dans son package.json : https://github.com/auth0/node-jsonwebtoken/blob/master/package.json#L61-L64 . C'est un paquet pour environnement « serveur » donc.
• Le paquet jsonwebtoken est donc utilisé à tort dans les tests e2e qui sont des tests réalisés dans un navigateur web.
• Le paquet jsonwebtoken dans ses versions 8.x pouvait encore être utilisé « en trichant » dans un environnement non-Node.js comme un navigateur par exemple, mais ce n'est plus le cas avec les versions majeures suivantes > 9.0.0

Par ailleurs cette alerte de sécurité porte uniquement sur le package.json utilisé pour les tests e2e et n'a d'impact que sur l'environnement de la CI. Et après examen, cette vulnérabilité n'est pas une menace pour l'environnement de la CI.

La solution à terme est de remplacer le paquet jsonwebtoken par le paquet jose qui fonctionne dans tous les environnements, y compris les navigateurs web et donc c'est ce qu'il faut pour les tests e2e. Seulement le remplacement de jsonwebtoken par jose n'est pas immédiat. J'ai une branche en cours pour cela, mais pas finalisée.

Donc idéalement il faudrait dire à renovate de ne plus jamais chercher à mettre à jour le paquet jsonwebtoken pour high-level-tests/e2e/package.json mais uniquement pour ce package.json. En effet on veut que les mises à jour de jsonwebtoken se fassent toujours pour api/package.json.

Aussi est-ce que vous savez comment dire à renovate : « ne cherche plus jamais à mettre à jour le paquet jsonwebtoken pour high-level-tests/e2e/package.json et uniquement » ?

[HEYGUL]

Aussi est-ce que vous savez comment dire à renovate : « ne cherche plus jamais à mettre à jour le paquet jsonwebtoken pour high-level-tests/e2e/package.json et uniquement » ?

En fermant cette PR ça devrait le faire.

[renovate]

Renovate Ignore Notification

Because you closed this PR without merging, Renovate will ignore this update. You will not get PRs for any future 9.x releases. But if you manually upgrade to 9.x then Renovate will re-enable minor and patch updates automatically.

If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR.