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 > > On Tue, Feb 18, 2014 at 11:17 AM, Vernon Nemitz <vnemitz@xxxxxxxx> > wrote: > > > > > Hello. > > > > > >[snip] > > > > The only issue I see with your issue is if the user has access to > > the tmp directory and/or a user is using that session they hijacked. > > If that is so, why not use a local directory to store sessions, > > which on most shared hosting (at least the smart ones) will limit > > access to your directories from other users. > > What I described was a bad guy inspecting my JavaScript code and > imitating what it does, for his own purposes. If there is a file > called "first.php" which the JavaScript calls, then he can call it, > too. If he sees that the JavaScript passes a session ID, then > he can imitate that, too. I'm not seeing any requirement for > him to know where the session stuff is located on the Server; > he is simply calling various .php files to see what he can get > away with doing, that the normal users are prevented from doing. > (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. > > Why not use the database to store sessions? It is more secure than using > > the URL/Cookies only.I usually use the session_start() along with a > random > > cookie string as salt and store this session in the DB along with other > > user parameters (agent string, ip, geo, etc..). > > > > Aziz > > 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. That's why one of the > standard behaviors is for a session cookie to exist. So, I'm > not understanding how ONLY having the Server know about the > session (regardless of where the data is stored on the Server) > can work. > > vernonner3voltazim > Vernon Nemitz > > > 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
