Guanping Zhang created CXF-9239:
-----------------------------------
Summary: JoseSessionTokenProvider accepts JWE-only (no JWS)
session tokens — enforce encrypt-then-sign or warn/document the integrity gap
Key: CXF-9239
URL: https://issues.apache.org/jira/browse/CXF-9239
Project: CXF
Issue Type: Improvement
Components: JAX-RS Security
Affects Versions: 4.2.1
Environment: Apache CXF 4.2.1, Java 11+, JoseSessionTokenProvider
configured for JWE only.
Reporter: Guanping Zhang
In JoseSessionTokenProvider, protectStateString() (lines 131-143) guards only
against BOTH the JWS signer and the JWE encryptor being null. If only JWE is
configured (jweEncryptor set, no jwsProvider/jwsVerifier, jwsRequired=false),
the session state token is encrypted but carries no JWS signature;
decryptStateString() (lines 121-129) verifies a JWS only when one is present.
Consequence: in a JWE-only configuration the state token has confidentiality
but no independent authenticity/integrity layer. A party able to decrypt and
re-encrypt (a holder of a shared/symmetric content-encryption key, or an
attacker who has compromised the key-wrapping key) can modify the embedded
state (redirect target, scope, state parameter) and re-encrypt it without
detection. This is a defense-in-depth gap: encrypt-only session tokens silently
omit the authenticity check that JWS would provide.
Scope note: this requires a JWE-only configuration plus the ability to
decrypt/re-encrypt, so it is a hardening / configuration-validation issue
rather than a default-configuration vulnerability. Risk is highest with
symmetric key-wrap modes, where one shared secret both protects and can forge
tokens.
Suggested improvement: (a) require or warn when JWE is configured without JWS
(enforce encrypt-then-sign / sign-then-encrypt), or (b) reject JWE-only
configuration with a clear error, or (c) explicitly document JWE-only mode as
integrity-unprotected and advise against shared/symmetric key-wrap in that mode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
