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

Jump to: navigation, search
(Black Box testing and example)
m (References)
Line 154: Line 154:
* CURL: http://curl.haxx.se/
* CURL: http://curl.haxx.se/
* PERL: http://www.perl.org
* PERL: http://www.perl.org
* Finger Google (module of Twister): http://sourceforge.net/projects/wf-twister/

Revision as of 03:26, 5 September 2008

OWASP Testing Guide v3 Table of Contents



Brief Summary


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 web application or web server, when we provide a valid username is different than we use an invalid usename.


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.

HTTP Response message
Testing for Valid user/right password

Result Expected:

Testing for valid user/wrong password

Result Expected:

or something like:

again any message that reveal the existence of user, for istance message similar to:

Login for User foo: invalid password


Testing for a nonexistent username

Result Expected:
or message like the following one:

Login failed for User foo: invalid Account




Other way to enumerate users
We can enumerate users in other several ways, such as:
- Analyzing the error code received on login pages

- Analyzing URLs, and URLs redirections
For example:


As we can see above, when we provides a userID and password to web application, we see a message indication that an error has occurred in the URL. In first case we has provides a bad userID and bad password, in second case instead a good user and bad password, so we can identify a valid userID.

- URI Probing
Sometime a web server responds differently if receive a request for an existing directories or not. For instance in some portals every users is associated with a directory, if we try to access to an exists directory we could be receive a web server error. A very common errors that we can receive from web server is:

  403 Forbidden error code 


  404 Not found error code



In first case the user exist, but we cannot view the web page, in second case instead the user “account2” doesn’t exist. Collecting this information we can enumerate the users.

- Analyzing Web page Title
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. For instance is common change a web title if we cannot authenticate to an application and receive a very clearly message similar to:

Invalid user
Invalid authentication

- Analyzing message received from recovery facilities
When we use a recovery facilities the applications that is vulnerable could be return a message that reveal if a username exist or not.

For example, message similar to the following:

Valid username: Your recovery password has been successfully sent

-Friendly 404 Error Message
Not always when we made a request for a user within the directory that is sure to not exist we receive 404 error code, we receive instead “200 ok” with an image, in this case we can assume that when we receive the specific image the users doesn’t exist. This logic can be applied to other web server response; the trick is a good analysis of web server and web application messages.

Guessing Users
In some case the userIDs are created with specific policies of administrator or company. For example we can view a users with a userID created in sequential order:
Sometimes the username are created with a REALM alias and then a sequential numbers:
R1001 – user 001 for REALM1
R2001 – user 001 for REALM2

Other possibilities are userIDs associated with credit card numbers, or in general a numbers with a pattern. In the above sample we can create simple shell scripts that compose a UserIDs and submit a request with tool like wget to automate a web query to discern valid userIDs. To create a script we can use also Perl and CURL

Again, we can guess a users from the information received from an LDAP query or from a google information gathering for example from a specific domain. Google for example can helps to find domain users through a specific queries or through a simple tools like finger google.

For other information about guessing userIDs see next paragraph 4.5.3 Testing for Guessable (Dictionary) User Account.

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 application 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:
For Example:

Credentials submitted are not valid