On 18 Feb 2014, at 16:17, Vernon Nemitz <vnemitz@xxxxxxxx> wrote: > 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. This would not take any patience. It’s trivial. No more or less trivial than finding the session cookie, especially since name you use below is "SessionName" - do you really think it would take patience to find the session token when it’s called that? > 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! Hang on, I don’t see the difference. All that’s happening here is that "bad guy" has decided what his session will be called. Why does this matter? What does this give him over just hitting your homepage and getting a random name? > 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!". You can’t. There is no built-in way to check that a session ID corresponds to a valid session. I’m guessing the reason for this is that you should never need to do that. > 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…. The call to session_start() doesn’t need to be the first thing in the file, it just needs to be before any output. But, please don’t check that the session ID is valid before calling session_start. What would you do differently if it’s not valid? And why? I really do think you’re creating a problem that doesn’t exist. > 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. Again, the core question is why you think it’s a bad thing that a user can specify what their session is called. Try making it something potentially dangerous like "/etc/passwd" (only dangerous if you’re stupid enough to run PHP as the root user) or "." or "..". I’d put decent cash on PHP containing sufficient checks on the name to prevent those causing any issues. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
