This is a branch off from a separate discussion on the PHP-FIG mailing list about other ways the Framework Interoperability Group can encourage and foster wider interoperability among its member projects (and by extension, the whole PHP community). I'll start by noting two interesting developments in recent months and one long standing best practice.

The two "interesting developments" he mentions are the relatively recently released SensioLabs Security Checker that uses you Composer file to find security issues and the new entry in the latest version of the OWASP Top 10 list for "Using Components with Known Vulnerabilities". The best practice he talks about is more around the timely/responsible disclosure of vulnerabilities and how some kind of decentralized tracking of these issues that puts the responsibility back on the developers of the tool and not on one tracking resource.

When a customer commissions Ibuildings for a new application, he usually has plenty of functional demands. [...] And maybe some thoughts have been given to performance metrics, but security? Well… it "needs to be secure". [...] It is said, conveniently enough mostly by software engineers, that building software is perhaps the most complex activity humans have ever undertaken.

He notes that "security is not a checkbox, it's a dropdown" and should be continuously considered continuously through out development. The OWASP ASVS provides a structure that a development group can follow to test the security of their application. It defines 4 types of testing/validation and fourteen other topics to consider.

While ASVS is a wonderful addition, it has it's issues: verification and reporting can take a significant amount of time and validation rules are not specific enough to use the tools and techniques.

Developers need to know a lot in order to build secure applications. Some of this is good software engineering and defensive design and programming - using (safe) APIs properly, carefully checking for errors and exceptions, adding diagnostics and logging, and never trusting anything from outside of your code (including data and other people's code). But there are also lots of technical details about security weaknesses and vulnerabilities in different architectures and platforms and technology-specific risks that you have to understand and that you have to make sure that you deal with properly. Even appsec specialists have trouble keeping up with all of it.

He links to several of the OWASP cheat sheets for things like:

• authentication best practices
• using HTML5
• preventing SQL injection
• input validation

Reform is a tool that does exactly this. Reform allows you to escape your data for a javascript, xml, html or vbscript (yes it still exists) context. It provides libraries for Java, .NET, PHP, Perl, Python, Javascript and ASP. Pretty cool!

The utility is simply included into the application an called via the static methods it adds. His example shows the escaping of some output text in a Javascript string to correctly prevent it from falling into an evil XSS scheme.

• Rodrigo Marcos - hacking PHP sockets for fun and profit
• David Kierznowski - exploitation techniques using real world examples
• Colin Watson - talk about security badges

There's links to the slides for one the formal presentations, the exploitation techniques - two sets: the remote exploit examples and local exploit examples.

I'm very, very excited to announce that OWASP has chosen to fund development of what I'm calling "Inspekt" as part of their OWASP Spring of Code 2007. You can read my full proposal at the OWASP SoC Application Page.

The idea behind Inspekt is to provide a comprehensive input filtering and validation library for PHP. Building upon Chris Shiflett's original Zend_Filter_Input implementation

Some of the new features of this library include retrieval and filtering support for multidimensional arrays, a variety of helper methods to reduce code verbosity, compatibility with PHP4 and PHP5, and will be entirely self-contained (yet easily "pluggable").

Check out his full proposal for more details on what direction the project's heading and some sample code to show how it might all work.

The Spring of Code 2007, an effort that will distribute $100,000 to worthy projects, is divided approximately as follows:

• $20,000 for one lucky project.
• $10,000 for 10 open source projects.
• $40,000 for 8 large projects.
• $22,500 for 9 medium projects.
• $7,500 for an internship.

Chris notes that the projects should be related somehow to web application security and interest was shown in helping out with the security issues that surround PHP (both the language and developing applications in it).

The PHP Top 5 is based upon attack frequency in 2005 as reported to Bugtraq. This information is a valuable insight into the most devastating attacks against the world's most popular web application framework.

The list is spot on, and Chris goes on to highlight some new PHP 6 security features and also his recommendation to use PDO to sotp SQL injection.