About the Author

Chris Shiflett

Hi, I’m Chris: entrepreneur, community leader, husband, and father. I live and work in Boulder, CO.


All posts for Jul 2005

Ask Chris

I just finished recording the first episode of Ask Chris, a new joint effort between the Pro PHP Podcast and Brain Bulb. I'd like to take a minute to explain how this show came to exist.

I receive quite a bit of email from people asking technical questions about various things - sometimes I know the answers, and sometimes I don't. I can't answer every email I receive, but I try to answer as many as I can in an effort to be polite and helpful. One problem with sending personal replies, however, is that only one person benefits from my effort. For this reason, I often request that people ask questions in a public medium.

Over time, I've observed patterns in the questions that I receive - people generally seem to have similar questions within a specific period of time. This makes sense, because once a few people figure out the answer to a question (or solution to a problem), the open and friendly nature of the PHP community guarantees that this information spreads rapidly. With this in mind, I thought it might be a good idea to publish the answers to questions that I receive, and inspired by Ask Tim, I came up with the very unoriginal idea of Ask Chris.

Coincidentally, Marcus Whitney recently asked me to do a segment on the Pro PHP Podcast where I answer questions sent in by listeners. Because I don't have anything set up yet, this seemed like the perfect chance to get the ball rolling.

I hope you enjoy the show, and many thanks to Marcus for hosting it.

ApacheCon EU 2005

ApacheCon EU was a nice conference - I gave talks on PHP security and testing PHP with Apache-Test. The testing talk went well, but having Geoff there would have made it much better. I modified the talk heavily in order to make it more pragmatic - I focused on how to use the framework more than how it works.

The PHP community really needs a good resource on testing PHP that covers fundamental ideologies and methodologies but also specific tools such as Apache-Test, PHPUnit, SimpleTest, .phpt, etc. Some of the best available information (specific to PHP) is what Marcus Baker has written in various places. With more of this sort of thing, I think testing could catch on, and this would benefit us all.

While at the conference, Zak showed me a cool DNS trick that I immediately recognized as an opportunity for a new type of web attack. I haven't seen this discussed anywhere, and as soon as I can discover a way to protect against it, I'll publish more information.

php|works Schedule Posted

php|architect has posted their schedule for php|works, which takes place this September in Toronto. Among the talks are three different PHP security talks by three different speakers, including a keynote by Rasmus on cross-site scripting (Ilia and I are giving the other two). It should be a great conference for security-conscious PHP developers.

Other talks include George speaking about XML and regular expressions, Wez speaking about streams and PDO, and Derick speaking about Unicode.

I hope to see you there!

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.

Ethics and Security

Paul Jones has published an entry on his blog discussing ethics and security. Although I don't have the time to properly respond, I do want to make a few points.

There is a tendency to view security research (in any form) as malicious. This seems to be the primary reason that people object to it. Of course, without such research, those with malicious intentions would gain an advantage. It is for this reason that I view attempts to curtail the ethical boundaries confining security research as counterproductive.

This is very similar to the issues surrounding the blood alcohol content levels used in certain laws. An overzealous restriction causes more people to be considered criminals. This makes the enforcement of severe penalties unjust in edge cases. In terms of security research, as soon as more researchers are viewed as unethical, fewer people are willing to engage in such research, and we all lose.

Of course, there must be boundaries, but I believe more flexibility needs to be afforded researchers than Paul asserts. I'm not suggesting that a Patriot Act approach is a good idea, but I think we need to be more forgiving rather than less when it comes to judging those with good intentions.

To those interested in this particular topic, the policies of the PHP Security Consortium are worth considering.