[
Lists Home |
Date Index |
Thread Index
]
One more issue on RPC vs REST -- security.
I'm not sure this is a differentiator, but consider this section of
http://www.counterpane.com/crypto-gram-0202.html#2
"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...
"Implementation of Microsoft [sic] SOAP, a protocol running over HTTP precisely so it
could bypass firewalls, should be withdrawn. According to the Microsoft documentation:
"Since SOAP relies on HTTP as the transport mechanism, and most firewalls allow HTTP to
pass through, you'll have no problem invoking SOAP endpoints from either side of a
firewall." It is exactly this feature-above-security mindset that needs to go. It may be
that SOAP offers sufficient security mechanisms, proper separation of code and data.
However, Microsoft promotes it for its security avoidance. "
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. What about SOAP-
RPC, though? I'm inclined to think that the article is unfair (and the prescription
draconian), because a SOAP RPC call could only invoke a procedure that had been
installed on the target machine it's impossible to secure a system against idiocy. On
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 about it, and that could
lead to SOAP-y worms.
So, what's the current thinking about SOAP-RPC as a security risk in *plausible*
scenarios where business services are exposed via SOAP? And is it generally accepted
that a REST-ful worm couldn't happen, or is this wishful thinking on my part? I guess
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 mechanism exists for the remote
user to execute code directly.
|
