Abstract
This paper discusses how a new secure perimeter is needed when deploying Web Services. This perimeter is more "porous," in that more gets through, but it also has stronger security requirements. To meet these needs, the perimeter must employ XML encryption, signature, identity; it must resist XDoS attacks, etc.
We will examine several factors that motivate the need for such a perimeter, discuss some considerations to keep in mind when constructing it, and identify some best practices to use in production.
Keywords
Table of Contents
The typical enterprise network configuration[1]has the internal network protected by a pair of TCP/IP firewalls. The outward facing one ensures that packets from the Internet only enter the DMZ, and the inward facing one ensures that packets from the DMZ are the only ones allowed into the internal network; see Figure 1.
The inner firewall is also responsible for limiting what internal systems can be accessed. Network administrators are responsible for keeping this configuration information current, such as modifying it when a new Internet application is deployed, moved, or taken down.
Custom gateways, usually installed in the DMZ, provide and access to the applications running on the internal network, or "back office." Security is maintained by writing the gateways so that the provide specific limited access. Sometimes the applications need configuration or modification as well.
For example, the gateway could be configured to use a specific identity when connecting to an internal database. The database itself is configured so that the gateway identity can only access certain stored procedures, and is not allowed to execute arbitrary SQL commands. This combination mitigates the risk of the so-called "SQL injection attacks" (see http://www.sitepoint.com/article/794 for an introduction).
Another option is to provide a read-only subset of an internal database on the gateway. For example, a complete inventory listing that includes quantity on hand and pricing information can be subsetted to provide a public catalog on the gateway[2].
The adoption of XML has had enormous impact on the back office. Obviously, XML is being used for data exchange. Whenever it is necessary to exchange information between two applications, using XML is certainly an acceptable method, and within a couple of years it will become the default way to do so. XML is also being used as a storage format, from configuration files to commercial database products.
In addition, more applications are being developed as XML applications, rather than as classic client-server Remote Procedure Call (RPC)applications that use XML as the serialization format. One of the biggest drivers of this effort is the Microsoft .NET platform.
This adoption being a number of benefits. The first one is the increased network effect: with a common syntax (and perhaps using HTTP as a common transport), it is possible to connect more things together than every before; this includes applications, internal users, external customers, and so on. This, in turns, results in greater re-use of existing applications, re-purposing of existing data for new markets, greater choice among vendors, and hopefully the need for less Information Technology (IT) plumbing, directly reducing the costs of doing business.
This adoption also brings with it new risks and security concerns. First, it is necessary to re-create much of the IT infrastructure. This includes complicated facilities such as operation commit and rollback, and subtle concepts such as identity and access control. An internal application operating on the local corporate network can more easily participate in a protocol that involves multiple round-trip packet exchanges, than can a client that is operating over a long-haul Internet connection that terminates in a residential broadband (e.g., DSL) link. Similarly, when all of an application's users are employees, it is easy to maintain a roster of authorized users, and to ensure that they are running well-tested software in the authorized manner. When the users are at a business partner, or changing set of business partners, such control is much more difficult to maintain.
The new XML-based software is immature compared to the enterprise application integration (EAI) facilities that have been available, and seen many development and bug-fix iterations, over the past decade or more. As an enterprise tries to fill in the gaps, they often use new vendors. Additional vendors means more systems to keep current with the latest set of security, and other, patches.
Finally, as described in Section 2, XML itself brings security concerns.
It can be very easy to generate an XML document. Unlike a binary protocol such as the Corba interoperability protocol (see http://www.blackmagic.com/people/gabe/iiop.html for more details), a valid XML document can be generated with a few simple print statements. The receiver, however, may be forced to spend significant effort in processing the document, particularly if it is designed to be troublesome, as seen in Figure 2.
<this-element-has-1000000-bytes-in-its-name...
<this element="has" a="million" attributes="...
<this
<document
<is-a
<million
<elements
<deep
Figure 2. Troublesome XML
The asymmetric level of effort between malicious sender and innocent recipient can result in a new type of risk, XML Denial of Service (XDoS). The most widely known example of this is the "billion laughs attack" that uses recursive entity expansion to consume all stack space in the receiving system (see http://lists.xml.org/archives/xml-dev/200212/msg00479.html).
Conventional firewalls -- even those that do "deep scanning" -- treat XML as a sequence of bytes, not as structured data. As a result, they will miss all of the above attacks and pass the XML through; see Figure 3.
From a security perspective, XML itself is incomplete. In order to protect the content from being modified, a mechanism such as XML Digital Signature (XML-DSIG)[XML Digital Signature] is necessary. This can also be used to authenticate the sender of a document. In order to address privacy concerns, a mechanism such as such as XML Encryption (X-Enc)[XML Encryption] is necessary.
In order to securely address the risks described above, some background analysis should be done first. The organization should understand what resources are being accessed, and why. Do not just open port 80 on the server. When feasible, require schema definitions for the data being exchanged, and a service description [Web Services Description Language] if appropriate.
It is important to mask the internal resources that will be used. A gateway, or XML-aware application firewall, should be deployed to rewrite URL's. In addition, design the architecture so that every XML message is validated and filtered. Incoming messages should be processed to protect internal resources, and outgoing messages should be processed to avoid leaking corporate information to external partners.
All XML should be carried inside a SOAP [XML Protocol WG]envelope. The most important feature, in this context, is that SOAP defines a standard place to marry meta-data about the XML document being transferred. This includes security information, but also allows for routing, version control, and so on. As illustrated in Figure 4, an XML-DSIG can use an href link within a Reference element to point to the application payload in the SOAP body.
All outgoing content should have a digital signature. The OASIS (http://www.oasis-open.org) such as Web Services Security (WSS)[WSS TC] specification is likely to be the most widely-used standard for securing SOAP messages. Even if the recipient cannot verify the signature, signing all messages helps protect the organization from misrepresentation.
For content privacy, the most widespread practice is to use SSL. XML Encryption is becoming more common, and is preferred. The current practice is to encrypt the entire body of the SOAP message; application design should allow for partial encryption, and networks and applications should assume that documents intended for different exposure to different parties will be received.
It is important for the organization to authenticate the senders, and less so for the sender to authenticate the organization. This is because the sender is making a conscious effort to connect to a known endpoint, and usually has out-of-band information to validate the identity, such as an SSL certificate. If the organization issues credentials to its partners, then this information should be carried in a WSS UserToken element. If the organization accepts credentials generated by the partner themselves, this should be carried as a Security Assertion Markup Language (SAML) assertion.
We have discussed the trends that are motivating a uniform XML IT infrastructure. We then looked at some of the risks brought about by this new infrastructure, and by XML itself. We finally discussed some mechanisms for addressing these risks. The end result should be a unified IT deployment that brings benefits inside, and across, the organizational perimeter.
[XML Digital Signature] The W3C XML Digital Signature Recommendation, found at http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/.
[XML Encryption] The W3C XML Encryption Recommendation, found at http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/.
[WSS TC] The home page of the OASIS Web Services Security Technical Commitee can be found at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss.
[Web Services Description Language] The current draft version of the recommendation can be found at http://www.w3.org/TR/wsdl20/.
[XML Protocol WG] The W3C group responsible for the SOAP 1.2 recommendations. The WG website is at http://www.w3.org/2000/xp/Group/.
  |
Design & Development by deepX Ltd. |
