[ 
https://issues.apache.org/jira/browse/CXF-9239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh reassigned CXF-9239:
----------------------------------------

    Assignee: Colm O hEigeartaigh

> 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)

Reply via email to