melbourne chapter

Sessional variables are variables that exist across a certain period of a web clients visit to your application. Sessional variables does not mean that your PHP application is running the whole time. Infact it works by saving all your sessional variables to a datasource at the end of execution. There is no way for us to store something in application memory (or RAM [to my knowledge]) that can be accessed again by another request.

Because of this it means that Database Pooling cannot be achieved without a layer manager (such as SQLRelay) and we can’t have our application prepend tasks (such as Model2 MVC prepend or boot tasks) performed once per client connecting to your site for a few requests.

Each time a PHP page is called everything is loaded up, and then teared down, including our sessional variables, which are stored to disk. - When your client makes another request - your sessional variables are searched for, and loaded into memory. It usually identifies the user through the HTTP headers where the browser maintains a session ID (issued automatically to your browser by php using session_start() call) and submits it to the server each time.
Sessional Hijacking/Fixation is something that is highly relevant to this topic and is a must read for learning about Session handling in PHP.

“Session security is a vast and complex topic. One of the fundamental principles of Web application security is to never trust data from the client. However, in order to achieve statefulness, the client must identify itself by sending a unique identifier. This fundamental conflict creates significant complexities for developers wanting to build secure, stateful applications. In fact, the session mechanism in any Web application is likely to be that application’s most vulnerable feature, and session security is one of the most complex topics of Web application security on any platform.” - Chris Shiflett

A great security recommendation he makes it to reissue a new session ID when reauthenticating or chaning a users access level.

session_regenerate_id();
$_SESSION[’logged_in’] = true;

Before considering how you will manage your sessions, I recommend you read the relevant articles on PHPSec here:

• http://www.phpsec.org
• http://shiflett.org/articles/security-corner-feb2004
• http://www.hackerscenter.com/archive/view.asp?id=21242 - A very well written article

The process of loading into memory is handled by a few different sessional method handlers. A detailed section is provided on PHP.net on Sessions.

Typically sessions are stored in temporary files on the server, and relies on the security of the webserver temporary folder to limit access to those variables. We can change the way we save where sessions are saved by writing our own class to handle the access of sessional variables. It also means that we can change where they are stored (say to a database), and because we have that contol over the read/write access we can do some nifty tricks like encryption, and extend the checks (such as cookie checks, regenerating ID’s, mutex) to provide another level of security to our sessions.

There is no silver bullet to writing sessional management as it changes depending on your requirements. Some implementations make use of encryption with a database, higher overhead, and some use persistent/sessional cookies etc. Searching online will reveal a lot of scary holes in standard session management, and also reveal a lot of different ways of managing it all.