Security - Java Coding Guidelines - page 26

</user>
<user>
<username>Busey</username>
<password>ad39b3c2a4dabc98</password>
</user>
</users>
The passwords are hashed in compliance with Guideline 13 , “ Store passwords using
a hash function . ” MD5 hashes are shown here for illustrative purposes; in practice, you
should use a safer algorithm such as SHA-256.
Untrusted code may attempt to retrieve user details from this file with an XPath state-
ment constructed dynamically from user input.
Click here to view code image
//users/user[username/text()='&LOGIN&' and
password/text()='&PASSWORD&' ]
If an attacker knows that Utah is a valid user name, he or she can specify an input such
as
Utah' or '1'='1
This yields the following query string.
Click here to view code image
//users/user[username/text()='Utah' or '1'='1'
and password/text()='xxxx']
Because the '1'='1' is automatically true, the password is never validated. Conse-
quently,theattackerisinappropriatelyauthenticatedasuser Utah withoutknowing Utah 's
password.
Noncompliant Code Example
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. This example is vulnerable to the attack described earlier. If the attack string de-
scribed earlier is passed to evaluate() , the method call returns the corresponding node
in the XML file, causing the doLogin() method to return true and bypass any authoriza-
tion.
Click here to view code image