Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SOAP-RPC and REST and security
 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 [expletive deleted] you into running it ... On day I think there will be enough layers between you and REST that you'll be a [expletive deleted] 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 
|
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
|
|||||||||
