If you are not already familiar with the concept of Session Management vulnerabilities, please see the article entitled “What Is A Session Management Vulnerability ?“.
For insight into how to detect Session Management vulnerabilities, please see the article entitled “How To Test For Session Management Vulnerabilities“.
Preventing Session Management Vulnerabilities
Avoiding or remediating Session Management vulnerabilities is straightforward if you observe the following guidelines:
- Use an up-to-date web-server framework to generate and manage the session identifier token, as this will guarantee values that defy prediction.
- Note that the default implementation will be to represent the session identifier token as a cookie
- It is particularly important to never design your own session-management solution.
- Take every precaution to ensure that the session identifier remains confidential to the application. This means you must:
- Exclusively use HTTPS to transfer the session identifier token.
- Never expose the session identifier in a URL, in the contents of a page, or any other insecure location or communication.
- Set the “secure” and “httpOnly” flags on the session identifier token cookie. This directs the browser to restrict transfer of the cookie to HTTPS and puts the cookie off-limits to Javascript.
- Ensure that the session identifier token (cookie) has a browser session lifetime. That is, the browser should store the cookie is in memory (not in a file) and it should expire and disappear when the browser closes. This is the default lifetime for cookies, and changing it is typically a mistake.
- Implement an “inactivity timeout” for every session. This is an application configuration setting or programmatic setting that should be consistent with documented requirements.
- Ensure that the session on the server is terminated (a.k.a. “invalidated”) when the user logs out.
- It is not sufficient to simply forward to the login page with a message that the user is “logged out”.
- Verify that a new session identifier value is generated in response to successful authentication, even if one pre-exists login.
- ASP .NET is an exception to this, as it complements the session identifier with an authentication token.
About Affinity IT Security
We hope you found this article to be useful. Affinity IT Security is available to help you with your security testing and train your developers and testers. In fact, we train developers and IT staff how to hack applications and networks.
Perhaps it was a network scan or website vulnerability test that brought you here. If so, you are likely researching how to find, fix, or avoid a particular vulnerability. We urge you to be proactive and ensure that key individuals in your organization understand not only this issue, but also are more broadly aware of application security.
Contact us to learn how to better protect your enterprise.
Although every effort has been made to provide the most useful and highest quality information, it is unfortunate but inevitable that some errors, omissions, and typographical mistakes will appear in these articles. Consequently, Affinity IT Security will not be responsible for any loss or damages resulting directly or indirectly from any error, misunderstanding, software defect, example, or misuse of any content herein.