Scanning Web Applications That Require Authentication

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