I am writing a small app.

It creates a session once the user authenticates. I am aware of this definition of fixation attack from owasp.

Attacker uses the app

In this App, once they log out the sessionID is destroyed. If they are still logged in, and fix this sessionID to another user, they would redirect the user to their profile.

But is this the trick? And how is it possible to set their sessionID in a different user, without accessing their PC?

  • No, the "trick" is that you have to change the sessionID when the user performs a log-in. So no matter what sessionID was valid before, after the successful authentication the authenticated session has a new sessionID.
    – Robert
    May 9, 2022 at 11:58
  • @Robert I dont see what the problem is if that isnt done. Sorry. Please take a look at the link i provided.
    – Mah Neh
    May 9, 2022 at 13:49
  • A session fixation attack requires the attacker to prepare a session that is later logged-in by the victim. If you create a new session upon login then session fixation attack will fail because the attacker only knows the old sessionID but not the new.
    – Robert
    May 9, 2022 at 14:33

1 Answer 1


(Is the explanation under "Attacker uses the app" your own understanding or something you found on the Internet? If the latter, the author didn't actually fully understand the attack or failed to explain it correctly.)

The vulnerability is actually very simple: the server/app uses sessions to store the authentication state, and which session is used can be controlled by a third party (e.g. via URL).

The attacker doesn't have to log in/out or even have an account. All s/he needs is the ability to obtain a session id.

Example attack:

  1. Hacker opens the vulnerable website and gets a fresh session id (123 in this example)
  2. Hacker tricks the victim to log in with a URL containing the session id, e.g. poor-site.com/password-protected-page-the-victim-wants-too-see?session=123
  3. Hacker can now access any other contents as the victim using poor-site.com/another-page?session=123

This attack is popular because many frameworks with backwards-compatibility baggage allow session info to be carried via URL as some (old) browsers don't handle cookies (or have them turned off).

If session ids can only be supplied via cookies, then this vulnerability becomes much harder to exploit (CSRF required).

If you still don't get it, think of this analogy:

There's a row of high-tech lockers [=sessions] in a public venue. The attacker walks up to one and the locker prints a ticket with the unlock barcode [=session id]. The attacker takes a photo of the code and leaves the door open. The victim then approaches, not knowing the technical details of the system [session id in URL], simply takes the pre-existing ticket, put his things in and closed the door [=logging in using a pre-planted session]. The attacker then opens the locker with the photo of the code.

One mitigation is to print the unlock ticket after the door is closed [= generate new session ID during log in].

  • I understand this well. But sessionIDs can be send in the body of a request (cookie). So they are encrypted. Sending it in the URL is utterly dumb...that is why I say I do not see the reason for regenerating. But I get your point about backwards comp. Just do not see how this affect my app, which does not use URL-session.
    – Mah Neh
    May 10, 2022 at 11:36
  • Ok i got it. In the other cases there are other tricks, like sending sessionID by tricking a user to log in from a fake/attacker made form...I am not sure if you can overwrite a cookie this way. I presume you cant bc it is httpOnly
    – Mah Neh
    May 10, 2022 at 12:02
  • If the server only uses the session ID in the cookie, then this attack doesn't apply. However, like I have mentioned above, many frameworks allow session in URL for compatibility.
    – billc.cn
    May 10, 2022 at 12:47

You must log in to answer this question.

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