XML and Web Services: Are We Secure Yet? (Continued)

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 (see Resources) 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.