⚠️ If you're thinking of an admin user when adding authentications, please read this article first: Adding an admin user when adding authentications
💡 If you have any trouble with form-based authentication, as a good first step, it might be worth trying the session cookie authentication method or using header-based authentication.
Selecting the authentication method
When you select Form-based authentication you will be presented with the following modal which allows you to enter the information necessary for our scanner to know where in your application to start scanning from, how to submit the login request, and what URL to avoid so that the scanner doesn't get logged out.
Before you start
http://
orhttps://
is required on your URLsThe
Login page URL
is optional but will be beneficial when our scanner tries to retrieve and update anti Cross-site Request Forgery (anti-CSRF) tokensThe
Logged in pattern
is optional but will help our scanner identify when it has authenticated correctly and if it needs to re-authenticate during the scan.
How to find the information
If you're unsure of where/how to find the information you need, please click the hyperlinks under 'Credentials' or refer to the Where to Find Required Information section at the bottom of this article.
Adding the credentials
Throughout this example, we will be using 178.79.154.6
where we are hosting our test application, but you may use any fully qualified domain name (FQDN) or IP address.
The Entrypoint URL tells the scanner where it should start all of it's crawling and scanning from. In this example, we are starting our scan from the root of our application (http://178.79.154.6/
). If you want the full application to be scanned, be sure to include a /
on the end of the URL.
Login page URL
This is the URL where we can find the login page of the web application. This will be the window where the login fields can be seen. In this example, our authentication data is sent to the same URL as the login page itself (http://178.79.154.6/DVWA/login.php
)
This is the URL to which your application sends the data that users have entered into the form. In this example, we want to send our authentication data to our login.php page (http://178.79.154.6/DVWA/login.php
)
In our example, we specify that there is a Logout URL which we want to exclude from scanning (http://178.79.154.6/DVWA/logout.php
), this will help us make sure that the scanner doesn't accidentally log itself out.
Note that if you have a Logout URL that includes query parameters (e.g. http://www.example.com/login?action=logout
), then we would recommend always including the Logged In Pattern (optional) parameter.
You are looking for the value of the name
field for each. In this example, the username field (in the form on our target web application) is named username
and the password field is named password
. (These are not your user credentials for logging in).
Additional Parameters
If the authentication sends more than just the username and password parameters, these would also need to be added to the configuration by entering these into the Key/Value boxes and pressing the + Add Parameter
button for any further parameters needed.
CSRF token (optional)
The scanner will attempt to use a CSRF Token from a list of the most common values (e.g. antiforgery-token
, csrf-token
, etc.). However, for best results, it is always best to include the exact value used in your web app, especially if you use an uncommon name for the token. In this example, we've told the scanner that we have an anti-CSRF token named user_token
which the scanner needs to submit when trying to authenticate.
Finally, you will be asked to provide the credentials for the user that you want the scanner to authenticate as.
Managing authentication(s)
Once you've completed this information you will see the authentication appear under the Authentications tab.
If you would like to disable or edit an authentication, you can do so by clicking the '...
' and selecting from the options shown
Where to Find Required Information
Where to Find Required Information
This section will explain where you can find the details that need to be entered when you're adding authentications to a target.
When entering a Form-based authentication it is best to visit the target login page (the page where your login form exists), as this is where most of information we need to gather can be found.
Quick search
Entrypoint URL
The entrypoint URL tells the scanner where it should start all of it's crawling and scanning from. Most often this will be the root of your web application. Which in our example would be http://178.79.154.6/
. Please note, there is not a path associated with the URL just a /
on the end, which you should include if you want the full application to be scanned.
There are times when you won't want to scan from the root of the application, instead you might want to scan a subset. For example, when you have multiple applications running on the same target, but which live at different paths. For our example:
http://178.79.154.6/DVWA/
http://178.79.154.6/MyOtherApp/
http://178.79.154.6/SecretApp/
In this case, you would want to add 3 separate authentications each using one of the paths in the list.
Login Page URL
The Login Page URL is the URL at which your login form can be found. In this example our login page is at http://178.79.154.6/DVWA/login.php
(which can be seen in the URL bar at the top of the following screenshot):
Login Request URL
This is the URL to which your application sends the data that users have entered into the form. This can be found by right-clicking on the form (such as on the username field), and then selecting Inspect
:
You are looking for the form
tag which encloses the username and password fields on your login form. The form
tag will have an action
field and the value of that field is what you're looking for. In our example, the value is login.php
, which can be seen below:
In our example we see login.php
is the value we see in the form. We need to add the prefix that we made a note of in our Login Page URL section above. So, the value we need to enter into our Login Request URL field is http://178.79.154.6/DVWA/login.php
. You may notice that this is the same as our Login Page URL from the previous section - this may not be the case in your app.
Logout URL
The easiest way to find this would be to login to the application and find the Logout button on your page (it may say Log Out
or Sign Out
or something similar). If you hover over the button you'll see the Logout URL in in the bottom of your page, you can also right click and 'Save link address', then paste into Intruder.
If that's not working, you can right-click on the logout button and click on Inspect
:
In our example the Logout URL is set to logout.php
but it needs to be fully-qualified by adding the path to the current page in front of the page. Which you can see in the screenshot above http://178.79.154.6/DVWA/logout.php
:
Note that if you have a Logout URL that includes query parameters (e.g. http://www.example.com/login?action=logout
), then we would recommend always including the Logged In Pattern (optional) parameter.
Logged In Pattern
In our example above an appropriate value for the Logged In Pattern
would be Logout
as it appears on every page when a user is authenticated.
Username Field
Logout of the application and go to your Login Page URL, right-click on the username field:
You are looking for the value of the name
field of the username input
which in our example is username
. When you mouse over the input
field in the source code it should highlight the username
text entry box on your screen.
Password Field
If you're not already, go to your Login Page URL and right-click on the password field:
You are looking for the value of the name
field of the password input
which in our example is password
, it could be named something different in your app. When you mouse over the input
field in the source code it should highlight the password
text entry box on your screen. Additionally, the password field is usually always set to type="password"
:
CSRF Token Field
Anti-CSRF tokens are usually found in forms which submit data to the application. But, it might be possible that your application doesn't have an anti-CSRF token at all.
Anti-CSRF tokens will usually have the following properties:
It will be an
input
field in the same form as your login fieldsThe
input
field will have atype
and it will be set to"hidden"
, which you can see in our example below astype="hidden"
The
input
will have avalue
and that value will usually be a long random block of textThe
input
will have aname
but there is no specification which dictates what the name should be, it can be anything. But, the name may include the termcsrf
,authenticity
,verification
ortoken
.
In our example below you can see the field that fits all these properties is the user_token
field, and this is our CSRF Token Field
:
Additional Parameters
While searching your form you may find additional input
fields. For example, when you view the Intruder Portal login form you will see another input
field with the name
commit
and the value
set to Log in
which can be seen below:
You need to add these fields to the Additional parameters
section when adding your authentication. If you don't then your authentication may fail. So, for the Intruder Portal Login form we would need to add the following to our authentication:
Username & Password
Both of these are mandatory. They should be the values that you have configured for your user in your application.