Re: SOAP-RPC and REST and security
Joshua Allen wrote: > > > "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... > > What does that have to do with SOAP? SOAP is explicitly *not* about > mingling code with data. It is impossible for me to imagine how > "commingling data and code" could become "SOAP". I agree. SOAP does not co-mingle code with data. It does, on the other hand, encourage a thin layer between business logic and implementation rather than a thick one. "Just download the toolkit, generate your WSDL from your existing COM object and you've got a web service." That's probably fine within the intranet so I'm not going to say that the tools are inherently broken but I would strongly discourage anyone from using them in that way on the public Internet. > > "Implementation of Microsoft [sic] SOAP, a protocol running over HTTP > > precisely so it could bypass firewalls, should be withdrawn. According > to > > This is a totally different issue. If the purpose of SOAP were to > bypass firewalls, I would agree with this statement. But that is > completely wrong. No, it isn't wrong. In the early days of SOAP this was exactly how it was promoted. http://www.microsoft.com/mind/0100/soap/soap.asp "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. Don't forget that SOAP makes it possible for system administrators to configure firewalls to selectively block out SOAP requests using SOAP-specific HTTP headers." Here's Don Box: "The network protocols used by these three technologies tend to require a non-trivial amount of run-time support to function properly. Ironically, while Microsoft and the Object Management Group (OMG) were arguing over whether the Internet would be run on DCOM or CORBA, the Hypertext Transfer Protocol (HTTP) took over as the dominant Internet protocol. Like many other successful Internet protocols, HTTP is simple, text-based, and requires very little run-time support to work properly. Additionally, many corporate firewalls block DCOM and CORBA traffic, while happily allowing HTTP packets into their (mostly) guarded networks." Over the last couple of years the rhetoric around SOAP has become a little bit more genteel when CIOs started screaming bloody hell. * http://www.vnunet.com/News/1103805 * http://rr.sans.org/start/myths.php But wink, wink, nod, nod, we all know why SOAP is not defined on top of UDP or even TCP like RPC protocols of the past and modern XML-based protocols like Jabber and BEEP. Oops, turns out that even today the rhetoric is not that well tuned: "Middle-tier business functionality exposed via standard Web protocols is known as XML Web services. XML Web services utilize HTTP as a transport allowing remote method requests to pass through enterprise firewalls." http://msdn.microsoft.com/vstudio/techinfo/articles/XMLwebservices/webservices.asp > ... SOAP does not "rely on HTTP as the transport > mechanism", and just because SOAP *can* use HTTP as a transport > mechanism, that does not mean that SOAP was designed to circumvent > security. The statement is shamefully wrong (and I am not sure what > "Microsoft documentation" that was taken from, but I am sure that it is > out of context. See above. >... > Melissa spread mostly through SMTP. The issue with Melissa was that the > mail client allowed commingling of data and code, which is a legitimate > problem. It had nothing to do with RPC vs. REST. I agree and pointed this out. There is nothing technically in common between Melissa and RPC. The only thing in common is a misunderstanding at the world's biggest software company of how to do security right. The details of what they've got wrong in the two situations are totally different. > > 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 > > 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+. > > REST is about "representation" of resources, and that "representation" > is assumed to be mediated in some way from the real underlying resource. > That mediation involves running code, period. Right, and mediation is a good thing in terms of security of public services. So REST has that much right, right? And CGI for all of its flaws, at last *requires* mediation. Where is the mediation in the RPC example discussed here: http://msdn.microsoft.com/vstudio/techinfo/articles/XMLwebservices/webservices.asp By the way, "http://someserver/sh?rm+-rf+" is classic RPC. You've got an endpoint. You are sending it methods. It happens to be sh rather than C#. > > scenarios where business services are exposed via SOAP? And is it > > generally accepted that a REST-ful worm couldn't happen, or is this > > Of course a worm could occur in REST just as easily as with RPC. > Actually, I don't think you could claim that any of the recent worms > have been RPC-based. It is debatable whether they had anything to do > with REST. I'm sure that some of them went over HTTP as Microsoft uses HTTP (and probably REST!) to talk between Outlook Express and HoTMaiL. >... > Not true at all. PUT and POST could modify (in pathogenic cases, which > is what worms exploit) code used to generate the resource > representation. This has in fact been done with the many Perl-based > code injection exploits that used to be so common (knowing that the CGI > used Perl to query the resource allowed people to supply parameters that > contained special characters to fool the Perl into doing something > else). That was a big problem. The Perl world eventually learned the value of mediation and transformation. Alot of that knowledge was incorported into HTTP-centric client and server components. Now we're back to this: http://msdn.microsoft.com/vstudio/techinfo/articles/XMLwebservices/webservices.asp I'll repeat, okay on the Intranet. Scary as hell on the Internet. I don't hear Microsoft, Sun or anyone making that distinction though. Web Services are easy. Click click, generate a WSDL, deploy to IIS. You're done. Note that that document doesn't talk about deploying on the Intranet. It talks about the *Internet*. And all it says about security is: "For security, use of the Secure Sockets Layer (SSL) protocol is supported, as well as standard Web authentication techniques." I can tell from talking to you that you understand as well as I do that SECURITY IS NOT A CHECKLIST ITEM. > > mechanism exists for the remote > > user to execute code directly. > > 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. The difference is that at the heart of REST philosophy is network->implementation mediation as you put it. At the heart of RPC philosophy is making the network look invisible. Or if it isn't at the heart of the philosophy it is at least what is being sold. REST doesn't directly address security. But it indirectly does by: a) discouraging people from reinventing wheels: * use the existing namespace * use the existing protocols * use the existing methods * if at all possible, use existing XML vocabularies b) encouraging people to use standards with well-undersood security characteristics rather than forcing standards bodies to reinvent wheels c) encouraging a layer of mediation between implementation (resources) and interface (representations). If you design in a REST-ful style you almost cannot avoid this level of mediation because of the gap between business logic expressed in terms of objects with arbitrary methods and the Web, with its fixed methods and URI namespace d) putting everything into a common namespace so that a common UI and model can be used for permissions. e) restricting developers to a limited set of methods with security characteristics that are already understood by security admins. f) making impossible (at least thus far) the generation of public interface descriptions from the type signatures of implementations f) discouraging the tunnelling of one application protocol on top of another. g) centralizing protocol design in one or two protocols instead of a new application protocol for each business problem (which is what you get when implement on top of RPC) REST is not a security panacea. There is no silver bullet. All we can do is evaluate each layer's *contribution* to security. SOAP's is negative. It detracts from the security of the protocols that it runs on top of. If that were not the case then you would not be defensive about the idea that SOAP is designed to bypass firewalls. 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