RE: Composibility problems with refps

I never said the hacker figures out how to sign arbitrary documents or
even manipulates the SOAP body.  Geez, stay with me here.  I said the
hacker figured out how to put in a refP into an EPR and then the rest of
the unhacked infrastructure takes care of signing, transmission, etc.

Dave

> -----Original Message-----
> From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-
> request@w3.org] On Behalf Of Francisco Curbera
> Sent: Wednesday, November 24, 2004 6:30 AM
> To: David Orchard
> Cc: Christopher B Ferris; public-ws-addressing@w3.org
> Subject: 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 17:03:56 UTC