Testing XML-Specific Attacks
Attacks specific to XML should be considered whenever an attacker controls XML input or input that is used to create XML. Many of these attacks take advantage of specific XML functionality. The following sections briefly describe various aspects of XML and related functionality in addition to details of the associated security concerns. For a more detailed discussion of these aspects and other XML functionality, please consult the XML specification ( http://www.w3.org/TR/REC-xml ).
Entities
Similar to a predefined character entity reference where > represents the right angle bracket ( > ), DTD schemas allow entities where user -defined names and replacement text can be created to provide an easy way to represent text of choice. When an XML parser encounters an entity, the entity name is replaced with its replacement text. C/C++ programmers will find this similar to the notion of #define . The string New Orleans, Louisiana can be represented as nola by using the following XML:
<!ENTITY nola "New Orleans, Louisiana">
where nola is the entity name and New Orleans, Louisiana is the replacement text. XML also allows entities to reference the contents of files defined by a URL. For example, the contents of http://www.microsoft.com/windowsxp/pro/eula.mspx can be represented as eula with the following XML:
<!ENTITY eula SYSTEM "http://www.microsoft.com/windowsxp/pro/eula.mspx">
Three attacks related to entities are infinite entity reference loops , XML bombs , and external entity attacks.
Infinite Entity Reference Loops
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 '%zz;'> <!ENTITY % zz '%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 .
| Tip | This example uses the percent sign (%) in the entity declaration. This is called a parameter entity . These entities can be used only within the DTD. |
XML Bombs
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.
| Important | XML bombs are a form of decompression bombs. Decompression bombs are discussed in Chapter 14. |
| Tip | Another important DoS test case to attempt against an application that allows XML input is to include complex XML as input. Complex XML includes XML data that contains a document structure that is heavily nested. The complex structure often requires more processing and memory when compared to a less complex XML structure of the same size . |
External Entities
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:\dir\SecretPlans.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.
| Important | XXE attacks aren t limited to accessing the contents of the victim s local hard disk. Because URLs are used to reference the external entity, any URL, including http URLs, that the victim can access, the attacker can then access. This could be used to access Web servers behind a firewall, a Web site on which the victim has been authenticated, and so on. |
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 Injection
XML is vulnerable to attacks similar to the HTML script injection issues discussed in Chapter 10 where output contains attacker-supplied data. Three common XML injection attacks are XML data injection, Extensible Stylesheet Language Transformations (XSLT) injection, and XPath/XQuery injection.
XML Data Injection
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!
| Tip | If you are able to inject data into part of the XML, it is worth attempting to send duplicate elements and attributes specified in the earlier part of the XML that you couldn t control. Some XML parsers will take the last instance of the element/attribute, so you might be able to overwrite the previous values with those of your choice. |
Extensible Stylesheet Language (XSL)
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.
| Important | When testing for XML injection, try sending angle brackets and quotation marks to escape out of the current XML attribute/tag. A correctly protected application will not allow user-supplied data to escape from XML tags or attributes to prevent XML injection. Generally, the same test cases that applied to script injection and cross-site scripting (XSS) apply to XML injection. |
XPath/XQuery Injection
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:
-
Any name that contains x
-
Any node in the XML file
-
Any name that contains y
Because the second condition returns all nodes, the attacker will receive all data from the XML file!
| More Info | For more information about XPath injection, see Amit Klien s paper Blind XPath Injection at https ://www.watchfire.com/securearea/whitepapers.aspx?id=9 . |
| Tip | The same concepts used in XPath/XQuery injection apply to SQL. SQL injection is discussed in depth in Chapter 16, SQL Injection . |
Large File References
XML files can reference other files specified by a URL. Sometimes the parser will load and parse these files. Two examples of file references are schemas and XML signatures. An attacker can send XML to the victim s machine and reference additional files in that XML. The additional files can be extremely large in size and consume resources on the victim s machine if that file is parsed. For example, an attacker might specify the following XML fragment in hopes that the parser visits http://server/file.html containing a large amount of data and computes the digest on the large file:
<Reference URI="http://server/file.html"> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <DigestValue>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue> </Reference>
EAN: 2147483647
Pages: 156