the-web-application-hackers-handbook

172 Chapter 6 n Attacking Authentication
Although it is a necessary part of an effective authentication mechanism,
password change functionality is often vulnerable by design. Vulnerabilities
that are deliberately avoided in the main login function often reappear in the
password change function. Many web applications’ password change functions
are accessible without authentication and do the following:
n Provide a verbose error message indicating whether the requested username
is valid.
n Allow unrestricted guesses of the “existing password” field.
n Check whether the “new password” and “confirm new password” fields
have the same value only after validating the existing password, thereby
allowing an attack to succeed in discovering the existing password
noninvasively.
A typical password change function includes a relatively large logical decision
tree. The application needs to identify the user, validate the supplied existing
password, integrate with any account lockout defenses, compare the supplied
new passwords with each other and against password quality rules, and feed
back any error conditions to the user in a suitable way. Because of this, password
change functions often contain subtle logic flaws that can be exploited to
subvert the entire mechanism.
HACK STEPS
1. Identify any password change functionality within the application. If
this is not explicitly linked from published content, it may still be implemented.
Chapter 4 describes various techniques for discovering hidden
content within an application.
2. Make various requests to the password change function using invalid
usernames, invalid existing passwords, and mismatched “new password”
and “confirm new password” values.
3. Try to identify any behavior that can be used for username enumeration
or brute-force attacks (as described in the “Brute-Forcible Login” and
“Verbose Failure Messages” sections).
TIP If the password change form is accessible only by authenticated users
and does not contain a username field, it may still be possible to supply an
arbitrary username. The form may store the username in a hidden field, which
can easily be modified. If not, try supplying an additional parameter containing
the username, using the same parameter name as is used in the main
login form. This trick sometimes succeeds in overriding the username of the
current user, enabling you to brute-force the credentials of other users even
when this is not possible at the main login.