ABSTRACT

Writing unvalidated data into an XML document can allow an attacker to change the structure and contents of the XML.

EXPLANATION

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 might be able to insert extraneous tags and cause an XML parser to throw an exception. In more nefarious cases of XML injection, an attacker might 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 1:

Assume an attacker is able to control shoes in following XML.


<order>
<price>100.00</price>
<item>shoes</item>
</order>


Now imagine this XML is included in a back end web service request to place an order for a pair of shoes. Suppose the attacker modifies his request and replaces shoes with shoes</item><price>1.00</price><item>shoes. The new XML would look like:

<order> <price>100.00</price> <item>shoes</item><price>1.00</price><item>shoes</item></order>


When using SAX parsers, the value from the second <price> overrides the value from the first <price> tag. This allows the attacker to purchase a pair of $100 shoes for $1.

REFERENCES

[1] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A1 Injection

[2] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A2 Injection Flaws

[3] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A6 Injection Flaws

[4] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3810 CAT I

[5] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 91

[6] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.1, Requirement 6.5.2

[7] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.1

[8] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.6

[9] Standards Mapping - FIPS200 - (FISMA) SI