Running a scan results with IBM Security AppScan Standard results in error "AppScan Standard has detected it is out-of-session and is trying to re-login"
Running a scan, the following notification is displayed in the UI followed by a 90 second countdown:
"AppScan Standard has detected it is out-of-session and is trying to re-login"
During this time, the Scan Log will display multiple login requests until the scan eventually stops with this log entry:
Stopping scan due to out of session detection
As the error message says, AppScan Standard detects it is out-of-session and it is not able to login into the target application.
Resolving the problem
Consult Login methods in AppScan Standard.
There are several possibilities why this can occur:
- Server stopped responding:
AppScan Standard may not be able to get a response in a timely manner from the application due to it being overloaded or temporarily down.
During the login steps, the system down checks are disabled, and AppScan is not detecting communication errors. To confirm if this is a communication error, uncheck Configuration > Logim Management > Activate Session Detection and scan again. If the scan stop, this time due to communication error, consult Scanning results in "Communication error".
- Issues with session cookies/parameters
This applies to the Request-based login.
Some session cookies or session parameters are missing or tracking is set incorrectly on them.
When recording, AppScan will automatically try to detect cookies or parameters in the login sequence that it believes to be related to the session state (i.e. "ASP.NET_SessionId", "JSESSIONID"), and AppScan determines if the cookies/parameters should be tracked or not. These will be listed on the Configuration > Login Management > Session IDs tab. There is a check box to set tracking.
If there are other session identifiers that were not detected, add them to the Session IDs list and try continuing the scan. Also check the tracking option for the cookies/parameters. The rule of thumb is to try setting anything that appears to have a dynamic value (usually a random alpha-numeric string) to be tracked and anything with a static value (an example being a 'username' or 'password') to untracked.
If this fails you may need to follow-up with the target Applications developer on what is/isn't a session identifier in the Application and adjust the configuration accordingly.
- The 'in-session page' is not accessible when requested out-of-sequence:
Because AppScan polls the In-Session page periodically throughout the course of its scan, it does so while not necessarily visiting it in the same sequence as when then login sequence was recorded.
If you suspect that the reason why AppScan 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 landing page URL which AppScan 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 as the in session pattern from the AppScan response traffic (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.
- The 'in-session page' is set on a POST request
AppScan may automatically set the login POST request as the 'in-session page.
If the request to the page contains the username and password parameters in the POST body, re-record the login and click a few pages deeper, and select one of the subsequent GET requests as your in-session page instead. Whenever possible use a GET request instead of a POST request as the in session page for best results.
Note: If the scan does not stop due to in-session detection but you notice quite a large number of "Performing login" entries in the Scan Log during the Test Phase, perhaps a particular test or group of tests are causing AppScan Standard to go out-of-session. To investigate further, try enabling the negative tests in the Scan Log (Tools > Options > Scan Options tab > Customize Scan Log and selecting Test ID [ID] is negative on: url (param)) and continuing the Test Phase. If you see numerous occurrences of one test being performed followed by the login sequence, consider excluding a commonly displayed page or parameter from testing, or modifying the Test Policy according to a common test being performed.
- The user account gets locked out
If the user account gets locked out during the scan, consult How to prevent user account lockouts while scanning.
- Scan looses the session after some scanning
The scan is in session for a while and explores/tests many pages but then goes out of session.
If the scan remains in session for a long period before going out of session it is possible that a specific test or series of tests is causing the scan to either loose session, invalidates the login credentials.
- If the Account gets locked out, check step #5.
- If the Account is fine but the Application stops responding during the scan check the scan log to see if it is a consistent test or tests causing the outage and remove these from your test policy.
- Incomplete recording
When recording a login sequence, sometimes when opening the recorded login browser, you are already logged into the application. Then the recording will not capture the full login sequence.
If this occurs, click logout, close the recorded login browser and the Start a new recording to capture the sequence from the start.
- The target Application is sensitive to concurrent sessions:
If the target application is sensitive to concurrent sessions (Example: If the same user logs in multiple times concurrently in different browsers/tabs) this can cause out of session issues when running a multi-threaded scan.
Set Configuration > Communication and Proxy > Number of Threads to 1. This will limit the scan to a single concurrent session.
- All other or persisting login/out of session issues:
If you are unable to resolve your session issues using the above general steps you may need to enable additional logging and reproduce the issue. Steps on enabling the Traffic log can be found How to turn on the Traffic Log in AppScan Standard.
Once you have this logging compare the login playback HTTP Requests and Responses to those in the recorded sequence (by clicking the globe button with each request checked) one by one.
Look for the specific page/request where the playback receives a different response from the recording.
- Is there a specific error message in the response from the application that can help you identify the cause? (Example: An account lockout message or other server error).
If not try to identify what is different in that request or prior requests which could lead to the failure.
- Was there any specific parameters or cookies which were not sent/updated correctly in the playback per the recording?
If so adjust the tracking accordingly.