[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SOAP-RPC and REST and security
Michael Brennan wrote: > >... > > OK. I see your point. But I would still say a couple of things about this. > > Making it "easy" to get through the firewall is not the same as > "subversion". The SOAP spec even offers a header explicitly for filtering at > the protocol layer: the SOAPAction header. If you don't want to subvert the firewall then there is a very easy way to do otherwise. You choose a new port and fight your way through the firewall as HTTP did and Jabber has not yet. That's the way the Internet works. Why does SOAP get to change the rules? Why do we have port numbers if henceforth everything is going to go through port 80. Is that logical? SOAPAction would be better than nothing but it was poorly described to start with and is now optional: "Use of the SOAP Action feature is OPTIONAL. SOAP Receivers MAY use it as a hint to optimise processing, but SHOULD NOT require its presence in order to operate. Support for SOAPAction is OPTIONAL in implementations. Implementations SHOULD NOT generate or require SOAPAction UNLESS they have a particular purpose for doing so (e.g., a SOAP Receivers specifies its use)." I understand that in practice, > use of this header is rather uneven. But it seems to have been an explicit > attempt by the spec writers to provide visibility to the firewall, among > other things. I'd be interested in your opinion on this. Would it help if > implementations treated the SOAPAction header more seriously, or was that > proposal a misfire to begin with? SOAPAction was a good idea with poor implementation. But let's go back to my purchase order example. If I started tunnelling purchase orders through comments in otherwise meaningless documents would you be happy if I added a <?po-hack ?> processing instruction? > The fact that tools by certain vendors promote questionable approaches is > not the same as the standard itself being flawed. Rather than fixating on > Microsoft's tools, I'd rather hear analysis focusing on the spec itself. I think that spec itself has three security weaknesses (holes would be too strong of a word). One is that it is designed to tunnel through HTTP rather than using its own port as is standard on the Internet. Two is that it leaves more in the realm of the application developer than needs to be left. They must invent their own addressing model. They must invent their own methods. This raises the bar for the security knowledge they need. Three it is RPC which makes it difficult for sysadmins to filter and monitor because it is too general and opaque. I can't make that last point too strongly and I'll point (again) to the writings of Fielding and Schneier. I'll try a different URI this time: "What makes HTTP significantly different from RPC is that the requests are directed to resources using a generic interface with standard semantics that can be interpreted by **intermediaries** almost as well as by the machines that originate services." **intermediaries** in this case are firewalls." "Most of the recently proposed extensions to HTTP, aside from WebDAV [60], have merely used HTTP as a way to move other application protocols through a firewall, which is a fundamentally misguided idea. Not only does it defeat the purpose of having a firewall, but it won't work for the long term because firewall vendors will simply have to perform additional protocol filtering. It therefore makes no sense to do those extensions on top of HTTP, since the only thing HTTP accomplishes in that situation is to add overhead from a legacy syntax." * http://www1.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_3 ===== BTW, in the last few weeks of argument here I'm yet to hear an inspired argument in favor of SOAP. Anyone here think it's great? Really inspired? Wonderful? That's kind of interesting to me. If SOAP had been invented by a couple of smart programmers and published as a spec, what kind of user pull would there be for it? 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
|