Repository navigation
hardening(security): require exp claim when verifying access and reset JWTs - #2514
Closed
failsafesecurity wants to merge 2 commits into
Closed
failsafesecurity wants to merge 2 commits into
failsafesecurity wants to merge 2 commits into
Conversation
…t JWTs Companion hardening for the shipped-default-secret finding. Even with a fail-closed signing key, a correctly signed token without an exp claim should never authenticate. - get_current_user rejects access tokens lacking exp (jwt.decode require=[exp]). - verify_password_reset_token requires exp as well. - Adds backend/tests/api/routes/test_jwt_claims.py covering: no-exp token is rejected, valid exp token accepted, reset token requires exp, and a token signed with the wrong key is rejected.
Contributor
|
This was marked as potentially AI generated and will be closed now. If this is an error, please provide additional details, make sure to read the docs about contributing and AI. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Companion hardening PR to the fail-closed
SECRET_KEYfix (#2513). Independently of the signing key, a JWT that carries noexpclaim must never authenticate.Related finding: Shipped default
SECRET_KEYwith fail-open validation permits forgery of any JWT (CRITICAL · CVSS 4.0 9.3 · CWE-321)Scan ID:
cmv17pczu00womo01ei5nap4fWhat this changes
backend/app/api/deps.py::get_current_usernow callsjwt.decode(..., options={"require": ["exp"]}), so an access token without an expiry is rejected.backend/app/utils.py::verify_password_reset_tokenrequiresexpas well, so a reset token without a lifetime bound can never be replayed.backend/tests/api/routes/test_jwt_claims.pyasserts:expis rejected,expis accepted,Nonewithoutexpand the subject with it,Why
Requiring
expis defense-in-depth for the same trust boundary the main fix hardens: tokens are the only thing standing between an unauthenticated caller and superuser access, so verification should never accept a token with an unbounded lifetime.Notes
Pure verification tightening; valid existing tokens (which always include
exp) are unaffected.