In his latest post Pádraic Brady shares his thoughts about the state of TLS/SSL functionality in PHP and how he thinks developers should avoid the trap of "lowest common denominator" and opt for insecurity.

A few weeks back I wrote a piece about updating PHARs in-situ, what we’ve taken to calling “self-updating”. In that article, I touched on making Transport Layer Security (TLS, formerly SSL) enforcement one of the central objectives of a self-updating process. In several other discussions, I started using the phrase “Lowest Common Insecure Denominator” as a label for when a process, which should be subject to TLS verification, has that verification omitted or disabled to serve a category of user with poorly configured PHP installations.

This is not a novel or even TLS-only concept. All that the phrase means is that, to maximise users and minimise friction, programmers will be forever motivated to do away with security features that a significant minority cannot support by default.

He goes on to talk about how, in some places, targeting the lowest common denominator is okay, security isn't one of them. He also includes four basic concepts developers can adhere to to prevent this targeting:

• You should never knowingly distribute insecure code.
• You should accept responsibility for reported vulnerabilities.
• You should make every effort to fix vulnerabilities within a reasonable time.
• You should responsibly disclose vulnerabilities and fixes to the public.

He follows these up with three steps you can follow to migrate an insecure architecture into something much more robust. This includes identifying the consequences of the update and documenting the solutions you've chosen, be those configuration updates or library changes.

The Zend Developer Zone has posted a new episode of their "ZendCon Sessions" podcast series as recorded at last year's Zend/PHP Conference in Santa Clara, CA. This time it's a recording of Christian Wenz's "(In)secure Ajax-y Websites with PHP" talk.

Welcome to the ZendCon 2008 edition of the ZendCon Sessions. The ZendCon Sessions are live recordings of sessions that have been given at previous Zend Conferences. Combined with the slides, they can be the next best thing to having attended the conference itself. [...] This episode of The ZendCon Sessions was recorded live at ZendCon 2008 in Santa Clara, CA and features Christian Wenz giving his talk: "(In)secure Ajax-y Websites with PHP"

You can grab the mp3 of the episode, use the in-page player to listen or subscribe to the podcast feed to get this and other great episodes.

Mikko Koppanen has posted about an extension he's written up that has only one real purpose - to help with unit testing a script with a file upload involved (making a "fake upload" possible).

The extension is doing things that shouldn't be done, it probably doesn't even run anywhere else than on CLI, it is insecure, it might behave incorrectly but in this scenario it worked fine so I decided to share it.

This "use at your own risk" extension gives you a new function to use instead of the normal move_uploaded_file, appropriately named "fakeupload_file". It creates the fake file so that even calls to is_uploaded_file will see it as if it was correctly on the file system. An unlink is all that's needed to remove the "file".

In a new post today, Ed Finkler shares some interesting stats he's generated based on some NIST NVD data and graphed out. It shows PHP as being in the top 20 list for more insecure applications.

What follows is a breakdown of the 20 PHP-based applications that had the highest aggregate vulnerability scores (NIST assigns a score from 1-10 for the severity of each entry), and the highest total number of vulnerabilities, over the past 12 months. Of the two, I feel that the aggregate score is a better indicator of security issues.

The Excel charts show the total NVD score and the total number of NVD entries for several popular PHP applications (like phpBB, phpMyAdmin, TikiWiki, and Joomla). He also notes that there are some other extenuating circumstances surrounding these numbers (not a level line) and that the trend seems to be more on the side of issues with forums than any other type of PHP application.

In a new post today, Ed Finkler shares some interesting stats he's generated based on some NIST NVD data and graphed out. It shows PHP as being in the top 20 list for more insecure applications.

What follows is a breakdown of the 20 PHP-based applications that had the highest aggregate vulnerability scores (NIST assigns a score from 1-10 for the severity of each entry), and the highest total number of vulnerabilities, over the past 12 months. Of the two, I feel that the aggregate score is a better indicator of security issues.

The Excel charts show the total NVD score and the total number of NVD entries for several popular PHP applications (like phpBB, phpMyAdmin, TikiWiki, and Joomla). He also notes that there are some other extenuating circumstances surrounding these numbers (not a level line) and that the trend seems to be more on the side of issues with forums than any other type of PHP application.

In a new post, Pádraic Brady wonders something that has bothered many a PHP community member at one time or another - "is one insecure PHP application too many?"

Unfortunately the nature of PHP as a programming language is that it's easy to foul up. And this has inevitably left the responsibility of security completely up to the individual programmer. The results have been less than comforting, leaving an internet populated by God know how many insecure PHP scripts and application written by well meaning but woefully under educated programmers and casual users.

He continues on talking about the education of programmers, PHP security resources, how the community reacts to the pressures of a wider audience hearing about the insecurities surrounding PHP apps, and some of the efforts the PHP development group is doing to help things (like the filter extension).

In a new post, Pádraic Brady wonders something that has bothered many a PHP community member at one time or another - "is one insecure PHP application too many?"

Unfortunately the nature of PHP as a programming language is that it's easy to foul up. And this has inevitably left the responsibility of security completely up to the individual programmer. The results have been less than comforting, leaving an internet populated by God know how many insecure PHP scripts and application written by well meaning but woefully under educated programmers and casual users.

He continues on talking about the education of programmers, PHP security resources, how the community reacts to the pressures of a wider audience hearing about the insecurities surrounding PHP apps, and some of the efforts the PHP development group is doing to help things (like the filter extension).

In this new post to his blog today, Stuart Herbert suggests something that the PHP community really is in dire need of - a site/resource providing a place developers can point at to help refute some of the PHP rumors floating around and provide examples and test cases for one of the most stubborn PHP markets out there - business.

At work, we make and sell software written in a number of languages; our flagship product is written in PHP.

But one of the unfortunate side-effects of Stefan Esser's much-publicized departure from the PHP Security Team has been an increase in the number of IT staff we're coming across who "believe" both that open-source is inherently insecure, and that PHP in particular has incurable problems. These "beliefs" hurt ISVs trying to sell PHP-based applications into skeptical organizations.

He asks why there is no "Why PHP?" resource out there that clients/businesses in general can be referred to for better information. He also suggests one of the most logical fits for this kind of information and is surprised they don't really have something already - Zend. Check out the comments to see how much of the community is already behind the effort.

In this new post to his blog today, Stuart Herbert suggests something that the PHP community really is in dire need of - a site/resource providing a place developers can point at to help refute some of the PHP rumors floating around and provide examples and test cases for one of the most stubborn PHP markets out there - business.

At work, we make and sell software written in a number of languages; our flagship product is written in PHP.

But one of the unfortunate side-effects of Stefan Esser's much-publicized departure from the PHP Security Team has been an increase in the number of IT staff we're coming across who "believe" both that open-source is inherently insecure, and that PHP in particular has incurable problems. These "beliefs" hurt ISVs trying to sell PHP-based applications into skeptical organizations.

He asks why there is no "Why PHP?" resource out there that clients/businesses in general can be referred to for better information. He also suggests one of the most logical fits for this kind of information and is surprised they don't really have something already - Zend. Check out the comments to see how much of the community is already behind the effort.

Tobias Schlitt has a great (long) post responding to a proposal made on the php.internals mailing list for the inclusion of "taint mode" in upcoming PHP versions.

Tobias starts with an overview of what "taint mode" is so that everyone's on the same page. His example involves the incoming and outgoing data usually involved in an application and how the incoming can be the most problematic when it comes to the values inside. This is where taint mode can come to the rescue. At its most basic level, it's a method for, assuming everything coming in is "tainted", creating a mechanism to automatically clean the data before it's even touched.

With the basics down, Tobias looks back to the proposal for a few additional comments. He considers the proposal a great way to introduce the functionality to the language. There are some draw backs he mentions, though, including the additional overhead of working through every inputted value.

Overall, I think this whole thing would be a great addition to PHP and I hope this could come for 6.0. What do you think?

You can also check out some other opinions on the matter:

• "Tainted mode" pour php on the Kamelot Blog