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 Jan 2005

PHP Security Consortium Official Launch

The PHP Security Consortium has officially launched. The following is the press release:

Leading PHP Experts Join Forces to Establish the PHP Security Consortium

NEW YORK, NY - January 31, 2005 - An international group of PHP experts today announced the official launch of the PHP Security Consortium (PHPSC), a group whose mission is to promote secure programming practices within the PHP community through education and exposition while maintaining high ethical standards.

"As PHP has transitioned from personal projects to enterprise application development, the need to educate the community about secure programming practices has risen," said Chris Shiflett, the group's founder.

The PHPSC web site (http://phpsec.org/) provides a variety of security resources for PHP developers, including the group's flagship project, the PHP Security Guide.

"PHP application security is a topic of growing importance," said Andi Gutmans, one of the group's charter members. "The launch of the PHP Security Consortium is a landmark event for the PHP community, and because most web development technologies face similar security concerns, we believe that developers using other solutions can also benefit from our efforts."

About the PHP Security Consortium

Founded in January 2005, the PHP Security Consortium (PHPSC) is an international group of PHP experts dedicated to promoting secure programming practices within the PHP community. Members of the PHPSC seek to educate PHP developers about security through a variety of resources, including documentation, tools, and standards.

In addition to their educational efforts, the PHPSC engages in exploratory and experimental research in order to develop and promote standards of best practice for PHP application development.

Zend's Marketing Controversy

I originally posted this as a comment on John's blog:

I must have missed the backlash this time, but I understand the scorn over Zend's marketing statements. In my opinion, the concern has more to do with the lack of credit given to Rasmus than anything else. When Rasmus is referenced as the creator of PHP, no one objects, nor do they seem to consider it to be hoarding credit from the many contributors to PHP.

Ask a mod_perl developer who created mod_perl, and they'll tell you Doug MacEachern. Ask them who the core mod_perl developers are now, and they'll name people like Stas Bekman and Geoff Young. Doug no longer contributes, but no one else can ever truly claim creation.

Andi and Zeev have made substantial contributions, and it's very likely that PHP would never have reached its current level of excellence without their early involvement. It is understandable for Zend to trumpet their founders' involvement with the language. However, I think there would be far fewer objections if Zend's marketing statements at least shared credit for the creation of the language. I personally think it makes sense for Zend to position itself as a company with key PHP creators and innovators as founders. We all know Andi and Zeev, and we know how substantial their involvement is. For the average company executive, however, they're lucky to have heard of PHP. Zend's marketing tries to make Andi and Zeev's roles sound as significant as they are.

I'm very glad to hear that they have intervened and will be toning down these statements. As for Zend calling itself "The PHP Company," I don't see a problem with that at all. It's no different than Xerox calling itself "The Document Company." It suggests a particular focus, and it's a marketing attempt to position itself as the only or paramount one of its kind. I could say I wrote "the book" on HTTP, and I think that's fine, even though there are others. :-)

Apache-Test for the PHP CLI

Now there's even more reason to be using Apache-Test to test PHP applications:

From Geoff's blog:

today I added the ability to run client-side PHP scripts to Apache-Test. so, now you can have


all within the same t/ directory.

the perl script t/foo.t will run using perl, just like always. t/bar.php will run using the php command-line interpreter, while t/response/TestPHP/baz.php will run via PHP within the Apache runtime (through standard Apache-Test magic). and all are executed with a simple make test and tabulated on the command line like you would expect.

Geoff also provides an example t/foo.php:


require 'test-more.php';


diag('this is a php test');

is('php', 'perl', 'something php passed');


This is a really great testing framework for PHP that I hope keeps getting more and more attention.

XSS Cheatsheet

I stumbled upon an interesting resource today - the XSS Cheatsheet. This is a really wonderful collection of XSS (cross-site scripting) test cases. If you don't know what XSS is, you might find the following resources helpful:

Christian has developed a script for filtering data specifically for XSS. He also has an example implementation where you can try it out for yourself - maybe someone with some free time can try entering all of the test cases to see if any of them expose a weakness.

Session Riding

I recently discovered a PDF that describes something called Session Riding. Having no idea what session riding is, I decided to read it. From the introduction:

In this paper we describe an issue that was raised in 2001 under the name of Cross-Site Request Forgeries (CSRF). It seems, though, that it has been neglected by the software development and Web Application Security community, as it is not part of recent Web Application Security discussions, nor is it mentioned in OWASP's Top Ten or the like.

I agree that CSRF is an important topic that is not given proper attention. I consider it to be one of the most dangerous web application attacks, especially after observing the results of my recent PHP security experiments.

We prefer to call this issue Session Riding which more figuratively illustrates what is going on.

To be clear, session riding is nothing more than a new name for Cross-Site Request Forgeries - an attack that has been discussed for four years and for which there exists four years of documentation. Of course, I suppose that you would have to get a new name adopted if you want your PDF on the topic to be a top Google result.

In short: with Session Riding it is possible to send commands to a Web application on behalf of the targeted user by just sending this user an email or tricking him into visiting a (not per se malicious but) specially crafted website.

This is actually completely backward. With CSRF, the victim unknowingly sends requests of the attacker's choosing to the target site. The attacker does not send "commands" (requests) on behalf of the victim. To be fair, the rest of the document demonstrates a correct understanding of CSRF, so this is apparently an honest mistake.

Most of this document is good. The main solution presented (Solution 1) is very similar to the solution I usually recommend, although it is a bit weaker and focuses more on the session risk. I believe that it offers adequate protection, else I would refute it. I'll let you read the document and come to your own conclusions about its merit as well as the merit of the other solutions presented.

What are your thoughts about renaming known security concerns? Are there special cases where it might be appropriate? I plan to continue to use the original term - CSRF is a more accurate description of the technique, and inconsistencies in naming aren't going to help people better understand it.

OSCON Call for Proposals

Want to go to the O'Reilly Open Source Convention 2005 for free? Go submit a proposal to give a talk. The conference runs from 01 Aug 2005 to 05 Aug 2005. Here is part of the CFP announcement:

Complete details are available on the OSCON web site, but we're particularly interested in exploring how software development is moving to another level, and how developers and businesses are adjusting to new business models and architectures. We're looking for sessions, tutorials, and workshops proposals that appeal to developers, systems and network administrators, and their managers in the following areas:
  • All aspects of building applications, services, and systems that use the new capabilities of the open source platform
  • Burning issues for Java, Mozilla, web apps, and beyond
  • The commoditization of software: who and/or what can show us the money?
  • Network-enabled collaboration
  • Software customizability, including software as a service
  • Law, licensing, politics, and how best to navigate other troubled waters
Specific topics and tracks at OSCON 2005 include: Linux and other open source operating systems, Java, PHP, Python, Perl, Databases (including MySQL and PostgreSQL), Apache, XML, Applications, Ruby, and Security.

OSCON has always been a favorite conference of mine. I hope to see you there.

2004 Highlights

Following in the tradition of my 2003 Highlights, I'm recording my personal highlights of this past year. This is mostly for my own curiosity.

This list is a bit longer than last year's, and it certainly seemed like a busier year. Here's wishing everyone a happy 2005.