RE: [xml-dev] SOAP-RPC and REST and security

["Joshua Allen" <joshuaa@microsoft.com>]

> "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 sucker 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.