This is only a vulnerability if you don't have any checks in your code for which privileges a given session/ID has. Keeping the old session alive may be desirable so that, if an attacker got in ahead of the user, you can display a message upon a 2nd successful login attempt to the effect of "This system has already logged you in once, if this is your first time logging in you may click here to terminate both connections.", and if someone is attempting to log in after the first user successfully has, you can display a message to them reporting how many attempts and suggesting ways they can check their local security.
You can keep track of the new session ID with a variable in the old session, and vice versa.
I put in a check for "PHPSESSID" in the GET string (I could modify it to check for POST as well), no matter where on the site they're trying to go, and print out a special error message to raise their awareness of the attack. I might be going a bit too far in checking the entire GET string (not just variables), but I figure that paranoia is a better foundation to work from than gullibility; FIRST users become accustomed to the simple question of "Is there a PHPSESSID string in this link I was given?", THEN (when/if they ever feel up to it) they can move on to parsing the string, only looking for substrings following a ? or & symbol, etcetera.
Shade's Profile
Last 10 Comments
1
2