|Pathologically Eclectic Rubbish Lister|
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.