[Axis2] DoS concersn and fautl handling [some thoughts] [ Re: [Axis2] How to Handle faults

[Aleksander Slominski <as...@cs.indiana.edu>]

Srinath Perera wrote:

>Well, IMO the idea of the infault flow is as high level as the inflow
>.. I belive the wsdl makes it so. One can have a dispatcher to do the
>check for a fault .. (he should not/ can not do the service disptah if
>it is a fault. )  Then it is we calling the infualt flow with in the
>in-flow.
>
>But we are running in to this chicken and egg problem too often
>.somehting is encrypted ...ect ..ect ... may be the pre diapatch
>pahses are common to all in* flows ..and we should redefine them so.
>
>Just thinking aloud .. what you guys think?
>  
>
IMHO decryption and signature verification should happen in an early 
inflow handlers (as early as possible) and encryption and signing in one 
of the last outflow handlers (if not the last one) - if not then there 
is plenty of problems to preserve infoset through handlers.

addressing handler should be after decryption in-flow and definitely 
before encryption out-flow (ws-rx/rm may sit between ws-addressign and 
WSS handlers).

if there is fault before decryption then there are only limited options 
how to handle this - you may not even know whhich target service was 
called ...

if there is fault it may still need be encrypted -right?

so what really is the problem? if there is in-flow fault before 
addressing handler is reached then no addressing should be used to send 
fault as it was not yet reached and problem is in a layer that is 
possibly below (like transport  or security ...) - right?

if you use addressing FaultTo for invalid message to send fault (such as 
wrong signature) you expose a possible denial-of-service (DoS) attack 
capability for any axis2 enabled service (send invalid messages to axis2 
service that acts as a "zombie" and sends fault message to DoS target 
host ...) - there is no easy solution for it AFAIK if no security or 
policy is used.

using Basic Authorization / WSS and/or policy on allowed values 
FaultTo/ReplyTo should help but it would be no good if security can be 
overridden and DoS executed even when service is supposedly using WSS 
encryption and signature verification ...

i think maybe there is need for some use cases ...

best,

alek

>On 8/17/05, Ajith Ranabahu <aj...@gmail.com> wrote:
>  
>
>>Ahum..
>>In my personal opinion I see the invokeFault(..) [or whatever it will be
>>called] as an elegant way of handling the error.So I don't think it's
>>complicating things. it's actually a better way of dealing with the
>>complication :)
>>The very reason why we need a fault flow is to avoid such fall through code
>>in the handlers :)
>>
>>
>>On 8/17/05, Eran Chinthaka < chinthakae@gmail.com> wrote:
>>    
>>
>>>Ok, can I know the things you are thinking of doing in the IN fault 
>>>flow, which you don't wanna do in the normal in flow (of course
>>>something other than logging :) )
>>>
>>>
>>>      
>>>
>>>>Hi dims;
>>>>
>>>>Lets say that we have the fault information in the soap header
>>>>        
>>>>
>>(addressing) 
>>    
>>
>>>>. In the current implementation what it does is when a message is
>>>>        
>>>>
>>received ,
>>    
>>
>>>>takes the inflow  (inflow handles ) and give it to the engine and call
>>>>engine.receive(msgContx) ,
>>>>addressing handler is in that chain , so we do need to go throgh the
>>>>        
>>>>
>>inflow 
>>    
>>
>>>>upto addressing handler to read the addressing headers to know the fault
>>>>        
>>>>
>>,
>>    
>>
>>>>and then we can call engine.receiveFault();
>>>>
>>>>so we have to start the in-fault-flow invocation in the middle of
>>>>        
>>>>
>>in-flow; 
>>    
>>
>>>>is that  ok?
>>>>        
>>>>
>>>Isn't this complicating the things ???
>>>Without doing the way you propose, you can achieve the samething like
>>>      
>>>
>>this.
>>    
>>
>>>1. Handler which handlers everything
>>>
>>>invoke (msgctx){
>>>     if( env.getBody().hasFault()){
>>>         // do your fault stuff
>>>     }else{
>>>        // do normal stuff
>>>    }
>>>}
>>>
>>>2. Fault Handler (any use cases ??)
>>>
>>>invoke (msgctx){
>>>     if(env.getBody().hasFault()){ 
>>>         // do your fault stuff
>>>     }
>>>}
>>>
>>>3. No Difference on faults handler
>>>
>>>invoke (msgctx){
>>>    // act on msgctx. No difference
>>>}
>>>
>>>
>>>See my point ??
>>>
>>>-- Chinthaka
>>>
>>>      
>>>
>>
>>-- 
>>Ajith Ranabahu
>>    
>>
>
>  
>


-- 
The best way to predict the future is to invent it - Alan Kay