Pádraic Brady has a new post today proposing that what the PHP ecosystem needs is a way to better publish security disclosures in a format that's easy to parse and deal with.

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.

On the iBuildings blog today there's a post from Boy Baukema about the use of the OWASP ASVS to help provide a framework of questions to ask about your application to help find any application security "pain points."

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.

Jim Bird has a new post with links to a few different resources helping you "cheat" at application security - links to cheat sheets with highlights of key points to keep an eye out for.

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

Evert Pot has pointed out a handy tool that can make escaping strings in and out of your application simpler - Reform.

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.

From the GNUCitizen blog, there's a new post about a recent meeting (of the OWASP London Chapter) where several presentations were given on methods for exploiting PHP applications. The three talks given were:

• 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.

Ed Finkler, in cooperation with the Open Web Application Security Project, will be working up a toolkit to help make input filtering and validation simple no matter if you use a framework or not.

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.

Ed Finkler, in cooperation with the Open Web Application Security Project, will be working up a toolkit to help make input filtering and validation simple no matter if you use a framework or not.

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.

As mentioned in this new post from Chris Shiflett, an announcement was made at the most recent Columbia PHP meetup by Andrew van der Stock (of OWASP) about an incentive to work in their Spring of Code 2007 competition - a bit of financial reward.

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).

As mentioned in this new post from Chris Shiflett, an announcement was made at the most recent Columbia PHP meetup by Andrew van der Stock (of OWASP) about an incentive to work in their Spring of Code 2007 competition - a bit of financial reward.

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).

Chris points out today that the OWASP (the Open Web Application Security Project) is now publishing a PHP Top 5 list, detailing the top 5 PHP security concerns.

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.