Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix(deps): update dependency jsonwebtoken to v9 [security] (#1112)
[![Mend Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com) This PR contains the following updates: | Package | Change | Age | Adoption | Passing | Confidence | |---|---|---|---|---|---| | [jsonwebtoken](https://github.com/auth0/node-jsonwebtoken) | [`^8.5.1` -> `^9.0.0`](https://renovatebot.com/diffs/npm/jsonwebtoken/8.5.1/9.0.0) | [![age](https://badges.renovateapi.com/packages/npm/jsonwebtoken/9.0.0/age-slim)](https://docs.renovatebot.com/merge-confidence/) | [![adoption](https://badges.renovateapi.com/packages/npm/jsonwebtoken/9.0.0/adoption-slim)](https://docs.renovatebot.com/merge-confidence/) | [![passing](https://badges.renovateapi.com/packages/npm/jsonwebtoken/9.0.0/compatibility-slim/8.5.1)](https://docs.renovatebot.com/merge-confidence/) | [![confidence](https://badges.renovateapi.com/packages/npm/jsonwebtoken/9.0.0/confidence-slim/8.5.1)](https://docs.renovatebot.com/merge-confidence/) | ### GitHub Vulnerability Alerts #### [CVE-2022-23539](https://github.com/auth0/node-jsonwebtoken/security/advisories/GHSA-8cf7-32gw-wr33) # 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](https://github.com/auth0/node-jsonwebtoken/security/advisories/GHSA-hjrf-2m68-5959) # 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](https://github.com/auth0/node-jsonwebtoken#jwtverifytoken-secretorpublickey-options-callback)) 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](https://github.com/auth0/node-jsonwebtoken/security/advisories/GHSA-qwph-4952-7xr6) # 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 <details> <summary>auth0/node-jsonwebtoken</summary> ### [`v9.0.0`](https://github.com/auth0/node-jsonwebtoken/blob/HEAD/CHANGELOG.md#​900---2022-12-21) [Compare Source](https://github.com/auth0/node-jsonwebtoken/compare/v8.5.1...v9.0.0) **Breaking changes: See [Migration from v8 to v9](https://github.com/auth0/node-jsonwebtoken/wiki/Migration-Notes:-v8-to-v9)** ##### Breaking changes - Removed support for Node versions 11 and below. - The verify() function no longer accepts unsigned tokens by default. (\[[`8345030`](https://github.com/auth0/node-jsonwebtoken/commit/834503079514b72264fd13023a3b8d648afd6a16)]https://github.com/auth0/node-jsonwebtoken/commit/834503079514b72264fd13023a3b8d648afd6a16) - RSA key size must be 2048 bits or greater. (\[[`ecdf6cc`](https://github.com/auth0/node-jsonwebtoken/commit/ecdf6cc6073ea13a7e71df5fad043550f08d0fa6)]https://github.com/auth0/node-jsonwebtoken/commit/ecdf6cc6073ea13a7e71df5fad043550f08d0fa6) - 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 </details> --- ### 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**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View repository job log [here](https://developer.mend.io/github/quirrel-dev/quirrel). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNC42Ni4xIiwidXBkYXRlZEluVmVyIjoiMzUuMTMxLjAiLCJ0YXJnZXRCcmFuY2giOiJtYWluIn0=--> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
- Loading branch information