A CDATA section begins with <![CDATA[ followed by free-form unescaped character data. The section is ended with ]]>. The data within the CDATA section is not interpreted by the parser. Consider the case in which the attacker specifies the name of the car in XML data <CAR color=“purple”>Car Name</CAR>, and the car’s name (text between the <CAR> and </CAR> tags) is stored and later displayed as HTML; a script injection attack should be attempted. The following XML causes the parser to fail:

<?xml version="1.0" encoding="UTF-8"?>
<CAR color="purple"><IMG SRC="javascript:alert(document.domain)">Car Name</CAR>

The problem is <IMG SRC=“javascript:alert(document.domain)”>: it is invalid XML because it has no ending tag. The Microsoft XML parser (MSXML) displays the error “End tag ‘CAR’ does not match the start tag ‘IMG’,” as shown in Figure 11-1.

Figure 11-1. Including angle brackets in content of the Car element, which causes a parser error (not well-formed XML)

A CDATA section can be used to include the image tag as shown here:

<?xml version="1.0" encoding="UTF-8"?>
<CAR color="purple">Car Type<![CDATA[<IMG SRC="javascript:alert(document.domain)">]]></CAR>

Another way to include character data in XML is by using a Character Entity Reference or a Numeric Character Reference (NCR). Just as characters, such as angle brackets, could be encoded in HTML, they can be encoded in XML. Table 11-1 shows characters and their predefined character entity reference.

Arbitrary characters can be represented as numeric character references by using the characters &#x[character’s hex value]. For example, a null character (hex 00) could be embedded in the XML data by using &#x00.

For printing blocks of printable characters, it is easier to use a CDATA section. Character references are good for representing a few characters at a time and nonprintable characters. Character references can also be used as an attribute of a tag (where CDATA sections aren’t permitted).

<EXAMPLE text= "1 &lt; 3" />

Really Simple Syndication (RSS) is a feature that reads an XML document known as a feed on a Web site. RSS readers interpret and display the feed to the user. RSS feeds are commonly used to publish news, mailing lists, and Podcasts. Hidetake Jo and I (Gallagher) recently tested parts of an RSS reader written in C++. The data controlled by the attacker was the RSS feed. In addition to attacking the parser itself, we also tried quite a few other test cases. Here is a partial list (the full list is too long for this text):

These test cases help stress the importance of testing for non-XML vulnerabilities in applications that interact with XML. Although RSS feeds are XML files, all of the bugs we discovered were non-XML bugs. Our test cases had to take into account the fact that we were dealing with XML because we knew the RSS reader used an XML parser to access the RSS feed.

It is possible to create an infinite loop of entities referring to themselves. Consider the following XML that defines two entities named xx and zz:

<!ENTITY % xx '&#x25;zz;'>
<!ENTITY % zz '&#x25;xx;'>
%xx;

The last line of this XML causes % xx to become % zz; and then % zz becomes % xx. Now % xx should be converted again. As you can see, the entity conversion is now in an infinite loop.

This can be used as a denial of service (DoS) against the XML parser. For this reason, the XML specification states XML must not contain recursive entity references to itself (either directly or indirectly). Parsers should not assume XML input is according to spec. Many XML parsers detect this today. When testing an XML parser, it is important to verify recursive entities are not processed.

Similar to an infinite entity reference loop, an entity can refer to two or more additional entities that also reference several more entities. The following XML is a great example from Rami Jaamour’s article, “Securing Web Services” (http://www.infosectoday.com/IT%20Today/webservices.pdf):

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE something [
  <!ENTITY x0 "Developers!">
  <!ENTITY x1 "&x0;&x0;">
  <!ENTITY x2 "&x1;&x1;">
  <!ENTITY x3 "&x2;&x2;">
  <!ENTITY x4 "&x3;&x3;">
  ...
  <!ENTITY x100 "&x99;&x99;">
]>
<something>&x100;</something>

The preceding XML first replaces “&x100;” with “&x99;&x99;” which is then replaced with “&x98;&x98;&x98;&x98;”. This string is next replaced with “&x97;&x97;&x97;&x97;&x97; &x97;&x97;&x97;”. This replacement chain would continue until the replacement string eventually became the string “Developers!” repeated 2^100 times! This is a huge string, and a fair amount of processing occurred to create it. This is another DoS attack against the parser.

As previously stated, an entity can refer to the contents of a file. The file is specified by the URL in the XML file. The security concern is that attackers might be able to specify an XML file that gets processed under a different security context (by the server, by another user, etc.). By using an external entity, attackers can specify files that they can’t already access. For example, if the XML is processed on the server, the attacker could specify “c:dirSecretPlans.txt” as the URL to retrieve the contents of SecretPlans.txt on the server’s hard drive, which occurs when the server loads the XML and processes external entity references in the DTD.

Sverre H. Huseby discovered an XML external entity (XXE) bug in Adobe Reader. He found that he could read files from victims’ machines when they opened his PDF document. He accomplished this by including XML that referenced the file of his choice on his victim’s hard drive and then used JavaScript contained in the PDF to submit the contents of the referenced file to his server. More information about this vulnerability is available on Sverre’s Web site (http://shh.thathost.com/secadv/adobexxe/). This issue has been fixed in Adobe Reader 7.0.2.

If you are testing an application that takes XML input, verify that you cannot gain access to files normally not accessible by using XML similar to the following.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE myTest [
  <!ELEMENT secTest ANY>
  <!ENTITY xxe SYSTEM "c:/boot.ini">
]>
<secTest>&xxe;</secTest>

XML is commonly used to store data. If user-supplied data is stored as XML, it might be possible for an attacker to inject extra XML that the attacker would not normally control. Consider the following XML in which the attacker controls only the text Attacker Text:

<?xml version="1.0" encoding="UTF-8"?>
<USER role="guest">Attacker Text</USER>

What is an interesting test case to try as your input instead of Attacker Text? If developers aren’t cautious, they could mistakenly allow XML injection. If User1</USER><USER role=“admin”>User2 is the input, the following XML would be generated (user input is in bold text):

<?xml version="1.0" encoding="UTF-8"?>
<USER role="guest">User1</USER>
<USER role="admin">User2</USER>

If an application reads this file to determine what level of access to give each user, User2 would receive administrative privileges!

In addition to injecting data into the XML, it is possible to get code to run as a result of XML injection. XSL consists of XSL Transforms (XSLT), XML Path Language (XPath) expressions, and XSL Formatting Objects (XSL-FO) and allows a style sheet to be applied to an XML file. This style sheet can transform existing XML data to new XML data. This new XML document is often HTML that is rendered in the Web browser. In this situation, an attacker can inject data that would result in script running in the browser. For example, the following XML is part of an RSS feed that renders a hyperlink:

<link>Attacker Text</link>

To render the preceding XML, an XSLT is applied to return the following HTML to the Web browser:

<A HREF="Attacker Text">Attacker Text</A>

Can you think of a way to run script if you control the text Attacker Text? Even if the programmer HTML-encodes the attacker-supplied text, a scripting protocol can be used to run script with input such as javascript:alert(). If the HTML is rendered within a site or zone that is different from the origin of the RSS feed, this is an HTML scripting attack that occurs through XML data.

XPath and XQuery are languages that allow querying an XML document in ways similar to SQL. In fact, many popular databases allow querying the database using XPath or XQuery. In many scenarios, an attacker cannot access the XML data directly, but some part of the attacker’s data is used to create an XPath or XQuery statement to query the XML. An attacker can carefully construct input to inject arbitrary queries to retrieve data that the attacker would not normally be allowed to access.

An XML file can contain several different pieces or fields of information. Sometimes only certain parts should be exposed to the end user. For example, the following XML contains our names and social security numbers:

<?xml version='1.0'?>
<staff>
  <author>
    <name>Tom Gallagher</name>
    <SSN>123-45-6789</SSN>
  </author>
  <author>
    <name>Bryan Jeffries</name>
    <SSN>234-56-7890</SSN>
  </author>
  <author>
    <name>Lawrence Landauer</name>
    <SSN>012-345-6789</SSN>
  </author>
</staff>

This XML is stored in a location on a Web server not directly accessible to the end user. A Web page on the server that queries the XML is accessible to the end user. Only the author names should be displayed through the Web page. The XML data is retrieved using the following XPath expression:

//*[contains(name,'Attacker-Data')]/name

where Attacker-Data is data specified by the end user. As you can see, an attacker can control parts of the XPath query. By specifying x’)] | //*| //*[contains(name,‘y as the data, an attacker can return the entire contents of the XML file. This input creates the following XPath expression:

//*[contains(name,'x')] | //*| //*[contains(name,'y')]/name

Notice that the pipe character (|) is used to represent the or operator and two forward slashes and an asterisk (//*) represents all nodes. The preceding XPath expression looks for any of the following three conditions:

Because the second condition returns all nodes, the attacker will receive all data from the XML file!

The second part of the SOAP specification (http://www.w3.org/TR/2001/WD-soap12-part2-20011217) describes how SOAP data can be encoded. Included in this part of the specification is information about SOAP arrays. A SOAP array of six integers looks like the following:

<unluckyNumbers xmlns:xs="http://www.w3.org/2001/XMLSchema"
                   xmlns:enc="http://www.w3.org/2001/12/soap-encoding"
                   enc:arrayType="xs:int[6]" >
  <number>4</number>
  <number>8</number>
  <number>15</number>
  <number>16</number>
  <number>23</number>
  <number>42</number>
</unluckyNumbers>

Some servers allocate memory to prepare for the array following the array size specification (int[6] in the preceding example). This allows for a potential DoS where the attacker specifies a large size that results in the server consuming large amounts of memory. For example, you can test for this condition by using XML similar to the preceding example, but by specifying the array size is 500,000.

As previously discussed, DTDs can be used to build strings dynamically on the victim’s machine and consume large amounts of memory. Just as many of the XML attacks discussed in this chapter apply to SOAP, XML bombs also apply. However, the SOAP 1.1 specification states that a SOAP message must not contain a DTD. Although this should make XML bombs nonexistent against SOAP, some programs parsing SOAP XML don’t disable DTDs. Microsoft learned the hard way about this. Amit Klein found that he could create XML bombs and send them to the .NET Framework to cause a DoS. Microsoft released an update (http://support.microsoft.com/default.aspx?kbid=826231) that allows disabling DTDs in SOAP messages.

If you test code that parses SOAP XML, it is worth testing to see if DTDs are allowed. If you don’t need to support DTDs, removing this functionality will help reduce your attack surface. If your application relies on another component such as the .NET Framework for SOAP XML parsing, verify that you have disabled DTD processing functionality if possible.