About the Author

Chris Shiflett

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

Zend Framework Wishlist

As has been widely discussed, Zend announced its PHP Framework this week. I wasn't invited to participate, so I think I can offer an unbiased opinion. The primary misconception seems to be that there is no code, and this isn't true. Although Zend thinks the framework is too immature to be released yet, it does exist. There are also some very smart people contributing to the project, and it's not just big companies like IBM - guys like George and Wez are also helping out. I'm giving it the benefit of the doubt, and I have high hopes for this project.

I'm particularly interested to see whether this effort capitalizes on the chance to help PHP developers write more secure code. In addition to support for filtering input (which I'm told is included), here are some characteristics I'm hoping to see:

  • Something comparable to a taint mode. Developers need to be able to easily and reliably determine whether a particular variable is tainted. The framework can keep up with this and offer a simple inspection mechanism. Currently, developers must rely on discipline, and it's easy to make a mistake.
  • An intuitive way to escape output. When someone wants to escape data to be used in a URL that is also the target of a link, it needs to be passed through urlencode() and then htmlentities(). The nature of representing data in different contexts is confusing for many developers, and I think the framework can help.
  • Protection against session fixation. For example, if I use something native to the framework to modify a user's privilege level (so it knows what I'm doing), I want the session identifier to be regenerated automatically. Of course, this behavior could be optional.
  • Protection against session hijacking. There's a lot that can be done here. Even Defense in Depth measures such as propagating an auth token would be nice.
  • CSRF protection. The framework could even make this transparent, so that a token is added to all HTML forms, and this is checked upon submission. If this check fails, let the developer decide what to do (if anything) - maybe just throw an exception. This type of approach can offer an easy solution for security-conscious developers without eliminating the flexibility that we've all come to expect and appreciate about PHP.
  • Support for persistent logins. Many developers want to add a "remember me" feature, and poor implementations of this are the cause of many security vulnerabilities.
  • Simple and secure authentication and authorization mechanisms. These are features that almost all PHP applications need, and OWASP lists both broken authentication and broken access control (authorization) on its top ten list of critical web application security vulnerabilities.

These are just a few of the things I'd like to see. What's on your wishlist?

About this post

Zend Framework Wishlist was posted on Sat, 22 Oct 2005. If you liked it, follow me on Twitter or share:


1.C Drozdowski said:

I'm wondering whether those involved in this project might be seling PHPs soul to the devil with the corporate involvement in this project.

Sun, 23 Oct 2005 at 02:45:48 GMT Link

2.Mustafa said:

there should be a matchless ajax support :)

Sun, 23 Oct 2005 at 08:35:57 GMT Link

3.Patrick Smallwood said:

Just one thing: A GPL-Compatible license. Right now, they are unclear, saying only "a PHP-type of license". The PHPL is incompatible with the GPL, so that would prevent hundreds of php apps from using the framework. My only real hope is that they go with something more like the BSDL, so that *everyone* can use it.

Sun, 23 Oct 2005 at 13:32:33 GMT Link

4.Brad said:

Have you thought on doing a "Security Corner" on "remember me" features? I'd love to learn more about how to make that kind of feature solid and secure. Thanks.

Sun, 23 Oct 2005 at 21:10:30 GMT Link

5.Artem Nezvigin said:


In a nutshell (this is my opinion, by the way), the best way to make a secure persistent login is to do the following:

Never store the password anywhere but in the database. The best way to do this is to use randomly generated tokens.

In the user's table in the database, simply add 3 more columns for the following:

- cookie token

- session token

- browser fingerprint

The user logs in and a session token is assigned to his session. This token is stored in the database. Upon all subsequent page loads, this token is checked. Also the browser fingerprint is checked as well.

For a persistent login, if the user chooses remember me, simply create the same type of randomly generated token for the cookie and store in the database. You store this token in the user's cookie.

So the process goes:

- User enters page.

- Check if session exists.

- If yes, validate session.

- If no, check if cookie exists.

- If yes, validate cookie.

- If no, display login form.

It's also important to do session_regenerate_id() every single time that the user's permissions change.

I once had a project where I was building an application that was used by a company and contained very sensitive information. Alongside all of the encryption, I added a neat little feature that allowed a user to specify which IP addresses were allowed to access his/her account. As many people aren't stupid enough to access their account from an internet cafe or other public place, they usually had, at most, 3 computers they would access their account from.

Mon, 24 Oct 2005 at 12:10:39 GMT Link

6.Chris Shiflett said:

Hi Brad,

I did write a Security Corner on persistent logins, so it will be available for free from my web site in the future. (I can't remember the exact date.)

Artem's solution is similar to what I proposed in the article. The key is to not use any data based on the password in the cookie, because this exposes something that offers long-term access.

Mon, 24 Oct 2005 at 20:26:39 GMT Link

7.Geoffrey L. Wright said:

You should all take a look at WASP:


We have working code that does this sort of thing right now -- in fact we already have deployed custom application built using WASP. We used the LGPL for the licence, and we'd love comments, feedback or participation of any kind. Or better yet, use WASP to build stuff!

Who know what the Zend folks will come up with? I'm sure it'll be good stuff. But while you wait feel free to take WASP for a spin.

Tue, 25 Oct 2005 at 08:01:17 GMT Link

8.Ben Ramsey said:

C Drozdowski:

What's wrong with corporate involvement? If the corporate world starts using PHP en masse because there's a framework that takes into account their needs, then that means there will be more jobs for PHP developers.

We all win.

Tue, 25 Oct 2005 at 14:03:21 GMT Link

9.magic8ball said:

I'm looking for peerless integration of AJAX and MVC concepts

Wed, 26 Oct 2005 at 19:02:29 GMT Link

10.Colin McKinnon said:


(as in Keep It Simple, Stupid)

I'd agree there's a lot could/should be done at the framework level to address security. I'd take issue with building in token control for preventing CSRF - look at the problems using use_trans_sid.

I think the most useful security add-in for me would be a privilege proxy for file I/O. I'd want to be able to pass the sessionId, and an operating system user/password at the

beginning of the session and have all subsequent I/O operations carried out with the privilege of that user (preferably without having to present the auth details again).

It'd probably need wrappers round the I/O operations (although if the native fns could be overwritten, all the better) along with a daemon process. I guess it would require the session handling functions to be stackable or support callbacks too.


Thu, 27 Oct 2005 at 16:41:09 GMT Link

11.Jimmy said:

I think that Zend must take a look at existing code. There are some brilliant frameworks for PHP5 - just take a look at Freeform (http://dev6.php5.nedlinux.com) - it's very fresh, and it addresses much wider list of issues that we can even think of! I would vote for it to become the basis for this future development.

Sat, 29 Oct 2005 at 10:48:00 GMT Link

12.Elliot Anderson said:

magic8ball: I doubt the Zend Framework will have AJAX integration.

It is supposed to be a PHP framework, so you might see some MVC design principles used, but AJAX techniques use a totally different language so it is unlikely to be included.

Thu, 03 Nov 2005 at 06:06:25 GMT Link

13.Jose said:

I was looking into Ruby on Rails when I came into TurboGears. Amazing. I then went on to look for something similar using PHP at its core (spent 10-15 minutes in all). Found Cake, Solar, and Symfony and finally thought of checking Zend itself. And from there, here.

I'm still lost. Is this "framework" aiming at being Ruby on Rails or TurboGears (python) but for PHP? Please save the trouble of going down into the nitty gritty and how much different/better it will be. I just want to know: are talking the same thing here?

If we are, then AJAX brought into the equation should be no problem. If we are not, at all, then thanks for all the fish. ;)


PS. By the way, where is the code? This doesn't seem that it is going to make it in another 3 to 6 months, at the earliest, TurboGears, here I come!

Mon, 07 Nov 2005 at 01:07:10 GMT Link

14.Jose said:

I think I found an answer to my question. Reading the Zend PHP Framework overview page, under the heading Why Yet Another Framework was "Keep PHP competitive among other technologies including Ruby-on-Rails,..."

Having Ruby-on-Rails there, at the beginning of that list just makes it clear. By the way, take a look at TurboGears video presentation of how to make a wiki in 20 minutes. It's really nice and I think better than the video for Ruby on Rails.


Mon, 07 Nov 2005 at 01:23:10 GMT Link

15.Lukas said:

In my framework I wouldnt say that I have really focused alotof energy on security. But I did recently add a number of input filters and validators as well as a custom echo function that defaults to the proper escaping based on the output format or that can be asked to specifically escape for a given format.

As for a taint model we simply stick all parameters send to a particular module inside an array and make it available to the module. The author of the module can then apply the defined validation rules.

In a similar manner the module author can configure what type of structure is allowed to be passed to the templates. This is again only partially a security feature. The main reason we added this was to ensure that there will be atleast some documentation of the possible values send to each given template.

We also have the ability to generate a unique id for a form that can only submitted once. The original idea being to prevent multiple submissions by going back and forth in the browser history.

Through the use of LiveUser we also have a quite flexible way of defning how to handle sessions, when to regenerate the ID, when to destroy the entire session. However I am hoping that one of these days we strip out the forced usage of the php sessions from LiveUser.

You can find the framework here:


Sat, 12 Nov 2005 at 08:02:50 GMT Link

16.Roman Ivanov said:

//An intuitive way to escape output.

In pure PHP? I'd like to see that.

//CSRF protection.

IMO, any 'real' CSRF protection system severely degrades website usability. (Unless you're just checking referrer domain.)

Thu, 17 Nov 2005 at 05:36:45 GMT Link

17.Chris Shiflett said:

Roman writes:

> In pure PHP? I'd like to see that.

Yeah, I know there may be no way to achieve this elegantly. Perhaps I'll just discover what others already have, but maybe with a little bit of creativity and luck, I can come up with something good.

> IMO, any 'real' CSRF protection system severely

> degrades website usability.

Can you elaborate? Generating and checking tokens should be transparent to the user, and there are even ways to make sure that users who use multiple tabs don't encounter problems. I might be missing something, though. :-)

Thanks for your comments.

Thu, 17 Nov 2005 at 05:44:46 GMT Link

18.Roman Ivanov said:

> Perhaps I'll just discover what others already have

Here is a link to the modernized version of my old html filter for PostNuke. Hope it helps. I'm not so sure about performance, though.


> Can you elaborate?

Unfortunately, no. I just had a few bad experiences with websites using CSRF protection. Usually, problems arise when user loads form A, then loads form B, then submits the first one.

> there are even ways to make sure that users who use

> multiple tabs don't encounter problems.

Can it be achieved without starting a session?

Thu, 17 Nov 2005 at 17:08:04 GMT Link

19.Dariusz Debowczyk said:

Code Igniter (by Rick Ellis) supports some the features you've mentioned:

- VERY easy to use XSS filters

- protection against session fixation (with Native_session)

- user management (with simple userlib)

Take a look at it - you'll be amazed by its beauty and simplicity.

Mon, 31 Jul 2006 at 13:25:28 GMT Link

Hello! What’s your name?

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