cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Mazza (Commented) (JIRA)" <>
Subject [jira] [Commented] (CXF-1636) Have WSS4J in/out interceptors require nonces and timestamps when using UsernameTokens?
Date Wed, 07 Mar 2012 17:40:57 GMT


Glen Mazza commented on CXF-1636:

quote: "What I am thinking of doing is to disable replay caching altogether for 2.5.x and
2.4.x, for backwards compatibility, but to merge this patch so that someone can enable it
if they want."

As not caching can be considered a security problem (and hence more important than backward
compatibility), if you wish I think it would be acceptable to activate it by default with
a note in the release notes of this change for 2.4/2.5.  (If it breaks anything users can
subsequently disable it.)  This is not a regular security hole because for years now we've
already documented that we haven't implemented nonce support yet (first paragraph under UsernameToken

> Have WSS4J in/out interceptors require nonces and timestamps when using UsernameTokens?
> ---------------------------------------------------------------------------------------
>                 Key: CXF-1636
>                 URL:
>             Project: CXF
>          Issue Type: Improvement
>          Components: WS-* Components
>            Reporter: Glen Mazza
>            Assignee: Colm O hEigeartaigh
>            Priority: Minor
>         Attachments: cxf-1636.patch
> Our WSS4J In/Out interceptors[1][2] do not appear to be requiring UsernameTokens to have
timestamps and nonces.  From [3], lines 176-190, these are used to prevent replay attacks
(i.e., an intruder just copying the entire soap header, encrypted or not, and reusing it for
another request).  
> To fix this problem, this blog sample[4] created a separate interceptor that will reject
any UsernameToken that does not have both a timestamp and a nonce.  Perhaps we should update
our WSS4J in/out interceptors to require both of these, so external users don't need to do
> A question though--I'm unsure where the nonce-checking is being done--our WSS4J interceptors
seem to be ignoring them, but perhaps WSS4J is doing the checking/validation that they are
not being used more then once.
> Glen
> [1]
> [2]
> [3]
> [4]

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message