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: Problem with Addressing Security and ordering of phases.
Date Tue, 15 May 2007 17:06:21 GMT
Hi,

On 5/15/07, David Illsley <davidillsley@gmail.com> wrote:
> Hi Amila,
> I've been working on a similar issue with a different WS-Sec
> implementation on top of Axis2 in the last couple of weeks. I've had a
> few discussions about potential vulnerabilites introduced by running
> the addressing based dispatcher before the security handlers.
>
> The potential vulnerability is that, given an unsecured operation A,
> and a secured operation B, an attacker could add a relatesTo captured
> from an insecure 'A' message and use it to get a message which the
> other dispatchers would dispatch to 'B' past the security handler. If
> a subsequent handler/dispatcher then redispatches the message based on
> the contents of the message to 'B' then there is a successful attack.

I'm not sure this really happens with Axis2 right now with the
dispatchers that we already have.
IMHO once we dispatch the service and/or operation by a dispatcher
then the *subsequent dispatchers* will *not* try to dispatch again.
Please correct me if this fact is not true about the default
dispatchers.

If the above is true then the attack mentioned here will not be
possible since there will not be a "re-dispatch"

Thoughts?

Thanks,
Ruchith


>
> Given the option of manual code verification of the full path between
> the security handler and the final dispatch (for every release) or
> adding a validation handler after the dispatch phase to ensure that
> the operation on the message context just prior to invoke is the same
> as the one the security used for config... I'm tending towards the
> verification handler approach.
>
> Does that make sense to you?
> Thanks,
> David
>
> On 15/05/07, Deepal Jayasinghe <deepal@opensource.lk> wrote:
> > Hi Amila,
> >
> >
> > > I wrote a sample client and a server to invoke a service using the
> > > dual chanel mode (i.e I started a
> > > separate listener in my client to get response). Obviously in this
> > > scenario we have to use the addressing
> > > to give the reply end point to the server. Every thing worked fine.
> > >
> > > Then I engaged the rampart at the client side (pragmatically ) and set
> > > the security policy file in the following way
> > >         StAXOMBuilder builder = new StAXOMBuilder(SECURITY_POLICY_FILE);
> > >         Policy securityPolicy =
> > > PolicyEngine.getPolicy(builder.getDocumentElement());
> > >
> > > clientOptions.setProperty(RampartMessageData.KEY_RAMPART_POLICY,
> > > securityPolicy);
> > > and engaged the security to service at the service level by giving the
> > > same security policy file.
> > >
> > > After that send the request as in earlier. But as I saw it never
> > > invoked my call back handler.
> > >
> > > After lot of debugging (using tcp mon)I found that the server sends
> > > the request back to the
> > > client but for some reason security handler could not process the
> > > request.
> > > The problem is with the RampartMessageData class.
> > >
> > > there it tries to get the security policy file from the message
> > > context and it is not there
> > > if(msgCtx.getProperty(KEY_RAMPART_POLICY) != null) {
> > >                 this.servicePolicy =
> > > (Policy)msgCtx.getProperty(KEY_RAMPART_POLICY);
> > >             }
> > >
> > > then as I understood the problem with the client side Inflow
> > >
> > >
> > >         <phase name="Security"/>
> > >         <phase name="PreDispatch"/>
> > >         <phase name="Dispatch"
> > > class="org.apache.axis2.engine.DispatchPhase">
> > >             <handler name="AddressingBasedDispatcher"
> > >
> > > class="org.apache.axis2.engine.AddressingBasedDispatcher">
> > >                 <order phase="Dispatch"/>
> > >             </handler>
> > >             <handler name="RequestURIOperationDispatcher"
> > >
> > > class="org.apache.axis2.engine.RequestURIOperationDispatcher">
> > >                 <order phase="Dispatch"/>
> > >             </handler>
> > >
> > > As we can see Security phase in invoked before the
> > > AddressingBasedDispatcher where we set those
> > > message context details. So the solution should be to invoke that
> > > phase before security.
> > >
> > > Then I changed the client_axis2.xml as follows
> > >
> > > <phase name="PreDispatch">
> > >             <handler name="AddressingBasedDispatcher"
> > >
> > > class="org.apache.axis2.engine.AddressingBasedDispatcher">
> > >                 <order phase="PreDispatch" phaseLast="true"/>
> > >             </handler>
> > >         </phase>
> > >         <phase name="Security"/>
> > >         <phase name="Dispatch"
> > > class="org.apache.axis2.engine.DispatchPhase">
> > >             <handler name="RequestURIOperationDispatcher"
> > >
> > > class="org.apache.axis2.engine.RequestURIOperationDispatcher">
> > >                 <order phase="Dispatch" />
> > >             </handler>
> > >
> > I am +1 for going with this change.
> > > And then it worked fine.
> > > So shall we reorder the phases to support this scenario and will there
> > > be any side effects?. I believe this is a very basic scenario.
> > >
> > > Secondly I saw  in RequestURIBasedDispatcher
> > >
> > >  public AxisOperation findOperation(AxisService service,
> > > MessageContext messageContext)
> > >             throws AxisFault {
> > >         // This Dispatcher does not need to resolve the operation, as
> > > that is handled
> > >         // by the RequestURIOperationDispatcher.
> > >         return null;
> > >     }
> > >
> > > basically it has commented out the findOperation method and that has
> > > moved to Dispatched phase.
> > > Could this make any problems with the Security when we have Operation
> > > level policies?
> > >
> > I think if we have enough data at any level then we should do the full
> > dispatching. Therefore findOperation should find the operation if it can
> >
> > Thanks
> > Deepal
> >
> >
> > ---------------------------------------------------------------------
> > 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