Re: issue 7911

I look at this slightly differently... you keep talking about how the 
Action and the Body MUST "match".  To me that's actually not true - at 
least not the way you mean it.  Sure from a human perspective there 
appears to be a relationship between the Action and the Body because they 
look similar, but in reality its just a coincidence.  Back at the Redwood 
City F2F we talked about this, and we agreed that even if the spec said 
that the Action MUST be "Store" and the Body MUST be "Put" you'd still 
have an issue.  And this is because the issue isn't that those two values 
needed to look alike, instead the issue is that the spec says what each 
one MUST be and if the client doesn't "match" what the spec says then its 
an error.  So, if we did head down this path I wouldn't want any fault to 
talk about those values needing to match each other, I'd want it to talk 
about them not matching what the spec says they must be.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.



Yves Lafon <ylafon@w3.org> 
Sent by: public-ws-resource-access-request@w3.org
10/26/2009 04:50 PM

To
Gilbert Pilz <gilbert.pilz@oracle.com>
cc
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Subject
Re: issue 7911






On Mon, 26 Oct 2009, Gilbert Pilz wrote:

> Yves,
>
> I think we need to break your proposal down into its constituent pieces. 

> Firstly, there is the definition of the fault that is generated when/if 
an 
> implementation detects that the first child of the [Body] does not match 
the 
> [Action] property. I have two problems with this:
>
> F.1) What is the point of standardizing the definition of this fault? 
Since 
> the mismatch in question is a result of a coding error, it doesn't seem 
> reasonable to expect anyone to write client code that could detect this 
fault 
> and address the underlying problem in any meaningful way. It seems to me 
that 
> any SOAP fault with a code of soap11:Client/soap12:Sender and a 
> soap11:faultstring/soap12:Reason that is equivalent to "the first child 
of 
> the [Body] does not match the [Action] property" (properly translated of 

> course) would serve the same purpose.

Ok, so malicious code wanting to exploit a buffer overflow using carafully 

crafted "wrong content" is a coding error?
If you have an implementation that checks only the action property to 
check access and another one that checks only the body element to actually 

perform the request, then you have an issue.

There is a difference between client requirements, currently in the spec 
(body MUST start with ... and action MUST be ...), and receiver 
requirements, especially in this case where we have two times the same 
information. Failing to explicitely check that on the receiving end leads 
to potential security issues.

> F.2) Even if we stipulate that it is necessary to standardize the 
definition 
> of this fault, it's not clear to me that it's within the scope of the 
WS-RA 
> WG's charter to define what is, essentially, a general-purpose 
> SOAP/WS-Addressing fault.

Ok, so why do we need a PutDenied fault? It's a generic ActionDenied fault 

that WS-Addressing should deal with, no?

> Secondly, there is the requirement on all WS-T resource implementations 
to 
> check for this condition and generate the fault.
>
> R.1) Why only WS-T? WS-Enum, WS-Eventing, and WS-Mex all have unique 
[Body] 
> children. If it is important to check for this condition in WS-T, surely 
it 
> is also important to check for this condition in the other specs as 
well? 
> Even if we did modify your proposal to include WS-Enum, WS-Eventing, and 

> WS-Mex, from the perspective of a general SOAP/WS-* stack, it seems 
really 
> strange to perform this check just for these spec and not for any others 

> (i.e. WS-RM, WS-Trust, etc.)

You are right, every time action is duplicated by a body element, it is 
needed.

> R.2) For what it's worth, my developers don't want to implement this 
check. 
> It is not required for the correct implementation of the WS-T protocol 
(when 
> the client sent the invalid request we left the realm of what the 
protocol 
> defines) and, in their view, it is not likely to happen often enough to 
be 
> worth the runtime cost.
>
> *Counter Proposal*: Close With No Action
>
> - gp
>
> On 10/26/2009 6:15 AM, Yves Lafon wrote:
>> On Thu, 22 Oct 2009, Gilbert Pilz wrote:
>> 
>>> Just went to look at issue 7911 in the issues list and found a whole 
>>> discussion thread in the comments section. I might have missed the 
entire 
>>> thing if I didn't happen to stumble upon it. Could people please 
constrain 
>>> themselves to discussing issues on the mailing list and use the 
comments 
>>> section for major developments (i.e. new proposals, directional 
>>> resolutions, etc.)?
>> 
>> You are entirely right, I should have moved discussion here...
>> Here is my proposal for resolving that issue:
>> 
>> In 3, before the definition of the different resource operations:
>> 
>> "If the [Body] first child is not matching the
>> [Action] parameter for any defined Resource Operation, the recipient 
MUST
>> generate a ActionAndWrapperMismatch fault"
>> 
>> and add the fault:
>> <<
>> 5.4 ActionAndWrapperMismatch
>> 
>> This fault is generated if the [Body] first child is not matching the
>> [Action]
>> 
>> [Code]    s:Sender
>> [Subcode] wst:ActionAndWrapperMismatch
>> [Reason]  Action and Wrapper mismatch
>> [Detail]  none
>>>> 
>> 
>> 
>> 
>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves