the-web-application-hackers-handbook

806 Chapter 21 n A Web Application Hacker’s Methodology
4.2 Test Password Quality
4.2.1 Review the application for any description of the minimum quality rules
enforced on user passwords.
4.2.2 Attempt to set various kinds of weak passwords, using any self-registration
or password change functions to establish the rules actually enforced.
Try short passwords, alphabetic characters only, single-case characters
only, dictionary words, and the current username.
4.2.3 Test for incomplete validation of credentials. Set a strong and complex
password (for example, 12 characters with mixed-case letters, numerals,
and typographic characters). Attempt to log in using different variations
on this password, by removing the last character, by changing a
character’s case, and by removing any special characters. If any of these
login attempts is successful, continue experimenting systematically to
identify what validation is actually being performed.
4.2.4 Having established the minimum password quality rules, and the extent
of password validation, identify the range of values that a passwordguessing
attack would need to employ to have a good probability of
success. Attempt to locate any built-in accounts that may not have been
subject to the standard password complexity requirements.
4.3 Test for Username Enumeration
4.3.1 Identify every location within the various authentication functions
where a username is submitted, including via an on-screen input field,
a hidden form field, or a cookie. Common locations include the primary
login, self-registration, password change, logout, and account recovery.
4.3.2 For each location, submit two requests, containing a valid and an invalid
username. Review every detail of the server’s responses to each pair of
requests, including the HTTP status code, any redirects, information
displayed on-screen, any differences hidden in the HTML page source,
and the time taken for the server to respond. Note that some differences
may be subtle (for example, the same error message may contain minor
typographical differences). You can use the history function of your
intercepting proxy to review all traffic to and from the server. WebScarab
has a function to compare two responses to quickly highlight any differences
between them.
4.3.3 If you observe any differences between the responses where a valid and
invalid username is submitted, repeat the test with a different pair of
values and confirm that a systematic difference exists that can provide
a basis for automated username enumeration.