SOAP Security Problems

LarryWest42 writes: "This article lists a number of sobering security problems with SOAP (not only the avoidable one of tunneling through HTTP). I found it thanks to Bruce Schneier's latest Crypto-Gram newsletter."

Comments

Re:REST

[Bazzargh]

REST is a great ideal, but still has limited applicability on the web. If you've read Roy Fielding's original REST thesis ( http://www.ics.uci.edu/~fielding/pubs/dissertation /top.htm ) you'll see that one thing which is ruled out by REST as misfeatures of HTTP is cookies (of any kind). Quote: 'The same functionality should have been accomplished via anonymous authentication and true client-side state'. (BTW in a different section he effectively rules out url-rewriting schemes too).

Ok. So _right_now_, how would you support a session? you can have javascript in a frameset and conduct the session in a child frame, or use some client-side technology (applet, flash, activex) to achieve the goal...since none of the browsers actually support this philosophy! So if you go down this line you'd be at the mercy of the balkanization of the browsers. Roy's architecture is bang on the money but unsupportable at present.

Another thing to note is the security side of things. The REST philosophy is based partly on the notion that HTTP scales because intermediate caches (and firewalls) can understand the semantics of messages. But to a large extent, intermediate caching is the antithesis of security. (Dont get me wrong: understandable semantics is fine, and is the argument Paul Prescod is making; And the REST URL-based architecture is far better than having your firewall figure out that SOAPAction might be important too).

It is definitely a Good Thing to strive for REST - your site will scale better - but REST really describes a web that we had (before cookies) and will not have again for a browser generation or so.

-Baz

Re:SOAPAction header, FUD or not ...

[angel'o'sphere]

Well,

I forgot what FUD measn(only remember its something EVIL).

The article says something true: SOAP has no build in features for security.

But it is designed to be exactly like that!

My problem with the article at: http://www.prescod.net/rest/security.html is: it has simply to many false statements.

e.g. SOAP subverts HTTP's addressing model by hiding all of the data objects behind a component end-point interface.

This statement is simply silly: its up to you how many end-points you define. If you make one per method or one per component or any mixture is your descission.

A endpoint is basicly only a URI and the SOAP server has to cope with it and knows how the end-point is configured.

The SOAP server, long before the application, descides if a SAOP request can be routed to a specific end-point. What do you think why a end-point publishes its interface?

As a trivial example, GET /getHistoricalStockQuotes?MSFT says to a security person: "okay, it's a GET. Barring tunnelling or a bug, it can't
modify the server. Probably returning some kind of report for historical stock quotes. If there is tunnelling or a bug it isn't my fault. We'll fire
the programmer."

When he sees getHistoricalStockQuotes("MSFT") he says: "Hmmm. Probably returns stock quote. But can I be sure it doesn't modify
anything on the server? Maybe it's creating a new object that can be queried about different quote dates. If so, who is allowed to create
these objects? When are the destroyed? Can a malicious hacker leak them until the server runs out of memory? I better go read the
documentation for this thing because what it does isn't obvious at first glance. Maybe i better go find the programmer to make sure I
understand it."

Of course the two are equally simple: they both return a report. But one is very explicit about a promise not to modify server state. The other
is not.

This above is from the article.
Well, I only understand it so far that this is bullshit :-)
What does the author like to say with that?

A HTTP GET request may modify the server?
Ah ha.

So a RPC or DCOM or CORBA request does *NOT* modify the server, or does guarantee it does not so?

Also: HOW, the heck should a SOAP service be able to create an other active object on the server and expose it via an external referable URI?

This is the sillist claim I've ever seen.

Consider this: how is a web server able to expose a new URI/URL to the external world for refferencing?

Get an idea? For SOAP the same restrictions apply.

Ah .... back to the top of that article:

SOAP uses a standard HTTP
POST method when it should use an extension method.

Wrong. SOAP can use the standard HTTP POST method and its up to the SOAP server if it accepts it or not.
The standard encaurages that applications using SOAP use the HTTP extension framework (M-POST).

After rereading that artice several times now, I'm getting tiered about the shallow level of EVERYTHING mentioned in it. As he mentiones Microsoft I asume he is mainly unhappy with their implementation or integration into Visual Basic.

Probably he should have a look on soap4j and the Appache/Tomcat SOAP extensions.

I realy would like to know WHAT the security isues with SOAP are.

Of course: the idea to tunnel SOAP through a firewall subverts the intention of a fierwall.

But the security problems are elsewhere.

A firewall easyly can say: oops thats not a request to a web page, I block it.

As the issue "security and SOAP" is very important IMHO, I realy would appreciate to get background infos and how to solve the issues WITH SOAP, not how to invent just another internet protocoll.

Regards,
angel'o'sphere

One good point

[f00zbll]

The one solid point in the whole article is "lack of clarity in SOAP literature." I've been following SOAP and honestly haven't seen a consistent clear set of guidelines and practices. I've read through a lot of microsoft literature about SOAP and most of it is vague. I'd have to agree the SOAP drivers in the early 99-00 days were buggy and poor, but now they are good. Atleast the drivers from apache group.

As others have mentioned, the argument doesn't go deep enough, but that doesn't discredit the whole essay. The point about SOAP doesn scale is probably true of all RPC. Doing truly distributed computing isn't easy because the network is not reliable. Anyone thinks there won't be network latencies or that latencies won't be significant is in for a surprise. Put SOAP in the hands of an experienced programmer and you'll see the true power, but the power isn't in the protocol. It's in the developer implementing the solution. A tool is a tool.

For SOAP to gain acceptance, there needs to be clearer guidelines about dos/don't and other important development issues. Without it, it's just an invitation for a VB programmer to open up a server to hackers. Hackers will try, so it's the responsibility of IBM and Microsoft to set the standard. That's where SOAP has really failed in my min