SOAP Security Problems 26
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."
This is just FUD (Score:1, Funny)
SOAP Security (Score:2)
REST? (Score:1)
REST (Score:3, Interesting)
The REST Wiki [conveyor.com] is a good place to start.
Re:REST (Score:3, Insightful)
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
performance (Score:2, Interesting)
~mark
Re:performance (Score:1)
Of course this is a security problem.... (Score:2, Funny)
This has been a known issue amongst the prison vendors for years... None of them have done anything about it yet, though.
SOAP Shenanigans (Score:1)
Objectivity / Bias (Score:2, Interesting)
The article is hardly FUD (Score:2)
What's putative about it? REST says, for example, that every method has its own URI, while SOAP bundles a service's methods together under one URI.
. .
The article's complaint is that, not only is existing web architecture incompatible with SOAP, but there don't seem to be guidelines for developing secure SOAP apps - developers are left to their own devices. The amount of trouble people have with existing, well-understood approaches to networked services (such as those that fall under REST) suggests that expecting application developers to come up with good solutions on their own is risky.
Re:The article is hardly FUD (Score:1)
> > [xml.com], a putatively alternative approach
>
> What's putative about it? REST says, for example,
> that every method has its own URI, while SOAP
> bundles a service's methods together under one URI.
I say it is "putative" because I do not take
it for granted that it is an approach which
provides an acceptable alternative to SOAP for
all the use cases where SOAP would be an
acceptable solution, although it may be.
> > the existing web architecture cannot be
> > used to satisfy the additional security
> > demands created by application level web
> > services interaction protocols like SOAP. I
> > do not see that as a "SOAP security problem"
>
> The article's complaint is that, not only is
> existing web architecture incompatible with SOAP
SOAP works on top of the existing web architecture as
a transport. It may not use transport security to derive
application security, but I do not think it claims to
derive application security from the transport, or provide
it by itself. I do not think it precludes transport
security (S/MIME, HTTPS,...), although it may curtail
the ability of the transport providers to enforce application
security, but I do not think they should need to.
> but there don't seem to be guidelines for
> developing secure SOAP apps - developers are
> left to their own devices. The amount of trouble
> people have with existing, well-understood
> approaches to networked services (such as
> those that fall under REST) suggests that
> expecting application developers to come up
> with good solutions on their own is risky.
SOAP provides part of a solution for developing
and deploying web services. I do not think
SOAP has ever been intended by itself to provide
the requisite security for a web service.
Clearly SOAP itself does not provide application
level security, but I personally do not see that
as a "SOAP security problem". I think the security
topic is a red herring, and that is why I think
the article is FUD
Re:The article is hardly FUD (Score:1)
level security, but I personally do not see that
as a "SOAP security problem".
Why is the lack of security in SOAP not a SOAP security problem? Are you saying that security is outside SOAP's scope? That doesn't sound right to me. Surely security should be one of the prime concerns of any protocol.
Re:The article is hardly FUD (Score:1)
> > Clearly SOAP itself does not provide application
> > level security, but I personally do not see that
> > as a "SOAP security problem".
>
> Why is the lack of security in SOAP not a SOAP
> security problem? Are you saying that security is
> outside SOAP's scope? That doesn't sound right to
> me. Surely security should be one of the prime
> concerns of any protocol.
I dont think there is a particular lack of security in SOAP,
or that security is outside the scope of SOAP, so much as
that SOAP is supposed to integrate well with separate security
mechanisms like XML Signature, XML Encryption, S/MIME,
HTTPS, etc., to let them provide the application and transport
security. So, maybe it could be said that SOAP "supports",
but does not "provide", security.
Re:The article is hardly FUD (Score:2)
No, it's been a major problem on the Internet that each protocol has had to develop its own security. Notice that editors such as vi and Emacs do not have their own security defined, they depend on the operating system to enforce security.
Similarly, the CGI specification also doesn't have anything about security. It does have provisions for passing along the authentication method and identity to the CGI program, but there's nothing in it about authorization or specifying how the authentication is to be done.
Notice that this has never been considered to be a problem. Using SOAP over HTTP has no more or less security problems than writing a CGI script. Yes, if you screw up, there are problems, same with CGI. Yes, you can modify databases. Same with CGI.
SOAPAction header (Score:1)
It's true that SOAP-over-HTTP is intended to pass through most current corporate firewall configurations. However, the creators of SOAP deliberately included a SOAPAction header so that firewall admins will still be able to filter out undesirable SOAP requests.
See http://www.w3.org/TR/soap12-part2/#soapaction [w3.org]
-- Brian
Re:SOAPAction header (Score:2)
Re:SOAPAction header, FUD or not ... (Score:3, Insightful)
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
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
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
Re:SOAPAction header (Score:2, Interesting)
-- Brian
Re:SOAPAction header (Score:3, Funny)
Weak article (Score:2, Informative)
The article states (I'm paraphrasing)-
SOAP is complex - yes it is. It is also powerful. Oftentimes, that's how things work out. Sometimes, when you're really lucky, simple will be powerful.
SOAP can go through firewalls - yes, it can also not. So what?
MS visual studio makes it too easy to make SOAP-speaking services. - first - there's nothing wrong with that. Second, that has nothing to do with SOAP, the protocol.
SOAP encourages developers to design their own protocols to transport SOAP data around - this is a terrible straw-man argument. I don't see where this is coming from.
The web has a unified namespace, SOAP does not - this is true. Probably the least invalid of the author's claims. But the 'X does something new, and does so in a new fashion, therefore X is less secure' taken to extreme would imply no new protocols would ever be created. I'm not saying that the author is saying nothing new should ever be created, but I am noting that his argument, to the extreme, would completely retard progress.
SOAP security literature is misleading, security rests with the developer - any specification for how to interchange data, and make actual changes to state, places an implicit burden of security on the developer of services of said protocol. SOAP is no exception. Neither is HTTP, or XML-RPC, or sending Comma-seperated values via FTP or carrier pigeon. The problem is not specific to SOAP.
SOAP is new and untested - another valid point. It is. It may become something very powerful and useful, in the future.
All that being said - I think that SOAP is overkill, does not address real legitimate needs at this time, and isn't going to become the panacea that many predict. But this article doesn't effectively attack SOAP's weaknesses, by focusing on the security problems 'inherent' in SOAP. Those security problems are the same for anything developed on top of, or as an extension to, HTTP. SOAP's weaknesses are its complexity, and that a subset of SOAP (say, a third of it) can solve 99% of the problems that SOAP purports to solve. I just had problems with some poorly-executed attacks on SOAP as a protocol. End Rant.
Just dont use it (Score:2)
I advise not useing it; complications in implementation, bugs, performance, debugging, and security just make it a bad choice.
One good point (Score:2, Insightful)
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