[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: SOAP-RPC and REST and security

  • To: "Mike Champion" <mc@x...>,<xml-dev@l...>
  • Subject: RE: SOAP-RPC and REST and security
  • From: "Joshua Allen" <joshuaa@m...>
  • Date: Tue, 19 Feb 2002 21:57:39 -0800
  • Thread-index: AcG5x5gFa/+Ych9nTE2XOSd7P/OB8wACEaYA
  • Thread-topic: SOAP-RPC and REST and security

bypass firewalls
> "And one of the simplest, strongest, and safest models is to enforce a
> rigid separation of data and code. The commingling of data and code is

> responsible for a great many security problems...

What does that have to do with SOAP?  SOAP is explicitly *not* about
mingling code with data.  It is impossible for me to imagine how
"commingling data and code" could become "SOAP".

> "Implementation of Microsoft [sic] SOAP, a protocol running over HTTP
> precisely so it could bypass firewalls, should be withdrawn. According
to 

This is a totally different issue.  If the purpose of SOAP were to
bypass firewalls, I would agree with this statement.  But that is
completely wrong.  SOAP does not "rely on HTTP as the transport
mechanism", and just because SOAP *can* use HTTP as a transport
mechanism, that does not mean that SOAP was designed to circumvent
security.  The statement is shamefully wrong (and I am not sure what
"Microsoft documentation" that was taken from, but I am sure that it is
out of context.

> However, Microsoft promotes it for its security avoidance. "

OK, now we get to the real issue.  This isn't about RPC vs. REST, it is
about the alleged motives of some faceless marketing department.

> One could surely argue that REST *does* rigidly separate code from
data,
> and I can't see offhand how a Melissa-esque worm could spread via a
REST
> web service.

Melissa spread mostly through SMTP.  The issue with Melissa was that the
mail client allowed commingling of data and code, which is a legitimate
problem.  It had nothing to do with RPC vs. REST.

> the other hand, I can imagine people getting carried away and making
all
> sorts of OS-level stuff accessible via SOAP-RPC without thinking too
hard 

This has nothing to do with RPC vs. REST.  I remember when Rob McCool's
HTTPD first started to proliferate and people started hooking up CGI to
/bin/sh.  It was really cool; you could do http://someserver/sh?rm+-rf+.

REST is about "representation" of resources, and that "representation"
is assumed to be mediated in some way from the real underlying resource.
That mediation involves running code, period.

> scenarios where business services are exposed via SOAP?  And is it
> generally accepted that a REST-ful worm couldn't happen, or is this 

Of course a worm could occur in REST just as easily as with RPC.
Actually, I don't think you could claim that any of the recent worms
have been RPC-based.  It is debatable whether they had anything to do
with REST.

> if you give me PUT access I could send you a virus that did all sorts
of
> harm, but I'd still have to [expletive deleted] you into running it ... with RPC, a


Not true at all.  PUT and POST could modify (in pathogenic cases, which
is what worms exploit) code used to generate the resource
representation.  This has in fact been done with the many Perl-based
code injection exploits that used to be so common (knowing that the CGI
used Perl to query the resource allowed people to supply parameters that
contained special characters to fool the Perl into doing something
else).


> mechanism exists for the remote
> user to execute code directly.

Again, I don't understand this.  RPC does not pass code to the server.
The user does not "execute code directly".  The user passes some
parameters, and the server executes whichever code it has been
configured to execute in response.  Same as happens with REST.



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.