Scanning Web Applications That Require Authentication

Web applications that manage sensitive data are usually protected with either basic or form-based authentication. Nessus can be configured with the appropriate credentials for these authentication schemes as they relate to web application testing. This post covers these authentication schemes in-depth, and explores some of the potential problems you may experience when scanning with credentials and how to overcome them.

Basic Authentication

For web applications, or sections of web applications, that require basic authentication, you can enter one username and password pair that Nessus can use each time it is prompted for credentials. On the "Advanced" tab in the "Login configurations" section, enter the desired username and password in the "HTTP account" and "HTTP password" fields as shown below.

It is important to note that the password in this case could be sent in clear-text, or most likely Base64 encoded depending on the encryption method implemented by the web server. When a scan is initiated, Nessus will use the credentials specified to login to any web site requiring basic authentication. For example, a WRT54G router, that uses basic authentication on the administrative web page was scanned and the following CGI was discovered:

Without successful authentication, none of these pages and CGI programs would be tested for vulnerabilities. In this case, you must also direct Nessus to test for the embedded web server, as the WRT54G will be identified as such. This configuration setting is located on the "Advanced" tab in the "Web application test settings", and is called "Test embedded web servers."

Form Based Authentication

The authentication for a web application is often embedded into the site using an HTML form and sent to the web server using a POST request, preferably over HTTPS. To provide an example of how to configure Nessus to authenticate using HTML forms, the web application called "Damn Vulnerable Web App" (DVWA) was scanned using Nessus. The first step was to review the site's login page and understand how it works. Browsing to the URL of the application presents the following form:

There are two ways to collect the information about the login form in order to configure Nessus to login for the scan: analyze the HTML source code or perform a packet capture and analyze the results. First, let's review how to read the HTML source code and map the form fields in the HTML to the Nessus configuration that resides in the "Adavanced" tab under "HTTP login page". The login page for the application contains the following elements:

The form action is the file in the web application that is called to perform the actual authentication. This may differ from the page that is serving the form itself, so you must enter this into the Nessus configuration in the "Login form" field. Do not forget to supply a fully qualified path and include a leading "/". In this case the "Login form" value will be "/dvwa/login.php".

The following lines show the username and password fields that will be entered into the "Login form fields" field:

Within the "input" tag look for the label "name=" and use that as the label for the username and password parameters. The parameter values are set with the "=" and separated by the "&" character.

Sidebar Discussion: HTML Form Autocomplete The autocomplete feature for HTML form fields was first introduced (and supported) in the Microsoft Internet Explorer web browser, version 5. It allows the browser to remember the values that were entered into form fields and auto completes them for the user. This can be a useful feature when entering information into various forms, as typically the end user is prompted for the same information across multiple sites (e.g., Name, Address, Email Address). However, when applied to password fields, it can pose a security risk as the password will be stored in the browser Tenable's Passive Vulnerability Scanner (PVS) (and Nessus via the web mirror plugin) can detect this condition. If PVS sees a browser accessing a page coded without "autocomplete" disabled on password fields it will generate an alert: While this is considered a "Medium" level vulnerability (with a CVSS score of 4.3, the most critical being 10) it should be addressed by web application developers.

The username and password parameters can be entered as follows into the Nessus configuration:

However, there may be other parameters required before a login request is accepted. Further searching through the source code of the login page reveals an additional input parameter:

This must be added to the request before the application will accept it. Now the full request will look as follows:

In the NessusClient, the final configuration for all parameters in the Nessus configuration is:

If the form information is somehow not available, or it is not working because the authentication sequence is more complex and additional parameters need to be set, you can gather the same information from a packet capture. A libpcap file containing the packet capture information from the login process was opened using Wireshark to analyze the parameters:

The first task is to filter the packet capture so that only HTTP POST requests are shown. This allows the login requests of the application to be analyzed, hiding all other requests and responses. The filter to accomplish this is "http.request.method matches "POST"". One packet is displayed as a result of the filter. By expanding the HTTP header information the login form values are displayed just after the "POST" command. The final piece of information needed is the data from the request, which represents all of the parameters and associated values. This information can be used to configure Nessus the same way as when the source code was analyzed.

Excluding Specific Pages

Once a scan has been properly configured with credentials, it will test the parameters inside the application that are available to authenticated users. Problems can arise in several areas, as this means that the web spider (webmirror.nasl) will try to find all of the pages within that application by visiting the links on each page discovered. The first problem encountered when scanning DVWA was the logout functionality. Since the mechanism to logout is simply a link, when the web spider runs it will "click" this link and log Nessus out of the application. Nessus will identify when problems such as this are encountered and trigger plugin 40406, CGI Generic Tests HTTP Errors:

To avoid this problem, the following was added to the web mirror settings in the NessusClient ("Advanced" -> "Web mirroring" -> "Excluded items regex"):

This successfully avoids the logout problem, and lets Nessus thoroughly test the application, and find several different web application vulnerabilities. However, while Nessus was still in the process of scanning the application I attempted to login with the admin username and was unsuccessful. To troubleshoot this problem I accessed the database and dumped the user table, specifically the entry for the "admin" user:

The value "d41d8cd98f00b204e9800998ecf8427e" (after some Google searching) was recognized as the equivalent of NULL (or ""). This means that the Nessus CGI testing was accessing the fields that allows users to change their password. Further regular expressions can be added to avoid these pages; however this means a portion of the application will not be tested. If testing the password change feature or similar features is required, then it is best to use a separate test copy of the application to perform the scan, rather than a production system.

Conclusion

Determining if web applications require authentication, and configuring the scanning tools accordingly, is an important step to application testing. It will uncover many new pieces of functionality in web applications that need to be tested for vulnerabilities. Currently Nessus supports basic and form based authentication, with more authentication methods on the way (such as cookie support). When testing your applications, it is also important to monitor the scan and review the results carefully. Any problems could be a sign that the test was not completed successfully and potentially missed testing for vulnerabilities. Nessus provides users with several ways to both detect and overcome these problems.

Resources

• Enhanced Web Application Attacks Added To Nessus
• Web Application Scanning Using Nessus Video
• Tips For Using Nessus In Web Application Testing
• Presentation: Using Nessus in Web Application Testing
• Detecting Base64 Encoded Authentication Requests