The DoS is not against the service itself, but using the service to send messages to a victim indirectly. To prevent the use of your server in this way, the suggestion from the WS-A group is to require the ReplyTo is signed. However, given that we populate the ReplyTo field before the security handler now, Axis2+Rampart users get no such protection because when Rampart throws an exception, a fault will be sent to the victim, not the originator of the request message.
Given that we don't have (and I see no appetite for) roll-back-able handlers, the solution I see is to split the reading of the addressing headers into 2. Part that runs before security and part that runs after. That way, anything which is security-sensitive (like ReplyTo processing) can run after security validation. Cheers, David On 09/08/07, Ruchith Fernando <[EMAIL PROTECTED]> wrote: > Apologies for jumping in late! Please see my comments below: > > On 7/30/07, David Illsley <[EMAIL PROTECTED]> wrote: > > Ah, the perrenial ws-sec+ws-a problem. > > This is a really complex issue, and unfortunately I don't think it can > > be resolved this simply i.e. what happens if security rejects the ws-a > > headers as invalid? There isn't any code to roll-back the ws-a related > > fields in the message context, so suddenly one of the main reasons to > > require signed ws-a headers (preventing your server from being used to > > DoS via ReplyTo) is bypassed. > > > > I think we probably need to split the addressing processing itself > > into 2 parts - the first which provides a guess of the AxisOperation > > based onthe To/Action/RelatesTo and the second which does the full > > ws-a processing (afer the security handler). > > I'm trying to understand the various placements of the addressing > dispatcher and its affect on the DoS attack that David mentioned. > Please correct me if I have missed something. > > With the addressing dispatcher running before the security handler > - An attacker changes the signed ReplyTo header of a message to a service > - Addressing handled extracts this information and addressing > dispatcher finds the operation. > - Signature verification fails and the fault is sent to the *changed* > ReplyTo address > > Now with David's proposal (The way I understood it) the earlier three > steps happen anyway ... its true that the fault is sent to the changed > ReplyTo but the message never reaches the service in either case. > > Now ... In case of a aync message invocation, even if we do *not* do > any addressing processing/dispatch before security processing when > signature verification fails due to someone modifying an addressing > header we will not be able to send an asyc response anyway, since at > the point where processing fails we do not know the ReplyTo address. > > David can you please explain how the DoS attack happen with the > current approach and how it can be prevented by splitting addressing > based dispatching? > > Thanks, > Ruchith > > > > > Do you have a list of use-cases you're trying to support? > > David > > > > On 27/07/07, Deepal jayasinghe <[EMAIL PROTECTED]> wrote: > > > In the case of WS-Security there are instance that the only way to > > > dispatch is using addressing , and service and operation must be found > > > before running the security handlers. If you take transport like SMTP > > > the only way to dispatch is using addressing so we need to run > > > addressing before security. > > > > > > May be Ruchith can add some more infor into this. > > > > > > Thanks > > > Deepal > > > > Um deepal, can you explain why we should have the > > > > AddressingBased*Dispatcher* running before the *Dispatch* phase? > > > > Thanks, > > > > David > > > > > > > > On 25/07/07, Deepal jayasinghe <[EMAIL PROTECTED]> wrote: > > > > > > > >> Hi Glen, > > > >> Yes I have to agree with you , but let's do that for next release. I > > > >> would like to consider that as the first item to be fixed. > > > >> > > > >> Thanks > > > >> Deepal > > > >> > > > >>> [Forward with correct prefix] > > > >>> > > > >>> Gosh. If only Modules ... > > > >>> > > > >>> http://marc.info/?l=axis-dev&m=118117804705440&w=2 > > > >>> > > > >>> ... could define their own Phases > > > >>> > > > >>> http://marc.info/?l=axis-dev&m=114404998012486&w=2 > > > >>> > > > >>> this commit could have consisted of a simple change to the Addressing > > > >>> module's module.xml, and that would basically be it. This > > > >>> demonstrates, > > > >>> once again, exactly the problem with the current overly-static design. > > > >>> > > > >>> I still stand by the position I wrote up last year: > > > >>> > > > >>> http://marc.info/?l=axis-dev&m=114417377917696&w=2 > > > >>> > > > >>> This needs to be fixed after 1.3, folks. > > > >>> > > > >>> --Glen > > > >>> > > > >>> > > > >>> [EMAIL PROTECTED] wrote: > > > >>> > > > >>>> Author: deepal > > > >>>> Date: Tue Jul 24 04:41:00 2007 > > > >>>> New Revision: 559011 > > > >>>> > > > >>>> URL: http://svn.apache.org/viewvc?view=rev&rev=559011 > > > >>>> Log: > > > >>>> -Add a phase called Addressing as I mentioned in the mailing list - > > > >>>> Move all the addressing handlers into Addressing phase > > > >>>> - Had to modify a set of axis2.xml and test cases to cope this chang > > > >>>> > > > >>>> [This is a big commit but no need to worry :) ] > > > >>>> > > > >>>> Modified: > > > >>>> > > > >>>> webservices/axis2/trunk/java/modules/addressing/src/META-INF/module.xml > > > >>>> webservices/axis2/trunk/java/modules/integration/conf/axis2.xml > > > >>>> > > > >>>> webservices/axis2/trunk/java/modules/integration/test-resources/deployment/deployment.both.axis2.xml > > > >>>> > > > >>>> > > > >>>> webservices/axis2/trunk/java/modules/integration/test-resources/mtom/MTOM-enabled-axis2.xml > > > >>>> > > > >>>> > > > >>>> webservices/axis2/trunk/java/modules/integration/test-resources/mtom/MTOM-fileCache-enabled-axis2.xml > > > >>>> > > > >>>> > > > >>>> webservices/axis2/trunk/java/modules/integration/test-resources/swa/SwA-enabled-axis2.xml > > > >>>> > > > >>>> > > > >>>> webservices/axis2/trunk/java/modules/integration/test-resources/swa/SwA-fileCache-enabled-axis2.xml > > > >>>> > > > >>>> > > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/engine/HandlerExecutionTest.java > > > >>>> > > > >>>> > > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/engine/chunking-disabled-axis2.xml > > > >>>> > > > >>>> > > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/engine/chunking-enabled-axis2.xml > > > >>>> > > > >>>> > > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/engine/commons-http-enabled-axis2.xml > > > >>>> > > > >>>> > > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/jms/jms-enabled-client-axis2.xml > > > >>>> > > > >>>> > > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/jms/jms-enabled-server-axis2.xml > > > >>>> > > > >>>> > > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/mail/mail-enabled-axis2.xml > > > >>>> > > > >>>> > > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/mail/mail-enabled-client-axis2.xml > > > >>>> > > > >>>> > > > >>>> webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/mail/mail-enabled-server-axis2.xml > > > >>>> > > > >>>> webservices/axis2/trunk/java/modules/kernel/conf/axis2.xml > > > >>>> > > > >>>> webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/deployment/axis2_default.xml > > > >>>> > > > >>>> > > > >>>> webservices/axis2/trunk/java/modules/kernel/test/org/apache/axis2/deployment/ModuleDisengagementTest.java > > > >>>> > > > >>>> > > > >>>> > > > >> --------------------------------------------------------------------- > > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > >> > > > >> > > > >> > > > > > > > > > > > > > > > > > > > > > -- > > > Thanks, > > > Deepal > > > ................................................................ > > > "The highest tower is built one brick at a time" > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > David Illsley - IBM Web Services Development > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > www.ruchith.org > www.wso2.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- David Illsley - IBM Web Services Development --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
