Zend Framework Wishlist
22 Oct 2005As 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?