What security features would you find useful or expect from a PHP framework? I have a PHP framework that I've developed that I'm going to be releasing as an open source project, but I want to make sure that it has appropriate security features. Here is what I have so far:
What else should a PHP framework reasonably include?
Well, building security into a framework is not an easy task. Take for example XSS protection you mentioned. Current trend in Web Application security states that three things are required for dealing with injection-flaws:
Even when handling all the above server-side, you could still be vulnerable to DOM XSS attack when vulnerable Javascript code has been introduced to the application (and, for example, jQuery might introduce DOM XSS as well).
Personally, I think the most important, and often neglected features of the frameworks are secure defaults and secure code examples. Developers often copy&paste the code or leave settings as default. So if you're introducing tokens as a CSRF protection, add them to every form by default and allow that to be toggled off in code/config.
If you're looking for some kind of a checklist for secure frameworks, there once was an OWASP project (now closed) - Web Application Security Manifesto. It aimed to provide such a testing and is currently the best checklist there is. Also browse through various OWASP cheat sheets to help you with implementing each security controls.
I'd recommend adding anti-automation measures to it. A user of the framework could choose what pages he wants to protect with this feature (for instance a login page or a feedback form). If an attacker would submit the form multiple times, he would be faced with a CAPTCHA for each subsequent request, based on his IP (not session ID!).
Furthermore, session handling is a tedious task. The framework should make sure that:
User-generated sessions are not accepted This in order to prevent session hijacking, where an attacker generates a session ID for someone else to use
Session IDs are re-generated after authentication So that when an attacker succeeds in convincing a victim to use a certain session ID, the attacker will not have an authenticated session when the victim logs in
Session IDs of authenticated sessions are never transmitted over HTTP But use SSL for all authenticated stuff
Session cookies have the proper flags HttpOnly, and Secure flag for authenticated sessions
Furthermore, I'd recommend that the framework allow the developer to set caching policies. For pages that are served to authenticated users, which might contain privacy sensitive data, caching should be easy (or even default) to turn off.
Oh joy - another PHP framework. Please excuse my sarcasm, but there are a huge number of frameworks already floating around in the wild. Most are bloated, slow and full of security bugs. But at least you are trying to address security problems up front.
I'd say it's questionable whether a framework should provide it's own database abstraction layer. e.g. Sometimes the active record pattern is useful, but not always.
By far the most valuable security add-on would be guarantees of backward compatability to encourage your user base to upgrade when you release new versions.
As per my comment elsewhere, validation is not a security issue - correct representations of data is. Providing a simple mechanism for changing between representations for different targets and to/from destination neutral formats (which usually means some tweaks to base64 encoding) would be good.
However validation for functional issues is not a bad thing - e.g. making sure that a departure date for a booking is after the arrival date.
Logging is very important.
Sandboxing of file I/O would be worth considering.
As Chris says - you should provide prevention against session hijacking/fixation.
You might consider providing an authentication framework (after all if you've got ACLs you're already imposing some constraints on how authentication is implemented).
If you want a really secure framework then think about how you'd implement non-searchable sessions (the only solutions I've come up with for this rely on daemons for privilege separation - so are entirely unsuitable for most people who would want to secure session data - i.e. those on cheap shared hosting packages).
There's lots of other stuff outwith the security domain - e.g. asynchronous messaging support. But bear in mind every time you add more functionality you may be denying the ability to use a complementary framework alongside your own (e.g. smarty, seagull, doctrine are all very capable in specific areas)
Input validation rules engine. (and output for that matter)
