[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SOAP-RPC and REST and security
Dare Obasanjo wrote: > >... > > What I'd like to know is WHY he is against SOAP. In the old days I could > understand why people didn't want various RPC services exposed on their > machines because they were a security risk due to all the buffer > overflows and the like that existed in them. Maybe there was a reason there were all of those buffer overflows. RPC requires ordinary programmers to take much more control of their own security model than application protocols do. When you see an SMTP message going through the firewall there are certain things you know based on your knowledge of the semantics of the SMTP protocol. When you see an RPC message it could as easily be a command to shut down the computer or to accept a purchase order or to frag a Quake competitor. There's no way you can know from the fact that it is RPC what it is "about" in even a vague sense. You COULD make a service to shut down a computer through HTTP or SMTP but people don't because the applicaion semantics would be so skewed. On the other hand most or all Windows boxes run an RPC program that DOES shut down the computer (after authentication, of course, if you trust the security). >... > Nowadays that web servers allow requests that execute server side code > from servlets to ASP to CGIs, I'm not sure exactly why anyone would be > opposed to what is simply another mechanism for telling a server to > execute some preset operation on the server. The semantics of those server side applications are almost all within what the Web encourages. People do not regularly use HTTP to shut down computers or play video games. When they do, it is almost always tunnelling which is what SOAP does. SOAP is on the side of the bad guys in that sense. > Unless Bruce Schneir us simply against all mechanisms that would allow > clients to execute code on the server even if the code was already > predetermined. Bruce says the problem is with RPC. This comes back to what I said before. The prohibition against exposing arbitrary RPC was, I thought, deeply engrained in the computer security world so that we don't have to explain it to each other over and over again. Bruce: "Let's continue the DCOM example. So what if DCOM runs over a firewall? DCOM is Microsoft's main protocol for inter-application communication. It's not just used by programs that are intended to be servers; it's used for all sorts of desktop communication and remote access. The result is that an average machine has dozens of programs using DCOM. Mine shows 48, ranging from "Microsoft PowerPoint Presentation" to "logagent" and including the catchily named "{000C101C-0000-0000-C000-000000000046}"; you may be able to list yours by bringing up a Command Prompt and typing "dcomcnfg". Now, there are lots and lots of ways to secure DCOM applications, so maybe all of those applications are happily responding only to authenticated requests from the local machine. On the other hand, there are lots and lots of ways to make DCOM applications insecure, so maybe one of them is just waiting for somebody to send it an entirely unauthenticated request to overwrite selected files on my hard disk. " RPC over a firewall is okay if you run one or two known services with well-defined semantics (e.g. NFS or syslog). Then those known vocabularies are like application protocols and you can ignore the fact that they happen to have an RPC substrate. Just tunnelling arbitrary SOAP vocabularies over HTTP is a CIO's nightmare. Why do you think that firewalls prevent DCOM from going across them in the first place? How does SOAP syntax help anything? 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
|