same logged in user assigned different session ids (in different browsers)

views:

291

answers:

same logged in user assigned different session ids (in different browsers)

Hi,

I've implemented a mysql-based session interface in php. I just found out that if I log in to my account using browser A (e.g. Chrome), and then I log in to the same account in another browser B (e.g. IE), each browser is assigned 2 separate session ids. How can I make it such that when I log in again using browser B, I retain the active session of the previous browser A?

The issue at hand is that I'm storing certain information in the session and the data not being synchronised between the same users in different browsers and is wrecking havoc. :S

Is there a way to achieve this?

Thanks!

Don't store the data in session, store it in the database.

RedFilter 2010-04-29 16:25:17

the session is stored in the database. but as i want to reduce the number of database calls, i'm storing some in the session.e.g. the session contains information for readonly purposes. so i don't need to call the database again to get this data. instead, only updates/inserts calls are made.

Lyon 2010-04-29 16:32:39

Sessions are normally identified by cookies, which are only visible in one browser. You could probably use Flash to share the session ID between browsers, but I cannot think of a use case. The point of the session is to store data which is bound to a single browsing session, and not to the user in general. You should use a database or some other form of server-side storage for generic user data.

Tgr 2010-04-29 16:30:53

i'm using the database to store generic user data but im also storing some basic statistical data in the session table so when through ajax polling, the script will just fetch it from the session table and avoid making excessive database calls.

Lyon 2010-04-29 16:49:11

+2 A:

If you're storing the session in the database, add a mechanism whereby the userId is stored as part of your database's session record, creating what I like to call a "semantic session". When the user logs in, check to see if another session already exists; if so, use session_id() to fixate the new session to the old session's ID, which will join them (and should change your new session's ID for all subsequent requests). Be sure to only perform this action during the login step, or you might end up with freaky race conditions of two sessions trying to be each other and "swapping".

Dereleased 2010-04-29 16:31:12

thanks! Im using dbsession script to manage my sessions. how would I detect if the userid is already stored as part of another active session in the db's session record? I do store the user's userid in $_SESSION['userid'] but that appears under the table record session_data.

Lyon 2010-04-29 16:45:34

you would actually have to modify the schema of the table that stores the data; my session table, for example, is set up with the following columns: `sessid, userId, lastIp, sessData, sessBegan, sessLast`. In doing so, you need only key off of the userId column. This will require some customization of your session storage engine.

Dereleased 2010-04-29 17:15:12

thanks. i managed to modify my table schema and session storage engine. one think i realised after doing this is...i can't regenerate the session id on login now. if i do that, it'll log out the other browsers. is that a security risk now?

Lyon 2010-04-29 17:45:00

this will open you to some session fixation vulnerabilities, yes, but without designing an extremely complicated solution there's really no way around that. What you can do is always regenerate the session ID when the user first logs in (i.e., when another session for the same user is not already active), as well as limit your exposure to session fixation attacks by changing the name of the session identifier (default PHPSESSID) and only allowing the session ID to be set from a cookie, preferrably from a secured cookie.

Dereleased 2010-04-30 09:06:45

Typically session fixation attacks rely on the attacker being able to force you to use a predetermined session ID (e.g., by specifying it in the QueryString), which they can later use to perform authorized actions. Regenerating the session ID once the user successfully logs in for the first time, and subsequently re-fixating it for subsequent logins to the same active session, along with not allowing the session ID to be specified by easily manipulable transports (GET, POST) should still afford you a great deal of protection. Check out secured cookies, too, while you're at it.

Dereleased 2010-04-30 09:08:59

ansaurus

tags:

views:

answers:

same logged in user assigned different session ids (in different browsers)

related questions