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.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.