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
My real concern about tunneling everything through a single port or protocol is that it makes network auditing much more difficult. If there is a security problem, or just a general network problem, the fact that everything looks like HTTP doesn't help track down the problem.
However, there is a flip side to this. I have been in the position of trying to convince large companies to change their firewall configurations. It would be easier to make lead in to gold than to get a large company to allow communications through a new port on their firewall.
This basically means that putting everything through port 80 serves two purposes. It give people the perception of security, and it lets the project actually happen. It is the case that not having to change your network configuration is a powerful marketing tool, but it doesn't make anything more secure. All of these issues are addressed in just about every networking book out there.
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..
Isn't that the point of firewalls ... you trust everything inside and distrust everything outside.
Errr.. no. Every competent network administrator distrusts the inside as much as the outside (except for the DMZ).
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.
If I make a function call that's because I want it to be synchronous (well, or because I'm too lazy or the language I'm using makes it far too hard to do asynchronous properly). I expect it to take however long it takes. Some of that time will be function call overhead. Some will be disk overhead. Some will be processing overhead. Some will be network overhead. All of those things are always there. I think you're making too much of an issue out of the increased function call overhead when there are plenty of other reasons a function might take many milliseconds to respond.
If I move my program from a flash device to an old MFM drive the drive latency would increase substantially but I don't think that would be reason for calling all synchronous disk I/O broken, evil, and misleading.
http://rfc.dk/3093
- Professional XML Web Services
expands on this topic quite a bit. Both are available at www.markrichman.comI asked pretty much the same thing of Microsoft when they first announced .NET (which is closely tied to SOAP) For anyone who's curious, I asked a couple people, so I don't really remember WHO I talked to, but I do know that Scott Gu was one of the people.
Their response?
Developers are tired of being hampered by netadmins, trying to open up unsecure ports just so that DCOM will work. Basically, SOAP is a way to do it where you don't have to open up esoteric and undocumented ports and protocols...
As far as security goes... it's up to the implementors. SOAP does have one advantage over some other forms of RPC, in that it has a few built in forms of authentication and is explicit as opposed to implicit. That means you can't just randomly activate bits of code just because you can log onto a server.
Another advantage of SOAP is that a decent XML coder can write his own parser for the protocol, so you don't have to use the vendor's, and you can customize your parser to only pass safe requests.
Of course, some of the MS people indicated that they felt I should use the MS parser at this point. I haven't seen anything bad with it, but I wouldn't have any qualms about writing my own if the business needs dictated it...
I am disrespectful to dirt! Can you see that I am serious?!
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.
I wrote "Web RPCs Considered Harmful" that briefly addresses the security issue.
Summary (and using more recent terminology): Web services that expose more new and unique code are more likely to expose bugs. RPCs, SOAP, and CGIs all encourage developers to write more exposed code by making that style easier to do.
One better alternative is to be more data-driven (some would say "functional", as in "functional programming"), so that you only expose data (via a standard server which would typically be more mature, heavily reviewed code).
Alas, that's an entirely different way of thinking that most people are not used to, since it flies in the face of "normal procedural or OO programming" that happens on the desktop. Some examples, though, are Linda Systems (TupleSpaces), REST (the traditional WWW architecture), and even P2P to a large extent.
One problem with firewalls (especially packet filters) is that it's hard to know exactly what data is flowing through. You can really tunnel any protocol over any other - you just need to know how to encapsulate and decapsulate it. Distinguishing whether data is regular data or encapsulated data of another type is hard to do. So I suspect that security people are going to have a hard time, unless we can convince the developers that they *need* firewalls and to stop tunneling holes through.
Software sucks. Open Source sucks less.
Mindterm looks interesting, but the GNU httptunnel application (here is another link) mentioned in another post will do roughly the same thing, and you can easily use ssh over httptunnel to tunnel other protocols.
Better yet, unlike Mindbright's applet, httptunnel is free software (GPL). Mindbright's applet does sound like it has some nice bell's and whistles, though. Probably worth paying for if you were going to roll SSS over HTTP out as a solution to a larger group of users. (using ssh over httptunnel works great, but it can be a little confusing to set up the first time.) Otherwise, try httptunnel instead.
BlueCollarTech.com
** The opinions expressed here are my own, and do not reflect those of my employers - past, present, or future**
SOAP does not drill any holes that POST would not have.
And you are most likely going to find SOAP engines that perform a lot of error checking and parsing of an XML message behore handing it to you than your average cgi-bin script that gets the POST request.
We run into the same problems with our clients. We've got milestones to meet to make the suites happy, but the IT guys are totally unresponsive when it comes to opening up the firewall. Thus we aim for 80.
The problem with IIOP and DRPC is that they encode the communication enpoints as a hard IP address and port in the requests on the wire.
This makes these products virtually incompatable with network address translation (NAT) out of the box. Basically, the NAT boxes will translate a local, non-routable IP address into the IP address of the NAT box with a made-up port number. The problem is they don't modify the IP address and port numbers imbedded into the IIOP message.
There are products that will do this but you have a choice: 1) Teach your admins about another product and install the product both at your site and the client site or 2) teach them how to secure web services using the existing firewalls, load balancers, and SSL that they already understand -- no client site modifications required.
Securing web services properly (IMHO) requires that you have a layer 7 device that can look at the incoming SOAP requests and dump requests for an unknown endpoint on the floor immediately. The you have to make sure the request gets properly validated by the SOAP implementation and application layer.
So on the one hand you have IIOP and DRPC that require additional products or you have SOAP with requires you to apply the products that, if you have a significant web presence, you already have. Seems like an easy choice to me but you have to understand how all the pieces fit together. If you don't have that expertise in house, go rent it from somewhere.
You are not a beautiful or unique snowflake -- but you could be if you got off your ass.