The PHP::Impact blog has pointed out that the Zend Framework has gotten even closer to having a true method for dependency injection in its applications - a proposal issued for Zend_Container.

Bradley Holt has announced the creation of a new proposal Zend_Container, a simplified version of Zend_Di. According to him, if the framework is going to have a dependency injection component this component needs to be as simple as possible, something along the lines of PicoContainer.

The proposal seeks to replace the use of class-managed singletons and Zend_Registry, scope access to containers and use reflection to determine dependencies for items inside. The component has been given the go-ahead from the ZF team and development is already in process.

Ian Barber has written up a look at dependency injection as a part of the Zend Framework's controller functionality for the Ibuildings blog.

Among the standard object oriented principles is favouring composition over inheritance, and there are plenty of design patterns that work along this line. However, one of the most useful day-to-day facets of the idea doesn't seem to get a lot of attention from PHP developers, namely dependency injection.

The general idea is, that if your class depends on some other object, that object should be passed in rather than generated internally or retrieved via a global variable or singleton.

He shares few ideas on how you can use this method in the controller of a Zend Framework including the use of the Zend Registry and an Action Helper. Code snips are provided for reach to show you how it'd be done.

On PHPBuilder.com, there's a new tutorial about validating user sessions - ensuring that data in your user's sessions is valid and isn't an attack trying to sneak in.

In a nutshell, sessions are the way that we "maintain state" from one page to the next, that is, how we identify specific users across multiple page requests. The ability to track users as they go from one page to the next using sessions allows us a number of options, such as tracking where they are going (web statistics) or to verify credentials for a specific section of the site.

First, there's a little mini-intro to sessions for those unsure on their use. It's followed by a look at some session vulnerabilities that could be introduces by malicious users looking to break things on your site (including HTML/Javascript injection, as their example shows).

They recommend a three step plan to get started with the validation of your user's sessions - making it easy for users to log out when they want to, use unique aspects of the remote machine to define the session and to validate all user input, especially things that will be put into a session variable.

Gareth Heyes has a quick new post to his blog today about the use of htmlentities and the false assumptions some developers have about it:

When someone uses htmlentities I've seen it time and time again that they expect that it filters variables from all XSS. This is wrong of course because the function requires a second parameter ENT_QUOTES which correctly replaces quote characters. Some developers aren't even aware that quotes can lead to XSS injection.

He reminds developers of the second parameter - the ENT_QUOTES parameter that correctly replaces quotes. Other people have mentions things in the comments as well like another optional parameter to force an encoding type and opinions about the function's use.

Paul Jones has posted a new tutorial about using the mail functionality of the Solar framework - the Solar_Mail and Solar_Stmp packages.

While each of these [PEAR Mail, PhpMailer, SwiftMailer, Zend_Mail] will work with Solar, the new Solar_Mail and Solar_Smtp packages work "natively", in that they support automatic configuration, locale and exception inheritance, and so on. Read on for some examples on how to use them.

In his example he sets up and sends a simple message, setting the contents of the email (sent as an HTML message). Since there's been much talk about the safety of a lot of the mailing systems in frameworks, Paul talks about how it's been secured from header injections, through safe attachments, and from a transport dependency-injection for SMTP.

There's even a method included that lets you take the SMTP information out of the script and put it into the Solar configuration file to use in the entire application.

This new post on the Sanisoft blog has some good news for CakePHP developers concerning the bundled email component - it now can be made header injection safe.

In Cheesecake 1.x we had used our home grown component for sending emails. Having learned our lessons from the headaches of Pixelpost team due to email header injection attacks in their comment mailing code we had taken precautions to make our code safe from such attacks.

They proposed an update to the CakePHP functionality to integrate this solution on a more permanent basis.

Continuing in their security theme for the month of March, the Zend Developer Zone has posted two more Security Tips for PHP developers out there:

• The first tip (#6 on their list) talks about the benefits of casting all of the values going in to your SQL queries. This helps keep you and your data away from things like nasty SQL injection issues that could result in exposure of valuable data.
• The second tip (#7) focuses on regeneration of session IDs to help prevent fixation. They give an example of how, without it, you could inadvertently allow in unauthorized users. Thankfully, one quick function call can remedy the situation - session_regenerate_id.

Check out their full list for more great tips.

The PHP Thinktank Blog has posted two new IRC logs of talks give over in their IRC channel on the Freenode network.

Now that all the yearly holiday chaos is out of the way, we bring you new logs of two recent IRC discussions. As usual, they are available on the google group.

The two talks were:

• a look at Injection from BigE
• a discussion of web scraping with Elzar.

Alright all of you WordPress users out there, listen up - the project has released a new version that you should update to as soon as possible - WordPress 2.0.6. Too lazy to upgrade? You might want to check out the reason for the new release:

We have a pretty important release available for everyone, it includes an important security fix and it's recommended that everyone upgrade. This is the latest release in our stable 2.0 line, which we've committed to maintaining for several more years.

They've also included a new anti-XSS bit of functionality (attribute_escape) and a new filter for comments and such called "query" to escape things nice and neat. This is all to help resolve the security issue that came up.

Check out some of the comments the community is making about this release too:

• A release announcement from the JSLabs blog
• Stefan Esser's post on the PHP Security Blog
• an informative post from Ryan Malesevich's Blog

As mentioned on Digg, there's a very simple guide to securing your PHP applications - or at least taking steps towards that.

For the purpose of this tutorial we have listed some commonly known attacks, and how to protect against them. This is crucial for beginners in PHP because PHP tutorials and basic documentation does not accentuate this problem enough. Examples are given that are vulnerable to attacks, and students are either not aware of the vulnerabilities, or are not adequately educated how to protect their scripts.

They topics they look at are SQL injections, XSS attacks, CSRF attacks, and PHP variable insertion. They talk talk about one of the best things you can do to help secure your site and its data - input filtering.

If you've been paying attention at all to the buzz in the PHP community lately, you'll know that articles like this are nothing new. These are the same things other developers are commenting on as well. It is good to see it get more exposure via digg though...