[
Lists Home |
Date Index |
Thread Index
]
Mike Champion wrote:
>
>...
>
> 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.
Once you get six or seven layers on top you'll get back to the worms.
SMTP is tried and true. As a protocol it is secure (even if
implementations were not). Yet works were spread through it because of
layers on top like VBScript. But REST certainly encourages security at
its level much more than RPC does.
> ... 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.
But remember the discussion we had a week or so ago. If you use the
protocols *properly* as they were intended to be used then a smart admin
can understand what is going on and enforce policies, like "the intranet
is write-only for people outside of our domain." Easy peesy if you use
HTTP as it was meant to be used. Hard if you use *any* form of RPC
because the admin doesn't have visibility. A method could take a hundred
parameters and only becomes dangerous if the fifteenth is a priviledged
userID.
Required reading:
http://www.xent.com/aug00/0605.html
I'll quote a bit but it isn't a replacement for reading the message and
some in the thread "Architects use protocols to enable a defined set of
communication. The degree to which that communication is visible to
intermediaries determines whether or not it can be safely passed through
a firewall. Now what is it about HTTP that makes it different from RPC,
and thus safe for transfer through firewalls?"
> .... 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.
Remember that one of the great advantages of SOAP and WSDL are that you
can just take an existing COM object and "generate" a network interface
to it. *That's the primary virtue*: it allows you to generate network
apps without re-thinking your interfaces.
I talked to an EJB expert about REST. We were talking about security
models. I described how REST has a natural ACL or capabilities model.
What's the natural model of RMI (which is basically OO RPC with class
distribution)? He said that there is some interface you hook in
arbitrary code and throw an exception if something is wrong. I asked
"how is that different than just rolling most of the security yourself."
He shrugged. Not really. Now do you think that your average sysadmin is
going to write Java code to help secure the app? No, they can't. That
means that all security is in the hands of the developers. They are
required more or less to invent a new permissions model (probably an ACL
workalike) for each app.
> 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 ...
On day I think there will be enough layers between you and REST that
you'll be a sucker without knowing it. But that isn't REST's fault. It
does what it can. I agree that it is pretty hard to figure out how to
fake REST out. It enforces a "marshalling and networking" layer that is
a sort of first-line of security.
> ... with RPC, a mechanism exists for the remote
> user to execute code directly.
Not long ago it was common sense in our industry that you would never
expose a generic RPC port to the general internet. David Megginson made
a joke about it several years ago at the annual XTech conference.
Security analysts are amazed at where the web services world is going. I
personally would not choose to be on the opposite side of a security
issue from Bruce Schenier!
You can absolutely define safe systems using RPC. But the tools do not
encourage it and the very model of RPC does not encourage it. Plus the
RPC model makes security *verification*, *auditing* and *policy
creation* much harder.
Paul Prescod
|
