On Tue, Feb 18, 2014 at 9:07 PM, Vernon Nemitz <vnemitz@xxxxxxxx> wrote: > On Tue, 18 Feb 2014 16:30:06 -0500, Aziz Saleh wrote > > Vernon: > > > > On Tue, Feb 18, 2014 at 3:41 PM, Vernon Nemitz <vnemitz@xxxxxxxx> wrote: > > > > > On Tue, 18 Feb 2014 11:52:50 -0500, Aziz Saleh wrote > > > (I'm leaving the details out, because no matter what I think > > > a bad guy might do, chances are his goal is something else.) > > > > > > > > I think I got what you meant. Why not customize the the session_id() > > to be more random. So random that someone has better luck winning > > the lottery. > > In general, that is not a bad idea, but ... (see below) > > > > > > As far as I can tell, the client still needs to know what session > > > it has been assigned, so it can keep telling the Server that it > > > is still participating in that session. > > > > > My way, I don't even change the session default usage (cookies). > > What I do is add another layer of protection that if someone wants > > to hijack the session, it would be very hard to (if not impossible). > > For example, in my session handler I associate the session with the > > current user's user agent and random cookie salt. This way if > > someone even guesses the session id correctly, once they try to use > > it and my session handler sees that there is a difference in user, > > it destroys the session. Normal users do not copy sessions across > > browsers, and for someone to hijack the session they would need to > > know the exact user agent of the user and that cookie salt. > > > > Aziz > > It seems you are saying that you have added more data to the session > cookie, which the bad guy can inspect and copy. So, not inherently > more secure than the session ID all by itself getting sent back > and forth between browser and Server. > > In a way, I'm doing some things like that, too, only not between > the browser and the Server. When a user's normal actions lead to > a normal session, the particular web-page responsible will be a > "parent" to all the other Web pages associated with that session. > Those pages all refer back to the parent page to make AJAX > requests, none can make AJAX requests by themselves. I have a > whole bunch of tests to make sure that if a child-page is opened > by a bad guy, it fails to work without the parent page existing. > > By the way, one of the other messages I've received in response > to my original question concerned a php.ini file setting, > session.use_strict_mode > (available PHP 5.5.2+) which appears to at least do the ignoring > thing, if a browser sends session data to the Server which does > not happen to match an existing session-data-file. Good show! > > vernnoner3voltazim > Vernon Nemitz > Glad you sorted it out. However, I don't think you understood what I meant. My original thought is that you were worried about session hijacking (someone finding out the session id a user uses, example and admin) and going into your site and plugin that ID into the URL (or cookie by default) to take control over that session, basically login in by the session id. What I do prevents that from happening by associating the session id to not just any user, but to that specific user that logged in.
