Introduction
w3af supports these types of authentication credentials that a user can provide in order for the scanner to keep a session open to scan the target web application:
- HTTP Basic authentication
- NTLM authentication
- Form authentication
- Setting an HTTP cookie
HTTP Basic and NTLM authentication are two types of HTTP level authentication usually provided by the web server, while the form and cookie authentication methods are provided by the application itself. It’s up to the user to identify which authentication method is required to keep a session with the application, but usually a quick inspection of the HTTP traffic will define what’s required.
Basic and NTLM authentication
First you’ll have to start w3af’s GUI, from the command line run “w3af_gui” and you should see the main window:
To configure basic or NTLM credentials you need to open the HTTP settings menu. The configuration set in this section will affect all plugins and other core libraries. In the top menu choose “Configuration” and then “HTTP Settings” and a window like this will appear:
Please note the two tabs called “Basic HTTP Authentication” and “NTLM Authentication”. Enter your preferred settings and click save. The scanner is now ready to start an authenticated scan, the next step would be to enable specific plugins and start the scan, for example, you could follow the Find Cross-Site Scriptings and SQL injections howto to finish the scan configuration.
Form authentication
Form authentication has changed significantly in the latest w3af versions. Starting with version 2.0 the form authentication is configured using “auth” plugins. There are two authentication plugins available in the framework:
Authentication plugins are a special type of plugin which is responsible to keep a session alive during the whole scan. These plugins are called before starting the scan (in order to get a fresh session) and once every 5 seconds while the scan is running (to verify if the current session is still alive and create a new one if needed).
This tutorial will explain how to configure the generic authentication plugin which has the following options:
- username: Web application’s username
- password: Web application’s password
- username_field: The name of the username form input that can be found in the login HTML source.
- password_field: The name of the password form input that can be found in the login HTML source.
- auth_url: The URL where the username and password are POST’ed to.
- check_url: The URL that will be used to check if the session is still active, usually this is set to the web application user’s settings page.
- check_string: A string that if found in the check_url’s HTTP response body proves that the session is still active, usually this is set to a string that can only be found in the user’s settings page, for example his last name.
Once all these settings have been configured, it is recommended to start a test scan only with crawl.web_spider and auth.generic in order to verify that all the post-authentication forms and links are identified. Also, keep an eye on w3af’s log since the authentication plugins will create log entries if there is any issue with the authentication process. Log entries like:
Login success for admin/password
User "admin" is currently logged into the application
Are what you would expect to see if the configuration was successful and messages like:
Can't login into web application as admin/password
Show that either the plugin configuration is incorrect, or the application requires more parameters to be sent to the auth_url which in some cases is solved by using the detailed plugin.
Setting HTTP Cookie
For the cases in which the form authentication doesn’t work, which might be related with login forms with anti-CSRF tokens, w3af provides users with a method to set an HTTP cookie to use during the scan. This method will set an HTTP request header which will be added to each HTTP request that’s sent by the framework, note that no verification of the session’s state is made when using this method, if the session is invalidated the scan will continue using the old cookie.
The recommendations for form authentication about blacklisting the application’s logout link apply to this method too, since we want to keep the session alive for the duration of the scan.
In order to use this method you’ll first have to create a text file using your favorite text editor with the following contents: “Cookie: <insert-cookie-here>”, without the quotes and inserting the desired session cookie. Then, in w3af’s main menu open the “Configuration” and “HTTP Settings” and a window like this should appear:
In the headers_file configuration parameter enter the path to the file you just created and click save. The w3af scanner is now configured to use the HTTP session cookie for all HTTP requests.