Most web applications and websites require some form of authentication – either as a whole or in an area. Many web vulnerability scanners struggle with such authenticated web assets. While some scanners are able to detect standard authentication forms and mechanisms, in the case of many custom web applications, you need some kind of mechanism to repeat the steps that a human would take. Such mechanisms are often called macro recorders.

Acunetix provides an automated mechanism that detects and handles standard login forms with the login data that you supply. However, in the case of more complex web applications, you might need to launch the Acunetix Login Sequence Recorder (LSR) and record a login sequence (*.lsr file), which can then be uploaded and saved with your target settings.

You use a login sequence to perform the following tasks during crawling and scanning phases:

• Access a form-based password-protected area
• Replay login actions to authenticate to the website or web application
• Restrict actions that the crawler and scanner can access (such as logout links)
• Mark actions that require manual intervention each time they are accessed, such as pages with CAPTCHAs, one-time passwords, and two-factor authentication

Stage 1. Creating a Target

1. Go to your Acunetix dashboard.
    
   
2. Click on the Targets -> Add Target menu option.
    
   
3. Set the Address of your target to http://testphp.vulnweb.com.
4. Set the Description to Test PHP Site.
5. Click on the Save button.

Stage 2. Configuring the Login Sequence

Step 1. Create the Login Sequence

1. Click the Targets menu option.
2. Click the target that you created in stage 1.
3. Scroll down to the Site Login section.
4. Select Use pre-recorded login sequence.
5. Launch the Login Sequence Recorder by clicking on the New button.
    
   
   This will launch the Login Sequence Recorder and open the target URL – in this case, the Acunetix test site called Acuart.
    
   
6. On the Acuart page, click on the Your profile link in the left-hand menu to open the login page.
    
   
7. Enter test in the Username field, enter test in the Password field, and click on the Login button.Note that:
   • With each action that you perform and record, the panel on the right will be populated with login actions
   • Since the LSR is recording actions and not HTTP requests, it also works with web applications that use anti-CSRF tokens
    
8. Some web applications may require additional manual intervention steps (such as a CAPTCHA sequence) to log in — see further down for some notes about manual intervention. This sample web application does not have such steps so you can click on the Next button to proceed to the Record Restrictions phase.

Step 2. Configure Restricted Links

Restrictions instruct the crawler and scanner not to follow specific links during a scan. Typically, you would want to restrict logout links or other links that might destroy a valid session in order to ensure that the scanner does not get logged out during the scan. The LSR also supports restrictions on HTTP methods commonly used in RESTful web services such as PATCH, PUT, DELETE in addition to the standard GET and POST requests.

If the link you are restricting contains a nonce or a one-time token, you may use wildcards (*) to restrict links with changing values.

In the Acuart web application:

1. Click on the Logout test link to restrict Acunetix from clicking on this link when it is crawling and scanning the site.
    
   
2. Upon clicking the link, a window will pop up asking if you wish for Acunetix to either:
   • Intercept this request (either in its exact form or by using wildcards)
   • Forward requests that match this request
   • Forward all requests, meaning that there will be no restrictions
   In this example, we do not need to make any modifications to the Restriction, therefore we can select the first option – Restrict request using exact match.
    
3. The restriction will be recorded and shown in the panel on the right. You may add as many restrictions as you need.
4. Click on the Next button to proceed to the valid session detection phase.

Step 3. Identify Valid Authentication Session Parameters

In our example (the Acuart site), Acunetix is able to identify valid session parameters automatically. You can see a notification that confirms this:
 

In this step, the LSR tries to identify a valid session automatically. The session pattern is required so that the scanner will be able to know the difference between an invalid (logged out) and a valid (logged in) session. If the scanner is able to know that the session has been invalidated, it can replay the login sequence and validate the session again.

This is done by comparing the logged in and logged out states of the web application. There may be cases where no difference can be identified automatically. In such cases, you will need to either configure it by navigating to pages and let the LSR identify the pattern, or it can also be done manually. In addition to authentication mechanisms that rely on cookies, the LSR also supports authentication mechanisms that rely on HTML5 LocalStorage.

In some cases, you may need to manually configure valid session parameters — see further down for some notes about manually configuring a user session pattern.
 

In many cases where immediate identification does not happen, you can still get Acunetix to identify a valid authentication session while navigating. You can do this by browsing to authenticated areas of the website that will return a different response depending on the user being logged in or logged out. For example, a response from the website will contain the text Logout if the user is logged in. If it is not found in the response, it means that the user is not logged in. When you have identified and configured the session pattern, you may verify it by clicking Check Pattern at the top of the right-hand-side panel.

Once you click on Finish, you will be returned to the Target Settings page in Acunetix. Click on the Save button to save your target configuration that now includes the login sequence file.

Configuring Manual Intervention (If Necessary)

Some login pages require additional steps before you can complete the login process – some examples would be CAPTCHA, two-factor authentication (2FA), multi-factor authentication (MFA), and other one-time password mechanisms (OTP). As you record your login sequence, you will encounter the point where you need to intervene manually to perform a step that cannot be automated. When you encounter this point, select the manual option.
 

The LSR will keep track of this. When you perform a scan, Acunetix will pause and prompt you for your manual intervention with a popup notification. When you complete manual intervention actions, make sure that any actions created by the LSR that are part of the manual intervention process are deleted by selecting each superfluous action, and deleting it by clicking on the delete icon ().

Now you can simply continue with the recording of the remaining login sequence actions.

Manually Configuring a User Session Pattern

If Acunetix is still unable to identify a user session pattern, you will have to configure one manually. The important point is that the responses sent by the web server will differ between those of a logged-in user and those of a user that is not logged in. Your task is to identify a reliable difference that the scanner can use to verify whether or not it is logged into the site.

For the sake of this explanation, we will assume that you are testing the Juice Shop application. Just like in the case of the Acuart application, you need to complete the above stage 1 and then steps 1-2 of stage 2.

There are 3 main options for session pattern validation.

• Option 1: Identify a visual difference on one of the web pages. For example, some web pages will show a Your Basket link only to logged-in users. Some other pages will show the name of the logged-in user. In such cases, you can instruct the LSR which page to go to by simply typing in something like this in the Session Validation Request text area:GET https://juice-shop.herokuapp.com/profile HTTP/1.1
  
  And setting the dropdown labelled Session VALID if: to pattern is found in response to the logged-in specific text or user name:
   
• Option 2: Identify a difference in the HTTP response headers in the logged-in web pages compared to the not-logged-in version. You can check this with Google Chrome, for example, by using the Inspect feature. The Network tab will show a Response Headers section that could include a header such as X-Logged-In: true, but would be absent or have a different value such as X-Logged-In: false:
   
  
  Now you can set the dropdown labelled Session VALID if: to pattern is found in headers to the identified header value:
   
  
• Option 3: Identify a web page that receives a numeric response when logged in (typically 200) and some other response when not logged in, such as a 404 (not found) or a 500 (server error). Set the dropdown labelled Session VALID if: to status code is to the valid value: