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 >>> 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. Well, if I'm not mistaken the default session handler uses session IDs with 128bit at least, so guessing a valid session ID is already way harder than winning the lottery. Anyway, it still seems to me Vernon is afraid that an attacker might use an arbitrary session ID -- what shouldn't do any harm. -- Christoph M. Becker -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
