An Interesting Quandary
My Mail Page scripts are broken again today, so I'm only picking the most interesting messages for posting. Doug is working on the problem. In the meantime...Jeff Allen, jra@corp.webtv.net, writes: "There's an interesting quandry with the HTTP-as-universal-protocol idea. Corporate firewalls disallow random TCP ports and all RPC since Bad Guys can do Bad Things on internal hosts from across the Internet using them. Firewall administrators have looked at HTTP, and are comfortable with it, since it appears to be a one-way information gathering medium. So, all firewalls allow HTTP-speakers almost free rein to jump the firewall.
"This is GREAT! It means that your XML-HTTP applications are all set to jump through firewalls out of the box, with no need to write and install new proxies. Coooool!
"Until the first breakin happens due to an XML-HTTP app.
"Then CERT puts out an advisory, and all the HTTP-proxies try in vain to shut out XML-HTTP apps. But they can't, because there's no fundamental difference between POSTing a search to AltaVista, and POSTing a Betty procedure call. And there's no easy way to tell if what's coming down in response is the HTML from scripting.com, or XML that manages to do some dirty deeds.
"It's against my nature to spread FUD about something that I don't have a solution to. But this is a real danger. Once the protocol evolves from simply displaying data off the net to using it intimately inside the guts of a non-sandboxed application, the protocol is no longer the happy fun safe protocol that firewall admins let thru unchecked."
Chuck Shotton, cshotton@biap.com
No disrespect to Jeff Allen, but his comments *are* FUD. Totally alarmist and not founded in the reality of the way the Web works. People don't implement HTTP security via firewalls. They implement it with usernames, passwords, security realms, custom CGIs, and access control files on their HTTP servers.
XML RPCs over HTTP are fundamentally no different that posting of form data to CGIs from a Web client. If you add firewall security, more often than not it's to keep people inside your firewall instead of keeping others out. Most companies with a clue about security keep public servers outside the firewall and private ones inside. But I digress.
If you have screwed up CGI security or access controls, I can do just as much damage to your corporate database with a Web browser as I can with a custom XML RPC. The *advantage* of XML RPCs sent over HTTP is that they can behave EXACTLY like all other HTTP transactions, meaning that existing HTTP security mechanisms can be used to enforce access controls without ANY server code changes or learning curves for admins.
Maybe Jeff has a different view of how XML RPCs get implemented over HTTP, but all the work I've done on the subject says that there are no significant risks or implementation concerns beyond those that are already present in the Web today with forms, Java applets, and custom clients, spiders, etc. sending requests to Web servers with dynamic back-end processes.
In a nutshell, a XML RPC call over HTTP is nothing but a slightly more structured submission of data to a CGI. Why is that so scarey? And if it *is* scarey, then we should have been scared the minute the first URL with search arguments appeared on the net in 1992. Because that was when we started allowing people with Web browsers to send data to processes on remote machines.
Dave Winer, dave@scripting.com
An important point, I don't think that all communication is going to go thru the net. I think a lot of the interesting traffic over this protocol will be between processes running on the same machine. Read A Note to My Readers, especially the part about personal web servers.
Angus Davis, angus@netscape.com
Jeff Allen's comments are not FUD. What he is saying is essentially this:
Today, network administrators block out certain protocols at the firewall. For example, I cannot open a telnet session with a host outside Netscape's firewall. Some administrators have blocked IIOP, FTP, etc. What Jeff is saying is that those network administrators have not blocked HTTP because it is considered "safe," and thus it shouldn't be blocked. He asks what will happen when HTTP is used for supposedly "unsafe" things, such as RPC.
The argument does fall apart, however. Virtually any protocol today can be "tunneled" via HTTP. For example, IIOP is tunneled through HTTP frequently. So, while the quandry Jeff poses is valid, it's nothing new.
Jacob Levy, jyl@tcl-tk.com
Nothing new really. People do all the time tunnel their X-wizzy-foobar protocol over HTTP. Microsoft DCOM has an option to use HTTP. XML/RPC is more secure than most RPC protocols because it relies on entry names rather than entry numbers (like DCOM? Pls someone correct me if I'm wrong) so they're harder to guess and misconfigure. Of course this is just a characteristic of *your* proposal, someone else might rely on entry numbers using a variant of the XML/RPC protocol.
HTTP Post by nature is bidirectional, so even today (even without tunneling other protocols over HTTP) sysadmins are knowingly allowing bidirectional communication across the firewall. I'd say that your proposed XML/RPC is about as secure as HTTP Post today.
|
This page was last built on 4/18/98; 10:35:11 PM by Dave Winer. dave@scripting.com |