0

I am testing website security when I came across this:

When I enter the site URL, the user is given a session ID without any user input like:

7F746326038B30F51609423B2086BEBB

Scenario 1: Once I logged into the website by providing the correct credentials, it logs in but the session ID remains the same. In the same session, I logged out again to see that the session ID was still not changed. Again logging in gives the same session ID.

Is this a potential vulnerability of the website? Can session fixation or hijacking be performed around this?

Scenario 2: What if the site gives a session ID when the user lands on the login page and does not change it after login, but it gets changed after logout and goes on? Is this also a vulnerability?

Scenario 3: I am logging out of the current user and logging in again as a different user. The session id is still the same.

Note: The site is using HTTPS and HTTP only and Secure flags are enabled for the Cookie.

Supraja
  • 7
  • 5
  • There is no way to answer this question in a meaningful way. "Session Id" is not a concept that universally means something specific. It could be used by/for anything and may not even be used/owned by "the site" (i.e. some ad-tracking script sets this cookie for they *fine* purposes). – Alexei Levenkov Apr 16 '22 at 00:56
  • I get it. But if I change a single value of this Session ID it logs me out of the site, or if I use the authenticated user's session ID in an unauthenticated user's session, it is logging into the former and displays all the data. Basically, it is in the Cookies but set right after the user visits the login page. – Supraja Apr 16 '22 at 01:02

1 Answers1

0

I'm assuming by "session ID" you mean the value in a cookie or bearer token that is transmitted to the server with every authenticated request, and is used as the key in a server-side lookup table of authenticated user sessions with associated users that have some non-overlapping permissions.

This absolutely sounds like a session fixation risk, especially the third scenario. The attacker either creates or discovers the session ID on one device (possibly a shared device), then logs out, copies the session into their own device, and waits for somebody else to log into their own account on the compromised device. When they do, the attacker is logged in too.

Scenario 2, and to an extent scenario 1, depends on whether the site will keep using a preexisting session ID. If the server accepts an existing session ID without changing it, then you can plant a session ID on one device, plant the same on your own device, and wait for somebody to use the compromised device. You might only get one victim (in scenario 2, where the ID is changed after logout)

Note that scenario 1 is only slightly vulnerable if the session ID changes when a new user logs in (the thing explicitly ruled out in scenario 3). However, even in that case, scenario 1 (and also 2) is potentially vulnerable because, since the session ID persists after the user logs out, an attacker who can access a device last used by Alice (after she signs out) can steal her session ID, and wait for her to log in again (maybe it's her device, so she's the primary user?).

It is definitely best practice to change the session ID every time the authentication state changes (any user logs in or out, a session expires, etc.) rather than ever reusing a session ID that the client sends you, as that ID may have been compromised.

CBHacking
  • 40,303
  • 3
  • 74
  • 98
  • I got my answer now. Thank you so much for your precise and clear explanation concerning each and every scenario. Marking this as the correct answer :) – Supraja Apr 17 '22 at 06:08
  • I have another doubt. So can this session ID be captured in any way? As the site uses The site is using HTTPS and HTTPOnly and Secure flags are enabled for the Cookie. – Supraja Apr 17 '22 at 08:21
  • Well, it can of course be captured by anybody using the device directly (e.g. by using the browser dev tools, or routing the request through a proxy). It can also be captured by anybody on the network if you're not using TLS (HTTPS), but you mention the Secure flag so that's probably not a risk. Otherwise... if it's a cookie with httponly, there's not much other risk. A bearer token can be stolen by XSS. But those are just general webapp threats, not specific to the weaknesses you highlighted. One last exposure risk: if the server DB is breached, and the session tokens therein aren't hashed. – CBHacking Apr 18 '22 at 08:30
  • Got it. Great explanation :) Just what I was looking for. Thanks – Supraja Apr 18 '22 at 21:37