[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: SOAP-RPC and REST and security
> "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". > "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. 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. > However, Microsoft promotes it for its security avoidance. " OK, now we get to the real issue. This isn't about RPC vs. REST, it is about the alleged motives of some faceless marketing department. > 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. 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. > 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. > 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. > 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 ... with RPC, a 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). > 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.
|
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
|