RE: Composibility problems with refps

Dave,

I may be wrong about this, since I am no expert in security, but if the
hacker figures out how sign arbitrary documents on your behalf then I will
guess that SOAP header extensibility will not be at the top of your list of
problems - certainly not the only one. Hackers will not need to worry about
the SOAP header extensibility model to steal all you money (and maybe also
mine); there are already plenty of ways to do this by manipulating the good
old SOAP body. That's what I was trying to say.

As for IBM's security concerns, so far our experts tell us ref. props as
SOAP headers are ok as long as we consistently sign everything, which you
need to do in any case.

Paco



                                                                                                                                        
                      "David Orchard"                                                                                                   
                      <dorchard@bea.com        To:       Francisco Curbera/Watson/IBM@IBMUS                                             
                      >                        cc:       Christopher B Ferris/Waltham/IBM@IBMUS, <public-ws-addressing@w3.org>          
                                               Subject:  RE: Composibility problems with refps                                          
                      11/23/2004 01:27                                                                                                  
                      PM                                                                                                                
                                                                                                                                        




Sure, everything can be hacked.  And the sky could fall and we could all
die.  So what?  By saying "well hacks happen and then the system is
totally broken" prevents us from talking about security problems of
systems.  And that can prevent us from thinking about security and
making appropriate trade-offs of security vs other properties.

Extending your analogy, nobody should switch to safer architectures
(like Java over C++ for the common string hack and stack overflows) or
operating systems(cough) or strongly typed languages because well,
that's just too bad if systems get hacked or mistakes are made.

Signing EPRs doesn't prevent this security problem.  I didn't point out
a widespread security failure in the software, I pointed out one
particular vulnerability that is fairly easily prevented.  In the
pipeline model that lots of vendors offer, it's pretty simple to insert
a ref property well before the signing/encrypting code is applied.  Most
of the stuff I've seen out of vendors seems to indicate that security
happens at the touch points to the network - the last node on outbound
and first node on inbound messages.

The point about SOAP is that SOAP offers a distributed extensibility
model with arbitrary ramifications, and the ws-a echoing processing
model could maliciously take advantage of that open ended extensibility
model.  This vulnerability can be prevented in a fairly simple way.

I'll say again, there is a software vulnerability that is created by the
combination of the ws-a processing model and the soap extensibility
model that can easily be prevented in ws-a.

I'm surprised that I've now heard two IBMer's now adopt the "no problem,
nothing to see, move along" approach to this potential security issue.

Cheers,
Dave

> -----Original Message-----
> From: Francisco Curbera [mailto:curbera@us.ibm.com]
> Sent: Tuesday, November 23, 2004 6:13 AM
> To: David Orchard
> Cc: Christopher B Ferris; public-ws-addressing@w3.org; public-ws-
> addressing-request@w3.org
> Subject: RE: Composibility problems with refps
>
> The fact is that everything can be hacked if it is not properly
protected.
> This includes SOAP headers but also SOAP bodies. The same model of a
> server
> sending opaque data to a client with the explicit understanding that
the
> client must include it in messages sent to the server is absolutely
> pervasive. This for example the case of an order number or a customer
id
> that a merchant sends back to his customer - it could also be a
complex
> piece of XML. A hacker with access to the merchant's systems could
very
> well figure out how to manipulate that information so that all
payments
> are
> credited to his account for example. Since we assume he even
understands
> how to sign EPRs on behalf of anyone, he may just as well understand
how
> the internal processing at the merchant site works; the sky is the
limit
> then. He may include signed XML in which any conceivable promise is
made
> by
> the merchant to the customer, or vice versa if he hacks the customer's
> site. Everything is possible; I just don't see what is so special
about
> SOAP headers - maybe that us just me.
>
> Having the ability to sign EPRs as well as individual ref. property
> headers
> should be more than enough to reasonably put this concern to rest.
>
> Paco
>
>
>
>
>
>                       "David Orchard"
>                       <dorchard@bea.com>              To:
> Christopher B Ferris/Waltham/IBM@IBMUS
>                       Sent by:                        cc:
<public-
> ws-addressing@w3.org>
>                       public-ws-addressing-req        Subject:  RE:
> Composibility problems with refps
>                       uest@w3.org
>
>
>                       11/22/2004 06:15 PM
>
>
>
>
>
>
> I'm not worried about ref props/params interfering with WS-* use of
> headers by a bad interface design.  The owner of the interface
controls
> both the use of WS-* specs and the use of RefPs.  They will quickly
sort
> out any interface conflicts.  And my guess is that Rule #1 of RefP
usage
> will be: Thou shalt not use WS-* QNames in RefPs.
>
> I'm more sensitive to the issue 8 concern about ref props/params being
> duplicates of user headers, particularly a security hole that allows a
> hacker to put a bad RefP into the EPR, ie
> <SendAssetsToGrandCayman amount="all" fromacct="chris"
toacct="hacker"/>
>
> This security problem isn't covered by signing the EPR but is covered
by
> a wrapper of some kind.
>
> Dave
>
> > -----Original Message-----
> > From: public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-
> > request@w3.org] On Behalf Of Christopher B Ferris
> > Sent: Monday, November 22, 2004 1:10 PM
> > To: Anish Karmarkar
> > Cc: Jonathan Marsh; public-ws-addressing@w3.org;
public-ws-addressing-
> > request@w3.org; tom@coastin.com
> > Subject: Re: Composibility problems with refps
> >
> >
> > Anish/Tom,
> >
> > But then this means that the refps that under the current design
> become
> > SOAP headers, and subject to
> > the SOAP processing model, would no longer be subject to the SOAP
> > processing model. I think that this
> > would be a collossal mistake.
> >
> > Frankly, I think that the idea of reference properties/params
> interfering
> > with other WS-* use of headers
> > is a red herring. Of course, it is always possible to do something
> that
> > would break any protocol. At most, I could
> > see adding a note in the spec that recommended caution when
including
> any
> > protocol elements
> > as reference property/parameters as their subsequent inclusion as
SOAP
> > header blocks in messages
> > addressed to the endpoint *might*, I repeat, *might* conflict with
> > constraints as to cardinality of such
> > header blocks in a message, etc.
> >
> > I would strongly discourage any thoughts of a wrapper element for
> > reference property/parameters.
> >
> > Cheers,
> >
> > Christopher Ferris
> > STSM, Emerging e-business Industry Architecture
> > email: chrisfer@us.ibm.com
> > blog: http://webpages.charter.net/chrisfer/blog.html
> > phone: +1 508 377 9295
> >
> >
> >
> > Anish Karmarkar <Anish.Karmarkar@oracle.com>
> > Sent by: public-ws-addressing-request@w3.org
> > 11/22/2004 02:03 PM
> >
> > To
> > tom@coastin.com
> > cc
> > Jonathan Marsh <jmarsh@microsoft.com>, public-ws-addressing@w3.org
> > Subject
> > Re: Composibility problems with refps
> >
> >
> >
> >
> >
> >
> >
> > I agree that would indeed solve the problem -- either refp specific
> > header(s) or the use of [to] property.
> >
> > -Anish
> > --
> >
> > Tom Rutt wrote:
> >
> > >
> > > As Glen has suggested before, encapsulating the ref parms and ref
> props
> > > in a ws-addressing specific header element would allow arbitrary
> > > qnames for the ref props and ref parms, without confusion.
> > >
> > > Tom Rutt
> > >
> > > Anish Karmarkar wrote:
> > >
> > >>
> > >> Yes.
> > >> Or in the context of SOAP, composability with any specification
> that
> > >> uses SOAP header(s) as a mechanism to convey information.
> > >>
> > >> -Anish
> > >> --
> > >>
> > >> Jonathan Marsh wrote:
> > >>
> > >>> Specifically, you're worried about the case where the reference
> > >>> properties and reference parameters are in a namespace used by
the
> > >>> reliability, security, etc. mechanisms, right?
> > >>>
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: public-ws-addressing-request@w3.org [mailto:public-ws-
> > >>>> addressing-request@w3.org] On Behalf Of Anish Karmarkar
> > >>>> Sent: Monday, November 15, 2004 11:10 AM
> > >>>> To: public-ws-addressing@w3.org
> > >>>> Subject: Composibility problems with refps
> > >>>>
> > >>>>
> > >>>> All,
> > >>>>
> > >>>> During last week's concall discussion of issue i008 I took an
> action
> > >>>> to
> > >>>> explain the composibility problem with refps in an email. This
> email
> > >>>> fulfills that action.
> > >>>>
> > >>>> WS-Addressing [1] Submission includes [reference properties]
and
> > >>>> [reference parameters] in the info models for EPR. These refps
> are
> > >>>> opaque to the consumer. In the SOAP binding of EPR, the refps
are
> > >>>> bound
> > >>>> as individual SOAP header blocks. I.e., a consumer of a EPR
using
> > SOAP
> > >>>> is required to copy the refps as individual SOAP header blocks
> > without
> > >>>> understanding what the blocks mean or do.
> > >>>>
> > >>>> Typically SOAP header blocks are part of a SOAP module and
> express
> > >>>> certain functionality. For example, WSS, WS-Reliability,
> > >>>> WS-ReliableMessaging, WS-C, WS-T WS-Context etc, specify header
> > blocks
> > >>>> that have a particular meaning that is conveyed from the sender
> to
> > the
> > >>>> receiver. Specifications in the realm of Web services are
> designed to
> > >>>> be
> > >>>> composible with other specs. For example, WS-Context can be
> composed
> > >>>> with WS-Reliability and WSS.
> > >>>>
> > >>>> A consuming application that dereferences an EPR that contains
> refps
> > >>>> may
> > >>>> have some policies in place wrt to reliability, security,
> > >>>> coordination,
> > >>>> transaction, privacy etc. Given that refps may contains any XML
> and
> > >>>> these refps are bound as SOAP header blocks, refps can
> potentially
> > >>>> interfere with composibility of WS-Addressing with other WS-*
> specs
> > >>>> that
> > >>>> the consumer may be using. The opacity of the refps prevents
the
> > >>>> consumer from making any inferences about the refps in an EPR.
> > >>>>
> > >>>> This issue is slightly different from the security of EPRs --
> which
> > >>>> *may* potentially be resolved by requiring the minter of the
EPR
> to
> > >>>> sign
> > >>>> the EPR.
> > >>>>
> > >>>> HTH to clarify the issue.
> > >>>>
> > >>>> -Anish
> > >>>> --
> > >>>>
> > >>>>
> > >>>>
> > >>>> [1]
> http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>
> > >
> >
> >
> >
>
>
>

Received on Wednesday, 24 November 2004 14:29:44 UTC