On Tue, Feb 18, 2014 at 11:17 AM, Vernon Nemitz <vnemitz@xxxxxxxx> wrote: > Hello. > > m developing a future web site and have basic session stuff > working OK. In thinking about what someone might do to bypass > the security tests I've associated with the $_SESSION data, it > occurred to me to experiment with a session ID that did not exist. > Could someone create their own session outside of my carefully > constructed hodgepodge? Yes.... > > I should mention that I'm not using the "cookie" system for > session-data propagation; I'm using the URL method with AJAX. > The user never sees the URLs being specified, unless a JavaScript > debugger is fired up, to set breakpoints and look at various > variables in the AJAX JavaScript code. With enough patience > it should be quite possible to identify a session ID, and > copy it. > > To see what might be done with that ID, first go to the "tmp" > (or other) directory where session data gets stored, and pick > any session that happens to be there. Suppose it is > "sess_pq89kf43rsmjfb75mb9bddko46"; copy the name to a note > somewhere, and now delete ALL the session data files from that > session directory. > > Now create a URL to call the initial .php file that the web > site would normally call, which would start a session create a > session-data file in the session (tmp) directory. Here I'll > call that file "first.php", and I'll use a "relative" URL > address: "./first.php?SessionName=pq89kf43rsmjfb75mb9bddko46". > We make the assumption that some "bad guy" has constructed a > URL similar to this one. When the URL is invoked, so as to > cause the Web Server to run the PHP code in "first.php", > one of the first things in that file is likely to be a call > to the "session_start()" function. > > NORMALLY, you want session_start() to create a new and unique > session-data-file, when no file exists in the session directory. > NORMALLY, if the URL includes a session ID, we want session_start() > to look for the previously-created session-data-file, in the > session directory, and open it. In this particular case, > however, there is no previously-created session-data-file > (because in this scenario, all such files were deleted a > couple paragraphs ago). > > LOGICALLY, the session_start() function should EITHER (1) create > a new session-data file, unrelated to the ID in the URL, OR > (2) do nothing and return FALSE, because of not actually > starting a session. > > But what actually happens is that session_start() creates > a brand-new session-data-file using the ID that had been > supplied in the URL. Our bad guy now has his own private > session started! > > If the above is deliberate behavior, then I need to know > what session-function can I use (and I've examined most of > them fruitlessly) to say, "Hey, the session ID in this URL > is invalid, because no such session-data-file exists!". > > Yes, I know I can work around the problem by making an > effort to extract the session name from the URL and > using the file_exists() function. But that cannot be the > most efficient way, in an environment where we want PHP > code to run as fast as possible. Not to mention that > such a work-around automatically prevents session_start() > from being the first thing in the file, so the trick can't > be used with the cookie method for session propagation --and > I assume a bad guy could construct a cookie OR a URL.... > > Finally, in reading through the wiki page at: > https://wiki.php.net/rfc/howto > It mentions some ordinary stuff about seeking out other > efforts that might coincide with one's own ideas, and, > sure enough, there exists an RFC about adding a set of > arguments to the session_start() function (currently it > takes no arguments). > > In thinking about how to deal with the issue I encountered, > I could see that an easy way to handle it is to have an > argument that would trigger any of 3 different behaviors, > for the function. The default would be the existing > behavior, for compatibility. One option would cause the function > to return False if a URL contained a session ID that did not exist. > And one option would cause the function to ignore that session ID > in the URL, and just create a brand-new session-and-ID. > > This particular argument would of course be "extra", relative > to the other arguments proposed in that existing RFC for the > session_start() function. > > Thank you! > vernonner3voltazim > Vernon Nemitz > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > 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. 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
