As for what SOAP is or isn't, I would suggest thinking of it as insecure procedural RPC hidden behind some OO terminology.
I'm not sure that we should blaim SOAP protocol itself. Obviously SOAP::Lite has a security bug but it doesn't make SOAP protocol insecure itself. It's all about writting properly SOAP servers and clients.
--
Ilya Martynov
(http://martynov.org/)
| [reply] |
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...
| [reply] |
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.
| [reply] |
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
(http://martynov.org/)
| [reply] |