Hi,
On 5/15/07, David Illsley <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [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]
