Testing for DoS Locking Customer Accounts (OWASP-DS-002)

The first case to consider involves the authentication system of the target application. A common defense to prevent brute-force discovery of user passwords is to lock an account from use after between three to five failed attempts to login. This means that even if a legitimate user were to provide their valid password, they would be unable to login to the system until their account has been unlocked. This defense mechanism can be turned into a DoS attack against an application if there is a way to predict valid login accounts.

Note, there is a business vs. security balance that must be reached based on the specific circumstances surrounding a given application. There are pros and cons to locking accounts, to customers being able to choose their own account names, to using systems such as CAPTCHA, and the like. Each enterprise will need to balance these risks and benefits, but not all of the details of those decisions are covered here. This section only focuses on testing for the DoS that becomes possible if lockouts and harvesting of accounts is possible.

Black Box Testing

The first test that must be performed is to test that an account does indeed lock after a certain number of failed logins. If you have already determined a valid account name, use it to verify that accounts do indeed lock by deliberately sending at least 15 bad passwords to the system. If the account does not lock after 15 attempts, it is unlikely that it will ever do so. If no account name has been determined at this point in the testing, the tester should use the methods below to attempt to discover a valid account name.

To determine valid account names, a tester should look to find places where the application discloses the difference between valid and invalid logins. Common places this would occur are:

1. The login page – Using a known login with a bad password, look at the error message returned to the browser. Send another request with a completely improbable login that should not exist along with the same bad password, and observe the error message returned. If the messages are different, this can be used to discover valid accounts. Sometimes the difference between responses is so minor that it is not immediately visible. Another way to check for this difference is to compare hashes of the HTTP response body from the server for both messages. Unless the server puts data that changes on each request into the response, this will be the best test to see if there is any change at all between the responses.
2. New account creation page – If the application allows people to create a new account that includes the ability to choose their account name, it may be possible to discover other accounts in this manner. What happens if you try to create a new account using an account name that is already known to exist? If this gives an error that you must choose a different name, this process may also be automated to determine valid account names.
3. Password reset page – If the login page also has a function for recovering or resetting a password for a user, look at this function as well. Does this function give different messages if you attempt to reset or recover an account that does not exist in the system?

Once an attacker has the ability to harvest valid user accounts, or if the user accounts are based on a well-defined, predictable format, it is an easy exercise to automate the process of sending three to five bad passwords to each account. If the attacker has determined a large number of user accounts, it is possible for them to deny legitimate access to a large portion of the user base.

White Box Testing

If access to the source code is available, look at the code logic related to the functions mentioned in the Black Box testing section. The login pages and the account creation pages are the most frequent location where valid login identities may be harvested. Things to focus upon:

1. If account names are generated by the system, what is the logic used to do this? Is the pattern something that could be predicted by a malicious user?
2. Determine if any of the code that handles initial authentication, any re-authentication (if for some reason it is different logic than the initial authentication), password resets, password recovery, etc. differentiate between an account that exists and an account that does not exist in the errors it returns to the user.

Some applications are developed with a single configuration file that contains a mapping of error codes to text strings that will be sent to the user in the event an error condition occurs. If the application being reviewed has a file of this type, it should be carefully screened to look for error messages that would distinguish between the valid and invalid account types.

OWASP Testing Guide Table of Contents