[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: RE: SOAP-RPC and REST and security
2/20/2002 12:57:39 AM, "Joshua Allen" <joshuaa@m...> wrote: > >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+. Nice counter-example! I was thinking about how easy it would be to do this with a SOAP toolkit, but it's not a challenge with HTTP (as we use it anyway) either. I think I'm convinced that idiocy with respect to security is neutral with respect to RPC vs REST. > >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. Al Snell made the same point, and I definitely shouldn't have said "directly." The point about Melissa-esqe viruses being triggered by mail clients and naive users rather than RPC or SMTP is also well-taken. I guess it comes down to my conception of the SOAP architectural style vs the REST architectural style. SOAP encourages a software engineering approach of building software components that can be invoked remotely. I can easily imagine how a componetization that was not rigorously audited for security vulnerabilities could leave too-powerful operations exposed to the internet. REST, on the other hand, encourages a "document processing" approach where the remote user submits data to a URI, and that triggers some executable version of a business process. It just seems a lot less likely to leave a hole in one's business process that says "exececute an arbitrary piece of code" than to leave a hole in one's software architecture that says "execute an arbitrary piece of code." It would appear that security is not a differentiator between RPC and REST at the *technical* level. I still think that the basic design pattern of considering Web Services as flows of business documents makes it easier for a non-expert to design a secure system than when one considers web services as as the remote invocation of software objects. The "flows of documents" design could be implemented in either SOAP-RPC or REST, no dispute, but it just seems more RESTful than SOAPy to me. I keep coming back to the same basic opinion: SOAP-RPC and the tools that support it are great for building distributed applications within an enterprise, behind a firewall, where people basically trust each other (and violations can be traced and punished), and where reliability and latency are either not a problem (or can be handled in a straightforward manner, such as with the extra step in VS.NET that Francis Norton mentioned). In these situations, you can indeed "hide the network behind the tools." But when you can't hide the network because of lack of bandwidth, latency, trust, reliable connectivity and so on, or you don't want to hide the network for some other reason, REST looks like an awfully good design pattern.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|