Does the ability for a user to choose the value of a session id cookie constitute a security flaw?

Question

In the context of a web application, a user connects to this application and a session id cookie is set to authenticate the user for next requests. As the cookie is actually present before submitting the login form, there is no new value generated on login success but instead, the value present in the cookie is taken as it is. So a normal user can choose to set the value to ‘0000000000000000000000000000’ for example.

Now I don’t know, but maybe there is a way for an attacker to set the cookie value of a victim before he/she logs in and once the login succeed, the value becomes valid and accepted for the server and then can be used by the attacker to enter the victim’s account.

So, is there a security risk in the fact that the value of the session id cookie is not necessarily chosen by the server?

EDIT: Some precisions regarding the first answers. I removed the tag "attack-prevention" because I just want to evaluate the risk of the scenario described as it is. I know HTTPS could resolve many security concerns but this is not exactly the question.

Answer 1

Yes there's a risk as this is a classic session fixation issue (OWASP Page). Standard good practice for web application session management would always be to re-issue a random session token whenever the user submits a login. Anything else (either not re-issuing on login or allowing user set session token values) is not a good idea.

How much of an issue this is depends on exactly how the application works and the user environment. Some examples of this being a risk

• A lot of web sites have unauthenticated ares which are not encrypted. so if the token is set on these and then not re-isued, the token can be hijacked by a packet sniffing attack (e.g. over a wireless network) before the user logs in and then the authenticated session can be hijacked

• If the application is accessed from a shared PC environment then an attacker who can set the value of the token in an open browser, would be able to hijack a users session if they use the system without closing and re-opening the browser (assuming that the token is deleted when the browser is closed).

Answer 2

This is a security concern, but not one that you can do anything about as the client can always set whatever session ID they want. If there is no session server-side with that ID then the user is likely to see a session expired message and be forced to authenticate.

If an attacker is able to obtain the legitimate users' session ID there is the possibility of a session-hijack by setting the same session ID on the attackers browser and navigating to the site in question.

HTTPS goes some way towards preventing this kind of attack by stopping a traditional man in the middle theft of the session ID.

There are other methods by which an attacker can obtain a victims' session ID such as a cross-site-scripting attack in vulnerable web applications. In such an application it is trivial to trick the victim into opening a page which may run some attacker-supplied javascript which sends them the session ID and allows them to assume your identity with that service.

I'm not so concerned about a hacker having the ability to set the session ID prior to login as when the victim authenticates with the web application, the response will set a new session ID supplied by the server.

Most web applications these days also contain secondary measures to prevent session hijacking through other cookies that contain checksums with machine specific information hashed in them. Sites such as Facebook allow you to specify a list of safe devices to prevent these kind of attacks.