This article shows how to scan a web application that requires authentication using the Website Vulnerability Scanner of Pentest-Tools.com.
Learn how to configure the authentication options of the scanner such that it automatically passes the login page and performs in-depth scanning.
Note: To access the authentication options of the scanners you need to first log in to your Pentest-Tools.com account.
Why authenticated scans?
If authentication is not enabled, the web scanner covers only a small set of application functionality, the one exposed before the user has to authenticate. However, there may be other uncovered vulnerabilities that can only be identified after logging in to the application.
Another good reason for performing authenticated scans is that it mimics the activities of a malicious authenticated user, which has additional attack vectors. Authenticated users have access to more functionality than unauthenticated users.
Supported authentication methods
Our Website Vulnerability Scanner supports three methods for performing authenticated scans:
The following sections of the article show you how to configure the scanner and how to interpret the results when doing authenticated scans.
1. Form-based authentication
The Website Vulnerability Scanner provides two types of scans: Light and Full. Only the Full scan supports authentication.
Here is the web interface of the scanner that allows you to configure the authentication options:
In order to configure the authentication for a Full scan you have to:
- Insert the URL of the website that you want to scan (the target)
- Select the Full Scan
- Enable the “Authentication” option
The “Login authentication” option allows the user to make an authenticated scan by having a valid pair of credentials in the target application.
You will have to provide the following details:
- The login URL of the application
(for example [http://bank.pentest-ground.com/private-dev/signin.php]. This is usually different than the target URL and is needed to contain the login form.
- The correct username and password
At this point, you can test if the authentication works properly by pressing the
Check Authentication button or Start the scan directly. The Check Authentication functionality does not initiate the scanning process but it only shows a screenshot of the successful login page (cropped at 1280 x 720px).
Here is a sample configuration of the” Login authentication” option and a sample screenshot of a successful login:
2. Cookie-based authentication
HTTP Cookies are pieces of data that a web browser receives from the server and are usually used to identify the web session of a user (they are also called session cookies). After receiving a session cookie, the browser sends it with each HTTP request that it makes to that server. It is helpful to know that the request is associated with that particular user.
Our Cookie-based authentication option mimics the behavior of a web browser that already has a session cookie. It requires the user to insert a valid session cookie in the ‘Cookie header’ field. The session cookie must be taken from an already established web session (you need to manually login to your web app and get the cookies from your browser).
The web interface for this type of authentication looks like in the picture below:
3. Headers authentication
HTTP headers enable the communication between a client and the server carrying information about the client browser, the server, the accessed page, and more. Some applications use specific headers to create sessions for users (login). As a result, the headers’ authentication method is required for users who need to scan these types of websites/applications (authentication).
In order to retrieve the headers needed, please follow the same steps described in the section above (cookie-based) and insert them in the format:
Header1 : the value of Header1
Header2 : Subheader1 = value of Subheader1; Subheader2 = value of Subheader2
How to get the session cookie?
First, you have to manually authenticate in the target web application using your web browser. Second, you need to get the session cookie string from the browser.
For example, using Google Chrome, you have performed the following actions:
- Enter Developer Tools – by Menu > More tools > Developer Tools (or Ctrl + Shift + I)
- Enter the ‘Network’ Tab
- Click on the ‘Name’ section, choose a URL that displays an additional ‘Cookies’ tab.
- Go to ‘Headers’ Tab (for that URL)
- Scroll to Request Headers and see the Cookie header
- Copy the string from the Cookie header and insert it as in the example below
‘PHPSESSID=a765feb13b4112f3d12f3dfa12e;_aa_id=ad4b654ad48f4d545a64d75ea’ (a list with name=value separated by “;” and no spaces)
Here are the Developer Tools interface:
Interpreting the results
Authenticated scanning covers more application functionality and pages than the unauthenticated scan. You should an additional “Authentication success” message in the final scan report, more exactly in the Spider results. Furthermore, the Spider results should contain more crawled URLs than the unauthenticated scan.
Results displayed for scanning with authentication
Results displayed for scanning without authentication
Behind the scenes
The main steps phases of a web vulnerability scan are spidering and active scanning. In order to perform these as an authenticated user, the scanner requires the user’s session cookie. It will be used for every request and it will uncover more information than an unauthenticated scan.
The Login authentication option performs an additional step in order to obtain the session cookie. First, the scanner detects the login form from the URL provided and tries authenticating with the credentials. Second, the scanner tries to obtain the session cookie from the authenticated user and use it from this point in every request.
If you select just the
Check authentication option, a screenshot of the user’s page is taken to help you visualize whether the authentication was successful or not. The spidering is not initialized and the scan stops.
In the Cookie-based authentication, having the session cookie already provided by you, the spidering and active scanning start directly. If the cookie is correct, the scan will result in more URLs discovered and analyzed for vulnerabilities.
Please note that the scanner cannot know if the provided cookie is correct or not. It will use it as is and it is up to you to validate if the scan has reached the desired parts of the application.
We currently also support performing authentication testing on Single Page Applications (SPAs) as our website scanner has been upgraded so that it is able to load, detect, and log in the user given the credentials. This method is available using the Form-based authentication method.
With the Headers-based authentication implemented, our Website Vulnerability Scanner now provides more accurate assessments and enhanced security for the application based on tokens (JWT).
You can find a step-by-step guide on how to perform an authenticated website scan with JWT in our Support Center.
Single Page Applications
As a workaround for this case, you should use the ‘Cookie authentication’ method and provide the session cookie manually.
At the moment, the scanning engine does not support token-based authentication (ex. JWT).
However, we are constantly developing our authentication methods and the Website Vulnerability Scanner, thus we will add these capabilities in the near future.
In conclusion, authenticated scanning provides more coverage within a web application, as it discovers more dynamic URLs. when you perform a more in-depth scanning, there is a higher chance to find well-hidden vulnerabilities and render your web applications more secure.