Fix JWTVerifier null expected values and builder reuse#785
Open
asim-alam wants to merge 2 commits into
Open
Conversation
Registering a null expected value (e.g. withSubject(null), withJWTId(null), withClaim(name, (Integer) null)) documents the intent "this claim must be JSON null". When the token actually carried the claim, verifyNull() returned false and the code then called value.equals(claim.asX()) on the null expected value, leaking a raw NullPointerException out of verify() instead of the documented IncorrectClaimException. Use the null-safe Objects.equals(value, claim.asX()) at every value-claim site (withSubject, withJWTId, the typed withClaim overloads, and the Instant overload, which withClaim(Date) delegates to). Behaviour is identical when the value is non-null; when it is null and the claim is present, verification now fails with IncorrectClaimException. No public API change.
The JWTVerifier constructor wrapped the builder's live ArrayList with Collections.unmodifiableList (a view, not a copy), and build(Clock) appended the mandatory exp/nbf/iat checks to that same list. Calling build() twice on one BaseVerification therefore appended a second set of mandatory checks AND retroactively mutated the first, already-returned (and documented as immutable and thread-safe) verifier. Build the mandatory checks into a fresh list inside build() instead of mutating the builder's field, and take a defensive copy in the constructor. build() is now idempotent and each verifier owns an independent snapshot. Single-build behaviour and all existing check counts are unchanged.
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
1 participant
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.
Changes
Two related robustness fixes in
JWTVerifier, each covered by a new test that fails onmasterand passes with this change. No public API change.1. Null expected value threw a raw
NullPointerException(should beIncorrectClaimException).Registering a
nullexpected value (e.g.withSubject(null),withJWTId(null),withClaim(name, (Integer) null)) is the documented way to require a claim to be JSONnull.But when the token actually carried the claim, the code called
value.equals(claim.asX())on thenull expected value, leaking a
NullPointerExceptionout ofverify(). Fixed by using the null-safeObjects.equals(value, claim.asX())at every value-claim site. Behaviour is identical when the valueis non-null; when it is null and the claim is present, verification now fails with
IncorrectClaimException.2. Reused builders shared and retroactively mutated verifier state.
The constructor wrapped the builder's live
ArrayListwithCollections.unmodifiableList(a view,not a copy), and
build(Clock)appended the mandatoryexp/nbf/iatchecks to that same list.Since a built verifier is documented as reusable, calling
build()twice appended a second set ofmandatory checks and retroactively mutated the first, already-returned verifier. Fixed by building
the mandatory checks into a fresh list inside
build()(making it idempotent) and taking a defensivecopy in the constructor. Single-build behaviour and all existing check counts are unchanged.
References
Found by manual code review - no static-analysis rule flags either issue.
Testing
Added
JWTVerifierTest.shouldThrowIncorrectClaimNotNpeWhenNullSubjectExpectedButClaimPresentandJWTVerifierTest.shouldBuildReusableVerifierWithoutDuplicatingMandatoryChecks. Both fail onmasterand pass with this change.Ran the full module suite with
./gradlew :java-jwt:test: 681 tests, 0 failures.This change adds unit test coverage
This change has been tested on the latest version of the platform/language
Checklist