Testing for User Enumeration and Guessable User Account (OWASP-AT-002)

OWASP Testing Guide v3 Table of Contents

This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.

OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here

Brief Summary

The scope of this test is to verify if is possible to collect a set of valid usernames by interacting with the authentication mechanism of the application. This test will be useful for the brute force testing, in which we verify if, given a valid username, it is possible to find the corresponding password. Often, web applications reveal when a username exists on system, either as a consequence of a misconfiguration or as a design decision. For example, sometimes, when we submit wrong credentials, we receive a message that states that either the username is present on the system or the provided password is wrong. The information obtained can be used by an attacker to gain a list of users on system. This information can be used to attack the web application, for example, through a brute force or default username/password attack.

Description of the Issue

The tester should interact with the authentication mechanism of the application to understand if sending particular requests causes the application to answer in different manners. This issue can be exists because the information released from applications responds to a valid username differently than a username is invalid. In some cases, we can receive a message that reveals if the provided credentials are wrong because an invalid username or an invalid password was used. Sometimes, we can enumerate the existing users by sending a username and an empty password.

Black Box testing and example

In a black box testing, we know nothing about the specific application, username, application logic and error messages on login page, or password recovery facilities. If the applications is vulnerable, we receive a response message that reveals, directly or indirectly, some information useful for enumerating users.
Testing for Valid user/right password
Record the server answer when you submit a valid username and valid password.
Result Expected:
Using WebScarab, notice the information retrieved from this successful authentication (HTTP 200 Response, length of the response).
Testing for valid user/wrong password
Now, the tester should try to insert a valid username and a wrong password and record the error message generated by the application.
Result Expected:
From the browser we will expect the following messsage:

Using WebScarab, notice the information retrieved from this unsuccessful authentication attempt (HTTP 200 Response, length of the response).
Testing for a nonexistent username
Now, the tester should try to insert an invalid username and a wrong password and record the server answer (you should be confident that the username is not valid in the application). Record the error message and the server answer.

Result Expected:
If we enter a nonexistent username, we can receive a message similar to:

or a message such as "Login failed for User foo: invalid Account"
The application should respond with the same error message and length to the different wrong requests. If you notice that the responses are not the same, you should investigate and find out the key that creates a difference between the 2 requests. For example:

• Client request: Valid user/wrong password --> Server answer:'The password is not correct'
• Client request: Wrong user/wrong password --> Server answer:'User not recognized'

The above responses let the client understand that for the first request we have a valid user name. So we can interact with the application requesting a set of possible usernames and observing the answer.
Looking at the second server response, we understand in the same way that we don't hold a valid user name. So we can interact in the same manner and create a list of valid username looking at the server answers.

Other user enumeration tests
We can enumerate users in other several ways, such as: - Analyzing the error code received on login pages, or recovery facilities - Analyzing URLs and URLs redirections - Analyzing web page titles

In some case, for example, we can receive useful information from the title of web page, which, by using a specific error code or messages, reveals if the wrong component of the credentials is the username or the password.

Attention: by enumerating user accounts, you risk to lock out accounts after a predefined number of failed probes (based on application policy). Also, sometimes, our IP address can be banned by dynamic rules on the firewall.

Gray Box testing and example

Testing for Authentication error messages
Verify that the application answers in the same manner for every client request that produces a failed authentication. For this issue the Black Box testing and Gray Box testing are the same concept based on the analysis of messages or error codes received from web application.
Result Expected:
The application should answer in the same manner for every failed attempt of authentication.
For Example:
'Credentials submitted are not valid'

References

Whitepapers
...
Tools

• WebScarab: OWASP_WebScarab_Project