Login Sequence Recorder (LSR) session detection advanced troubleshooting
This document provides details on common LSR (Acunetix standalone Login Sequence Recorder) playback errors, their potential causes, and recommended troubleshooting steps. Understanding these errors can help diagnose and resolve session-related issues efficiently.
In some cases, the LSR may fail to detect a valid session manually or may encounter errors noted in the debug logs. Below is a step-by-step guide to efficiently troubleshoot and resolve such issues:
Invalid session detection error
The error "Invalid session detection - Session still invalid after login playback" may occasionally appear in the debug logs during a scan.
Setting up
- Identify Acunetix Installation Location:
- Locate the directory where Acunetix is installed. On Windows, the default installation path is typically:
C:\Program Files (x86)\Acunetix - Retrieve the Acunetix version number from the installation directory.
- Set Up Fiddler:
- Download and install Fiddler from the official website.
- Enable the option to decrypt HTTPS traffic.
- Temporarily stop traffic capture to prepare for the next steps.
- Launch LSR in Developer Mode with Proxy Support:
- Adjust the directory path in the following command to match the location where Acunetix is installed. Replace VERSION_NUMBER with the version number identified in Step 1.
- Open a command prompt and run the following command:
cd "C:\Program Files (x86)\Acunetix\VERSION_NUMBER" && node lsr standalone --devtools --proxy 127.0.0.1:8888 - This command opens the LSR in developer mode and routes all requests through Fiddler. The default port for Fiddler is 8888, listening on localhost (127.0.0.1). You can adjust these settings to match any proxy configuration.
- Use LSR with Fiddler:
- In the LSR window opened from running the previous command, Open an existing LSR file or configure a new one.
- Playback the authentication steps to simulate login actions.
- Verify that all traffic generated by the LSR is now being routed through Fiddler.
Identifying session pattern issues
There are 2 common scenarios:
- Scenario 1: LSR cannot identify a session pattern:
- The following error is displayed in the LSR interface:
"Session Pattern could not be identified."
- Scenario 2: Session pattern incorrect during a scan:
- The scan logs or the Activity Tab in the UI displays the following error:
"Invalid session detection - Session still invalid after login playback
Scenario 1: Troubleshooting "Session Pattern Could Not Be Identified"
- Explore the application in the LSR:
- After successfully authenticating in the LSR, navigate through the application.
- Interact with various features of the application, such as submitting forms or clicking on links to generate authenticated requests.
- Analyze captured traffic in fiddler:
- Review the traffic captured in Fiddler to identify elements that are only accessible when authenticated.
- Look for specific requests and responses that include authentication-only content, such as "Change Password," "Manage Account," or other user-specific pages like /mycart or /cart.php.
- Example:
Refer to the screenshot below of Fiddler traffic analysis
- In this example, we observed a request to /cart.php. Based on the captured data, this request appears to be available only when authenticated.
- Key observations from the screenshot:
- Request URL: /cart.php
- Cookies and Headers: The login cookie value suggests authentication.
- Response: The successful response (HTTP 200 OK) confirms that this resource is available only after authentication.
- We will attempt to establish a session pattern:
- Use the identified request, such as /cart.php, to configure a session pattern in the LSR.
- Assuming the /cart.php will return a status code 200 when logged we will attempt to use this for a session pattern
- In the LSR we will build to session validation request to look like
GET http://testphp.vulnweb.com/cart.php HTTP/1.1 if status code is 200 - we are doing this assuming that if a status code of 200 is returned we are authenticated
- Click on “Check Pattern” to verify
- Key observations from the screenshot:
- Request URL: /cart.php
- Cookies and Headers: The login cookie value suggests authentication.
- Response: The successful response (HTTP 200 OK) confirms that this resource is available only after authentication.
- Check pattern
- Click “Check Pattern” in the LSR
- If the pattern is successful “Pattern was successfully identified” will be displayed. The LSR can be saved and the scan started
- In this case specifically, requesting /cart.php did not help us identify a pattern
This takes us to scenario 2.
Scenario 2: Troubleshooting: Session Pattern Incorrect During a Scan:
Whilst the error message was not displayed during the scan, or found in the logs, the method of troubleshooting remains the same. We need to identify a session pattern that can be used for this Target.
Troubleshooting steps:
- Analyze Captured Traffic in Fiddler:
- Click on "Check Pattern" in the LSR to verify the session pattern.
- Two requests will be sent when clicking on "Check Pattern":
- Authenticated Request: Includes session information, cookies, and authorization tokens.
- Unauthenticated Request: Excludes session-related cookies or tokens.
- Look for these 2 requests in Fiddler
- Opening the requests in Fiddler:
- Identify the two requests sent by "Check Pattern" and open them.
- Delete all extra requests sent for clearer presentation.
- Open the "Headers" view in the Inspectors tab as an initial step
- Reviewing the requests in Fiddler
- Compare the response status code for both requests.
- If both responses return a 200 status code, it indicates that the LSR could not differentiate between authenticated and unauthenticated states.
- Key observations:
- The authenticated request contains a cookie in the header, for example: Cookie: login=test%2Ftest, indicating it was sent with session information.
- The response headers for both requests are nearly identical, apart from the Content-Length.
- Investigate further
- Open the Raw
- Notice that the initial request had a cookie in the header “Cookie: login=test%2Ftest” indicated this is the authenticated request sent by the LSR
- Notice the in the headers in the response are nearly identical, apart from the content length, indicating that something in the response is different from when authenticated and not
- Notice the different responses for when authenticated
- For the request with the cookie, we observe that the response contains unique content only visible when authenticated. Specifically, the response includes:
<a href='logout.php'>Logout test</a> - This "logout" link is only available in the authenticated state, making it a suitable indicator for a session pattern. We can use this as the basis to configure a session pattern
- This will allow us to configure a new session pattern
- Configure the new Session pattern
- Since the <a href='logout.php'>Logout test</a> is available in the response, we need to configure the session pattern to check for this.
- Navigate to the Session Validation Pattern section and set the session as valid if the “pattern is found in response” (see screenshot below):
- Enter the following pattern in the text field:
<a href='logout.php'>Logout test</a> (see screenshot above): - This will instruct the Login Sequence Recorder and scanner to consider the session authenticated only when <a href='logout.php'>Logout test</a> is present in the response.
- Validate the Pattern
- Click on check pattern
- This "logout" link is only available in the authenticated state, making it a suitable indicator for a session pattern. We can use this as the basis to configure a session pattern
- This will allow us to configure a new session pattern based on <a href='logout.php'>Logout test</a> being available in the response
- By completing these steps, the LSR will be able to differentiate between authenticated and unauthenticated states based on the presence of the logout link (<a href='logout.php'>Logout test</a>) in the response.