axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ruchith Fernando" <ruchith.ferna...@gmail.com>
Subject Re: [axis2] Re: svn commit: r559011 - in /webservices/axis2/trunk/java/modules: addressing/src/META-INF/ integration/conf/ integration/test-resources/deployment/ integration/test-resources/mtom/ integration/test-resources/swa/ integration/test/org/ap
Date Thu, 09 Aug 2007 11:53:28 GMT
Apologies for jumping in late! Please see my comments below:

On 7/30/07, David Illsley <davidillsley@gmail.com> 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 <deepalk@gmail.com> 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 <deepalk@gmail.com> 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
> > >>>
> > >>>
> > >>> deepal@apache.org 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: axis-dev-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >>
> > >>
> > >>
> > >
> > >
> > >
> >
> >
> > --
> > Thanks,
> > Deepal
> > ................................................................
> > "The highest tower is built one brick at a time"
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
> --
> David Illsley - IBM Web Services Development
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>


-- 
www.ruchith.org
www.wso2.org

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message