Not Everything You Always Wanted to Know About Web Services Security

Woody Allen, that famous web services guru and comedian on the side, once described James Joyce as “the most incomprehensible and hence the finest poet of his time.”

Sometimes, it seems as if XML is like the James Joyce figure of computing. With something of the order of 20 new protocols lined up to make the whole web services thing succeed, it's hard enough just to figure out how the stuff, works let alone find the security holes. Even more interesting, in a recent Aberdeen study our company co-funded, CIOs from a dozen Fortune 500 companies didn't know what XML transformation was (do you?) and few, if any, had any XML security initiatives under way. And this is what we're going to use as the foundation for capitalism for the next 100 years?

To try to get a handle on the broader security issues I called up Woody Allen. However, he wasn't available to take my call so I settled for Eugene Kuznetsov, founder and president of DataPower, an early leader in XML-aware networking. Eugene has been thinking about these issues longer than Woody Allen - and most other web services gurus for that matter. Here's his take on XML security.

Throop Wilder: Do XML and web services introduce new security challenges at all? Why can't we just use SSL, firewalls and VPNs for secure business connectivity?

Eugene Kuznetsov: Well, if XML were simply a new application that needed to transmit over a secure connection, then SSL and VPNs would work just fine. The problem is that XML web services are fundamentally about enabling new connectivity via a new set of rich protocols. So you can't just look at web services as simply another application framework or even application development paradigm. Web services are about structured network interactions between previously unintegrated systems. By the way, as for firewalls, you can forget about it - XML tags today mostly ride over web protocols which go right through Port 80, the open web port in just about every firewall. Where there is new connectivity, there is always a new set of security challenges.

TW: Ok, but what's different about these new protocols from HTTP, say?

EK: Well, like I said, many of them do ride on top of HTTP - but almost everything else is different. First and foremost, we're not talking about a user, or more precisely, a person as the agent interacting with a server somewhere. Web services is about machines talking to machines, business processes in one company talking to business processes in another. During an authentication transaction, for example, you can't just pop up a certificate window and ask a user to type in some information. These are unattended machines that have to establish trust relationships with each other and across companies.

TW: Kind of like RPC [remote procedure call]?

EK: Exactly! Unattended RPC, except that it can also be asynchronous. An application on one machine can invoke an application on another as long as it is trusted. Not only that - one business's application will actively change data in another's business system. Now, imagine five business partners doing business through a private exchange of some kind. You've dramatically multiplied the trust relationships as well as the complexity of the interactions.

TW: What do you mean - complexity of the interactions?

EK: Just-in-time manufacturing of a particular part may require coordination of materials ordering, financing, assembly, credit verification and shipping. In a web services model, this process is completely automated but requires multiple simultaneous interactions between the business systems of each participant in the transaction.

TW: So what is the security issue here?

EK: There are several main areas we worry about. Take privacy and keeping people from snooping your data - today, when you pay for something over the web, you generally use SSL and that is fine if it is just you and the merchant. In an XML model, it's really not about credit cards but about high-value information. For example, you may have a document that needs to be shared by three partners but you don't want each to see the other's private account and pricing information. SSL doesn't help you here. What you need is a way to selectively encrypt parts of a document depending on who is reading it. So security needs move from the transport layer to the XML transaction layer.

TW: What about the complex web of trust relationships? PKI rollouts haven't really been done successfully across multiple partners. How will the authentication issues get solved?

EK: Today, you see some very pragmatic systems being rolled out, just storing a small set of certificates at different partners' sites without a lot of additional infrastructure. In the long run, there are some XML web services standards that will make both PKI and access control much easier and drive far wider adoption than previously possible - XKMS and XKISS create new XML-based protocols for certificate status checks and other traditional PKI functions. Interoperability is the goal, and that's just what SAML, XACML try to do for interconnecting authorization systems.

TW: I wonder what Woody Allen would make of XKISS. You said it isn't about credit cards, but high-value information. What do you mean?

EK: Once web services becomes widespread what you are really talking about is companies' backend systems being exposed to the Net and to other companies' backend systems. Credit card theft pales in comparison to the exposures that come with a widely deployed web services system.

TW: How so?

EK: It's an issue of what is at stake. Today, with web sites you usually hear a lot of concern about stolen credit card numbers. While that does cause damage, the financial risk is greatly limited by fraud-prevention software, quick cancellation and credit line caps. So while unpleasant and expensive, it's not the end of the world if they get stolen. [Credit card numbers are not insured, but the liability is limited by fraud protection and credit line limits.] But now, if someone hijacks a thousand 401K portfolios or steals proprietary business data, those aren't insured and so the stakes are much higher.

TW: In this new world of web services how does a thief exploit XML holes to wreak this kind of havoc? Is it already happening?

EK: Well, first of all, this world is not widely deployed yet and so we have time to prepare for many of the holes. Today's attacks are not yet at the production level but mostly theoretical. On the authentication side you still have a lot of wrangling over things like the non-repudiation of what looks like a valid certificate: how do you know every time you interact with a previously trusted partner that you can still trust them?

TW: What other types of attacks are you seeing?

EK: On the protocol interaction side you have some fairly big issues. For example, XML is a structured way of formatting data - as long as the data adheres to XML formatting conventions, anyone can send an application some valid XML that it will at least look at. Now, it may not be valid against your application's schema and so normally would be rejected. However, before being rejected, the application has still opened a socket to receive the XML data. If the app is only expecting 1Kb of data but a hacker sends 100Mb of XML, this can effectively create a denial-of-service (XDoS) attack on the application and bring the particular business application to a halt. Remember, these are the crown jewels of the company that are being affected - the very business processes that provide the lifeblood of the enterprise.

TW: But aren't web service developers building in protection against this?

EK: They try to, but there's a significant problem when they start trying to build in the validation mechanisms: everything slows down to unacceptable response levels. And then, as users everywhere do, they turn off the validation mechanisms.

TW: So what are you telling your customers to do?

EK: First, since some of the security infrastructure simply doesn't exist yet, we tell customers to use SSL since most are in prototype mode and have few multi-partner connection issues. Second, they really should be implementing some kind of XML-level security, even if it has performance drawbacks. This is not entirely satisfactory, though. Recently, there was a large study that 44 per cent of all web services projects are currently stalled because of security issues exactly like this. So we actually put together a list of best practices for secure XML web services for our customers.

TW: Are there other measures they can take?

EK: An important step is to create a layer between the outside applications and their own application servers. The best way to do that is through an XML proxy mechanism. This is a well-known security response. For example, an XML-aware product that front-ends servers running web service applications can do much of the data validation and prevent the types of attacks I mentioned before.

TW: Are there any bright spots from a security angle?

EK: While web services presents a set of difficult and complex issues, the way they are being solved by the industry will open up a much richer set of interactions that reduces the cost of doing business. The structured format of XML offers a real opportunity for application-aware custom filtering and business-level filtering. This is as opposed to filtering today on coarse criteria such as an IP address. Imagine being able to filter access based on who the trading partner is or filtering based on a particular transaction amount. So while there are serious risks in the short-term, in the long-term you will have a more uniform set of application protocols and a much easier time implementing filters and controls at the application level. The big risks are in the next couple of years. After that I expect XML web services to actually improve security overall.

Throop Wilder is co-founder and vice president of marketing for Crossbeam Systems, Inc. (

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.