note 12838 deleted from ref.session by sniper

To pablo@phpshop.org 03-May-2001 10:03<br> The anonymous post from 22-Apr-2001 09:53 is not talking about session hijacking but a local exploit. Of course anyone can hijack a session by getting the sessionID from listening to network traffic or just physically sitting at your desktop.<br> The point is the following (I believe): A machine have users alice and oscar. Alice has an application in http://host.com/~alice that uses sessions. Oscar can set up php scripts in his directory http://host.com/~oscar and if he guesses (or just looks at the cookie in he's own browser, or just goes to he's own page since the cookie will be sent there too) the sessionid of an ongoing session he (in he's scripts, not browser) will get access (read and write) to all of the session variables in alices application. <br> The solution that is missing is that there should be a way of restricting the scope of session variables to only certain directories.<br><br> A temporary fix would be to serialize and encrypt your variables and then store that as a sessionvar. But since files have to be readable to the webserver, this usually means oscar can read the source too. Right? So he'll be able to use the same encryption and password anyway.(Hmm... never thought of this, but this generalizes to reading all kinds of interesting stuff from other users php-scripts like business logic, how and with what password to connect to a database... Reading other peoples public_html when it just contained html just wasn't that exciting.)<br> Was this clear enough? Am I missing something? Didn't bother to test... henrik