Page History

...

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

Note that the passwords must first be encrypted through a hashing function, so that they are not stored in the database in cleartext. See MSC18-J Store passwords using a hash function for more information.

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

...

If an attacker knows that Utah is a valid login ID, they can specify an input login ID such as:

Utah' or '1'='1

This would yield the following query string:

//users/user[login/text()='Utah' or '1'='1' and password/text()='xxxx' ]

The Since the '1'='1' is automatically true, and causes the password to is never be validated. Consequently the attacker is falsely logged in as user Utah, without having to know the password.

In order to comply with guideline MSC18-J Store passwords using a hash function, the passwords would have to be encrypted. Unfortunately, on many small systems, they are not, and so the password text added in the query string would match precisely what the user enteres. An attacker could supply a password such as:

' or '1'='1

This would yield the following query string:

//users/user[password/text()='xxxx' and login/text()='' or '1'='1' ]

This time, the '1'='1' tautology disables both login ID and password validation, and the attacker is falsely logged in without knowing a login ID or password.

Noncompliant Code Example

...

If passed the attack string for login described above, the evaluate() method call returns a set of all nodes the corresponding login node in the XML file, causing the login() method to return true and bypass any authorization.

...