Form Authentication settings enable you to scanning the pages on your website that require user authentication. When Form Authentication is configured, Netsparker tries to login to the website before beginning the crawling and attacking phase. Then, if Netsparker detects the session has ended, it will attempt to log in again during the scan.
- If you notice this happening repeatedly, it means that you have incorrectly configured the Form Authentication.
- If you do not fix the configuration, the scan duration can increase significantly and be prevented from progressing properly. In this article, we will talk about what causes this and how you can configure correctly.
In Netsparker Standard, you can view the login phase in the Activity Panel.
When the login process is successful, you will see a log similar to the following.
- If you notice that the Logs are listing too many logged in events during a scan, something is wrong, indicating that the scanner cannot retain a logged in session.
- What is happening is that:
- Netsparker somehow logs out
- Netsparker is trying to re-login continuously, assuming that the session has ended
This topic explains how to analyze and solve these types of session problems.
Causes of Logout During Scanning
This section lists and explains the reasons why logout may happen during scanning. They include:
- Logout Buttons on the Website
- Pages That May Cause Logouts
- Change Password Pages
Logout Buttons on The Website
Netsparker simulates the activities of the end user during a scan, navigating the pages on the site, filling out forms and clicking on buttons. This includes logout buttons for terminating the session on the site.
In the Scope section of the New Scan screen, you can define the URLs you want to exclude. Netsparker has a set of pre-settings in the Exclude URLs with RegEx section to exclude words that may be related to logout.
Although the default RegEx covers various logout and sign out expressions, it doesn’t cover pages such as disconnect.php. Therefore, Netsparker will visit those URLs and logout unless you exclude them manually.
For further information, see How to Configure the Scan Scope in Netsparker Standard.
Excluding Buttons Using the CSS Selector
Since there isn’t a specific URL we can pinpoint here, we can use the CSS selector to exclude the buttons.
How to Exclude Buttons Using the CSS Selector in Netsparker Enterprise
- From the main menu, click Scan Policies, then the policy you want to edit.
- In the Exclude by CSS Selector field, use a CSS selector to define which element(s) should be excluded from the scan. All matched elements will be excluded with their children. To test this, please try your selector in Chrome using
How to Exclude Buttons Using the CSS Selector in Netsparker Standard
- Launch the Scan Policy Editor dialog.
- Click New or Clone. (See Overview of Scan Policies)
- In the Exclude by CSS Selector field, click the ellipsis (). The Exclusion CSS Selector dialog is displayed.
- Use a CSS selector to define which element(s) should be excluded from the scan. If you need to use multiple selectors at once, separate them with commas.
- Click Select. You are returned to the Scan Policy Editor dialog.
- Click OK.
Pages That May Cause Logouts
When Form Authentication is configured, Netsparker will also attack it if the URL in which the login process takes place is in the Scope of the scan. Some websites end all existing sessions when the login page is called. If your site does this, you should exclude the login URL from the Scan Scope, to ensure Netsparker does not visit the login page during the scan. However, in order to make sure that you do not miss anything on the login page, you can run a scan without setting Form Authentication.
Change Password Pages
Netsparker simulates user behavior, so if your site has change password forms, Netsparker will try to fill in these forms with defined values and send them. Netsparker will also attack these entry points.
It is usual behaviour for the password change pages to ask for the current password as a matter of security. But if your site does not have such a structure, Netsparker may change the password of the current user. The result of this is that Netsparker is unable to login again. If your site has such pages, it is useful to exclude relevant URLs before initiating the scan.
How Does Logout Detection Work?
Netsparker uses two methods to determine whether a logout has occurred:
- Redirect Based Logout Detection
- Keyword Based Logout Detection
A third option involves shutting down the Logout detection mechanism.
Redirect Based Logout Detection
In order to detect the logout mechanism, Netsparker makes a request to the login page without a logged in session. If the page redirects Netsparker to a different page, Netsparker deduces that every time it encounters that redirected page, it has been logged out from the current session.
Sometimes, we need to interfere with Redirect URL Pattern. For example, if we send a request to dashboard.php without a session, we will be redirected to this URL:
The purpose of the site is to redirect the user to the page in the
return_url parameter after logging in.
Let's say that Netsparker detects this parameter for the login URL mentioned above. Then, the session somehow ended when it visited the contact.php page. In this instance, the site would redirect to this URL:
But this doesn't match the Redirect URL Pattern Netsparker caught before. This time Netsparker will not realize that the logout took place, and the scan will end earlier than it should. To solve this problem, we need to update the Redirect URL Pattern using the wildcard character.
This means that, whatever value the
return_url parameter is, Netsparker will successfully detect the logout.
Keyword Based Logout Detection
Keyword Based Logout Detection is a mechanism that determines whether a logout has occurred when it detects certain keywords in an HTTP response. These keywords are not on the login page, but on the page that is logged out.
Netsparker will make suggestions to you automatically based on the patterns on the page, but you can also configure them manually.
You can also use regular expressions in the keywords. If you do, you must enable the Is Regex? option next to the keyword pattern.
We have to make sure that the keywords that we defined are only found on the logout page. Because if these words appear in any URL during scanning, Netsparker will attempt to log in again, assuming that a logout has already happened. Instead of using generic keywords, you will get better results by using RegEx expressions.
For example, instead of specifying the username as a keyword, if we specify a RegEx expression instead, this provides a stricter match:
The reason is that username is a generic keyword, so it can be on any other page. This causes Netsparker to log in again, even if there is no logout.
If your keyword patterns match the .js and .css files, and you experience a logout problem, you can exclude the URLs that contain these files. When you exclude .js and .css files, Netsparker will continue to request these files to make the site fully functional, but it will not detect the logout.
We recommend that you use the Redirect Based Logout Detection method if your site has a Redirect Based structure, because it is difficult to make sure that the keywords you may use are not already on the pages that are logged in.
If none of these logout detection methods fit the structure on your website, or cause problems, you can disable logout detection by selecting None. Also, make sure that the pages that could cause logout are excluded because otherwise Netsparker will continue operating even if the session ends.
Logout problems interfere with efficient security scanning. They can extend scan time and make scan results less accurate. If you are experiencing logout problems, the solutions provided here should help to ensure Netsparker retains the logged in session prior to crawling and scanning. This will reduce your scan time and ensure that the website is scanned properly. But if you are still experiencing logout problems, please contact firstname.lastname@example.org.