Session Identifier Not Updated risk, real vulnerability or just false positive risk?

Question

In a recent security scan using IBM AppScan in one of our ASP.NET applications, the following medium vulnerability is reported

Session Identifier Not Updated
Severity: Medium
Risk: It is possible to steal or manipulate customer session and cookies, which might be used to impersonate a legitimate user, allowing the hacker to view or alter user records, and to perform transactions as that user
Causes: Insecure web application programming or configuration.

I found different threads talk about the same and found suggested solutions as well. But in that KB article Microsoft explains how reuse of session IDs could be useful and the same article doesn't mention any risks about the reuse of session IDs. Also in Session Identifiers | MSDN no risks mentioned other than SessionID values are sent in clear text whether as a cookie or as part of the URL.

So my question here is that risk is a real vulnerability / possible session fixation attack or it is just false positive risk?

Answer 1

There is a possibility that session identifier can easily traced before authentication. Because the identifier defines the browser session so when the user browse the login page the session id will be generated. so attacker can have an idea of pattern of session id. so better change the Session ID after successful login.

There are other scope where you should change the session identifier. You can have a look to the site https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

Answer 2

Using cookies always brings some level of vulnerability, if the transport medium is not secured.

This means that you could elaborate on what happens when someone eavesdrops session cookies or forms authentication cookies or any other cookies but having your communication over secured wire (SSL) removes all such threats.

I can't think of a reason why it would be ASP.NET specific and session cookie specific. Also, I don't quite understand what they meant here

[...] steal or manipulate session and cookies

First, the "or". To manipulate the session you have to steal it first. Then, the "and". You can't manipulate cookies, you can only steal them.

This should rather be then

To steal cookies and manipulate session.

In a response to such warning, you should make sure that:

• communication is always secured after cookies are issued
• cookies are properly destroyed when user logs out or closes the browser (there are no persistent cookies)