W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2004

RE: Composibility problems with refps

From: David Orchard <dorchard@bea.com>
Date: Mon, 22 Nov 2004 16:25:19 -0800
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF0BE453F6@ussjex01.amer.bea.com>
To: "Christopher B Ferris" <chrisfer@us.ibm.com>
Cc: <public-ws-addressing@w3.org>

> -----Original Message-----
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> Sent: Monday, November 22, 2004 4:07 PM
> To: David Orchard
> Cc: public-ws-addressing@w3.org
> Subject: RE: Composibility problems with refps
> David,
> That's a pretty far fetched example:-) Why would I choose to
> <allYourAssetsAreBelongToUs/>?

I wouldn't want to preclude a bank from having an interface that deals
with account transfers.  SOAP gives a powerful extensibility model for
interfaces, and an account transfer is a possible example of a header
block.  Oh, is this the "make the example sound as ridiculous and
farfetched and silly as possible" argument style? 
> And how is the example you give an example of duplicate user headers
> (whatever they are)? 

It's a duplicate user header because the service offers the
"SendAssetsToGrandCayman" interface as a soap header that clients can
invoke, which is also accidentally or intentionally invoked by the EPR.

> And what makes
> you say that duplicates would necessarily be a security hole? 

Because the hacker gets the minter of the EPR to put the "sendAssets"
header in the EPR.  According to the WS-A processing model, they can't
tell whether it is a legit header block or not, they just echo away.

> And how does
> a wrapper mitigate against any of this?

Because the EPR could contain the "sendAssetsToGrandCayman" RefP, but it
wouldn't be sent as a soap header block, and thus the functionality
wouldn't be invoked.

> By your account, we shouldn't have a SOAP processing model at all
> some unscrupulous client
> could stick in a <sendMeAllYourAssets soap:mustUnderstand='true'/>
> block.

No, that's not the same, because the two sides agree upon the interface
and the client is allowed to send the "sendassets" header block.  I'm
just pointing out a case where there's a valid interface, the EPR minter
can get hacked, and the normal model of EPRs - even with securing the
EPR - doesn't prevent the wrong thing from happening.  

People can easily say "well don't get hacked internally" but that's
harder said than done.


Received on Tuesday, 23 November 2004 00:26:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:28:21 UTC