XML Security Threats
All the components in web services are described in XML. SOAP and all the WS -Security specifications are XML formats. Hence it just makes sense for expressing security data in XML format. Fortunately, there has been no need to invent new cryptography technologies for XML. The XML security standards have used existing cryptography directly. XML-based data transfer has emerged as the standard for organizations to exchange business data. As with all communications over the public Internet, XML-based transfers have their own set of vulnerabilities to confront. Like any other document exchange, XML document exchange must support the usual security measures which are Confidentiality, Integrity, Authenticity, and Non-Repudiation. The following list illustrates some specific XML security threats:
- Schema Altering — Manipulation of WS schema to alter the data processed by the application.
- XML Parameter Tampering — Injection of malicious scripts or content into XML parameters
- Coercive Parsing — Injection of malicious content into the XML
- Oversized Payload — Sending oversized files to create an XDoS attack
- Recursive Payload — Sending mass amounts of nested data to create an XDoS attack against an XML parser
- XML Routing Detours — Redirecting sensitive data within the XML path
- External Entity Attack — An attack on an application that parses XML input from suspicious sources using an incorrectly configured XML parser
These threats pose potentially serious problems to developers creating applications, components, and systems that depend on XML data. The solution for the above problems is XML Encryption.
XML Encryption provides end-to-end security for applications that require secure exchange of structured data. XML itself is the most popular technology for structuring data, and therefore XML-based encryption is the natural way to handle complex requirements for security in data interchange applications.
XML Encryption is a process for encrypting and decrypting parts of XML documents. Most of today's encryption schemes use transport-level techniques that encrypt an entire request and response stream between a sender and receiver, offering zero visibility into contents of the interchange to intermediaries. Contentlevel encryption converts document fragments into illegible ciphertext, while other elements remain legible as plaintext.
Some features of XML encryption are:
- The ability to encrypt a complete XML file
- The ability to encrypt a single element of an XML file
- The ability to encrypt only the contents of an XML element
- The ability to encrypt binary data within an XML file
Encrypting an XML File
Here's a short sample XML file that can serve to demonstrate XML encryption:
<Date>July 6, 2006</Date>
When you encrypt an entire XML file, the process simply replaces the root element (<POInfo> in the sample) with an <EncryptedData> element that contains the encryption details, including the encrypted content.
Here is how the encrypted file will look:
<?xml version="1.0" encoding="UTF-8"?>
Encrypting a Single Element
To encrypt a single element of an XML file, you specify the desired child element, rather than the root element of the input file as the element to encrypt. The following snippet shows the results of encrypting only the <CreditCardNumber> element of the sample file.
<?xml version="1.0" encoding="UTF-8"?>
<Date>July 6, 2005</Date>
Notice that the encryption process replaced the <CreditCardNumber> tag and its contents with an <EncryptedData> tag, while leaving the siblings of the <CreditCardNumber> element unaltered.
This type of encryption can be performed using XML Signature and Encryption. The interested reader may look up the implementation at the Apache site (http://xml.apache.org/security/).
Best practices for XML encryption, can be summarized as follows:
- It is good to have standard element tags for representing encrypted elements within the XML documents. This will enable parsers to better understand encrypted elements and data during the validation process.
- It is necessary to provide means for encrypting only the desired elements within an XML document instead of encrypting the whole document. This will pave the way for incorporating several confidential data elements that are intended for different recipients within a single XML document.
- There should be standard mechanisms for exchanging the secret keys used for encryption and decryption processes.
- The standard should allow encryption of different parts of the document with different keys, so that multiple recipients can decrypt only those portions that are intended for them.
- The standards should be adaptable to both ASCII and binary data.
- The standards should be adaptable to different cryptographic algorithms.
- The standards should work along with other XML security standards and specifications.
SSL versus XML Encryption
Why do we need exclusive standards and methodology for XML encryption when we already have established technologies like Secure Socket Layers (SSL) and Transport Security Layer (TSL), which also use cryptographic concepts to secure communications?
Although SSL and TSL are good for securing communications across two parties, they are not suitable for multi-party interactions, which is a typical characteristic of XML/web service interactions. Also, SSL and TSL do not have the capacity to encrypt only specific parts of the document or to encrypt different portions of the document using different keys — which are critical to XML encryption.
SSL guarantees security of payload during the transit. However, when the payload reaches a node, it is unprotected. Also, SSL is a point-to-point security mechanism where as XML encryption guarantees end-to-end security.
XML Signature is a W3C recommendation that defines XML syntax for digital signatures. It is used by various web technologies such as SOAP, SAML, and others.
XML signatures will enable a sender to cryptographically sign data, and the signatures can then be used as authentication credentials or a way to check data integrity. This also guarantees non-repudiation.
XML signatures can be applied to any XML resource, such as XML, an HTML page, binary-encoded data such as a GIF file, and XML-encoded data. The primary feature of the XML digital signature is its ability to sign only specific portions of the XML document just like the encryption example we discussed in the previous section. XML signatures can be broadly classified into three types:
- Enveloped signature — An enveloped signature is the signature applied over the XML content that contains the signature as an element. The Signature element is excluded from the calculation of the signature value.
- Enveloping signature — An enveloping signature is the signature applied over the content found within an Object element of the signature itself. The object or its content is identified through a Reference element by way of a Uniform Resource Identifier (URI) fragment identifier or transform.
- Detached signature — A detached signature is the signature applied over the content external to the Signature element, and it can be identified by way of a URI or a transform. The signed XML resource can be present within the same document as the Signature element, or it can be external to the XML document.
Guidelines for Securing Your Services
Security testing, which is important for any software application, is even more crucial for web services. Web services' security architecture not only depends on the standard security measures, it also depends on the service scope and scale of deployment. For instance, security can either be enforced in the application server itself, or as a separate security appliance that can virtualize the service by sitting in the middle between the service and its consumers.
The points that you need to consider for securing your web services are:
- Find suitable security architecture — Decide whether to implement the security on the transport layer or on the message layer. TLS (Transport Layer Security) is a mature technology so both standards and tools have already been developed. It also provides a good transition path for engineers who are somewhat familiar with transport-level security but are new to web services. On the other hand, TLS has inherent limitations that make it inappropriate when you desire an end-to-end security. Fortunately, message layer security provides an alternative solution for situations where TLS's limitations are troublesome.
- Follow the standards religiously — publicly available, commonly used, well-analyzed cryptographic algorithms are the best choice, simply because they've already undergone a great deal of research and scrutiny since they were adopted by the industry.
- Filter your XML — XML requires complex processing to ensure that transactions are known to be good before they penetrate deep into the enterprise. XML filtering offers a variety of functionality as complex rule sets can be built around network-level information, message size, and message content.
- Prevent XML Denial-of-Service (XDos) — To protect against XDoS, implement reasonable constraints for all incoming messages. With the use of an XML security gateway as a proxy, you can configure simple settings on message size, frequency, and connection duration.
Securing your web services is a vital aspect of ensuring a successful deployment. When deployed externally for consumption by partners or customers, only secure web services can provide a justifiable integration solution. An interested reader may refer to the WS-Security standard for creating secured web services. WS-Security is a communications protocol originally developed by IBM, Microsoft, Verisign, and Forum Systems. It contains specifications on how integrity and confidentially can be enforced on web services messaging. It describes how to attach signature and encryption headers to SOAP messages. It also describes how to attach security tokens, including binary tokens such as X.509 certificates and Kerberos tickets, to XML messages.