Slashdot Mirror

← Back to Stories (view on slashdot.org)

SOAP Security Problems

Posted by timothy on from the seeking-a-safer-detergent dept.

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."

26 comments

  1. This is just FUD by Anonymous Coward · · Score: 1, Funny

    Geeks are afraid of bathing, and thus want soap, shampoo, and other normal cleaning implements to look bad. This is just a pathetic attempt to justify their unconscionable stench. Just take a bath already!

  2. SOAP Security by MrBlack · · Score: 2

    There was an article on SOAP security in the MSDN recently where they advocated turning off the HTTP-Get and HTTP-Post protocols for production web services and rely on SOAP instead. It hardly seems like enough. Now every developer is going to have to be responsible for ensuring their web-services can only accpet valid parameters, and can only be accessed by those who should be able to access them. I can see that security for web-services as being a key issue for developers in the near future. I know my local MSDN users group is getting a discussion from a technical evangelist from M$ on this topic very soon.

  3. REST? by gizmo_mathboy · · Score: 1

    For those of you like me that have no clue what REST is (REpresentatational State Transer) here's a decent wiki page I found on it.

  4. REST by Fweeky · · Score: 3, Interesting

    Everyone who even pretends to be able to knock up websites, hack PHP and CGI scripts etc should be familar with REST; it's one of the core concepts behind the web.

    The REST Wiki is a good place to start.

    1. Re:REST by Anonymous Coward · · Score: 0

      I find it interesting that the REST stuff seems
      to echo precisely what Pike et al. have been
      saying, and doing, for years with Plan 9's 9P (and Inferno's Styx). Maybe people are finally getting it?

    2. Re:REST by Bazzargh · · Score: 3, Insightful

      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

  5. performance by pHaze · · Score: 2, Interesting

    Besides security, we quit using Soap for our web services and use our own custom libs which we provide to clients because the performance is horrendous. When you're providing a web service API to thousands of clients, that becoms an issue quite quickly. Sure XML is platform neutral/agnostic, but is the parsing performance hit you take really worth it?

    ~mark

    1. Re:performance by 21mhz · · Score: 1

      Why reinvent communication libs when we have CORBA?

      --
      My exception safety is -fno-exceptions.
  6. Of course this is a security problem.... by shr3k · · Score: 2, Funny

    Someone asks you to pick up the bar of soap off of the shower floor. You bend over to pick it up... BAM!... your security is breached.

    This has been a known issue amongst the prison vendors for years... None of them have done anything about it yet, though.

  7. SOAP Shenanigans by Prowl · · Score: 1

    While I appreciate SOAP is a great technology, and its impact will be huge, It did always puzzle me why everyone kept insisting on cramming it all through port 80. The justification that it would go through existing firewalls never really washed (sorry...) with me. Is there really such a problem with assigning a new protocol? I mean, if a company are going to expose web services, then a firewall config change isn't really going to cause too much hassle in the grand scheme of things. my $0.02

    --
    That man tried to kill mah Daddy
  8. Objectivity / Bias by LarryRiedel · · Score: 2, Interesting

    It seems the author is trying to proffer REST, a putatively alternative approach to the use of the existing web infrastructure as little more than a transport for messages to be interpreted by the endpoints, like SOAP does, and I think that is the motivation for the FUD article mentioned in this slashdot story. To me that article does not seem to say much besides that 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".

  9. The article is hardly FUD by jslag · · Score: 2

    It seems the author is trying to proffer REST [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.

    . . .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, 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.

    1. Re:The article is hardly FUD by LarryRiedel · · Score: 1

      > > It seems the author is trying to proffer REST
      > > [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

    2. Re:The article is hardly FUD by tradervik · · 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.

    3. Re:The article is hardly FUD by LarryRiedel · · 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.

    4. Re:The article is hardly FUD by NearlyHeadless · · Score: 2
      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.

      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.

  10. SOAPAction header by Shimmer · · 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

    -- Brian

    --
    The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
    1. Re:SOAPAction header by Wonko42 · · Score: 2

      Except that SOAPAction seems to have been deprecated. At least, according to the article. Which I'm sure you read from start to finish.

    2. Re:SOAPAction header by Shimmer · · Score: 2, Interesting

      Except that SOAPAction hasn't actually been deprecated. At least according to the spec. Which I'm sure you read from start to finish.

      -- Brian

      --
      The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
    3. Re:SOAPAction header by Wonko42 · · Score: 3, Funny

      Except that I was referring only to the article and not to the spec, which I clearly stated in my comment. Which I'm sure you read from start to finish.

  11. SOAP by Anonymous Coward · · Score: 0

    I think SOAP will be useful, and hope that open source developer will support it. Inhouse database application developers like me will find COBRA too hard. :) So using VB + COM is a very trival solution for 3 tier stuff. If open source tools support SOAP, there is finally a choice other than MS.
    Actually, I think it will be more useful in internal network other than internet. Other than the security problem, I can't see a hugh demand on sharing information in such a way. Commerical entity tends to provide the presentation together with the data. :) It maybe used in a few applications, but won't be a great impact on internet. However, it does provide a high level aspect for dummy programmer like us. :)

  12. Re:SOAPAction header, FUD or not ... by angel'o'sphere · · Score: 3, Insightful

    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

    --
    Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  13. Weak article by camusatan · · Score: 2, Informative
    I'm no SOAP apologist, nor am I any kind of neo-luddite anti-XML bigot, but this article is weak, at best.

    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.

  14. Just dont use it by rufusdufus · · Score: 2

    Why anyone would use SOAP is beyond me. Its a very complicated middle layer of proprietary logic and gobbly-gook code just to turn a message into a function.

    I advise not useing it; complications in implementation, bugs, performance, debugging, and security just make it a bad choice.

  15. One good point by f00zbll · · Score: 2, Insightful
    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