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?"
Exactly, there has been much gnashing of teeth on the xml-dist-app list about this (a SOAP standardization list).
Although SOAP is bound to HTTP, there is no requirement that you use port 80 -- it's just a well-known HTTP port. As long as the people who need to use your service agree to it, you can use port 12345 if you want. If you are really paranoid, you should be running HTTP over something more secure, like a VPN between you and the service requestor, and not the public (great unwashed) internet.
You can use any port you choose. A bit "security through obscurity" this one, but no harm there>
You don't really need a full web server. All you're going to get is an HTTP request with a SOAP envelope thingy inside. If it doesn't match the WSDL (or whatever) schema thingy you've published, then just ignore it. You only need give the information to people who are going to be legitimately calling your service. Of course you're still vulnerable to normal DoS, but then isn't everyone.
It is quite possible to digitally sign SOAP requests. Just ignore anything not signed/not signed by a recognized customer.
If you are only exepcting SOAP requests from a few other servers, then consider client-side SSL. Since only a few servers will be calling you, then you'll only need a few client certs.
... well ... you get what you ask for. Signatures on SOAP requests aren't (easily) supported by everything yet - but then SOAP implementations differ (eg MS SOAP has no types, IBM SOAP does). This isn't a major issue as it's pretty easy to roll your own request - it's only XML after all.
Like everything, it's as secure as you make it. If you expose "FuckMyOS" as a SOAP method and publish it through UDDI or something then
PS I have no opinion on Vladinator's website.
This sig made only from recycled ASCII
SOAP is NOT bound to HTTP by any means. It is the most popular implementation of the transport layer, but it can, just as I'm looking at now, go thru other transports, such as an SSL socket connection.
-- I'm the root of all that's evil, but you can call me cookie..
It's not about security, it's about the adminstrative effort of getting a firewall configuration change made in a large organization. In short, it's really hard to do.
Here's a purposely oversimplified and perhaps harsh explanation:
Simplisting firewall adminstrators don't care what you send over the network, as long as it's on port 80. More sophisticated adminstrators also insist that it's HTTP. Even more sophisticated ones inspect in more detail, such as checking to see if files transferred have viruses in them.
It's only a matter of time before firewall adminstrators notice that SOAP requests are really RPC calls, and block them by default - then we will all be back to having to get specific configuration changes done to let apps work over the firewall. We won't want to do that for the same reasons we don't want to try to convince someone that it's OK to open a port.
I predict that there will therefore be a way developed to wrap SOAP not only in HTTP, but in HTML. The XML SOAP request could sit inside of simple HTML wrapper tags; this would let it go through the likely block-by-default of SOAP traffic.
SOAP has actually gone well out of its way to allow server admins to filter requests. It makes use of the "Mandatory Header" aspects of the HTTP protocol such that every soap request must come with an HTTP header specifying which function is being called. Since it's in the header, a server doesn't need to know SOAP to filter, it justs needs to know HTTP, and the server can simply turn away anything that doesn't provide such a header.
I agree there is still a major lack of support for this type of filtering, and even the standard leaves something to be desired in this respect, but the SOAP designers definitely did think that this was a big enough problem to provide facilities for future closing of these holes.
It's a bit of a pain to administer, but it definitely *can* be done.
SOAP was developed specifically so companies (such as Microsoft) can execute arbitrary code through otherwise secure firewalls where all they have to do is get the user to download a simple client program that wraps the commands in an XML format and sends it as an innocent looking HTTP response. It was designed to *solve* the problem of corporate users wanting to run network applications that are verboten or otherwize blocked by their network administrators.
SOAP is designed with security in mind. Security circumvention.
I work for an ASP, and we basically have to build full web applications that function like Office tools, and believe me, port 80 is a necessity.
.jar files being executed. Some of them just don't want to allow anything but port 80.
We need to fire up a java applet on the client machine that maintains a session with the server. We also need to allow chat.
I can't begin to tell you how many million sof dollars we've lost as a company because of large corporations that refuse to adjust their firewall settings to accomodate web applications.
Some of them don't want
If we're only allowed traffic on port 80, which is the case when dealing with 90% of corporate environments, your choice is either a) get the services running over port 80 or b) give up on maintaining your business.