The web services model brings into the system unique security challenges because the business data in the form of XML documents may be required to travel across untrusted networks and has the chance of being manipulated by external systems.

Throughout the entire business transaction, different classes of users and systems need access to the entire business transaction. If any part of this chain is compromised, the whole business application deployed as a service will fail. Web services are inherently about how to share the process of computing across a distributed network of systems. Web services' communication channel being XML, messages are text-based, readable, and self describing.

In this article, authors Poornachandra Sarang, Frank Jennings, Matjaz Juric, and Ramesh Loganathan explain the XML security threats and the guidelines for securing your XML Documents.

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

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:

1. The ability to encrypt a complete XML file


2. The ability to encrypt a single element of an XML file


3. The ability to encrypt only the contents of an XML element


4. 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:

    <?xml version='1.0'?>
    <POInfo xmlns='http://packtpub.com/payments'>
        <Name>FJ</Name>
        <Amount>125.00</Amount>
        <CreditCardNumber>1234-5678-4564-4321</CreditCardNumber>
    <Date>July 6, 2006</Date>
    </POInfo>

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"?>
    <xenc:EncryptedData
        xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
        Type="http://www.w3.org/2001/04/xmlenc#Element">
        <xenc:EncryptionMethod
            Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"
            xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"/>
        <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <xenc:EncryptedKey
                xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
                <xenc:EncryptionMethod
                    Algorithm="http://www.w3.org/2001/04/xmlenc#kw-tripledes"
                    xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"/>
                <xenc:CipherData
                    xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
                    <xenc:CipherValue
                        xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
                        MKeT0ZmHFLwnZaSXO+oZSxlSJ5/BqvblqG76B3nOMU0=
                    </xenc:CipherValue>
                </xenc:CipherData>
            </xenc:EncryptedKey>
        </ds:KeyInfo>
        <xenc:CipherData
            xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
            <xenc:CipherValue
                xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
                    +M/Tamk/62Lut4HqLpU/es9sdhnNTTpasbeszN8GN8EAJZsX0vvClcKEW
                    UAgIdbvyJpprQ+jUIiWJKTz1X3L6VAefHqO963pU3bzmGMo
                    pHLqS1Eg7iAPFhKV1PJclyswyyepEjyu+bOgqzgGnS1XA0/V
                    NP7kLK70rB2Zb0DSbaCi+7HjTNGWF9YKtPIP5bvrs5xw+x
                    HnKO++2EuqzK+deD7mCu8w6sG9vmRCrUR99Mx1QDZon9a2962ZD
                    FSwoIJKg5I83GzOU+RObBBUme+yTf7UWybEiwtHp5ZgvuaQYJA=
            </xenc:CipherValue>
        </xenc:CipherData>
    </xenc:EncryptedData>

SOA Approach to Integration

 

XML, Web services, ESB, and BPEL in real-world SOA projects   Service-Oriented Architectures and SOA approach to integration SOA architectural design and domain-specific models Common Integration Patterns and how they can be best solved using Web services, BPEL and Enterprise Service Bus (ESB) Concepts behind SOA standards, security, transactions, and how to efficiently work with XML In More Detail

---

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"?>
    <POInfo xmlns="http://jeffhanson.com/payments">
        <Name>John Doe</Name>
        <Amount>125.00</Amount>
        <xenc:EncryptedData
            xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
            Type="http://www.w3.org/2001/04/xmlenc#Element">
            <xenc:EncryptionMethod
                Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"
                xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"/>
            <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <xenc:EncryptedKey
                    xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
                    <xenc:EncryptionMethod
                        Algorithm=
                            "http://www.w3.org/2001/04/xmlenc#kw-tripledes"
                        xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"/>
                    <xenc:CipherData
                        xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
                        <xenc:CipherValue
                            xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
                                6zhAcEW7KIKrbSjEOkXDrVkmws5zhQQLDO4YYW+RfRY=
                        </xenc:CipherValue>
                    </xenc:CipherData>
                </xenc:EncryptedKey>
            </ds:KeyInfo>
            <xenc:CipherData
                xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
                <xenc:CipherValue
                    xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
                    JqsRmdSoS+PXqCe80Y8zNiQ49sHTLNaAgHX1Ja7d+u9fv
                    TFBrkBMK7C7EHsQTglZ3yT9yCZDuFnjBoQTLULKqOy71Qw
                    EPRPObtYLPIJgy1vUdNrw47uDmJ/R5r/B0SH37HN8mfNv
                    i50zPt1qPxxRwA==
                </xenc:CipherValue>
            </xenc:CipherData>
        </xenc:EncryptedData>
        <Date>July 6, 2005</Date>
    </POInfo>

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.

SOA Approach to Integration

 

XML, Web services, ESB, and BPEL in real-world SOA projects   Service-Oriented Architectures and SOA approach to integration SOA architectural design and domain-specific models Common Integration Patterns and how they can be best solved using Web services, BPEL and Enterprise Service Bus (ESB) Concepts behind SOA standards, security, transactions, and how to efficiently work with XML In More Detail

---

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 Signatures

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:

1. 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.
2. 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.
3. 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:

1. 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.
    
2. 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.
    
3. 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.
    
4. 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.

SOA Approach to Integration

 

XML, Web services, ESB, and BPEL in real-world SOA projects   Service-Oriented Architectures and SOA approach to integration SOA architectural design and domain-specific models Common Integration Patterns and how they can be best solved using Web services, BPEL and Enterprise Service Bus (ESB) Concepts behind SOA standards, security, transactions, and how to efficiently work with XML In More Detail

---

Poornachandra Sarang, Ph.D. runs a Software Consulting and Training firm in the name of ABCOM Information Systems (http://www.abcom.com) and is currently an adjunct faculty in the Univ. Dept. of Computer Science at University of Mumbai. Dr. Sarang has previously worked as a Visiting Professor of Computer Engineering at University of Notre Dame, USA and has been a Consultant to Sun Microsystems for several years. Dr. Sarang has spoken in number of prestigious international conferences on Java/CORBA/XML/.NET organized by O’Reilly, SYS-CON, WROX, SUN, Microsoft and others. He has authored several articles, research papers, courseware and books.

Frank Jennings, works in the Information Products Group of Sun Microsystems Inc. He has more than 9 years of experience in Java, SOA and System Design. He is an Electronics Engineer from Madras University and has worked for several open source projects.

Matjaz B. Juric holds a Ph.D. in computer and information science. He is Associate Professor at the University of Maribor. In addition to this book, he has coauthored Professional J2EE EAI, Professional EJB, J2EE Design Patterns Applied, and the .NET Serialization Handbook, published by Wrox Press. He has published chapters in More Java Gems (Cambridge University Press) and in Technology Supporting Business Solutions (Nova Science Publishers). He has also published in journals and magazines, such as Java Developer's Journal, Java Report, Java World, Web Services Journal, eai Journal, theserverside.com, OTN, ACM journals, and presented at conferences such as OOPSLA, Java Development, XML Europe, OOW, SCI, and others. He is a reviewer, program committee member, and conference organizer. Matjaz has been involved in several large-scale object technology projects. In cooperation with IBM Java Technology Centre, he worked on performance analysis and optimization of RMI-IIOP, an integral part of the Java platform. Matjaz is author of courses and consultant for the BPEL and SOA consulting company BPELmentor.com. For more information, please visit http://www.bpelmentor.com.

Ramesh Loganathan has 16 years of Systems engineering and R&D management experience in technology-intensive product development organizations including Sonic Software (Technical Director, India Dev Center), Pramati Technologies (VP, Engineering) and Informix (Principal Engineer). Ramesh has full life-cycle experience setting up and managing product development organizations and motivating high-caliber engineering teams. He has strong insight into Systems software, Middleware-technology, Database internals, Internet Architectures, and frameworks. Ramesh has led engineering efforts building software infrastructure products at Pramati and Sonic Software. After a brief engagement with Sonic/Progress, Ramesh is now VP-Middleware Technologies at Pramati, driving the product direction and setting up a new Technology Consulting business around Middleware Systems.Ramesh has worked with several organizations in India and in the US including IBM, Lever, Compaq, TCS, Informix, and Integra.Ramesh is an accomplished Technologist and evangelist regularly speaking at workshops and seminars. He is active in Tech fora, JCP, and SPEC organizations. He is a member of several Standards Expert groups including J2EE 1.4 and is a founding member of ebXMLIndia.org and hyd-eclipse.org. Ramesh is actively engaged with academia and researchers and is an Adjunct Faculty member at IIIT-H, teaching two courses on Middleware systems.