In this recent post to his blog Padraic Brady looks at the Zend Framework security releases that were made the other day - versions 1.9.7, 1.8.5 and 1.7.9 - to correct a number of security issues in each release. For those that are curious, you can find the full list of fixes here.

While an ongoing process, the initial [security] review focused on specific areas most likely to deal directly or indirectly with user input and the output of user sourced data. [...] The review also included an examination of all new components due to enter service with Zend Framework 1.10. This yielded a number of issues whose fixes will preempt their release into a stable version, and have been reported to the relevant lead developers.

Padraic mentions some of the things that were found and corrected in these security releases including the enforcement of a default character set throughout the framework (with new functions to help with keeping your data consistent) and several potential XSS vulnerabilities in components like the Zend_Json, Zend_Dojo_View_Helper_Editor and Zend_Filter_StripTags.

In this new post to his blog Gareth Heyes points out a legacy issue that those running older PHP4-based code might want to look into:

I thought about something I found ages ago in PHP4 and it's been long enough now. This is also quite funny because my server is vulnerable to this. So what happens if you escape PHP_SELF with htmlentities($_SERVER['PHP_SELF'], ENT_QUOTES)? Safe from XSS? I hope so. Safe from everything? Well not really or at least it didn't used to be.

He gives a simple example of how the PHP_SELF issue can be used to change the form's target just by using a few well-placed slashes. Thankfully, this seems to be only back in the world of PHP4, so those working with PHP5 should be safe.

Keith Casey has a suggestion for budding (PHP) developers out there looking to jump head first into their first project: "Don't trust the users."

Recently I taught a class of bright-eyed, bushy-tailed PHP'ers just getting their start in the world. They haven't done their first production application and we were working in the "safe" confines of a classroom, but there was one concept that I pounded into their heads: Don't Trust the Users.

Generally, as Keith mentions, users aren't malicious/incompetent/ignorant 99 percent of the time, but there's always that off chance that they are and you need to protect you and your application from it by filtering input and escaping all output to prevent any mishaps.

Juozas Kaziukenas has an example of how to keep you and your application's data safe from prying eyes by filtering input with the HTML_Purifier package.

It's really hard to decide what data is acceptable, especially when user has permission to insert HTML content through form. [...] However, problem can be solved, and quite easily. Almost a year ago I was reading some random blog when I find out about HTML Purifier. Basically, it's library which can filter and fix any HTML.

He gives an example - running a web scraping tool against a site with malformed HTML. By running it through the HTML_Purifier package first, the errors were corrected and the "more correct" HTML source could be parsed easily. The package also helps to protect from XSS attacks via a whole set of filters included by default.

Douglas Brown has a few helpful hints to help you write your PHP code defensively, protecting your code from malicious attackers.

The phenomenal growth of PHP applications has also led to a mushrooming of increased quantum of malicious activity. It thus becomes imperative that you write secure PHP code to protect your website. Here are some tips for the same. The three most vulnerable aspects of PHP that can become easily accessible to anyone are XSS (Cross Site Scripting), Global Variables and SQL code.

He details what each is and how you can protect your code against the problems they cause. Some example code is included to give you a better idea of the possible solution.

Jani Hartikainen has posted a few ideas on cross site request forgeries in a new blog entry, including some methods to help prevent it in your application.

CSRF, or Cross-Site Request Forgery, is a vulnerability very common in websites. [...] This can be dangerous, especially if your admin interface is compromised: There may be a button on the other site which goes to your admin interface and deletes the latest blogpost for example - and you wouldn't want that!

His method is a three-step process for protection - use POST, protect against cross-site scripting and use a CSRF key in the form to help prevent abuse. A simple script is included to show it working and is adapted to work in a controller plugin for the Zend Framework.

On the symfony blog Fabien Potencier encourages all symfony developers that the security of your application must be taken seriously and that, despite the built-in protection the framework offers, there still could be issues.

The symfony framework has always provided the tools needed by the developers to secure their applications. With the new form framework, we have added an automatic protection against CSRF. Speaking of the form framework, we have also added a lot of security features to protect you against all sort of injections.

He does include an example, though, of a situation where it's not just about protecting from cross-site scripting or attacks. It's about checking user input to ensure it's what it should be. They give the example of a user pushing an "is_admin" value into a form posting where there wasn't one and updating the right column to give them admin rights.

He mentions some work the Rails team has tried to do to prevent this sort of thing automatically, but Fabian points out what the symfony framework already does - prevent any injected fields other than what's in the forms from being submitted and included.

The IBM DeveloperWorks site has posted some advice that can help keep you, your application and your data safe from security-related attacks.

Security in a PHP application includes remote and local security concerns. Discover the habits PHP developers should get into to implement Web applications that have both characteristics.

The habits in their list are:

• Validate input
• Guard your file system
• Guard your database
• Guard your session
• Guard against XSS vulnerabilities
• Guard against invalid posts
• Protect against CSRF

Each comes with their own explanation and for some, code to help you spot the mistakes and correct them.

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.

The CodeIgniter framework has made a new release today, 1.6.3, containing updates to fix a few bugs and address some security concerns.

We are happy to release CodeIgniter version 1.6.3 today. Version 1.6.3 is primarily a maintenance release, with a variety of bug fixes and some refinement to existing features (with a few new ones tossed in for good measure). Details of course can be found in the Change Log.

The release also fixes a potential cross-site scripting issue that, while it hasn't been reported as used yet, could still have some bad consequences if found and abused. You can grab this latest version from the CodeIgniter downloads page.