Skip to content

Latest commit

 

History

History
184 lines (74 loc) · 6.37 KB

Day 37 Task.md

File metadata and controls

184 lines (74 loc) · 6.37 KB

🎯 Day 37 Task

✅ 4.3.4 Testing for Account Enumeration and Guessable User Account

Test Objectives

  1. Review processes that pertain to user identification (e.g. registration, login, etc.).
  2. Enumerate users where possible through response analysis.

How to Test

In black-box testing, the tester knows nothing about the specific application, username, application logic, error messages on log in page, or password recovery facilities. If the application is vulnerable, the tester receives a response message that reveals, directly or indirectly, some information useful for enumerating users.

HTTP Response Message

Testing for Valid Credentials

Record the server answer when you submit a valid user ID and valid password.

Using a web proxy, notice the information retrieved from this successful authentication (HTTP 200 Response, length of the response).

Testing for Valid User with Wrong Password

Now, the tester should try to insert a valid user ID and a wrong password and record the error message generated by the application.

The browser should display a message similar to the following one:

Testing for Valid User with Wrong Password

Now, the tester should try to insert a valid user ID and a wrong password and record the error message generated by the application.

The browser should display a message similar to the following one: Authentication Failed

Testing for a Nonexistent Username

Now, the tester should try to insert an invalid user ID and a wrong password and record the server answer (the tester should be confident that the username is not valid in the application). Record the error message and the server answer.

If the tester enters a nonexistent user ID, they can receive a message similar to: This User is Not Active or a message like the following one

Generally the application should respond with the same error message and length to the different incorrect requests. If the responses are not the same, the tester should investigate and find out the key that creates a difference between the two responses. For example:

  1. Client request: Valid user/wrong password

  2. Server response: The password is not correct

  3. Client request: Wrong user/wrong password

  4. Server response: User not recognized

The above responses let the client understand that for the first request they have a valid username. So they can interact with the application requesting a set of possible user IDs and observing the answer.

Looking at the second server response, the tester understand in the same way that they don’t hold a valid username. So they can interact in the same manner and create a list of valid user ID looking at the server answers.

Other Ways to Enumerate Users - Testers can enumerate users in several ways, such as:

Analyzing the Error Code Received on Login Pages

Some web application release a specific error code or message that we can analyze.

Analyzing URLs and URLs Re-directions

For example:

http://www.foo.com/err.jsp?User=baduser&Error=0

http://www.foo.com/err.jsp?User=gooduser&Error=2

As is seen above, when a tester provides a user ID and password to the web application, they see a message indication that an error has occurred in the URL. In the first case they have provided a bad user ID and bad password. In the second, a good user ID and a bad password, so they can identify a valid user ID.

URI Probing

Sometimes a web server responds differently if it receives a request for an existing directory or not. For instance in some portals every user is associated with a directory. If testers try to access an existing directory they could receive a web server error.

Some of the common errors received from web servers are:

403 Forbidden error code

404 Not found error code

Example:

http://www.foo.com/account1 - we receive from web server: 403 Forbidden

http://www.foo.com/account2 - we receive from web server: 404 file Not Found

In the first case the user exists, but the tester cannot view the web page, in second case instead the user “account2” does not exist. By collecting this information testers can enumerate the users.

Analyzing Web Page Titles

Testers can receive useful information on Title of web page, where they can obtain a specific error code or messages that reveal if the problems are with the username or password.

For instance, if a user cannot authenticate to an application and receives a web page whose title is similar to:

  1. Invalid user
  2. Invalid authentication

Analyzing a Message Received from a Recovery Facility

When we use a recovery facility (i.e. a forgotten password function) a vulnerable application might return a message that reveals if a username exists or not.

For example, messages similar to the following:

  1. Invalid username: email address is not valid or the specified user was not found.
  2. Valid username: Your password has been successfully sent to the email address you registered with.

Friendly 404 Error Message

When we request a user within the directory that does not exist, we don’t always receive 404 error code. Instead, we may receive “200 ok” with an image, in this case we can assume that when we receive the specific image the user does not exist. This logic can be applied to other web server response; the trick is a good analysis of web server and web application messages.

Analyzing Response Times

As well as looking at the content of the responses, the time that the response take should also be considered. Particularly where the request causes an interaction with an external service (such as sending a forgotten password email), this can add several hundred milliseconds to the response, which can be used to determine whether the requested user is valid.

Guessing Users

CN000100
CN000101
...

Sometimes the usernames are created with a REALM alias and then a sequential numbers:

R1001 – user 001 for REALM1

R2001 – user 001 for REALM2

By enumerating user accounts, you risk locking out accounts after a predefined number of failed probes (based on application policy). Also, sometimes, your IP address can be banned by dynamic rules on the application firewall or Intrusion Prevention System.

Tools

BurpSuite/ZAP

Note - I am making notes from Official OWASP Website you can check it from here https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/

I am just Sharing what I learn for help Other's !!!

#infosec #learn365 #owasp