4

I am testing a web app and it works like this:

  1. user opens the page and is assigned a sessionId.
  2. user logs in, sessionId stays the same but user is also given an authToken.
  3. user logs out, authToken is deleted, sessionId changes.
  4. user logs back in, session Id is the same and a new autToken is given.

Is this app vulnerable to session fixation? I am confused because of the extra token that is given when the user logs in.

Marcel
  • 3,494
  • 1
  • 18
  • 35
b4da
  • 690
  • 1
  • 7
  • 20
  • On step #4 when you say "session ID is the same" do you mean the same as the new value assigned in step #3? Additionally, have you tested whether the app keeps the user authenticated if they don't have a valid session ID but do have a valid authToken? My suspicion is that the session ID may be assigned by the app server or framework but isn't actually used by the app for authentication. – PwdRsch Apr 04 '19 at 19:24
  • Hi, it is the new value assigned in step #3 and app does not respond to requests without a valid authToken. I asked devs to remove the sessionId value if it is not used by the app and they said it is required because of some server side processing. – b4da Apr 04 '19 at 19:48
  • What will happen if I guessed a correct `authToken` but wrong `sessionId `? will you consider me the legitimate client ? – AccountantM Apr 04 '19 at 19:53
  • _given an authToken_: this token is stored on the session, or a cookie? – ThoriumBR Apr 05 '19 at 12:44

2 Answers2

3

No, you are not vulnerable to session fixation, because of this authToken that you give to your clients when they log in.

You would be if

...the attacker has fixed a session he knows on the victim's computer, then the victim logged in with this session and made it authentic, now the attacker can use only this session to get access. But you are giving your clients new secret when they log in - the authToken.

without something new you give to your clients when they sign in, you would be vulnerable.

I am confused because of the extra token that is given when the user logs in.

In your model the authToken plays the role of the sessionID that you generate and give to your clients when they log in.

AccountantM
  • 296
  • 1
  • 6
2

We can't tell for sure with the information provided.

In order to verify, you could try to access some protected resource (which is only available after login), with different Requests:

  1. Request with session-ID and without authToken
  2. Request with authToken and without session-ID

If one of those Requests are successful, you know, where the session is really stored and can therefore tell, if it is a session fixation or not.

Euphrasius von der Hummelwiese
  • 1,018
  • 4
  • 20