Catering for session collision
Moderator: General Moderators
Catering for session collision
So I'm embracing sessions, it's actually the first time I've had to deal with them to any great extent, previously (many moons ago) where sessions may have been a possible solution I was lead to believe they were 'buggy' although admittedly I never did any testing myself to confirm this.
Anyway, I'm opting for storing the session data in a database, and as I drafted up the code it came to mind that session collision is a possibility (small but regardless still a possibility). So it left me curious on two accounts.
1. Has anyone ever had any problems with unintentional/accidental session hijacking due to a session collision?
and
2. Does anyone actually bother to cater for the possibility of session collision?
It's actually more acedemic now really as I've already thrown in some initial code which although doesn't fully address the problem (it's still being developed) preliminary testing indicates that even if there was a session collision, no unintentional/accidental session hijacking would occur, but it still leaves me curious.
Anyway, I'm opting for storing the session data in a database, and as I drafted up the code it came to mind that session collision is a possibility (small but regardless still a possibility). So it left me curious on two accounts.
1. Has anyone ever had any problems with unintentional/accidental session hijacking due to a session collision?
and
2. Does anyone actually bother to cater for the possibility of session collision?
It's actually more acedemic now really as I've already thrown in some initial code which although doesn't fully address the problem (it's still being developed) preliminary testing indicates that even if there was a session collision, no unintentional/accidental session hijacking would occur, but it still leaves me curious.
Of course session hijacking is always possible, wether intentional (someone sniffed the traffic and stole the sessionID), or unintentional (a user copied and pasted his friend a url with an id in it).
There are ways of dealing with this, one of the quickest easiest and most effective is binding the session to the user's IP. Of course you will have to allow users with non-static IPs to disable this feature.
but I think this was the wrong forum, try 'theory and design'
There are ways of dealing with this, one of the quickest easiest and most effective is binding the session to the user's IP. Of course you will have to allow users with non-static IPs to disable this feature.
but I think this was the wrong forum, try 'theory and design'
When I say unintentional/accidental I mean by way of session id collision i.e. two users being issued/assigned with the same session id.jshpro2 wrote:Of course session hijacking is always possible, wether intentional (someone sniffed the traffic and stole the sessionID), or unintentional (a user copied and pasted his friend a url with an id in it).
There are ways of dealing with this, one of the quickest easiest and most effective is binding the session to the user's IP. Of course you will have to allow users with non-static IPs to disable this feature.
but I think this was the wrong forum, try 'theory and design'
A quick fix would be to store a random number in a seperate cookie on the user's system, than store that random number in their session, if they don't match invalidate the session. Isn't foolproof but it does decrease the odds.
Another fix is to keep a list of all generated IDS, and generate your own Ids, you set the Id with http://us2.php.net/manual/en/function.session-id.php
I think PHP already does this internally? (not sure)
Another fix is to keep a list of all generated IDS, and generate your own Ids, you set the Id with http://us2.php.net/manual/en/function.session-id.php
I think PHP already does this internally? (not sure)
OK, now, not trying to be funny, but, which one of my questions are you answering here? 1 or 2 ?jshpro2 wrote:A quick fix would be to store a random number in a seperate cookie on the user's system, than store that random number in their session, if they don't match invalidate the session. Isn't foolproof but it does decrease the odds.
Another fix is to keep a list of all generated IDS, and generate your own Ids, you set the Id with http://us2.php.net/manual/en/function.session-id.php
I think PHP already does this internally? (not sure)
This should be in the theory forum, imo.
Session collision is of course a concern, to cater for it will only require a simple check of the table (as you mentioned you are using DB's to store session data)
If that is the case, have a field for session id in the user table and store the ID there so you can then check if the id is already in use and regenerate if it is. Add a time check as well so you don't regenerate for a session id match that was last used a long time ago and will have since expired.
I myself have not had to deal with this as I am yet to defer from the default method of storing session info.
Session collision is of course a concern, to cater for it will only require a simple check of the table (as you mentioned you are using DB's to store session data)
If that is the case, have a field for session id in the user table and store the ID there so you can then check if the id is already in use and regenerate if it is. Add a time check as well so you don't regenerate for a session id match that was last used a long time ago and will have since expired.
I myself have not had to deal with this as I am yet to defer from the default method of storing session info.
Well, I originally posted this in the general section for the simple reason I was (or thought I was) asking general questions, as I noted in my original post, I'm not looking for any ideas/theories on how to solve the problem. But feel free to move it where ever you like, it makes no odds.
Oh, I also got out of the wrong side of bed this morning
Oh, I also got out of the wrong side of bed this morning
General covers anything not covered by the other forums.. i.e. anything not related to development 
because both of your questions ask for experiences, of which I have none, I couldn't answer them but I did assume you would be wanting to know of a way to avoid collision in the likely event of someone answering "Yes" to either
Have a look at Concurrency patterns - just so happens to be the chapter of PoEAA I am currently reading.
because both of your questions ask for experiences, of which I have none, I couldn't answer them but I did assume you would be wanting to know of a way to avoid collision in the likely event of someone answering "Yes" to either
Have a look at Concurrency patterns - just so happens to be the chapter of PoEAA I am currently reading.
OK, let me just expand a little to avoid further confusion.
I've already written my session handler base, the base also includes code which deals with other areas of session data handling other than just DB storage, as a "Brucey Bonus" that code also provides a decent inital base for session collision/hijacking detection/prevention, I am happy with the approach I have chosen therefore I'm not looking for ideas/theories.
I've already written my session handler base, the base also includes code which deals with other areas of session data handling other than just DB storage, as a "Brucey Bonus" that code also provides a decent inital base for session collision/hijacking detection/prevention, I am happy with the approach I have chosen therefore I'm not looking for ideas/theories.
Well, in all honesty, you've already answered your own question(s) anyway.. you've stated it can happen, so it should be treated as it will happen, thus yes - I would cater for it if I needed to handle session data in such a way. Most of the time I do not need to do this myself, as PHP does this already.

I've had a look over at php.net and I don't see anything to suggest that collisions are not possible but then again I don't see anything to suggest that they are possible either. So when you say "as PHP does that already" where is that documented? Are you suggesting that PHP itself tracks which IDs have been issued, when they've expired or destroyed and are free for use again? I can't remember exactly but it is my understanding that session ids are randomly generated from a combination of server time and PID (I'm sure there was more than that) the last time I looked at that code (approx a few years back) I don't remember seeing any storage/tracking mechanism (but then, I wasn't looking for it either). Perhaps I'll just go look.Jenk wrote:Most of the time I do not need to do this myself, as PHP does this already.
As for answering my own questions, read them again, I don't see how I've answered my own questions? I have decided (by way of lack of documentation) that collisions are something I should account for, however I am asking if anyone else has had any problems/issues of this nature and also if they take it into account at all <-- two questions that I cannot answer myself.
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
Redmonkey, I suggest you read viewtopic.php?t=36218&highlight=session+collision