CWE Glossary
- CWE-22: Path Traversal
- CWE-78: OS Command Injection
- CWE-79: Cross-Site Scripting
- CWE-89: SQL Injection
- CWE-90: LDAP Injection
- CWE-91: XML Injection
- CWE-94: Code Injection
- CWE-98: PHP File Inclusion
- CWE-113: HTTP Response Splitting
- CWE-119: Buffer Errors
- CWE-130: Improper Handling of Length Parameter Inconsistency
- CWE-193: Off-by-one Error
- CWE-200: Information Exposure
- CWE-211: Information Exposure Through Externally-Generated Error Message
- CWE-236: Improper Handling of Undefined Parameters
- CWE-276: Incorrect Default Permissions
- CWE-284: Improper Access Control
- CWE-285: Improper Authorization
- CWE-287: Improper Authentication
- CWE-297: Improper Validation of Certificate with Host Mismatch
- CWE-306: Missing Authentication for Critical Function
- CWE-312: Cleartext Storage of Sensitive Information
- CWE-345: Insufficient Verification of Data Authenticity
- CWE-352: Cross-Site Request Forgery
- CWE-384: Session Fixation
- CWE-427: Uncontrolled Search Path Element
- CWE-434: Unrestricted Upload of File with Dangerous Type
- CWE-476: NULL Pointer Dereference
- CWE-521: Weak Password Requirements
- CWE-601: Open Redirect
- CWE-611: Improper Restriction of XML External Entity Reference ('XXE')
- CWE-613: Insufficient Session Expiration
- CWE-618: Exposed Unsafe ActiveX Method
- CWE-671: Lack of Administrator Control over Security
- CWE-798: Use of Hard-coded Credentials
- CWE-799: Improper Control of Interaction Frequency
- CWE-822: Untrusted Pointer Dereference
- CWE-835: Infinite Loop
- CWE-918: Server-Side Request Forgery (SSRF)
- CWE-942: Overly Permissive Cross-domain Whitelist
CWE is a trademark of the MITRE Corporation.
XML Injection [CWE-91]
XML Injection weakness describes improper neutralization of special elements used in XML queries.
Created: February 23, 2013
Latest Update: December 28, 2020
Table of Content
- Description
- Potential impact
- Attack patterns
- Affected software
- Mitigations
- Severity and CVSS Scoring
- References
Want to have an in-depth understanding of all modern aspects of XML Injection [CWE-91]? Read carefully this article and bookmark it to get back later, we regularly update this page.
1. Description
A variety of popular software (Apache Tomcat, OpenOffice, Microsoft Office, IM Jabber, Zend Framework, IBM WebSphere) uses eXtensible Markup Language (XML) to communicate with back-end servers, authenticate users, store information, etc. XML data structure is used in plenty of protocols, such as XML-RPC, SOAP, Jabber, WDDX, XMI.
To demonstrate XML injection weakness we will use a simple application that creates new users. The XML file with user credentials should look as follows:
XML file
- <?xml version="1.0" encoding="ISO-8859-1"?>
- <users>
- <user>
- <username>admin</username>
- <password>VeryStrongP@ssw0rd</password>
- <userid>1</userid>
- <groupid>1</groupid>
- <email>admin@mysite.com</email>
- </user>
- <user>
- <username>user</username>
- <password>weakpass</password>
- <userid>500</userid>
- <groupid>10</groupid>
- <email>user@mysite.com</email>
- </user>
- </users>
Registration form
- <form name="frm" method="post" action="">
- <p>Username: <input type="text" name="login"></p>
- <p>Password: <input type="password" name="passwd"></p>
- <p>Email: <input type="text" name="login"></p>
- <p><input type="submit" value="Log In" name="btLogin"></p>
- </form>
Let's assume that application assigns privileges based on group membership. In this case, we have to modify the resultant XML file during registration and add new user to group #1. To achieve this, we must provide the following data:
Username: attacker
Password: password</password><!--
E-mail: --><userid>10000</userid><groupid>1</groupid><mail>attacker@attacker.com
Once executed the XML file will look like this:
- <?xml version="1.0" encoding="ISO-8859-1"?>
- <users>
- <user>
- <username>admin</username>
- <password>VeryStrongP@ssw0rd</password>
- <userid>1</userid>
- <groupid>1</groupid>
- <mail>admin@mysite.com</mail>
- </user>
- <user>
- <username>user</username>
- <password>weakpass</password>
- <userid>500</userid>
- <groupid>10</groupid>
- <mail>user@mysite.com</mail>
- </user>
- <user>
- <username>attacker</username>
- <password>password</password> <!--
- <userid>500</userid>
- <groupid>10</groupid>
- <mail>--><userid>10000</userid><groupid>1</groupid><mail>attacker@attacker.com</mail>
- </user>
- </users>
The provided result will be as follows:
- SimpleXMLElement Object
- (
- [user] => Array
- (
- [0] => SimpleXMLElement Object
- (
- [username] => admin
- [password] => VeryStrongP@ssw0rd
- [userid] => 1
- [groupid] => 1
- [mail] => admin@mysite.com
- )
- [1] => SimpleXMLElement Object
- (
- [username] => user
- [password] => weakpass
- [userid] => 500
- [groupid] => 10
- [mail] => user@mysite.com
- )
- [2] => SimpleXMLElement Object
- (
- [username] => attacker
- [password] => password
- [comment] => SimpleXMLElement Object
- (
- )
- [userid] => 10000
- [groupid] => 1
- [mail] => attacker@attacker.com
- )
- )
- )
As you can see, the new user is member of the first group. So, we successfully injected XML code and achieved the needed result.
2. Potential impact
As for any code injection, potential impact depends on vulnerable application and its functionality. An attacker might be able to gain access to potentially sensitive information, modify or delete data and elevate privileges within the application. XML Injection can be used in XXE attacks to gain access to internal networks, gather sensitive information, perform port scans, etc. In a worst-case scenario this weakness could result in full system compromise.
3. Attack patterns
According to CAPEC there are following attack patterns for this weakness:
- CAPEC-83: XPath Injection
- CAPEC-99: XML Parser Attack
- CAPEC-250: XML Injection
Another classification from WASC gives the following attack techniques:
- WASC-23: XML Injection
- WASC-39: XPath Injection
- WASC-43: XML External Entities
- WASC-41: XML Attribute Blowup
4. Affected software
Extensible Markup Language is integrated in a variety of client/server applications and protocols. Software that uses XML-based protocols might be potentially vulnerable to this weakness.
5. Mitigations
Possible protection mechanisms against XML injections depend on validation of external input. When developing application pay extra attention to supplied input data. Programmers can use regular expressions to validate untrusted input. The following regular expression can limit the scope of potential attacks by allowing only numbers and letters:
/[^0-9a-z]/i
Perform filtration of output information as an additional level of security.
6. Severity and CVSS Scoring
XML injections weaknesses can influence confidentiality, integrity and availability of the application. Depending on application’s functionality, an attacker might be able to read, modify, delete information stored in XML files or even elevate privileges within the application.
In case of information disclosure for unprivileged user, this weakness should be scored as:
5.3 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N] – Medium severity.
In case of unauthorized data manipulation, this weakness should be scored as:
6.5 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L] – Medium severity.
In case of authentication bypass and privilege escalation, this weakness can be scored as:
9.8 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H] – Critical severity.
7. References
- CWE-91: XML Injection (aka Blind XPath Injection) [cwe.mitre.org]
- Testing for XML Injection (OWASP-DV-008) [www.owasp.org]
- XML Injection [clawslab.nds.rub.de]
Copyright Disclaimer: Any above-mentioned content can be copied and used for non-commercial purposes only if proper credit to ImmuniWeb is given.
↑ Back to Top