Web services are an attempt to offer software as services over the Internet. Although web services are cluttered with a mind-bending array of acronyms (SOAP, WSDL, UDDI, just to name a few), the key to the puzzle is SOAP (Simple Object Access Protocol). SOAP is a network protocol that lets software objects communicate with each other, regardless of programming language or platform. SOAP is based on XML (eXtensible Markup Language), which is the leading web standard for universal Internet data exchange. Although Microsoft originally purposed SOAP as an extension of XML-RPC, it was quickly adopted by many other vendors, most notably Microsoft’s sometime ally, IBM, and their archenemy, Sun Microsystems. There are implementations of SOAP in almost any language you can name.
Web services seem to promise the holy grail of universally distributed programming through increased interoperability. However, with such increased interoperability comes a corresponding increased threat to security. Distributed programming is potentially vulnerable to distributed hacking. Ironically, however, the original SOAP protocol was written without ever mentioning security.
XML itself does provide for a measure of security in the form of signatures and encryption, but these standards have yet to be tested by widespread implementation. Although not specific to Microsoft platforms, the following section discusses theoretical vulnerabilities in XML encryption and XML signatures. This section assumes basic familiarity with XML.
The World Wide Web Consortium (W3C) proposes XML Encryption (Xenc) as a standard for encrypting the XML data and tags within a document. Xenc allows you the flexibility of encrypting portions of a document. In other words, you can encrypt only the sensitive parts, leaving the rest in plain text. The data remains encrypted, but XML parsers can still process the rest of the file. In addition, by using different keys to encrypt different parts of the document, you can distribute the document to multiple recipients. Each recipient will be able to decrypt the portions relevant to him but unable to decipher the rest. This capability allows for wide distribution with a granular control of accessibility.
However, the W3C has raised some issues regarding the security of Xenc. For instance, using both encryption and digital signatures on parts of an XML document can complicate future decryption and signature verification. Specifically, you need to know whether the signature was computed over the encrypted or unencrypted forms of the elements when you are verifying a signature. Another security issue is potential plain-text guessing attacks. For example, encrypting digitally signed data while leaving the digital signature unencrypted may open a potential vulnerability. In addition, there is a potential security risk when combining digital signatures and encryption over a common XML element. However, you can reduce this risk by using secure hashes in the text being processed.
The W3C states that this is an “application” issue that is beyond the scope of their protocol specification. Thus, the burden is on developers to implement cryptographically robust systems. The W3C recommends that when you encrypt data, you make sure to also encrypt any digest or signature over that data. This step solves the issue of whether the signature was computed over the encrypted or unencrypted forms of the elements, since only those signatures that can be seen can be validated. This solution also reduces the threat of plain text guessing attacks, though it may not be possible to identify all the signatures over a given piece of data.
The W3C recommends that you also employ the “decrypt-except” signature transform (XML-DSIG-Decrypt). According to this specification, if you encounter a decrypt transform during signature-transform processing, you should decrypt all encrypted content in the document except for the content exempted by a numbered set of references. Consider the example from the W3C in the sidebar Decrypting All but an Exempted Section of Content.
Other attacks against Xenc besides this W3C example are theoretically possible. In certain encryption algorithms, when you encrypt the plain text with the same key, the resulting ciphertext is always the same. For example, XML encoding and tags are redundant; since an attacker may determine the data’s structure, this can introduce potential vulnerabilities. Careful encryption implementation and testing mitigates this risk.
Another potential risk to Xenc is denial-of-service, since the specification permits recursive processing. The W3C gives the following example:
EncryptedKey A requires EncryptedKey B to be decrypted.
EncryptedKey B requires EncryptedKey A to be decrypted.
EncryptedKey A...
In another DoS scenario, the hacker submits for decryption an EncryptedData that references very large or continually redirected network resources. To mitigate these risks, your implementation should allow limits on arbitrary recursion, processing power, and bandwidth.
XML signatures are analogous to security certificate signatures. An XML signature fingerprints an XML document so that the recipient can verify the origin and make sure the document has not changed. XML signatures depend on canonicalization , which creates a signature based on the data and tags in an XML document, while ignoring less important formatting such as spaces and linebreaks. In this way, the signature functions universally despite wide variations in file formats and parsers.
XML signatures must be implemented with security as the foremost consideration. The W3C specification says that signatures can apply to either part or all of an XML document. Transforms facilitate this ability by letting you sign data derived from processing the content of an identified resource. For example, suppose you want your application to sign a form but still allow users to enter fields without changing a signature on the form. In this case, use Xpath to exclude those portions the user needs to change. Transforms can include anything from encoding transforms to canonicalization instructions or even XSLT transformations.
Such uses do raise security considerations. For example, signing a transformed document is no guarantee that any information discarded by transforms is secure. This is described as the principle of “only what is signed is secure.” Canonical XML automatically expands all internal entities and XML namespaces within the content being signed. Each entity is replaced with its definition, and the canonical form represents each element’s namespace.
Thus, if your application does not canonicalize XML content, you should not implement internal entities, and you must represent the namespace explicitly within the signed content. In addition, if you are worried about the integrity of the element type definitions associated with the XML instance being signed, then you should sign those definitions as well. Furthermore, keep in mind that the signature does not verify the envelope. Only the plain-text data within the envelope is signed. The signature does not authenticate the envelope headers or the envelope’s ciphertext form.
A second security principle is that “only what is seen should be signed.” In other words, the optimal solution is to sign the exact screen images that the end user sees. Unfortunately, this is not practical, as it would result in data that is difficult for subsequent software to process. More practically, you can simply sign the data along with the corresponding filters, stylesheets, etc. that will determine its final presentation.
A third security principle outlined by the W3C is to “see what is signed.” In other words, use signatures to establish trust on the validity of the transformed document, rather than on the pretransformed data. For instance, if your application operates over the original data, a hacker could introduce a potential weakness between the original and transformed data.
Security is critical to the widespread adoption of web services. Ironically, the original SOAP specification did not mention security. As web services evolve, they will become increasingly dependent on integrated security features.
“XML-Signature Syntax and Processing.” Copyright © 12 February 2002 World Wide Web Consortium. All Rights Reserved. (http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/)