Cart
|
[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: > >... > > Personally, I think you make valid points. What I take issue with is the > notion that SOAP has introduced something fundamentally new into the mix. Thread 1: Q: "Why do you use SOAP? A: "Because it is SO EASY to wrap up business logic into a component and throw it onto the Web and have a web service. Microsoft has a tool to do it." Thread 2: Q: "How is SOAP any different from other abuses of HTTP?" A: "Because it is *specifically designed* to make doing things the wrong way easy." Is SOAP in and of itself a security hole? No. Will it give rise to more security holes than other approaches? I'll wrap myself again in the Bruce Schneier flag. > ... I > still think the focus on RPC misses the point. It's still just XML over > HTTP, XML over HTTP is not necessarily abuse of HTTP. SOAP is abuse of HTTP. If you show me a particular example of XML over HTTP then I'll tell you whether or not it is working against the security of the Web. Barring RPC, it is much, much easier to use XML over HTTP in a way that respects HTTP than to try and work around it. So people do. But RPC makes it easier to use XML over HTTP in the *wrong way*. You're simplifying the mechanism for doing things in the wrong way and thus introducing a bias against doing things the right way. > ... and I don't see how the RPC approach to SOAP is really fundamentally > different from the applications developers are doing that accept HTML form > posts. It's radically different because there is no easy way to build a bridge from form posts to arbitrary COM objects, is there? It takes effort. It takes mediation. The extra effort introduces a layer of indirection which makes security holes less likely. If you continue to think the issue RPC is irrelevant than I'll ask again why no RPC protocol (not an RPC-based protocol, but an RPC protocol) has ever become popular on the public Internet. And if SOAP does so by working around the firewalls that system administrators put in to *stop RPC* will it be an accomplishment? > In fact, with existing tools its easier for me to expose logic via an > HTTP post using HTML forms than it is for me to use SOAP, and I'm hiding > things just as much as with SOAP. Expose logic, yes. Expose your applications internal behaviours? No. Because your application is probably a COM object and nothing could be easier than spewing out a SOAP layer from a COM object through visual studio. > ... I fail to see how pointy brackets vs. > name/value pairs poses an inherent new security risk. You can use either to > invoke logic behind the firewall. Pointy brackets have nothing to do with it. * It's about the semantics. Application protocols have application semantics. RPC protocols do not.* * It's about the semantics. Application protocols have application semantics. RPC protocols do not.* * It's about the semantics. Application protocols have application semantics. RPC protocols do not.* Bruce S. says this. Roy Fielding says this. I say this. Long before I had heard of SOAP I thought it was common knowledge that you don't let RPCs through your firewall because *you can't know what they are doing because they have no application semantics*. If I run "netstat" and see that I'm running with an open SMTP port then I know exactly what kinds of data will come through that port...email. If I see port 80 then I know (or used to know) that that's web traffic and will go to IIS. But when RPC starts streaming through, any packet could be directed to any application and do anything whatsoever because RPC protocols have no application semantics. > SOAP-RPC seems to me to just be building upon the approach toward building > web systems that started with CGIs. I don't see SOAP as having introduced > anything fundamentally new into the mix in this regard. I've found this > whole REST debate to be interesting and enlightening. I feel those of us > building web apps could learn quite a bit from REST. What I don't see is why > some folks are picking on SOAP so much and suggesting that this is somehow > intrinsically worse than all of those CGI programs out there accepting a > bunch of form posts through one big fat honking resource -- all with content > that is just "application/x-www-urlencoded" or "multipart/form-data". It seems to be damning SOAP with faint praise to say that it isn't much worse than other abuses of the infrastucture that you can already pull off. Somehow it seems a little different to me when a lone programmer engages in an abuse versus the world's biggest software company. > ... That I > don't understand. Developers are left with the impression from Bruce > Shneier's criticism (and that of others) that there is something > fundamentally new about SOAP that poses greater security risks to the > network. Just wait until someone installs a SOAP-DCOM bridge inside a big corporation. We'll see the sparks fly then, baby. Please describe what the analogous bridge looks like for HTTP and CGI. You could implement it but you'd be reimplementing SOAP. And why would you do that when you could just use ... SOAP. SOAP was always designed to allow the routing of DCOM over firewalls. Think about it...all of the infrastructure software companies in the world are working together to sell FIREWALL SUBVERSION TECHNOLOGY. And they advertise it as such. Doesn't that seem a little strange to you??? If system administrators wanted to allow RPC through their firewalls they could have done it six years ago. They don't need Microsoft's help. >... > On the other hand, if the criticism is simply over vendors failing to put > enough emphasis on security issues, I don't disagree. The vendor push behind > SOAP is pouring gasoline on the fire with regard to pervasive security > problems in software today. But I don't see anything inherent in SOAP that > is making things worse than they already are. SOAP is designed to make things worse. It is designed to evade detection at the firewall and to make it "easy" to expose your application's logic to the network. 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
|
|||||||||
