β οΈ 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.
π‘ If your login process is a little more complicated, you might want to have a quick skim of this article; and if you have questions about scan scope, you might want to give this article a read.
πΉ Prefer a video walkthrough?
We also have a video tutorial on adding form-based authentication which you can find here:
Before you start
The information below is required 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. A few extra tips:
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.
Adding a new target with authentication
Throughout this example, we will be using vulnerablesite.intrud.es
where we are hosting our test application.
β
β οΈ If you're unsure where to find the parameters needed, we have just the article for you.
Targets >
Add target
>External web application
βType the target into the top box, add the Entrypoint URL and any tags (if applicable), and then click the
Add target
button.
β
Adding the Authentication to a pre-existing target
Head back to Targets > All >
...
>Add authentication
β
Adding the authentication
Enter in the 'Details:
Entrypoint URL
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://vulnerablesite.intrud.es/DVWA
). 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://vulnerablesite.intrud.es/DVWA
)Login request URL
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://vulnerablesite.intrud.es/DVWA
)Logout URL
In our example, we specify that there is a Logout URL which we want to exclude from scanning (
http://vulnerablesite.intrud.es/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.Enter the form parameters
Username field and Password field
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 namedusername
and the password field is namedpassword
. (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 nameduser_token
which the scanner needs to submit when trying to authenticate.
Verifying the authentication
Complete
Given how nuanced apps are, we don't presume the accuracy of authentication β instead, we show you what the scanner encountered and allow you to decide whether it has worked or not (the screenshot in particular is helpful, as you can use that to gauge if the scanner can access pages behind the login).
You could get any combination of results, here are just a few:
β
Managing authentication(s)
Once you've completed this information you will see the authentication appear under the Authentications tab.
β
To disable an authentication
Click ...
> Disable:
And the modal will update to this:
β
To re-enable, just click the ellipsis again > Enable
:
β