About the Author

Chris Shiflett

Hi, I’m Chris: web craftsman, community leader, husband, father, and partner at Fictive Kin.


Stefan Esser Discusses Security Guide

This is an interesting (and unexpected) continuation of the ethics and security discussion. Ben just pointed me to an interesting article by Stefan Esser, who claims to have found two errors in the PHP Security Guide. In the article, Stefan states:

Before continuing, it should be mentioned, that these bugs where disclosed to atleast 5 (if not 6) members of the PHP Security Consortium during the last 2-3 months (and nothing has changed, yet).

I find this quite surprising, since the last correspondence I had with Stefan was when he declined to assist with the efforts of the PHP Security Consortium (several months ago when the group was being formed), citing a "conflict of interest." As the founder of the group, it seems like he would have tried to bring these issues to my attention before such public disclosure.

One of the errors he mentions is valid, although luckily a recent update to the guide addresses it. While writing the shared hosting chapter of my book, I wrote functions for storing sessions in a database that include a few best practices not covered in the guide, such as the use of mysql_real_escape_string() instead of mysql_escape_string(). The guide contains these new functions.

The other concern is due to an error in Stefan's interpretation of the technique, which suggests that we need to explain the technique more clearly in the guide. We do not promote the use of uninitialized variables, and this is exactly what is required in order for a vulnerability to exist in the example cited. Variables should always be initialized, and a user's session is no exception. For example, you might initialize a few different session variables when you begin a session:

<?php 

session_start
();

if (!isset(
$_SESSION['logged_in']))
{
    
$_SESSION['logged_in'] = FALSE;
}

if (!isset(
$_SESSION['token']))
{
    
$_SESSION['token'] = md5(uniqid(rand(), true));
}

?>

The guide includes small sections of code intended to teach a specific technique, and these are not always complete examples. Despite the lack of a vulnerability in this particular case, the guide fails to adhere to the principle of Defense in Depth, so an update has just been made to the guide that checks for a valid token as follows:

<?php 

if (isset($_SESSION['token']) &&
    
$_POST['token'] == $_SESSION['token'])

?>

Although this safeguard is redundant, it can save the day if you forget to initialize your variables. Remember to develop with error_reporting set to E_ALL to help you identify the use of uninitialized variables.

About this post

Stefan Esser Discusses Security Guide was posted on Mon, 11 Jul 2005. If you liked it, follow me on Twitter or share:

3 comments

1.Chris Shiflett said:

I don't want to promote more animosity in this discussion, so let me offer an apology for the slightly negative tone in my post.

The purpose of the PHPSC is to help people. Period. I felt that by convincing other people to help out and form a group, we could do more. Perhaps we're not doing as much as we can, but I think we're making a positive difference.

I sincerely appreciate all of the efforts of the Hardened-PHP project, and I consider their efforts to be complimentary to ours. I only ask that the PHPSC be notified prior to any such public disclosure in the future. I believe anything less to be unprofessional and unethical.

Tue, 12 Jul 2005 at 22:43:17 GMT Link


2.John Sinclair said:

Thanks to you Chris and the many people responding and posting on php session security (pro and con). I've been Googling everything I can find for some days now, and realize there isn't as much interest in hardening session security as there should be. Too many developers just hope the problem goes away by itself, or worse -- they give up on php sessions altogether.

I have put into practice your suggestions for regenerating the session id and for using a second tier fingerprint not based on IP address that stays on the server. I believe capture and fixation hijacking can be stymied.

Mon, 03 Oct 2005 at 19:36:28 GMT Link


3.Prem Kurian Philip said:

Thanks for your book and for your thoughtful, mature

response to Stefan Esser. It is good to see that the

discussion has not deteriorated into a flamebait.

Mon, 20 Feb 2006 at 15:10:18 GMT Link


Hello! What’s your name?

Want to comment? Please connect with Twitter to join the discussion.