XML and Web Services: Are We Secure Yet? -- Microsoft Certified Professional Magazine Online

XML and Web Services: Are We Secure Yet?

From confidentiality, integrity, and availability to authentication, authorization, and audit, find out how you can employ best practices to make Web services secure.

By Mark O'Neill
07/20/2004

Eighteen months ago "Web services security" was still seen as an oxymoron. One of the principal reasons was that "Web services" was still largely understood as meaning "services on the Web." A CFO overhearing a suggestion that the corporate accounting system be exposed as a Web service may have hit the roof, imagining teenagers accessing accounting data from their bedroom PCs. A CSO overhearing the same suggestion may have experienced a pain in the pit of her stomach and asked her firewall administrator to investigate. The firewall administrator would have quickly realized that Web services almost always involve XML traffic masquerading as Web-browsing traffic, and imagined this to be part of a grand plot to bypass his carefully controlled perimeter security policies. Back then, secure Web services seemed a long way off.

But then a funny thing happened—Web services started to be rolled out anyway. How can this be? There are two reasons. The first reason is that many Web services are deployed internally, without a publicly facing attack surface. The second reason is that when engineers and architects looked closely at the Web services they were developing, they realized that they could take practical measures to make them secure. Best practices have started to emerge. Vendors such as my employer, Vordel, have been implementing them in their products and solutions. Let's examine these best practices.

We start by taking a step back and looking at what being "secure" means (see Figure 1). What does it mean to say that an individual XML message is "secure"? If the XML message comes from a trusted source, does that mean that it is "secure"? But what about Web services that are designed to be publicly available, with no authentication at all; is security relevant for such Web services? The answer to these questions involves the application of well-established security concepts to Web services. We will look at how three established security concepts—CIA security, AAA security, and message-level content analysis—and apply all three concepts apply to Web services.

The Tenets of CIA Security
CIA security stands for confidentiality, integrity, and availability. The first two of the three CIA requirements—confidentiality and integrity—are most often achieved using cryptography. XML Encryption and XML Signature are mature standards that provide, respectively, confidentiality and integrity for XML documents.

The WS-Security standard, ratified by OASIS in April 2004, describes how these two XML security standards apply to SOAP messages, so that part of a SOAP message can be encrypted, or digitally signed, which allows end-to-end confidentiality and integrity across SOAP intermediaries. End-to-end security is especially important in privacy-sensitive applications, such as in the health care field. It is becoming best-practice to encrypt those parts of an XML document that contain personal information, while allowing the rest of the SOAP message to be available to routing and business logic. WS-Security, XML Encryption, and XML Signature are implemented by the WebSphere SDK, which is described by IBM as "an on-ramp to Web services for Java programmers."

WS-Policy is a specification that allows a Web service to indicate to a client which parts of a message must be signed and which parts must be encrypted, as well as which keys to use for encryption and signing. BEA WebLogic Workshop implements something similar, though not identical, to WS-Policy, called a "WS-Security Policy File." It allows a developer to specify encryption, signature, and security token policies for SOAP messages entering and leaving the BEA WebLogic application server.

WS-SecureConversation is another useful specification—it allows a session to be created between a Web service requester and a Web service, using symmetric keys. WS-SecureConversation is analogous to SSL, which also involves the negotiation of a symmetric key to streamline encrypted message transfer. WS-SecureConversation is available in Microsoft's WSE 2.0 toolkit, but no Java implementation is available at present.

Availability is the CIA requirement that is most often overlooked. Availability includes protection from flooding attacks, as well as protection from attacks that bring down the system on which the Web service depends. It is not very clever to concentrate on shoring up the XML interfaces to an application and then discover that the application has been brought down by an attack against the operating system on which it depends. Therefore, patch management, combined with a full understanding of the dependencies of a Web service, is crucial.

Triple-A
Much of the recent work on Web services security standards has focussed on identity and access control, commonly known as AAA security, standing for authentication, authorization, and audit. This work reflects the fact that Web services are finding applications in partner-integration projects, situations that in the past would have involved a costly leased-line or subscription to an EDI value-added network. In Vordel's customer base, we see Web services being used by insurers to connect to brokerages, by credit-reference agencies to connect to lenders, and by global manufacturing conglomerates to link their regional operations. In all of these cases, the chief security requirement is to ensure that only trusted customers, partners, and suppliers can connect to Web services. WS-Security is relevant here also; in particular, the WS-Security X.509 Token profile and the WS-Security UsernameToken profile are used to embed credentials into SOAP messages sent to a Web service. These credentials may then be used to perform AAA security. The Axis-WSSE project includes code to implement the WS-Security UsernameToken profile in Java.

Following authentication, a SAML token may be issued to assert that the client was authenticated, is authorized for a particular service, or has a certain attribute (such as a credit limit). Commercial Java toolkits may be used to process and validate SAML assertions. SAML is also the basis for interoperability between XML gateways (or XML firewalls) and existing security infrastructure such as extranet access management tools.

The WS-I (Web Services Interoperability) organization takes the standards from OASIS and W3C, examines current practice by vendors and customers, and produces usage profiles. These profiles describe how standards are to be used together to achieve common tasks. A simple explanation of the profiles is that while the standards contain many uses of the word may (a certain algorithm may be used, a certain security token format may be used, and so on), the WS-I specifies which of these must be used if a vendor is to claim interoperability. You can imagine the WS-I lining up the standards on top of each other and cutting out a cross-section through them—this cross section is that piece which each WS-I compliant vendor must implement. A vendor is not required to be a member of the WS-I to claim WS-I interoperability.

The WS-I released a draft of a Basic Security Profile in February 2004. This draft includes profiles for SSL and HTTP-Auth, alongside profiles that use WS-Security. This shows that AAA security for Web services is not limited to new Web services security technologies, but that older technologies still apply.

Interestingly, the WS-I Basic Security Profile draft devotes a lot of time to the security of the AAA technologies themselves. For example, a vendor implementing authentication using the WS-Security X.509 Certificate Token profile must ensure that an attacker cannot intercept a valid message and replay it (a "capture-replay attack") to gain entry to a protected Web service. A capture-replay attack is the equivalent of finding a signed document beside a fax machine and refaxing it. If the recipient is not careful about examining timestamps or numbering in the messages they receive, then they may trust this second message, which in turn calls into question the trust of the first message. The WS-I describes best practice with regard to timestamps and message numbering, since this is a vague area in the standards themselves.

The WS-I Basic Security Profile draft notes that HTTP-Auth and HTTP-DigestAuth, which are challenge-response authentication systems, both involve two round-trips to the target Web server. The first round-trip is to pick up the challenge and one round-trip is to send back the response. Therefore, HTTP-Auth and HTTP-DigestAuth are poor choices for authenticating large XML messages, since the messages must be sent up to the Web service twice.

Injections and XML Bombs
As well as the CIA and AAA security, there is a third aspect of security that is relevant for Web services. It is an aspect of security familiar to anyone who has set up an e-mail server or who has developed an interactive Web site—content-filtering security. Content-filtering security is independent of CIA and AAA security, since the content of an XML message is independent of whether it was encrypted and signed, or whether it came from a trusted source.

In the past year, a lot of effort has been applied to thinking about content-level threats to Web services. Many of the ideas have come from the field of Web application security, which involves protection against threats such as attempts to perform a buffer-overflow attack through parameters passed in a SOAP messages, or to perform a SQL injection attack. (A SQL injection attack involves including SQL commands in data that the attacker knows will be appended to a SQL query.)

In addition to the attacks that have been generalized from the field of Web application security, there are new attacks that take advantage of capabilities of XML itself. Amit Klein from Sanctum Inc. has described an XPath injection attack, which is analogous to SQL injection. Another example of an XML-specific attack is the XML external entity attack, which takes advantage of the fact that outside data can be embedded into an XML document through a document type definition (DTD) entry such as: . By specifying a URI that points to a local file, some XML engines could be made to access unauthorized information, or to cause denial of service by spending cycles "slurping up" large files from the local file system.

Another similar attack also uses a feature of DTDs—this time, however, the attack has the ability to pull in entities that are defined in a DTD. For example, HTML developers who wish to display HTML source code in a Web page are familiar with the requirement to use < and > instead of angle brackets, so that the Web browser does not parse the HTML source code. The usage of ampersand says to the browser "look up lt and gt in the HTML DTD and replace them with what you find." A similar technique is used for £ to display the British pound sign.

Now, think about what happens if an entity is defined recursively. Let's say &x100 is looked up in a DTD and it is found to be &x99;&x99; (that is, the entity called &x99; appends to itself). The DTD parser must then look up &x99;, and let's say it finds that it is &x98;&x98;. You can imagine the rest—the XML message explodes in memory (hence the name "XML bomb") and causes a denial of service.

Finally, SOAP messages may contain attachments that may be threatening if they are very large and difficult to process (a clogging attack) or if they harbor viruses. Attacks using SOAP attachments are somewhat mitigated by the current MIME vs. DIME confusion around which technology to use for SOAP attachments, which means that many organizations are eschewing the usage of SOAP attachments entirely until the Message Transmission Optimization Mechanism (MTOM) becomes a W3C recommendation. However, it is important that even if an organization chooses not to use SOAP attachments, their Web services platform will not process attachments that they unwittingly receive.

Putting Security on the Bus
The security technologies that we've examined so far—CIA security, AAA security, and XML content-filtering—must be applied to XML architectures that involve messages passing between applications, often crossing security domains as they do so. These architectures include the enterprise service bus (ESB) architecture. There is some argument about whether an ESB is something new or if it is qualitatively the same as what vendors such as Sonic and TIBCO have been doing for years.

Even without a conscious ESB architecture, some organizations are finding that their usage of an XML gateway brings them into ESB territory, since the XML gateway forwards messages into internal Web services and introduces a requirement to pass a security context from the XML gateway to the protected Web service (see Figure 2). Imagine an XML gateway that performs mutual SSL or HTTP-Auth authentication on incoming SOAP messages. If the protected Web service wishes to know who the client is—for example, to look up information about the client in a preferences database—they hit an architectural stumbling block because the client is not directly "touching" the Web service that it accesses.

In this situation, it is becoming best practice for the XML gateway, following successful authentication and authorization of the client, to embed the principal name (the identity of the client) into the XML message. This information may be embedded in the form of a WS-Security UsernameToken structure, or in the more information-rich form of a SAML authentication statement. In this way, security and identity information may travel along the XML bus as a kind of parallel "security bus."

Once the principal name is passed to a J2EE application server, a session context can be created by populating the run-as element that is inside the security-identity element, which is inside the session element, inside the enterprise-beans element, in an EJB deployment descriptor. In this way, the EJB now runs in the security context of the end user, even though that end user did not directly connect to the application server.

Web services containers, such as BEA WebLogic, are often deployed behind Web servers such as IIS or Apache. When security rules are enforced over incoming XML traffic, it makes sense to enforce the rules at the Web server, so that unwanted XML messages are blocked as early as possible. This enforcement can be achieved by embedding an XML firewall agent into the Web server to filter XML messages against a predefined security policy (see Figure 3).

Putting It All Together
That's pretty much the current state of Web services security. Now let's single out the best practices that emerge from this discussion.

Where confidentiality and/or integrity are required across SOAP intermediaries, use WS-Security. WS-Security uses XML Encryption and XML Signature to sign and encrypt portions of XML messages.
Make a list of the dependencies of your Web service, including the Web service container and the operating system on which it runs. Ensure that all patches are applied, and remember that Web service security is not just the new stuff, but involves the full underlying software stack also.
User timestamps to ensure that your message-level authentication policies are not vulnerable to capture-replay attacks. A policy such as "We allow all XML messages that have been signed by our partners" is a prime candidate for a capture-replay attack, unless timestamps are included in the signed content.
HTTP-Auth and HTTP-DigestAuth are bad choices for authentication when large XML messages are involved because they require that the XML messages be sent from client to server twice.
If your organization already has security policies in place inside extranet access management tools, ensure that your XML firewall vendor can reuse these, preferably through the use of SAML. A proliferation of policy stores can only lead to confusion.
Unless it is absolutely required, do not support DTDs. Remember that the SOAP 1.1 specification disallows the use of DTDs, and that DTDs expose your XML applications to XML bomb attacks.
If you have decided to use SOAP attachments, whether MIME-based or DIME-based, pass these attachments through security filters. If you have made a decision not to use SOAP attachments, make sure that your Web services platform is not still open to the processing of attachments sent by an opportunistic attacker.
When messages have passed successfully through an XML security gateway, embed a security token into the messages, so that downstream applications have visibility of the client's identity (the "principal") and are aware of the fact that the message has been authenticated, how it was authenticated, and when it was authenticated. SAML authenticate statements, embedded into SOAP messages, are ideal for this purpose.

Although Web services security was nascent 18 months ago, it is now possible to see it in terms of established security patterns. Best practices can be verified and used. I hope that some of these best practices will help you set up your secure Web services.