in reply to Re: Re (tilly) 1: SOAP::Lite dispatch routine
in thread SOAP::Lite dispatch routine

SOAP has no security model.

According to Microsoft, ones of its primary purposes is to enable people to bypass existing security checks.

Now you say that there is no security problem here, we just need to get the servers and clients right. I say that anyone who thinks there is a snowball's chance in Hell of this really happening doesn't understand the realities of software development. If security is something people have to get right again and again, then mistakes will happen. Repeatedly. And people will turn out to (quite predictably) wind up making similar mistakes, making life quite convenient for crackers.

Yes. There is a specific gaping security hole in SOAP::Lite. That mistake is directly in the module, not the protocol. But that mistake should be regarded as a symptom of something that will happen.

Dominus draws a nice analogy to unsafe programming practices being like smoking in bed. Everything is fine as long as you don't fall asleep and drop the cigarette. And that is the problem with SOAP. Its complete regard for security is an unsafe programming practice. Everything will be fine as long as you make no mistakes. This is true, but it is still a piece of stupidity.

And continuing the analogy, using SOAP to tunnel to the Internet through a firewall for applications is like sprinkling gasoline on your bed before smoking. Again, everything will be fine if you do nothing wrong. Isn't that comforting?

I would like to avoid having software developed by developers who fail to understand this being used inside my network, thankyouverymuch...

  • Comment on Re (tilly) 3: SOAP::Lite dispatch routine

Replies are listed 'Best First'.
Re: Re (tilly) 3: SOAP::Lite dispatch routine
by ferrency (Deacon) on Jan 05, 2002 at 00:22 UTC
    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).


    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.

      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?

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

Re: Re (tilly) 3: SOAP::Lite dispatch routine
by IlyaM (Parson) on Jan 04, 2002 at 01:52 UTC
    I just don't understand why SOAP is treated so specially. SOAP have not added anything really new. You can roll your own RPC implementations using HTTP and CGIs, SMTP and scripts in /etc/aliases, etc. SOAP can be more convinient in some cases because it is standart and is supported in many languages. And developer who doesn't understand security implications of networking applications can open security holes both in CGI and in SOAP server.

    I tend to agree that with SOAP::Lite it is too easy to make mistakes. But it is just fault of SOAP::Lite but not fault of SOAP protocol itself. Adding requirement to specify list of methods which can be remotly called could solve this problem.

    Ilya Martynov (

      Extending my analogy above, SOAP is like buying manufactured cigarettes. No, you don't need to use them to cause damage, but easy availability increases the problem.

      All of the other RPC mechanisms you discuss suffer from the same problems that I gave for SOAP. And in all of those cases the use of those on servers regularly leads to problems. They don't generally lead to horrible client issues though since the clients at least tend to be relatively solidly designed. (Compare IE with, say, Microsoft Word for security. There is no comparison. IE, for all of its mistakes, had to take it into account from day 1. Microsoft Word, as the routine macro viruses can attest, was not.) There is certainly nothing magic about SOAP that makes it better or worse than them.

      But I single out SOAP because it is the protocol of choice for would-be buzzword-compliant people (a group who I have distrust and distaste for at best) who want to enable a wide variety of random clients to use a programatic interface to use over the Internet. It is particularly popular among people who want to do the kinds of things that firewall administrators (rightly) are inclined to audit and possibly block. It is even being marketed that way.

      Therefore I believe that the density of scarily moronic things being done with SOAP is much higher than with the other RPC mechanisms that you mention. If people were being encouraged to open sloppily written Excel spreadsheets over the Internet with another RPC mechanism, I would be just as unhappy with it. But it isn't another RPC mechanism, it is SOAP which has that dubious honor, so it is SOAP I am speaking up about.