Details
When the session information is stored on the client, the session ID, along with the user authorization and identity information, is sent along with each client request and is stored in either a cookie, embedded in the uniform resource locator (URL), or placed in a hidden field on the displayed form. Each of these offers advantages and disadvantages. The biggest disadvantage to all three is the hijacking of a session along with all of the user’s credentials.
When the user authorization and identity information is stored on the server in a protected and encrypted database, the communication between the client and web server will only send the session identifier, and the server can then retrieve user credentials for the session when needed. If, during transmission, the session were to be hijacked, the user’s credentials would not be compromised.
ASP.NET provides a session state, which is available as the HttpSessionState class, as a method of storing session-specific information that is visible only within the session. ASP.NET session state identifies requests from the same browser during a limited time window as a session, and provides the ability to persist variable values for the duration of that session.
Solution
Follow the procedures below for each site hosted on the IIS 8.5 web server:
Open the IIS 8.5 Manager.
Click the site name.
Under the ‘ASP.NET’ section, select ‘Session State’.
Under ‘Session State Mode Settings’, verify the ‘In Process’ mode is selected.
Select ‘Apply’ from the ‘Actions’ pane.
Supportive Information
The following resource is also helpful.
This security hardening control applies to the following category of controls within NIST 800-53: Access Control.This control applies to the following type of system Windows.
References
- 800-53|AC-10
- CAT|II
- CCI|CCI-000054
- Rule-ID|SV-214444r508659_rule
- STIG-ID|IISW-SI-000201
- STIG-Legacy|SV-91471
- STIG-Legacy|V-76775
- Vuln-ID|V-214444