Which database storage system to use?

Any system that PHP can communicate with:

• MySQL
• PostgreSQL
• Microsoft SQL Server
• LDAP
• XML

Why use a database?

• Excellent solution for load balanced sites - those that are spread across a number of web servers
• Session data is accessible by any application and server with access to the database server

Designing the session object

A simple login/logout example

Identify the weaknesses

As it stands, the session handler has one major weakness - it relies on the session id provided without any other form of authentication.

Someone can grab a session id and pretend to be another user on the site.

The session handler would happily serve the false user someone else's information.

Looking beyond just the session id....

Methods for securing the session

1. IP address restriction
2. Regenerate the user's session id
3. Don't rely on the session id alone
4. Don't use session ids in the URL
5. Clean up stale sessions quickly
6. Think about the data you are storing

How sessions are compromised

Sessions can be hijacked by third parties. This can be done via:

• Prediction of the session id
• Stealing of the session id
• Fixation - forcing the user to use a session id of the attackers choosing (e.g via an email, third party website, ...)

IP address restrictions

Record the initial requestors IP address and only allow that IP to, at a minimum, read session data

Note: multiple users can come from the same IP address.

This method won't catch these users.

Regenerate the session id

Once a user has logged in successfully, give them a new session id and destroy the original session id.

This will help to avoid session fixation

Use session_regenerate_id() - a PHP session function

Don't use session ids in the URL

Session ids stored in the URL - like http://example.com?sid=4567 can be stored in web logs, browser caches, search engine results.

If the session 4567 remains in the database then anyone can access that data.

Don't rely on the session id alone

One possibility is to give the user a second cookie. This cookie is only available to the initial user who logged in and they must provide it when accessing secure pages, along with their session id.

The second session id should be stored in a separate data store to the main session id.

In a session fixation attack, the 3rd party would only have the initial session id and not the session id from the second cookie provided

Clean up stale sessions quickly

Don't allow old session data to hang around.

Make sure your session destroy function really does destroy the data.

If you want to store historical session data for some purposes, for instance user tracking, aggregate statistics, trend data then migrate this data to another database.

Think about the data

Finally, think about what data you are storing in the session. If someone does compromise a session what data are you giving away?

• Do you really need to store credit card numbers in a session?
• Are you storing passwords in the session?
• Do you need to store personally identifiable information in a session?