Re: session_start() and a bad guy

Please either include the mailing list when replying or ask me about my consultancy rates. On 18 Feb 2014, at 21:05, Vernon Nemitz <vnemitz@pinn.net> wrote: > On Tue, 18 Feb 2014 17:00:03 +0000, Stuart Dallas wrote >> On 18 Feb 2014, at 16:17, Vernon Nemitz <vnemitz@pinn.net> wrote: >> >>> With enough patience it should be quite possible to identify >>> a session ID, and copy it. >> >> This would not take any patience. [WINDOWS-1252?]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 [WINDOWS-1252?]it’s called that? > > If a different name was used (which I am actually doing), I > would not expect that to be more than a matter of patience > for the ID number to be discovered. I only used SessionName > in the example below to make it easier to describe the overall > situation. It won’t take patience, just some very quick observation of the requests going back and forth between client and server. Anyone who needs patience to spend a few minutes observing a site’s behaviour doesn’t deserve the label "bad guy!" > [snip] >>> 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 [WINDOWS-1252?]don’t see the difference. All [WINDOWS- > 1252?]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? > > I'm using the definition that if someone bypasses the session > handling process that I have defined for the web site, then > that someone qualifies as a bad guy, and has worse things in > mind to accomplish. I won't pretend to know exactly what he > has in mind, but I CAN in theory attempt to prevent early > success at bypassing the site's session-handling stuff. What session handling process? What are you doing in your process that will have a problem if someone creates a new, empty session with an ID they chose? If that has any negative consequences then you need to look at how you’re using the session. The existence of a session should not be taken to indicate anything; it’s the contents of the session that should matter. >>> 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 [WINDOWS-1252?]can’t. There is no built-in way to check >> that a session ID corresponds to a valid session. >> [WINDOWS-1252?]I’m guessing the reason for this is >> that you should never need to do that. > > "Never need to check to see if something is valid?" > Come on! Whoa, way to change my words to make me look like an idiot. You want a gold star for that?! I said there is never a need to validate that a session ID corresponds to a valid session, where (in this case) valid simply means exists. The validity of a session as far as your code goes should depend on its contents, not its existence! >> But, please [WINDOWS-1252?]don’t check that the session ID >> is valid before calling session_start. What would you do >> differently if [WINDOWS-1252?]it’s not valid? And why? I >> really do think [WINDOWS-1252?]you’re creating a problem >> that [WINDOWS-1252?]doesn’t exist. > > With respect to that "first.php" file, there should NEVER > be a session ID in the URL that calls that file. So, if > there is, that means someone is messing around where > they shouldn't. I would want to return an error message. Two words that should never (!) be in the same sentence when describing software: should and never. Defensive programming is all about never assuming anything, so there should be no reason why first.php cannot handle being given a session ID. If it’s that important to you all you need is a chunk of code at the top of first.php that says "if there’s a session ID here, redirect to the same URL without the session ID." Do that before anything else and you’re covered without assuming anything. >>> Finally, in reading through the wiki page at: >>> https://wiki.php.net/rfc/howto > [snip] >>> 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 [WINDOWS-1252?]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 [WINDOWS-1252?]you’re stupid enough to run >> PHP as the root user) or "." or "..". [WINDOWS-1252?]I’d put >> decent cash on PHP containing sufficient checks on the name >> to prevent those causing any issues. >> >> -Stuart > > Perhaps it is just my control-freakiness, wanting to ensure that > users interact with my site in the way it was designed, rather > than some other way. Your site sounds like it’s been designed with a specific user in mind; one who knows how they should be using it. That’s unrealistic and potentially quite dangerous. All users are ignorant/stupid <- develop your site with that in mind and stuff like this won’t be an issue. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/