In a Lather About Security

February 27, 2002

Leigh Dodds

This week the XML-Deviant attempts to pick apart the strands of a lengthy XML-DEV debate on web services security.

SOAP Security

"...what's the current thinking about SOAP-RPC as a security risk in plausible scenarios where business services are exposed via SOAP?" Michael Champion asked last week, starting a lengthy XML-DEV discussion on the security implications of SOAP, RPC, and REST. Champion was prompted to ask the question by a recent newsletter from security expert Bruce Schneier, which responded to Bill Gates' new "Trustworthy Computing" strategy for Microsoft. In the article Schneier recommended that "implementation of Microsoft SOAP, a protocol running over HTTP precisely so it could bypass firewalls, should be withdrawn."

Schneier has previously singled out SOAP as a potential security issue in an earlier issue of the cryptogram newsletter, noting that because

no security is required in either HTTP, XML, or SOAP, it's a pretty simple bet that different people will bungle any embedded security in different ways, leading to different holes on different implementations. SOAP is going to open up a whole new avenue for security vulnerabilities.

Schneier's particular objection is the use of an HTTP server listening on port 80 to tunnel SOAP messages through the corporate firewall. These issues were also touched on in last week's "REST and the Real World" article by Paul Prescod, who's played a large role in the resulting XML-DEV debate, being the staunchest critic of the SOAP/RPC approach.

As always happens with these debates, views seemingly polarize into different camps, although the reality is usually less clear cut. Sifting out the key points from the large volume of messages helps to bring to light the real points of disagreement. For example, the early parts of the discussion seemed to pit SOAP versus REST and to ask "which is the most secure?". Of course this is comparing apples and oranges: REST is an architectural style, and SOAP is a concrete technology. Fairer questions to ask are

• How does the REST style benefit security?
• What are the security issues with RPC in general and SOAP specifically?
• What security issues are there with web services?

We'll use these questions as the basis for tackling the large volume of messages that have already been exchanged on this topic.

REST and Security

So how does the REST architectural style benefit security? Paul Prescod has addressed this question in several places including his XML.com article, a recent summary of SOAP security issues, and during this discussion in which he itemized seven ways that the REST style indirectly addresses security.

It's not worth summarizing Prescod's arguments further here, as the original sources make a far clearer case. Briefly, because the visibility of messages and their meanings are central principles in REST, this makes them easier to secure and audit. Prescod later argued that visibility involves clearly labeling messages by

• choosing a unique port;
• having a consistent, simple structure;
• having well-defined semantics; and
• having a transparent addressing model

While there were no obvious critics of the RESTful approach to security, Michael Brennan did suggest that HTTP-based security wasn't adequate for typical enterprise applications.

Maybe I'm just naive, but based on the sort of work I've done, I don't see how HTTP security alone is going to be anywhere near adequate for the typical enterprise application...I would be happy to learn more about how REST can help, here, but I am doubtful that it will be anywhere near a complete enough solution for many enterprise apps, much less an enterprise-wide or cross-enterprise integration strategy. The web is just an interface for these things, and security can not be web-centric; it just needs to integrate cleanly with web protocols.

So, while the REST architecture does seem to facilitate security, it's not a complete solution. And that's a point that Prescod was happy to admit.

REST is not a security panacea. There is no silver bullet. All we can do is evaluate each layer's contribution to security. SOAP's is negative. It detracts from the security of the protocols that it runs on top of.

RPC and Security

This bring us to our next question: what are the security issues with RPC and SOAP-RPC? A REST advocate would argue, simply, that because RPC isn't RESTful, because it doesn't conform to the deployed Internet architecture, it neither encourages nor enables security. This is not totally damning though. RPC can clearly be used to architect entirely safe systems, but ones that work within the corporate firewall rather than across the public Internet.

Prescod highlighted three weaknesses in SOAP, each of which can be linked to one of the above points about clearly labeled messages:

I think that spec itself has three security weaknesses (holes would be too strong of a word). One is that it is designed to tunnel through HTTP rather than using its own port as is standard on the Internet. Two is that it leaves more in the realm of the application developer than needs to be left. They must invent their own addressing model. They must invent their own methods. This raises the bar for the security knowledge they need. Three it is RPC which makes it difficult for sysadmins to filter and monitor because it is too general and opaque. I can't make that last point too strongly...

These three weaknesses neatly summarize the entire debate against SOAP and RPC and reraise the central theme of visibility. HTTP has been designed for visibility; or, more precisely, the evolution of its design up to HTTP/1.1 has enhanced visibility. It is possible to identify the basic meaning of individual HTTP messages. For example a POST changes state on the server, while a GET does not -- it is idempotent.

SOAP does not define any message semantics and is thus entirely generic. This means that a sysadmin is unable to identify the potential side-effects of particular messages simply by looking at a SOAP message. She would need detailed knowledge of the business logic. Indeed because all of the interesting bits of a SOAP message are in the body, Prescod noted that a firewall would need to be able to "apply XPaths to figure out what kind of document is flowing through the network."

Michael Champion provided a good summary of the different environments in which SOAP/RPC and REST are applicable.

I keep coming back to the same basic opinion: SOAP-RPC and the tools that support it are great for building distributed applications within an enterprise, behind a firewall, where people basically trust each other (and violations can be traced and punished), and where reliability and latency are either not a problem. In these situations, you can indeed "hide the network behind the tools." But when you can't hide the network because of lack of bandwidth, latency, trust, reliable connectivity and so on, or you don't want to hide the network for some other reason, REST looks like an awfully good design pattern.

Web Services and Security

Champion's comment about hiding the network "behind the tools" highlights the third theme in the security discussion. Specifically, the suggestion that the "wizard approach" to building web services, as exemplified by .NET, but promoted by other web service toolkits, will have serious effects on security as it will enable a developer to quickly expose functionality as services without reviewing the security implications or even being prompted to do so.

Mike Champion captured this viewpoint with a graphic analogy.

Mechanically, it seems almost certainly true that anything bad that could be done with SOAP could be done with the previous generation of web technologies. On the other hand, SOAP is getting so many power tools hooked up to it that CGI (etc.) never had, so bad things could happen more quickly and easily. You can cut off your arm with a handsaw if you really try, but it is SO much easier with a power saw whether or not you try.

While there was no disagreement that vendors should be going to greater lengths to highlight security issues, few felt that these were really issues attributable to web services as a new technology. Michael Brennan argued that while there will undoubtedly be some serious security breaches resulting from web services, these will be caused by naive developers rather than technology problems. Brennan believed that the issues that will cause security breaches in web services will be exactly the same as those that cause breaches today.

1. Naive developers writing apps that trust the information they get over the network.
2. Naive developers thinking that if they don't advertise their web service, the hackers won't find it.
3. Naive developers trusting that no one is listening in on the conversation.
4. Vendors focusing on features and time to market, but ignoring security concerns because that's not what will ultimately sell the product.
5. Vendors selling snake oil that purports to solve your security problems for you.
6. People thinking a firewall = security

	Also in XML-Deviant The More Things Change Agile XML Composition Apple Watch Life After Ajax?

There seemed to be a general desire to see more focus on security issues. Len Bullard suggested that the problems may be mitigated by adhering to the following steps:

1. Training before development of web services.
2. Inspection prior to deployment of web services.
3. Security testing suites.
4. Properly constructed contracts for web services that include security provisions and remediation clauses.

There have been a number of interesting features of this discussion. One has been a continued promotion of the REST architecture from a desire to help demonstrate its strengths. Another has been an attempt to identify why RPC, and SOAP in particular, detracts from these strengths to the point that they actively work against the deployed infrastructure. A third is partly a reaction to the web services hype -- "deploy your existing applications as web services in six easy steps" -- and partly due to the increasing recognition of the importance of security for web applications.

As far as concrete proposals go, the discussion has generated only one: that SOAP should not use HTTP and port 80. Paul Prescod suggested gathering a petition to get the SOAP specification amended to say that "Applications of SOAP MUST NOT use port 80 unless they adhere to all of the semantics of HTTP.*". This seems like it ought to be a non-controversial suggestion. Indeed any controversy would lend weight to the argument that SOAP is being tunneled over HTTP to directly circumvent firewall policies.

A more extreme proposal would be for SOAP to be rejected and an altogether more RESTful approach adopted. However even REST advocates aren't pushing this strongly, apparently content to wait out their predictions that the whole effort falls apart within a couple of years. But by then, if this article is any indication, the Internet may be a very different place, having been reinvented from the top down.