This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Testing for User Enumeration and Guessable User Account (OWASP-AT-002)"

From OWASP
Jump to: navigation, search
(Brief Summary)
Line 3: Line 3:
  
 
== Brief Summary ==
 
== Brief Summary ==
The scope of this test is to verify if is possible to collect a set of valid users interacting with the authentication mechanism of the application. This test will be usefull for the brute force testing in which we verify if given a valid username it is possible to find a valid password.  
+
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 the web applications are not properly configured, or we have an application that will reveal when a username already exists on system. In fact, sometimes when we submit wrong credentials to application, we receive a message that username is present on the system, or password is wrong. In other case we receive a defined error message that can be reveal if username is present on system or not.
+
Often, web applications reveal when a username exists on system, either as a consequence of a misconfiguration or of 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 attacker, to gain a list of users on system that can be used to attack the web application, for example through a brute force or default username/password.
+
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.
 
<br>
 
<br>
 +
 
== Description of the Issue ==  
 
== Description of the Issue ==  
 
The tester should interact with the authentication mechanism of the application to understand if sending particular request the application answer in a different manner. In some case we can receive a message that reveal if the wrong credential is for an invalid username or invalid password. Sometimes we can enumerate the users sending a username without send any password.  
 
The tester should interact with the authentication mechanism of the application to understand if sending particular request the application answer in a different manner. In some case we can receive a message that reveal if the wrong credential is for an invalid username or invalid password. Sometimes we can enumerate the users sending a username without send any password.  

Revision as of 06:22, 18 August 2008

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 of 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 request the application answer in a different manner. In some case we can receive a message that reveal if the wrong credential is for an invalid username or invalid password. Sometimes we can enumerate the users sending a username without send any password.

Black Box testing and example

In a black box testing we know nothing about 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 reveal directly or indirectly the some information for enumerating users.
Testing for Valid user/right password
Record the server answer when you submit valid username and valid password.
Result Expected:
Using WebScarab notice the information retrieved from this successful authentication (HTTP 200 Response, lenght 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 server answer.
Result Expected:
From the browser we will expect the following messsage:
AuthenticationFailed.png
Using WebScarab notice the information retrieved from this not successful authentication (HTTP 200 Response, lenght of the response).
Testing for a not existing username
Now, the tester should try to insert a not valid 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 Not Existing Username we can receive a message similar to:
Userisnotactive.png
or message such as : "Login failed for User foo: invalid Account"
The application should response with the same error message and lenght to the different wrong requests. If you notice that the answer are not the same, you should investigate and find out the key that create 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 regnognized'

The above answers let the client to understand that for the first request we hold a valid user name. So we can interact with the application requesting a set of possible username and observing the answer.
Looking at the second server answer, 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.

Others 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 Title

In some case, for example, we can receive useful information on Title of web page, where we can obtain a specific error code or messages that reveal if the problems are on username or password.

Pay attention The problems with user enumerating is the risk of locking out accounts after a predefined numbers of probe (based on application policy), or sometimes our IP address can be filtered by a dynamic rules on firewall.

Gray Box testing and example

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

References

Whitepapers
...
Tools