You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rampart-dev@ws.apache.org by "Amila Jayasekara (JIRA)" <ji...@apache.org> on 2010/05/03 18:26:56 UTC
[jira] Issue Comment Edited: (RAMPART-294) Does Rampart handle
replay attacks when using UsernameToken password digest?
[ https://issues.apache.org/jira/browse/RAMPART-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12863321#action_12863321 ]
Amila Jayasekara edited comment on RAMPART-294 at 5/3/10 12:25 PM:
-------------------------------------------------------------------
Attached svn diff contains a fix for this issue.
There are several ways of handling repeating messages.
1. Use a sequence number and secure transport channel like https (WS-Addressing can be used to have a message id)
2. Record nonce values for a given user, for a period of time and check whether same nonce value repeats. If a message arrives with the same nonce value for a particular user, throw an error.
Attached changes incorporate option 2 to code. i.e. Record nonce value for period of time and reject repeating nonce values.
Also implementation is according to specification "Web Services Security UsernameToken Profile 1.1 OASIS Standard Specification, 1 February 2006". (Page 7, option 3)
Thus this specification only recommends to cache seen nonce values for a period of time.
I made this change on top of svn revision 940383
was (Author: amilaj):
Attached svn diff contains a fix for this issue.
There are several ways of handling repeating messages.
1. Use a sequence number and secure transport channel like https (WS-Addressing can be used to have a message id)
2. Record nonce values for a given user, for a period of time and check whether same nonce value repeats. If a message arrives with the same nonce value for a particular user, throw an error.
Attached changes incorporate option 2 to code. i.e. Record nonce value for period of time and reject repeating nonce values.
Also implementation is according to specification "Web Services Security UsernameToken Profile 1.1 OASIS Standard Specification, 1 February 2006". (Page 7, option 3)
Thus this specification only recommends to cache seen nonce values for a period of time.
> Does Rampart handle replay attacks when using UsernameToken password digest?
> ----------------------------------------------------------------------------
>
> Key: RAMPART-294
> URL: https://issues.apache.org/jira/browse/RAMPART-294
> Project: Rampart
> Issue Type: Question
> Affects Versions: 1.4
> Environment: Windows XP Professional
> Reporter: Balamurali
> Assignee: Ruchith Udayanga Fernando
> Attachments: RAMPART-294.diff, SimpleTestService.aar
>
>
> I am using a simple axis2 service and client to play around with rampart module. As you could see from the policy below, I am using UsernameToken with digest authentication. Rampart does generate different nonce for each request in the client. When I replay the same request using TCPMon i.e. using the same security header, I thought the server (which again engages rampart) would reject this as the nonce is same as the previous request. But the request goes through rampart without any issues.
> So, my question is, is there any configuration to enable rampart (on the server side) to check for duplicate nonce values?
> Followng is the policy file used by the client:
> <wsp:Policy wsu:Id="UsernameToken" xmlns:wsu=
> "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
> xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
> <wsp:ExactlyOne>
> <wsp:All>
> <sp:SupportingTokens
> xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
> <wsp:Policy>
> <sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
> <wsp:Policy>
> <sp:HashPassword/>
> </wsp:Policy>
> </sp:UsernameToken>
> </wsp:Policy>
> </sp:SupportingTokens>
> </wsp:All>
> </wsp:ExactlyOne>
> </wsp:Policy>
> Follownig is the service.xml entry:
> <service>
> <parameter name="ServiceClass" locked="false">samples.services.SimpleTestService</parameter>
> <operation name="add">
> <messageReceiver class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"/>
> </operation>
> <wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="UsernameToken">
> <wsp:ExactlyOne>
> <wsp:All>
> <sp:SupportingTokens
> xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
> <wsp:Policy>
> <sp:UsernameToken
> sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
> <wsp:Policy>
> <sp:HashPassword/>
> </wsp:Policy>
> </sp:UsernameToken>
> </wsp:Policy>
> </sp:SupportingTokens>
> <ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy">
> <ramp:passwordCallbackClass>samples.services.PWCBHandler</ramp:passwordCallbackClass>
> </ramp:RampartConfig>
> </wsp:All>
> </wsp:ExactlyOne>
> </wsp:Policy>
> </service>
> Thank & Regards,
> Bala
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.