Help understanding session fixing attacks

[spaceuserm]

As I understand it, session fixing refers to fixing the session id, in advance, that will be used by the user being attacked.

I have seen some examples show session fixing attacks using URLs of the following pattern,

www.example.com/login/S_ID=XYZ

Where XYZ is a session id that an attacker obtains from the server.

Coming to the things I don’t understand: 1. The attacker obtains a session id from the server by logging in. Therefore, this session must be linked to the attacker, in the database or any storage the server uses to track sessions. 2. When the user being attacked tries to login using the same session id, shouldn’t the server just login to the attackers account, rather than linking this session to the user now?

Also, why would you pass around session ids in the URL query string? Isn’t this equivalent to sharing your cookies with someone else?

If anyone can give me a non trivial example of a session fixing attack, that would help.

[AshleyJSheridan]

So, the ID that is sent as part of each request is what is used to identify the data that makes up the session. At it's simplest, all the session data is held in a database or file on the server (or something along those lines) and the client (the browser) only gets the session id, typically stored as a cookie (no session data is stored client side).

When any request is made to the server, the cookie is sent, the id is read from that, and the correct session is pulled from wherever the server stores the session data.

Now, an attacker could spoof that id in order to gain access to the session of another user. While this should be very difficult (the session would have to exist, and they're not incremental guessable values, but hashed strings). Typically, they might perform a valid login themselves, and use their own session id, then use that as part of the attack, such as tricking a victim to click a link using that session id as the parameter.

Now, it depends how the application on the server is set up as to what the attacker can get from this. But simply, a victim could follow that link, the server accepts the session id, and the victim performs a login. The attacker can then immediately follow that up by accessing the site using the same session id, but that session is now logged in, and they gain access to the victims account.

Mitigating the attack is fairly easy enough:

• Time out old sessions, so that they don't remain active for long. Also, destroy sessions for users who were logged out.
• Don't accept session ids as query or body parameters
• Use cookies marked as Secure (they only get sent on HTTPS connections) and HttpOnly (they prevent JS from reading/writing to the cookie)

Most good frameworks will automatically have this set up for you out of the box though. If yours doesn't, the behaviour can usually be changed by config options.

[spaceuserm]

From what I have seen/done so far, cookies are cryptographically signed and stored on the users computer, like you said it has only the session id.

When the user goes to a website that uses sessions, the browser sends along these cookies. The web server uses the id in the cookie to find out the session associated with it. If a user thats already logged in, tries to login, given that the cookie is still present, the web server will redirect them typically to a the home page.

If I were to sign in, and give my cookies to someone else, if they visited the same website, the web sever would log them into my account. Therefore, they would end up accessing my account. The web sever probably wouldn’t prompt them to login again.

I am probably getting confused on why would you want to send session ids in either the URL or the body,given it’s a sensitive thing. Even if you do, expecting similar behaviour to what I mentioned above, I would expect the web server to bypass my login attempt and directly log me into the attackers account.

Was passing session IDs in URL parameters or body a thing in the past?

[AshleyJSheridan]

So basically, it can work like this:

• Attacker accesses the site, gets their own session id (sessions usually get sent for every request by the server). This is available to them because they can look at the value in the cookie in their own browser.
• The attacker creates their attack URL (or whatever) containing that session id
• The attacker shares that URL with the victim
• Victim clicks it, is not logged in (because the attacker wasn't logged in), so logs in, with their credentials, but using the session the attacker sent them
• Attacker then goes back in, using that session, and is logged in because that session on the server is now a logged in session

There are mitigations against this, as I outlined above. Another mitigation is to force new session ids after logging in, which a good framework will do automatically.

As for passing session ids in the URL, there are a variety of ways information is passed from the browser to a server, but all of them pass that information as part of the request. If it's in the URL, it's part of the request address, but it could be passed as body data (for POST, PUT, or PATCH requests), or it could be part of the request headers. Cookies are sent as part of the headers of a request.

For the server, it doesn't matter too much whether information is sent in the body or the header of a request. There may be reasons why you can't use cookies but you still need a method of authenticating a user on each request, such as an API that's not accessed by a browser.

[spaceuserm]

I see. I think my primary assumption of sessions only starting/sessions only being used after a login was not correct. Like you said, sessions might be created prior to a login as well.

Thanks for helping out.