How to correct in-session detection issues in AppScan Enterprise

Technote (FAQ)


How do you ensure the login session is maintained throughout a scan in IBM Security Appscan Enterprise and IBM Rational Policy Tester?


The technote describes how to address common in-session issues along with an overview of the In-Session Detection functionality.


Overview of In-Session Detection

In session detection is important when scanning Applications which require a login. It is designed to ensure the scan remains logged in at all times to maximize the scan coverage and accuracy of test results. When in-session detection is disabled you may not be aware when a scan cannot login successfully, or when it looses its session with the target application and is being redirected back to the login or error page.

To record a login sequence and enable In-Session Detection go to the Job Properties under Login Management, click on the drop down for In-session Detection Details, this will display an option to Activate In-Session detection, an a text box to define an In-Session Pattern.

From the list of recorded URL's one of the pages will need to be marked as In-Session by checking the box next to the URL and clicking the In-session button. On this page should exist either the default in session pattern (as defined by a regular expression in a text box under in session details) or a custom string or regular expression. This pattern is frequently set as the logout link (for proof that you are logged in).

If the specified pattern is not detected on the page which is marked as in session you will see a red icon with the message:

   In-session detection is enabled, but an in-session page has not been identified.

In this case you should review the HTTP traffic (click the globe icon) and select a better in-session page/pattern. It can be any page which you can only reach from a logged in state, and any pattern you can only see on that page when logged in. The logout link is a common example of an in-session pattern but is not required, another commonly used pattern would be a user preferences link. Once a proper page and pattern is selected click the Update button and the icon should change to a green checkbox with the message:

   In-session detection is active.

AppScan Enterprise/Policy Tester will poll the application periodically (during the automatic explore and test phases) to check if it can reach the page and if it is able to detect the marked pattern.

If the check is successful, then AppScan is in the in-session state. If the check is unsuccessful (e.g. the response is a redirect to the login page or a customized error page), AppScan is in the out-of-session state.

If AppScan detects an out-of-session state, it will stop exploring/testing, replay the login sequence, and then re-send the in-session request confirming if a valid session state was re-attained. If an out-of-session state is detected in the test phase, AppScan will stop its testing threads, re-login, check its in-session state, and then re-run all of the tests since the last point a valid session was confirmed.

If AppScan is not able to successfully log back in nor get a valid in session page/pattern (e.g. because of a configuration issue or server outage), the scan will Suspend with an Out of Session error.

Common Issues and how to address them

There may be instances where AppScan detects it is out-of-session and is not able to successfully validate its marked in-session pattern. If this occurs, an out of session notification will be displayed in the the scan log and if it cannot log back in after multiple attempts the scan will suspend.

There are several possibilities why this can occur:

  1. Server stopped responding:

    AppScan may not be able to get a response in a timely manner from the application due to it being overloaded or temporarily down.

    To test, try disabling the "Activate In-Session Detection" checkbox then restart the scan.

    If it still suspends due to communication issues, check that the target application is currently up and running.

  2. Required session cookies or parameters were not automatically detected by AppScan Enterprise in the login sequence:

    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"). These will be listed under Login Management if you click the Login Session IDs (advanced) drop down. There are buttons to Track or Stop Tracking any parameters/cookies you believe are or are not session identifiers, make sure to track anything that is.

    If there are other session identifiers that were not detected, add them to the Parameters and Cookies section of the job properties (and track them) and try stopping/re-running the scan.

    If you are not sure which parameters or cookies are session identifiers, the rule of thumb is to try setting anything that appears to have a dynamic value (usually a random alpha-numeric string) to be track 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.

  3. 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.

  4. Detected In-Session page is a POST with the login parameters:

    If AppScan 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 in the HTTP traffic (check the box next to the in session page and click the globe button).

    If the request to the page contains the username and password parameters in the POST body , try re-recording the login and click a few pages deeper, select one of the subsequent GET requests as your in session page instead. Whenever possible a GET request instead of POST should be used as the in session page for best results.

  5. The user account gets locked out

    If the user account gets locked out during the scan, consult How to prevent user account lockouts.

  6. Scan is in session for a while and visits/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.

  7. Recording the login does not capture the full login sequence:

    When trying to record a login sequence, sometimes upon opening the recorded login browser, you are already logged into the application.

    If this occurs, click logout, close the recorded login browser and the Start a new recording to capture the sequence from the start.

  8. 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.

    In AppScan under Connections set the Number of Threads used for exploring and Number of Threads used for Testing to 1. This will limit the scan to a single concurrent session.

  9. Under Login Session Ids, the session id is displayed as Tracked for a specific doman (example:

    This is because when the recorded login was recorded this domain ( was the domain that set the cookie. When viewing the requests in the recorded login (or a tool like Paros) for the login sequence, there are additional subsequent domains that also utilize this session id i.e. Because the session id is set to be tracked under Login Session Ids for domain, the session id will not be updated for the playback of the requests and the scan will go out of session.

    To fix this issue perform as follows:
    1. Under "Parameters and Cookies", delete all occurrences of the session id with the exception of one
    2. Edit the session id settings for this session id:
      • Remove the value in Domain (optional) - this will no longer tie the session id to a specific domain
      • Ensure Track Type is set to Login Value (Recommended) 3; re-record the login in order to reset the session id setting
    3. Rerun the scan to verify it fixes the in-session detection out of session issue

  10. 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 in AppScan can be found here.

    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.

Cross reference information
Segment Product Component Platform Version Edition
Security Rational Policy Tester Authentication

Document information

More support for:

IBM Security AppScan Enterprise
Scan: Authentication/In-session

Software version:

8.6,,,,, 8.8,, 9.0,, 9.0.1,, 9.0.2,, 9.0.3

Operating system(s):


Software edition:

Enterprise, Reporting Console

Reference #:


Modified date:


Translate my page

Content navigation