by Blake Dournaee
This is the second of two articles that focus on security for ebXML. The first article, Message Exchange, examined message layer security and security policies for ebXML messages. That is, it focused on the fact that the actual payload may be signed and encrypted to provide persistent security, data privacy, and audit capabilities for ebMS messages. As previously discussed, this payload protection is over and above that which is provided by transport level mechanisms such as SSL or TLS. This type of message-level security falls under a category of trust enablement, allowing the message to contain signed and encrypted payloads irrespective of the transport.
The main purpose of this article is to focus on a new content threat category, collectively called XML Content Attacks. These attacks rely on the executable nature of the XML payload and the capacity for code injection and coercive parsing attempts within an ebMS message. As we will see, even countermeasures such as header encryption, signature, and transport layer security will not adequately protect against these types of business threats.
An XML Content Attack is any type of XML-based, content-borne threat that has the capability to do one or both of the following:
To understand how to protect against XML Content Attacks, we first must understand what happens when XML (and ebMS specifically) is processed.
When an ebMS message is transmitted and subsequently processed, even if it has an encrypted payload, there is an outer structure and metadata that must always be processed in the clear. This outer structure is the SOAP header and body and the ebMS message header and manifest. The processing that occurs here in typical scenarios includes XML parsing and XML grammar validation.
The parsing step is a basic prerequisite for any type of XML processing, and the second step involves schema validation, which ensures that the message meets the necessary SOAP and ebMS specifications before it is passed to a downstream entity. Some implementations may perform parsing and validation simultaneously through the use of a validating parser.
The schema validation step involves the use of a W3C-compliant schema to validate the grammar of an incoming XML message. For ebMS, the main SOAP message relies on two schemas, the SOAP v1.1 structure and the header and manifest extensions defined by ebMS 2.0. A simple picture of the steps involved is shown in Figure 1.
Figure 1. Typical ebMS standard XML processing configuration
In Figure 1, the ebMS 2.0 message enters a trading partner's B2B gateway where it is parsed and subsequently validated. The figure also shows the B2B server relying on two schema definitions (XSD documents), the SOAP v1.1 schema and the ebMS 2.0 schema. Both are used in the process of schema validation to perform the content model checking and to protect against malformed requests.
As we will see in the next section, this standard configuration is vulnerable to XML content attacks even in light of the schema validation step.
Most newcomers to the XML security space might believe that the schema validation step is sufficient to protect against XML content attacks. For example, schema validation claims to accurately check the ebMS 2.0 message against the standard schema. If any sort of malformed request is sent, the schema validation step should fail and the message should be rejected outright. Unfortunately, this reasoning is incorrect due to the use of extensibility points in standard schemas, including ebMS 2.0.
In a schema, an extensibility point is a general term used to refer to an open content model. An open content model is one that allows content from a foreign namespace to be placed inside an XML payload while still maintaining schema validity. In other words, the message maintains validity with the standard schema in light of the presence of foreign content. The reason why extensibility points exist in schemas is because schema validity is not meant to be a security feature; rather, it is meant to be a language grammar validation feature. When a language has an open content model, this essentially means that valid instances of the language may include unanticipated or foreign content.
Open language content models allow schemas to be extensible and future proof. Unfortunately, this same extensibility is a huge, gaping hole for partners who wish to use XML for secure business transactions.
To see how the extensibility points work with ebMS, it is necessary to take a look at the content model as defined by the ebMS 2.0 schema definition. The following examples and definitions are based on the standard ebMS 2.0 schema available from the following location:
As mentioned before, we must investigate the ebMS 2.0 content model if we are to understand how its extensibility points operate. The first thing to do is to look at how the ebMS 2.0 schema is defined. For starters, because ebMS relies on SOAP v1.1, the schema definition is defined in terms of SOAP extension points. In particular, a BNF grammar style view of the element structure is shown in Listing 1. This structure uses standard cardinality symbols where an asterisk (*) means zero or more, a question mark (?) means zero or one, a plus sign (+) means one or more, and the absence of a symbol means exactly one. Namespaces have been omitted for clarity.
Listing 1. SOAP/ebMS Element Structure
<Envelope> <Header> <MessageHeader> <From> <To> <CPAId> <ConversationId> <Service> <Action> <MessageData> (<DuplicateElimination>) ? (<Description>) * </MessageHeader> <Header> <Body> (<Manifest> (<Reference> + (<Schema>) * (<Description>) * </Reference ) + </Manifest> ) ? <Body> </Envelope>
The previous content model shows the outer structure for ebMS. Schema-valid instances of an ebMS message need to have at least the structure and cardinality rules as shown. Listing 1 does a good job of describing the minimal requirements to maintain schema validity but does not show the various extension points. Many of the element schema type definitions in ebMS allow for arbitrary content to be inserted. For example, consider the following two examples of the
Manifest element as shown in Listing 2. Once again, namespaces have been removed for clarity.
Listing 2: Two Schema Valid
ebMS Manifest Schema Valid Instance A
<Manifest id="Manifest" version="2.0"> <Reference id="pay01" xlink:href="cid:payload-1" xlink:role="http://regrep.org/gci/purchaseOrder"> <Schema location="http://foo.com/po.xsd" eb:version="2.0"/> <Description> Purchase Order for 100,000 widgets </eb:Description> </eb:Reference> </eb:Manifest>
ebMS Manifest Schema Valid Instance B
<Manifest id="Manifest" version="2.0"> <Reference id="pay01" xlink:href="cid:payload-1" xlink:role="http://regrep.org/gci/purchaseOrder"> <Schema location="http://foo.com/po.xsd" eb:version="2.0"/> <Description> Purchase Order for 100,000 widgets </eb:Description> <Garbage a="1" a="2" a="3" a="4" a="5" a="6" ...> <Garbage> <Garbage> <Garbage> <Garbage> <Garbage> <Garbage> <!-- lots and lots of text here --> </Garbage> </Garbage> </Garbage> </Garbage> </Garbage> </eb:Reference> </eb:Manifest>
At this point it should be apparent that there is possibly dangerous, extraneous content inside ebMS message B shown in Listing 2. The extra content added here is only a short example, and the idea is that many hundreds of megabytes of extra data may be used to tie up XML processing resources. Furthermore, point weaknesses in certain parsers can be exploited if strange but well-formed content is added, such as deeply nested attributes or code injection.
The reader might raise an objection here by noting that, due to the effect of an XML Signature, the entire header is protected, making the insertion of arbitrary XML content impossible. The reason why this argument is ineffective is because the document must be parsed before the signature can be validated. In the case of binary format documents with a traditional signature, this might not always be true; the signature might be processed first. In the case of XML, however, the XML Signature is itself XML. Therefore, the first thing that happens is XML parsing, meaning that the parser must eventually process the entire node set of the document before signature verification can occur, so the attack will strike either before or during the process of validating the signature, but never after.
The main point in Listing 2 is that neither schema validation nor XML Signature will protect against the extra content shown in instance B. The reason lies with the extensibility points in the ebMS 2.0 message specification. Specifically, the
Reference element is defined to be extensible and allows any elements from a foreign namespace to be added in a completely unbounded manner. The schema definition mechanism used to provide this extensibility is known as the
any element, and it is one of the primary security holes in schemas that use this element. For reference, the schema definition fragment for
Reference is shown in Listing 3.
Listing 3: The Schema Definition for the
<element name="Reference"> <complexType> <sequence> <element ref="tns:Schema" minOccurs="0" maxOccurs="unbounded" /> <element ref="tns:Description" minOccurs="0" maxOccurs="unbounded" /> <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" /> </sequence> <attribute ref="tns:id" /> <attribute ref="xlink:type" fixed="simple" /> <attribute ref="xlink:href" use="required" /> <attribute ref="xlink:role" /> <anyAttribute namespace="##other" processContents="lax" /> </complexType> </element>
The most important points here are the
anyAttribute elements. The
any element is positioned as the last constraint in the
sequence element, and the
anyAttribute element is positioned as the last constraint in the
Both of these type definitions essentially permit the
Reference to have an extensible, unbounded number of elements and an extensible, unbounded number of attributes, while still maintaining schema validity. This lax approach to schema validation is cemented by the use of the lax attribute value for the
processContents attribute on both of these elements.
It can be argued that if we have found one extensibility point in ebMS, it might be a simple, pragmatic fix to plug the hole. This is known as
schema hardening, which is the process of removing schema extensibility points like the
any element. The dilemma here is the fact that removing any of these extensibility points breaks the ebMS 2.0 message specification, as there might be legitimate uses for the extensibility points in the original design of the language. In fact, ebMS 2.0 has four such extensibility points within the ebMS 2.0 schema definition, as summarized in Table 1.
Table 1: ebMS 2.0 Schema Security Holes
|ebMS 2.0 Element||Element Security Hole?||Attribute Security Hole?|
In the face of extensible content models like ebMS, the proposed solution should rely on a strategy for XML content threat prevention that is able to go above and beyond simple schema validation to provide Advanced Data Validation (ADV).
ADV comprises a number of configurable checkpoints for XML processing, both during the parsing and the content inspection. Some of the limits provided by ADV include limit enforcement for XML parsing, with the ability to specify exact ranges on how much XML should be parsed for a given transaction as well as the ability to control the generic structure of the XML with tree-based limits, for example, the number and size of attributes, elements, and comments, as well as tree depth. ADV should cover the following attributes of an XML document:
Another aspect of ADV is that it provides cross-field checks and string filtering for suspect requests. These semantic checks can place further enforcement on the content and protect against code injection attacks such as SQL injection.
The ebMS standard is designed around SOAP with Attachments, and in most practical cases, the actual business message exchanged is going to be the second MIME container in the SOAP structure. This fact leads to questions surrounding the protection of the actual payload as well as the header.
Protecting the payload against semantic threats is especially important for ebXML because the payload is where parameter tampering and code injection attacks may be hidden. In many cases, the attachments are XML based, but ebXML architectures deployed today also use text or binary format messages to conduct units of business.
The difficulty in designing general protection for ebMS payload lies in the fact that in the general case, there is no reliable a priori XML language detection scheme. That is, there is no completely reliable way to determine the XML language used as the payload. It may be a custom namespace and language agreed upon by two trading partners. Even if payloads are signed, the signer may have unknowingly passed along an XML instance full of XML content attacks that was deemed valid by his or her previous schema validation mechanism. In addition, even signed payloads that use XML Signature must be parsed before the signature is validated.
In the case of unknown payloads, it is especially important to perform some type of semantic checking based on the payload type, whether it is text, binary, EDI, or XML. Using the Advanced Data Validation (ADV) checks described in the previous section works well for XML, but other mechanisms like string searching or binary payload type inspection should also be used.
At this point, the reader should have a good idea about where the various message layer security policy mechanisms are defined in an ebXML Collaboration Protocol Profile (CPP) document as well as the message-level security and content threat points for ebMS.
In a typical ebXML deployment, trading partners rely on a B2B server or gateway to handle the message-level security requirements. As an example, consider Figure 2.
Figure 2. Standard ebXML B2B architecture
Figure 2 shows the standard deployment of an ebXML-compliant B2B server at each trading partner. In this example, the CPA is implemented directly by the B2B server. The CPA not only contains security policy information; it also contains the business collaboration information as well as the supported transactions that define the units of business. Due to the comprehensive nature of the CPA, it must be consumed by each partner's B2B server.
When transaction rates for ebXML reach critical mass, and B2B servers begin to bear the burden of increasing numbers of business transactions, decoupling the message-level security to an XML firewall or security gateway makes sense from a security, reliability, and scalability standpoint. In the revised architecture, the security policy information is extracted from the CPA by the gateway, and the message-level security mechanisms are disabled at the B2B server, centralizing the security at the XML firewall. This expanded architecture is shown in Figure 3.
Figure 3. Extended ebXML B2B architecture with an XML firewall
Due to the XML firewall shown in Figure 3, the role of the B2B server is expanded. For example, it can handle more units of business and safely expose business transactions over the open Internet. Furthermore, the XML firewall protects the B2B server and ebXML infrastructure from XML content attacks. Finally, the entire business infrastructure can scale easily by adding further XML firewall units in the future.
We've covered a lot of ground in this series of articles, and it is prudent to provide a summary of the most important points:
As a final summary, Figure 4 contains a high-level diagram of how ebXML utilizes other open standards.
Figure 4. ebXML standards relationship diagram
Blake Dournaee is a senior architect at Sarvega, Inc, based in Oakbrook Terrace, IL.