Session
Database-backed secure sessions
About
The CSF Session module provides the ability to store data between requests. The data itself is stored in a database table, with a unique identifier. This unique identifier is stored in a cookie so a client can be identified across multiple requests.
Security
There are two main security concerns with sessions: unauthorised third parties reading the stored session data (which may be personal in nature), and the hijacking of existing sessions giving an unauthorised third party access to facilities they shouldn't have.
The first issue is addressed by encrypting the session data when it's stored in the database. The encryption key for this data is held by the client in a cookie, and so the data cannot be accessed without the correct cookie being supplied. The cookie itself is encrypted with a "server" key (csf.session.secret), so discovering the client's key requires a compromised server (the risk of a compromised server is very difficult to mitigate). The Encrypt module is used for encryption - by default the core Encrypt module uses the Rijndael-256 (a.k.a. AES-256) cipher.
The second issue is addressed by only continuing a session if the session ID, user agent and IP address match those from when the session was created. If they do not match, the session is deleted as a precaution to prevent "brute force" style attacks.
Configuration
- csf.session.name
- Session name (used as cookie name)
- csf.session.db_module
- The CSF module that provides the session database
- csf.session.db_table
- The table in the session database that contains session information
- csf.session.secret
- Session cookie encryption key
- csf.session.path (default: '/')
- Session cookie path
- csf.session.domain (default: request hostname, determined by PHP)
- Session cookie domain
- csf.session.lifetime
- Session lifetime, in seconds
Usage
Setup
The Session module needs a database module for a database that understands a small subset of standard SQL. A table of the following format is needed:
| Field | Type | Comments |
|---|---|---|
| session_id | VARCHAR(40) | PRIMARY KEY, SHA1 hash of unique ID |
| ip_address | VARCHAR(15) | |
| user_agent | VARCHAR(96) | User agent truncated to 96 chars |
| last_activity | INTEGER | Not Y2K38-safe, but SQL date types vary too much! |
| data | TEXT | Encrypted session data |
Initialisation
Since all the configuration for the Session module is stored in the main configuration array, it is initialised with no arguments, with a simple call to CSF::load_module('session').
Usage
The $_SESSION superglobal is aliased to the internal data array of the Session module, so the following methods of accessing session data are equivalent:
<?php
$csf = CSF::CSF();
$csf->session->foo = 'bar';
echo $csf->session->get('foo'); // Would output 'bar'
$csf->session->set('foo', 'baz');
echo $_SESSION['foo']; // Would output 'baz'
?>
Overriding
See the CSF core documentation for information on overriding core modules.