Troubleshooting in-session detection

There might be instances where the scan detects it is out-of-session and is not able to successfully validate its marked in-session pattern. During this time, the scan log will display multiple login requests until the scan eventually stops with the following log entry: "Suspending scan due to out of session detection".

There are several possibilities why this could occur:

1. Server stopped responding: The scan might not be able to get a response in a timely manner from the application because it is being overloaded or is temporarily down. To test, try disabling the "In-Session Detection" check box, then continue the scan.
2. Required session cookies or parameters were not automatically detected by the scan in the login sequence: The scan will automatically try to detect cookies or parameters in the login sequence that it believes to be related to the session state (that is, "ASP.NET_SessionId", "JSESSIONID"). These will be listed in the Login Session IDs list. If there are other session identifiers that were not detected, add them to the Session IDs list and try continuing the scan. If you are not sure, try first adding all that show up in the login sequence and if the scan is then able to remain in-session, you can go back and remove some IDs until the specific cookie or parameter is isolated. To figure out which ones to add, go to the Login Session IDs list, highlight each URL, click the View HTTP Request button, and examine the HTTP header for cookies and parameters.
3. In-Session page is not accessible when requested out-of-sequence: Because the scan polls the in-session page periodically throughout the scan, it does so while not necessarily visiting it in the same sequence as when the login sequence was recorded. If you suspect that the reason why the scan is not able to remain in-session is caused by this type of configuration, try testing by exploring the sequence using your browser, copying the URL that the scan is using as its in-session page, continuing with a short explore of the application, then forcefully browsing to the page in question. If you are not able to see the text in the response that you had previously marked (for example, you are redirected to a customized error page), try selecting other pages as your in-session page until you find one that permits this type of behavior.
4. Detected in-session page is a POST with the login parameters: If the scan automatically detects a page as its in-session page and you notice that it is not able to remain in-session throughout the scan, examine the marked page by highlighting it and clicking the View HTTP Request button. If the page contains the username and password parameters, try selecting another page further down in the list, marking its pattern in the browser, then continuing the scan. If there is no other page to select, try rerecording the login sequence and include one extra page in the explore, then mark that page as your in-session page.
5. An in-session pattern does not match the actual response. For example, you might have entered 'logout' as the pattern, but someone changed the site and now the text is 'log out'. Use the HTTP Request feature to determine the differences in the expected response 'logout' and the actual response 'log out'. Change the pattern if necessary and scan again. Then check the HTTP Request response again.