How to Avoid Account Lockouts When Scanning Web Applications

Organizations that use automated scanners to test the security of their web apps must watch out for instances where these tools may trigger user account lockouts inadvertently.  Here we explain why this occurs and offer some tips for how to prevent this from happening with Qualys Web Application Scanning (WAS).

Why Account Lockouts Occur

In order to have full access to a password-protected web application and test the entire site for vulnerabilities, the web application scanner needs to successfully log into the app. These are some reasons why some user accounts could be locked out as a result of a web application scan:

1. Crawling of password-reset forms
2. Enforcement of limit on invalid credentials by web server
3. Enforcement of single active session policy
4. Re-authentication attempts

How to Avoid Account Lockouts

Here’s how to avoid these four cases.

1. Crawling of Password-Reset Forms

Reset Form Type 1: Some web applications will allow you to reset the password of a valid user account by clicking on a “reset password” link, such as this hypothetical one: www.site1.com/resetPassword

If Qualys WAS encounters such a link during its scan, WAS will crawl and test it using a default username, such as “john.” If “john” also happens to be the actual username for a valid, active account of the app, a password reset process would be triggered. If the user was at that moment logged into the app, their session would be terminated and they’d be required to change their password before logging back in.

Reset Form Type 2: Some web applications will have a reset password form with only one input field to enter a new password. This form will be accessible only when a user is authenticated. In authenticated scans, WAS will test this form and change the password. After testing this form, the user gets locked out and the rest of the site cannot be scanned.

To work around these situations, WAS customers should blacklist password-reset forms.

2. Web Application Enforces Limit on Invalid Login Attempts

When web applications limit the number of invalid login attempts, the lockout could happen in two different parts of the scan. One is during the crawl phase when doing authentication and the other during the test phase when performing brute force login attempts.

Authentication Process

If we were scanning a hypothetical site — www.site1.com — that places limits on login attempts, we would find a login form at: www.site1.com/login

Let’s say we start a standard form authentication process with login attempts using invalid credentials four times before trying to log in with valid credentials. We will submit the login form with invalid credentials and save the responses. We will then submit the login form with valid credentials and compare the resulting pages between valid and invalid credential submissions. If the website has a restriction on the number of invalid credential submissions, we recommend authentication using a Selenium script. Selenium authentication will allow the scan to authenticate to the site and complete scanning without getting locked out.

Login Brute Force Testing: Lockout Due to Restriction on Number of Invalid Login Attempts

Login Brute Force (LBF) testing involves WAS trying to log in to the customer’s site using different combinations of common user names and passwords. During the LBF test phase, we will input our username/password combinations on the login prompt at www.site1.com/login and submit the form.

The web application could be configured to restrict the number of continuous login attempts to their site from a specific IP or against a specific user. In those cases, it might trigger a server error or refuse connections. If WAS is logged in using the credentials of a specific account, then the account’s user may not be able to login to the application and complete scanning the site successfully.

In this scenario, the customer should use the Brute Force configuration options in the Qualys Portal Application to work around the web application’s logic. Specifically, the customer should modify the ‘Options Profile’ in Qualys WAS to use either ‘Minimal’ or ‘Limited’.

Login Brute Force Testing: Lockout Due to Character Length Limit

Some web applications will report server errors for some of our login attempts because the usernames or passwords exceed a certain number of characters. In this scenario, our regular expression may not catch the server error and/or trigger an account lockout. In this scenario, we suggest customers disable LBF testing or use custom LBF login credentials which will not lock their site.

3. Single Active Session Enforcement

Some web applications limit the number of active sessions per user to one. In this scenario, after Qualys WAS finishes scanning the site, WAS might not completely log out, leaving an active session open. If the customer then tries to log in on their browser or launch another scan, depending on the way the web application is designed, designed, the account might get locked out.

Consider the customer site: www.site1.com. Let’s say the customer has an enforced limit of single session on jojo@site1.com.

If jojo@site1.com is logged in to their browser, then WAS won’t be able to log in to the site using this user’s credentials because the user’s session is already active. Alternatively, if jojo@site1.com isn’t logged in, then WAS would be able to launch an authenticated scan using this account’s login credentials. However, this means that the user won’t be able to log in while the scan is running, or even after it’s completed if WAS doesn’t log out. (In the latter case where WAS doesn’t exit the account right after the scan is completed, most web applications will at some point of inactivity terminate the session.)

In this scenario where accounts are limited to a single active session, we recommend a separate user account is created for WAS scan which will not be used by anybody else.

4. Re-authentication Attempts

Qualys WAS may not recognize the logout link on a customer’s site if the link doesn’t match our typical logout patterns. In such scenarios, WAS will crawl the logout link, lose its authentication and try to log back in. After numerous re-authentication attempts, the app could lock the account. In order to work around this scenario, customers should blacklist the logout link so that WAS ignores it.

In certain scenarios, the authentication may be lost due to dropped server connections, in which case WAS will try to re-authenticate to continue its scan. The web application could then lock the user account that has been employed to launch the authenticated scan. Sometimes servers drop connections either due to the intensity or number of requests. In order to get around this scenario, dial down the scan intensity to the lowest point or launch multiple scans, each with a limited number of tests enabled.