Slashdot Mirror
Web Services - More Secure or Less?
visibleman asks: "I have recently moved onto a project which is based around web services and SOAP and have, therefore, been doing some reading on those subjects. One thing which keeps coming up is that web services are claimed to be more secure than CORBA and RMI because it means drilling less holes through firewalls. If I was a firewall administrator (I am not, I am a developer) I would want to know that if I open up a port (port 80 for instance) I know what kind of requests are coming through it. Since SOAP is essentially a mechanism for sending functional requests over a port specified for web page requests this would make me nervous. My preference would be that requests for web pages go over one port and requests to run services go over another - favouring an IIOP solution. Am I off my trolley or would other Slashdotters have similar fears?"
Hi,
SOAP is transport independant. That's one of its (theoretical) virtues. You can implement SOAP over SMTP, HTTP, whatever.
Practically, it does seem fair to say that HTTP is what an awful lot of SOAP tools are going to be expecting, and given that SOAP is still quite bleeding edge, I wouldn't want to try using another transport protocol unless I could afford time and skill to do a lot of fixing up.
However, HTTP doesn't have to run on port 80. Furthermore, most SOAP implementations will be (well, claim to be) happy on HTTPS too, so that's an easy way to do encryption.
As for the 'web page vs functional' thing, well that's not so simple. A request for a page produced by a CGI script is a functional request coming from strangers over the web. SOAP need not be different.
At the moment, if I want to make an XML version of my content available to folks, I might tell them to use HTTP GET with a URL that invokes a CGI program that returns some XML.
In the future, I might want to make the same XML available via the getXML method my Website class, and then SOAP enable my Website class.
The differences isn't that great.
-----
After posting my last reply, I thought of something that is a GOOD thing regarding SOAP over HTTP that deserves mentioning. By directing and detecting all web traffic, you now have a transactional log off all RPC calls being made into your system. So while yes, you are possibly exposing things, you have a much better logging mechanism in a central location then you would have by having any given application tunneling thru its own socket, making calls to its hearts content. All calls cal now be logged, filter, redirected, etc..
Now of course, this does apply only to SOAP over HTTP, and possibly not SMTP/POP3, Raw socket, MSMQ, etc..etc..
-- I'm the root of all that's evil, but you can call me cookie..
Bruce Schneier had an interesting statement on security and SOAP:
. html#SOAP">CryptoGram Newsletter on 2001-June-15:SOAP</a>
<a href="http://www.counterpane.com/crypto-gram-0006
A couple of rebuttals if I may.
Many people claim that one can run services on any port they choose, so port filtering is not the same thing as service filtering. True, but if people ran anything on any port we would have no concept of well-known-services at specific ports. Moving web traffic from port 80 makes almost no sense because that's where everyone is going to look for it by default. There is a high probability, then, that filtering on specific ports will filter specific services.
Network administrators, by default, are highly suspicious and paranoid people. They don't even trust the people they work with, and for good reason. If they could force everyone to use pine or mutt for e-mail reading, I'm sure they would since it is less succeptible to Outlook-born viruses. If development teams would communicate with and seek advice from the security team when developing applications I'm sure there wouldn't be as much hostility to opening a port as there is when approached with "We just wrote an application. Can we have a free port?"[1]. In the latter case, the security team has no idea what the application does or how it was developed and is certainly not inclined to open a port to untrusted software.
Finally, on to the subject of my article, Apache (or whatever server you're running) is the inetd of the future. Look at the facts:
- both listen on one or more ports for requests
- when a request comes in it is dispatched to the correct subsystem
- most security (ssl, https, tcpwrappers) is handled by the daemon before it gets to the service handler
- the service handler can perform further accouting or security checks
- the daemon handles all the networking details on behalf of the subsystem
Add to this the fact that this is all multiplexed on a single port, and configuring your firewall should be a breeze. Virtually anything you can do with inetd you can do with a good web server.Paradoxically, network admins appear less paranoid about their web servers than other inetd-based or standalone services. Some guy codes up a web app and, with little fuss, gets it deployed on the server. No code review, no hassle, no problem! There are only two reasons I can think of for this behavior: 1) The administrator inherently trusts the web server, or 2) the web server box is in a DMZ. I would be suspicious of administrators in the former case.
Despite the security advantages of a DMZ, it is still necessary for application developers to communicate with security people. Say, for example, that a web application is deployed on server in a DMZ and that the machine is later compromized. If the application had a configuration file with passwords for a database, the database should now be considered compromized. Damage can be reduced or prevented by correct configuration of the database (providing write access only to a specific table rather than the whole database), but you should check with the security people before actual deployment.[2]
[1] The standard answer to this question is "No". Note that the administrator only answers the question asked. If you want to be more successful in the future, present a full document detailing what the software does, how it works, and maybe provide the admin with a code review, THEN ask for a port. I know this is a lot of work, but it is necessary to maintain the security of the network. You may not take security seriously, but your administrator does.
[2] Yes, I know that there are moron security people out there. My comment assumes you have good to excellent security people working in your company.