Page History

XML can be used for data storage in a manner similar to a relational database. Data is frequently retrieved from such an XML document using XPaths. XPath injection can occur when data supplied to an Xpath XPath retrieval routine to retrieve data from an XML document is used without proper sanitization. This attack is similar to SQL injection or XML injection (see the appropriate parts of IDS00-J. Sanitize untrusted data passed across a trust boundary) where whereby an attacker can enter valid SQL or XML constructs in the data fields of the query in use. In typical attacks, the conditional field of the query resolves to a tautology or otherwise gives the attacker access to privileged information.

...

Consider the following XML schema.:

<users>
  <user>
    <username>Utah</username>
    <password>C^f3</password>
  </user>
  <user>
    <username>Bohdi</username>
    <password>C@fe</password>
  </user>
  <user>
    <username>Busey</username>
    <password>cAf3</password>
  </user>
</users>

Untrusted code may attempt to retrieve user details from this file with an XPath statement constructed dynamically from user input.:

//users/user[username/text()='&LOGIN&' and password/text()='&PASSWORD&' ]

If an attacker knows that Utah is a valid user name, they he or she can specify an input such as the following:

Utah' or '1'='1

...

Compliance with MSC51-J. Store passwords using a hash function requires encrypting the passwords. Unfortunately, many small systems fail to comply with MSC51-J, so the password text added in the query string would match precisely what the user enters. An attacker could supply a password such as:

' or '1'='1

This would yield the following query string:

...

This noncompliant code example reads a user name and password from the user and uses them to construct the query string. The password is passed as a char array, and then hashed,  to comply with MSC51-J. Store passwords using a hash function and MSC63-JG. Limit the lifetime of sensitive data.

This example is vulnerable to the attack described aboveearlier. If it is passed the attack string for username described previously, the evaluate() method call returns the corresponding node in the XML file. This causes the doLogin() method to return true and bypass any authorization.

...

• Treat all user input as untrusted, and perform appropriate sanitization.
• When sanitizing user input, verify the correctness of the data type, length, format, and content. For example, use a regular expression that checks for XML tags and special characters in user input. This practice corresponds to input sanitization. See  IDS51-JG. Prevent code injection for additional details.
• In a client-server application, perform validation at both the client and the server sidesides.
• Extensively test applications that supply, propagate, or accept user input.

...

Related Guidelines

Bibliography

...