Is this a session fixation

Question

I really can't understand the session fixation attack.

I've read OWASP definition that said:

Session Fixation is an attack that permits an attacker to hijack a valid user session. The attack explores a limitation in the way the web application manages the session ID, more specifically the vulnerable web application. When authenticating a user, it doesn’t assign a new session ID, making it possible to use an existent session ID. The attack consists of obtaining a valid session ID (e.g. by connecting to the application), inducing a user to authenticate himself with that session ID, and then hijacking the user-validated session by the knowledge of the used session ID. The attacker has to provide a legitimate Web application session ID and try to make the victim's browser use it.

At the same time, I read this report, and the security researcher says that this vulnerability is session fixation session fixation report:

Summary:

The application does not set a new Session ID in the cookie after what appears to be an authentication attempt by the user. If this was a successful login and the Session IDs are stored in cookies then this application is affected by Session Fixation vulnerability.

My question is: is the vulnerability in this report session fixation, and is the steps of testing this vulnerability the steps of testing session fixation?

Answer 1

The text that you quoted describes a session fixation problem. But the entire report (I included it below for reference) describes a problem with logout. Specifically, it says that logout only happens on the client side, not the server side. Per the OWASP Session Management Cheat Sheet's discussion of the logout button:

the web application must invalidate the session at least on server side.

So, if correct, this is a vulnerability, just not session fixation. (I'm not sure if it has a name.)

The OWASP's guide for Testing for logout functionality describes how to test for this, but the report's instructions to reproduce, included below, also describe it.

Just to be extra sure, you may also wish to test for a session fixation vulnerability. Just follow a session fixation testing guide, such as this one from OWASP.

Vulnerability Report

bug-session fixation
Severity: Medium

Summary:

The application does not set a new Session ID in the cookie after what
appears to be an authentication attempt by the user. If this was a
successful login and the Session IDs are stored in cookies then this
application is affected by Session Fixation vulnerability.

To reproduce this vulnerability

1.open chrome and download edit this cookie ad-don
2.now open https://www.reddapi.com/ and log in 
3.now go to edit this cookie addon and click export all cookies ...
  by clicking this we get the cookie copied in clipboard..
4.logout from your https://www.reddapi.com/ account...
5.if needed u can close and open your browser.
6.now again go to https://www.reddapi.com/ but don't login..just
  simply go to edit this cookie addon and click import a cookie
  and paste the code which we previously exported.
7.after pasting just refresh the page and that's done you are now
  logged into your account without login details...

problems faced

the problems face if the vulnerability exits are
1.anyone can easily hijack victims or users session and get into his account
2.cookie stealing is the best way the hacker can get into and account..
  it would not take more than 5min to steal someones cookie using php n all...
3.even friends can fool the victim and get him hacked..

Answer 2

It doesn't matter what the tester thinks. Test it yourself. Open the site, check the cookies.

Login.

Check the cookies.

Did the site reset the cookies?

If not, you are vulnerable to session fixation.

Other varieties exist. Logoff and logon, did the cookie change?

It should change.

That's it. Make sure the cookie changes.

The risk is somehow someone can check the cookie or set the cookie while you're logged out, wait for you to login, and impersonate you using your cookie.