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.

Improve this question
4
  • 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
    Commented Apr 4, 2019 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
    Commented Apr 4, 2019 at 19:48
  • What will happen if I guessed a correct authToken but wrong sessionId ? will you consider me the legitimate client ?
    – AccountantM
    Commented Apr 4, 2019 at 19:53
  • given an authToken: this token is stored on the session, or a cookie?
    – ThoriumBR
    Commented Apr 5, 2019 at 12:44

2 Answers 2

Reset to default
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.

Improve this answer
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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .