[
https://issues.apache.org/jira/browse/KNOX-3413?focusedWorklogId=1035333&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1035333
]
ASF GitHub Bot logged work on KNOX-3413:
----------------------------------------
Author: ASF GitHub Bot
Created on: 12/Aug/26 08:52
Start Date: 12/Aug/26 08:52
Worklog Time Spent: 10m
Work Description: hanicz opened a new pull request, #1345:
URL: https://github.com/apache/knox/pull/1345
…or a different token
[KNOX-3413](https://issues.apache.org/jira/browse/KNOX-3413) - KnoxToken
passcode verification accepts a valid passcode for a different token
## What changes were proposed in this pull request?
The cache abstraction conflates two token models. For JWTs the key is the
entire serialized JWT (self-authenticating, and identity is derived from that
same token). For passcodes, validity is a property of the `(tokenId, passcode)`
pair, but the cache stored only the passcode while identity came from a
separately supplied `tokenId`.
The only check that binds the passcode to the token identifier is
`validatePasscode(tokenId, passcode)`, which compares
`tokenMAC.hash(tokenId, issueTime, userName, passcode)` against the passcode
stored for that specific tokenId. On success it records the verification in a
shared, per-topology cache (`SignatureVerificationCache`) keyed on the passcode
string alone.
Because the guard at `AbstractJWTFilter.java:571` is
`hasSignatureBeenVerified(passcode) || validatePasscode(tokenId, passcode)`,
and tokenId/passcode are two independently attacker-controlled fields (parsed
from Base64(tokenId)::Base64(passcode) at JWTFederationFilter.java:213-215), a
caller who has verified its own passcode once can then present that same
passcode paired with a different, victim tokenId.
Key the passcode verification cache on the `(tokenId, passcode)` pairing
instead of the passcode
alone. Introduce one private helper and update the three passcode-path call
sites. The JWT path
(`verifyTokenSignature`, keyed on `serializedJWT`) is unchanged.
Also adds new regression test for the scenario.
## How was this patch tested?
Unit tests
Tested locally with two new topologies (tokenissuer, tokenconsumer)
```
curl -vku admin:admin-password -X "GET"
"https://localhost:8443/gateway/tokenissuer/knoxtoken/api/v2/token?lifespan=P0DT1H0M";
curl -vku tom:tom-password -X "GET"
"https://localhost:8443/gateway/sandbox/knoxtoken/api/v2/token?lifespan=P0DT1H0M";
curl -vk -H "Authorization: Basic replaced_tokenid_token" -X "GET"
"https://localhost:8443/gateway/tokenconsumer/auth/api/v1/pre";
```
## Integration Tests
N/A
## UI changes
N/A
Issue Time Tracking
-------------------
Worklog Id: (was: 1035333)
Remaining Estimate: 0h
Time Spent: 10m
> KnoxToken passcode verification accepts a valid passcode for a different
> token
> -------------------------------------------------------------------------------
>
> Key: KNOX-3413
> URL: https://issues.apache.org/jira/browse/KNOX-3413
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Affects Versions: 2.1.0, 3.0.0
> Reporter: Tamás Hanicz
> Assignee: Tamás Hanicz
> Priority: Blocker
> Time Spent: 10m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
