Encrypt session data in PHP

Zimuel writes; As promised in my last post I present an example of strong cryptography in PHP to secure session data.
This is a very simple implementation that can be used to improve the security of PHP applications especially in shared environments where different users have access to the same resources. As you know, the PHP session data are managed by default using temporary files. In shared environment a malicious user that is able to access to these temporary files can easly read the session data because they are stored in plaintext (data in a session file is theserialization of the array $_SESSION).
In theory, the session data should be stored in folders that are accessible only by the owner of the web site, but never say never (btw, you can manage the location of the session data using the session_save_path function or changing the session.save_path in the php.ini).

To secure the session data I used strong cryptography to encrypt the content using the mcrypt extension of PHP. I chosen the simmetric cipher AES (Rijandel-256) to encrypt the session data and the openssl_random_pseudo_bytes() function to generate a random key of 256 bit.
The idea is to use a cookie variable to store the key that will be used to encrypt the session data. In this way the key is stored only in the client (the browser) and only the client is able to decrypt the session data on the server. Each time we encrypt the session data we re-generate the IV vector in a random way using the mcrypt_create_iv() function. It is very important to generate a unique IV in each encryption. This best practice increase the security of the encryption algorithm.
It’s important to note that this implementation is not secure against session hijacking attack. If someone is able to capture the cookie variable of a client and have access to the temporary session files, in the server, he/she will be able to decrypt the session data. Our goal is to protect session data against attacks on shared environments.

The idea to encrypt the session data is not new, for instance Chris Shiflett proposed an implementation in his book “Essential PHP Security” (O’Reilly, 2006). Shiflett used a $_SERVER variable to store the key used to encrypt the session data. Kevin Schroeder, my colleague at Zend Technologies, implemented a very similar session encryption algorithm extending the Zend_Session class of Zend Framework (you can find it here). In my solution, I used some of the best practices related to strong cryptography to implement a secure session handler.

Below the source code of my implementation:

Full class @ Zimuel’s blog.

Zend Framework – Reporting Potential Security Issues

If you have encountered a potential security vulnerability in Zend Framework, please report it to us at [email protected]. We will work with you to verify the vulnerability and patch it.

When reporting issues, please provide the following information:

  • Component(s) affected
  • A description indicating how to reproduce the issue
  • A summary of the security vulnerability and impact

We request that you contact us via the email address above and give the project contributors a chance to resolve the vulnerability and issue a new release prior to any public exposure; this helps protect Zend Framework users and provides them with a chance to upgrade and/or update in order to protect their applications.

For sensitive email communications, please use our PGP key.


Zend Framework takes security seriously. If we verify a reported security vulnerability, our policy is:

  • We will patch the current release branch, as well as the prior two minor release branches.
  • After patching the release branches, we will immediately issue new security fix releases for each patched release branch.
  • A security advisory will be released on the Zend Framework site detailing the vulnerability, as well as recommendations for end-users to protect themselves. Security advisories will be listed at http://framework.zend.com/security/advisories, as well as via a feed (which is also present in the website head for easy feed discovery)

via Zend Framework.

Zend Framework Security Related Releases Now Available

And finally there has been some actual movement on securing up the Zend Framework in an proactive fashion (at least from now on:) )

As announced earlier by Matthew, Zend Framework 1.9.7, 1.8.5 and 1.7.9 have been released incorporating routine maintenance and a number of security fixes detailed in the announcement. It's recommended that framework users upgrade as soon as possible to the latest release of whichever of these minor branches they are using.

As the announcement also indicates, following December's excitement I spent much of the Christmas and New Year period conducting a security review of the framework. While an ongoing process, the initial review focused on specific areas most likely to deal directly or indirectly with user input and the output of user sourced data. The results of that initial review were reported over the holidays to the Zend team, who patiently put up with my long winded emails and managed not to strangle me…so far. I'm keeping myself holed up in the mountains for now ;-).

The review also included an examination of all new components due to enter service with Zend Framework 1.10. This yielded a number of issues whose fixes will preempt their release into a stable version, and have been reported to the relevant lead developers. These will not be disclosed at this time, and will not form any new advisories for the simple fact that ZF 1.10 currently exists only as an alpha release where issues are to be expected anyway. Regardless, you all owe me extra cookies for those ;-).

On to the vulnerabilities, the majority are linked to encoding inconsistencies. One of the more far-reaching results of the fixes is that all developers should note the Zend Framework now enforces a default character encoding of UTF-8, including Zend_View which until now has defaulted to ISO-8859-1. This will require users needing that encoding to now set it manually. In addition, numerous classes have been given methods allowing developers pass in their preferred encoding. It's essential you do so to benefit from the full protection of all escaping mechanisms using htmlspecialchars() and htmlentities(). The remaining vulnerabilities are self-explanatory and, besides upgrading, require little additional work on your part.

It's also important to note that these fixes often go beyond fixing the immediate symptoms. So reporter's credit aside, thanks to Matthew, Ralph and Thomas Weidner who worked on the patches for these fixes as well as spending the time discussing and debating them all in turn. I'm sure Matthew and Ralph had lots of fun (in between apoplectic fits) preparing for three releases but it's truly appreciated.

I remember from December (when not ranting ;-)), that one of the identifiable problems with the Zend Framework was its overall security strategy which has been reactive in nature. The reason for performing this security review, in addition to finding it exciting to spend hour after hour staring at source code (I'm being sarcastic), is that my original rant was misdirected in one aspect. If the framework is reactive, it is because everyone who contributes source code also contributes to that particular attitude. Performing the review was one way of breaking the reactive trend, and so instead of having these security issues persist into the framework's future versions to be discovered by accident (or not), they have been deliberately searched for, found, poked, prodded, debated and then dutifully exterminated. Welcome to proactivity.

If there is a point, it is that as Zend Framework contributors it's still ultimately our job to enforce and promote a security awareness. We can't pass that responsibility to Zend (all of three employees) and wave our hands innocently. We now have two new jobs we better get used to. The first is applying the new Security Policy and notifying the security channel of any reported or self-discovered security issues. Don't sit around wondering if it's a problem, send it in and let the guys look at it. That goes for all security issues without exception (or should). Secondly, we need to build some semblance of a security conciousness because at present that is sorely lacking. I believe the Zend guys are on a similar track here so they may have more to say in the near future. I'll doubtlessly blog about these two topics more specifically over the next few days.

In the meantime, you have some new releases to work with ;-). I sunk a lot of time into this, but being an open source project it's only right you exploit that for all it's worth :-P.

via Maugrim The Reaper’s Blog.