Got it! :-) Thanks for the explanation David.
- Ruchith On 8/9/07, David Illsley <[EMAIL PROTECTED]> wrote: > 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] > > -- www.ruchith.org www.wso2.org --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
