- Listen to our monthly AppSec Stats Flash podcast
- LEARN MORE
XML injection manipulates or compromises the logic of an XML application or service. The injection of unintended XML content and/or structures into an XML message can alter the intended logic of an application, and XML Injection can cause the insertion of malicious content into resulting messages/documents.
With a successful XML Injection attack, the attacker can steal the entire database, or can even log in as the administrator of the website. Other security issues such as XSS and DOS attack can be leveraged with malicious XML Injections.
Determining whether or not an application is potentially vulnerable to XML Injection will involve attempts to check if the application is sanitizing incoming data. This can be done by injecting characters that would break the expected syntax. If your input is not sanitized, the application will most likely return an error.
If your input is being used as an attribute like so:
You could try this:http://example.com/?id=5’
If the application is not sanitizing your input, then this would break the XML syntax potentially causing an error to be returned to you. If you received an error indicative of this, you can move on to attempt some exploits.
*Example from confluence
Consider the request:
Now consider the following xml:
<item id="5" perItemPrice="50.00" quantity="1" />
We could try to manipulate the cost of this item like so:
Resulting in the following XML:
<item id="5" perItemPrice="0.00" quantity="10" />
<item id="5" perItemPrice="50.00" quantity="0" />
You can see here how our injectin has created a new line in the XML document which could be processed.
*example from owasp
Let’s say the XML database is set up to store users like so:
We then have a request like so:
What we want to try to do is assign the user Thomas with an ID of 0, which is often the id assigned to the administrator account. Let’s say we inject the following:
http://www.example.com/create_user.php?name=thomas&password=hfdj7!dn</password><!--&mail=--><id>0</id><mail>[email protected] This will comment out the id and the first mail tag, leaving you to inject your own id value.
<mail>=--><id>0</id><mail>[email protected] </mail>
From here, you will be able to log in with the privileges assigned to user with id 0.
XSS can be exploited in via the CDATA section in a XML document. This area is treated as character data and will therefore not be picked up as markup in the XML parser.
For example, let’s say the application is using the following XML to generate HMTL markup:
<mail><![CDATA[<$mail]]></mail> An attacker could inject a script tag like so: <mail><![CDATA[<]]>script<![CDATA[>]]></mail>
In a HTML document this would result in <script> rendering, and from here you could build your injection.
Example taken from: http://projects.webappsec.org/w/page/13247002/XML%20Entity%20Expansion
The XML Entity expansion attack, exploits a capability in XML DTDs that allows the creation of custom macros, called entities, that can be used throughout a document. By recursively defining a set of custom entities at the top of a document, an attacker can overwhelm parsers that attempt to completely resolve the entities by forcing them to iterate almost indefinitely on these recursive definitions.
The malicious XML message is used to force recursive entity expansion (or other repeated processing) that completely uses up available server resources. The most common example of this type of attack is the "many laughs" attack (some times called the 'billion laughs' attack).
<!DOCTYPE root [<!ENTITY ha "Ha !">
<!ENTITY ha2 "&ha; &ha;"><!ENTITY ha3 "&ha2; &ha2;">
<!ENTITY ha4 "&ha3; &ha3;">
<!ENTITY ha5 "&ha4; &ha4;">
...<!ENTITY ha128 "&ha127; &ha127;">
In the above example, the CPU is monopolized while the entities are being expanded, and each entity takes up X amount of memory - eventually consuming all available resources and effectively preventing legitimate traffic from being processed.
XML injection attack defenses should ensure user input is properly managed and sanitized before it is allowed to reach the main program code. The best approach is to consider all user input as unsafe and to properly monitor/sanitize this input.
All user input should be checked for the presence of special characters. Often, however, you will want to allow users to input special characters safely; for example, single quotes if they are needed for a surname. As you cannot simply strip these it is important that the application allows them but does not process them as part of the XML code itself.This can be achieved with the use of various XML libraries that can used to process and sanitize incoming user data.
Very detailed information on this: