[
https://issues.apache.org/jira/browse/CXF-9239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved CXF-9239.
--------------------------------------
Resolution: Won't Fix
IMO it's up to the user what they want to configure in this class, if they want
to configure encryption only then that's up to them.
> 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
> Assignee: Colm O hEigeartaigh
> Priority: Minor
>
> 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)
