[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..., "'Paul Prescod'" <paul@p...>
• Subject: RE: SOAP-RPC and REST and security
• From: Michael Brennan <Michael_Brennan@A...>
• Date: Wed, 20 Feb 2002 13:11:51 -0800

> From: Mike Champion [mailto:mc@x...]

<snip/>

> 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 [expletive deleted] you into running it ... with RPC, a 
> mechanism exists for the remote 
> user to execute code directly.

I think Bruce Schneier really missed the mark on this one. I was quite
disappointed in his article. I don't think he has made any sincere effort to
understand SOAP. He took some superficial marketing statements by Microsoft
and treated them as a technical assessment of SOAP.

The truth is that SOAP-RPC poses no more a security risk than CGI programs.
There is nothing really new, here. And although I think Paul makes valid
points with regard to REST, I also think he overplays the value REST brings
in terms of security. REST won't keep naive programmers from doing foolish
things. If a developer does not understand the need for sound authentication
mechanisms in a web service (which I can tell you from personal experience,
many don't), REST won't help. If they don't understand the need to ensure
message privacy, REST won't help.

I don't doubt that the web services "revolution" will bring us some really
scary security breaches, but that will be do to naive developers, not
failings of the technology. I've seen ordinary, browser-based web
applications that accept form submissions in which one of the parameters is
evaluated on the server using Javascript's "eval" function, or similar
facilities. What is SOAP-RPC bringing to the picture, here, that will really
make things worse? And just throwing a firewall in the mix doesn't provide
any real security.

Instead of scapegoating technology, there is a desperate need to raise
awareness on the part of developers with regard to security issues, and to
hold vendors accountable for failing to treat this stuff seriously. Bruce
Schneier usually gets this stuff right. His SOAP article was a letdown, in
this regard.

This is not to say I am endorsing SOAP-RPC as the best approach to web
services. I just think the security criticisms miss the mark and are not
contributing to the sort of discussions that will arm developers with the
knowledge they need. RPC is not the issue, here. You can do secure RPC. The
issue is the failing of developers to understand you can't trust what comes
over the wire, and you can't assume that others are not listening in on the
conversation. It is truly scary how many developers don't understand the
basics, and these are the developers who will be implementing web services.

And all this talk about firewalls is a bit baffling to me. It has not been
my experience that SOAP is flourishing because of a bunch of sneaky
programmers trying to slip one by their firewall administrators. Maybe there
is some of that going on out there, but I haven't seen it. What I have seen
is projects where those in charge of network security are consulted, and
they always respond "just use HTTP -- I don't want to have to open up other
ports on the firewall". So I don't really understand the firewall
criticisms, although I do understand (to some degree) Paul's points about
visibility.

• Prev by Date: RE: SOAP-RPC and REST and security
• Next by Date: RE: SOAP-RPC and REST and security
• Previous by thread: Re: SOAP-RPC and REST and security
• Next by thread: RE: SOAP-RPC and REST and security
• Index(es):
  • Date
  • Thread