Re: Re (tilly) 3: SOAP::Lite dispatch routine

[ferrency]

I agree that the security problem is not with the protocol, but with the implementation. Yes, I hate Microsoft as much as the best of them, but I don't think SOAP is necessarily inherently evil as some would like to believe.

There are several separate security issues in play here.

One is authentication. The SOAP protocol doesn't define any authentication requirements. But that's okay, because it's transport-layer independant, so the transport layer can provide authentication (SSL/TLS, firewalls, etc). And, it's an RPC protocol, so the routines you're actually calling using the SOAP protocol can also implement their own authentication (shared secrets, more public key encryption or signing, etc). Like HTTP, the main purpose of SOAP is to provide unauthenticated access to public services. Luckily, the protocol itself doesn't prevent you from performing authentication checks if you want to.

A completely separate security issue is what you can do once you have access to the server. This is the issue raised in the Phrack article. Server security is completely server-implementation dependant. I would not use a SOAP server which didn't provide a way to strictly limit the method calls available to the connecting client. Client implementation doesn't matter at all, because as a SOAP-based service provider you have no control over the client software which connects to you.

Saying that the SOAP protocol is broken because SoapLite allows connected clients to do things they shouldn't is like saying that the CGI-BIN/HTTP protocol is broken because the Matt's Script Archive scripts allow clients to do things they shouldn't. HTTP and CGI-BIN don't force any more security over the protocol than SOAP does. It's just that the security holes in HTTP servers were (mostly) found and fixed a long time ago (except for in the M$ servers/clients, of course).

Alan

Update: Back in perspective for the thread... Yes, I agree with tilly that anyone who's considering SoapLite (or any other implementation, for that matter) should be familiar with the issues in the Phrack article. However, I don't think those issues are large enough to dismiss SOAP out of hand as an unsuitable protocol for any purpose.

Another update: I see your point, Tilly. But I still don't think SOAP is inherently evil; just that stupid people do stupid things no matter what you try to do to stop them. The bugs in all unwritten code are unknowable at this time. The scenario you describe could just as easily happen in HTTP as SOAP. It's not the protocol's fault.

[tilly]

Two things.

First of all on the server side you are talking about what could theoretically happen. I prefer talking about what I think really will happen. SOAP servers are going to get it wrong early and often.

On the client side, you completely miss my point. I don't mind the client side because I think bad clients are going to harm servers (except through things like DDoS). I mind the client side because I think that poorly coded clients will lead to a stream of client-side compromises. Allow those clients on your network, and bad guys with access to a server will manage to compromise clients, and once they have control of clients will be able to do damage inside of your network.

As you say, the browser bugs are mostly known and fixed. The existence of, say, a hole where IE will allow arbitrary code to be executed locally is rare enough that when it happened it was newsworthy. But by contrast the upcoming Word, Excel, etc bugs are not known. Let alone all of the upcoming bugs for random applications (both Windows and not) which other people are dreaming up that talk SOAP. With that diversity of clients expecting to talk over the internet from behind firewalls you can expect network compromises of the local machine to come fast and furiously until it is no more newsworthy than the latest macro virus.

Perhaps this doesn't bother you. It should. To see why, let me outline one simple scenario.

Suppose Microsoft achieves its goal. Suppose that they have some common application (eg Word or Excel) routinely connect to a passport service. Suppose further that a smart black hat discovers one remotely exploitable security hole in that client and one in the passport servers. The black hat then produces one piece of spyware, compromises passport to make it compromise every connecting client, and compromises the client to install its spyware, which can then call home through SOAP.

What kind of damage could they then do? (Stealing valuable information, industrial espionage, etc.)

Is this really how vulnerable we want our networks to be?

UPDATE
It is rather ironic that I would say good things about IE's security on today of all days...