[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: SOAP-RPC and REST and security
> From: Paul Prescod [mailto:paul@p...] <snip/> > 2. SOAP lies. HTTP is an application protocol, not a > transport protocol. > It has syntax and semantics, just as XML has syntax and semantics. > Imagine if someone asked you to submit a purchase order in some ebxml > schema and you generate a valid instance but you actually put > all of the > "real" information in comments. The PO stuff is just 0's and empty > fields. And maybe you've done this because you've colluded > with someone > on the "inside" to send the information this way instead of > the regular > way. They told you that if you sneak it through in this way > then it will > bypass the company's screening and business logic and they'll > make sure > it gets approved at whatever price. This is what SOAP does to > firewalls. > It lies to them. It says: "I'm HTTP traffic. I'm doing a > POST. Check the > HTTP specification to know what that means." Jabber, BEEP and > many other > XML protocols do not do this. They are defined at the TCP level as is > logical. Routing SOAP over HTTP is a way for someone inside > the company > and someone outside the company to collude to disable the > RPC-filtering > features of the service. > > SOAP lies both about what it is doing (POST to do getStockQuote) but > what it is working with. "Ignore the component behind the curtain. It > isn't working with millions of resources that really should have URIs. > It's just one resource. One big fat honking resource. Really." If SOAP > ran on TCP it would not need to feel obliged to obey the rules of the > Web and HTTP. But it doesn't. 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. I still think the focus on RPC misses the point. It's still just XML over HTTP, 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. 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. 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. 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". 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. The truth is that the issues with SOAP are the same issues that have been there since the very first CGI script was written. I've heard nothing, yet, to convince me otherwise. 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.
|
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
|