DevShed continues their look at security in PHP applications in this third part of the series, a focus on filtering and login systems for your applications.

Any web site that is selective in the kind of users that it wants to grant access to will need some method of filtering. This filtering is usually done through a login system. This (and more) is what we will be building.

The site is made up of a few key components - login/logout pages, password management, a registration page and various configuration and settings files. They include everything you'll need, including the HTML and CSS to make things look exactly the same. The backend is driven off of a MySQL database to store the users and their account info.

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 Zend Developer Zone has a reminder for those in the Amsterdam area - the phpGG user group (newly formed) will be having their next meeting on September 23rd.

On Tuesday 23 September 2008 the Dutch PHP user group will have its first meeting, in what will become a bi-monthly event. The goal is have meetings with other members, enjoy some coffee and tea and meeting other developers and the chance of prizes to win.

Two speakers will be presenting from about 8pm to 10:30pm - you can find out more about the group and the meeting from their site, including how to get there.

In a new post to the Debuggable blog Felix Geisendorfer illustrates a simple access rights system that can be plugged into any CakePHP application you might be developing.

If your application is like most, then you have some basic permission requirements for your data. A simple scenario is the following. Blog posts can only be edited by their owners and administrators. Same goes for viewing unpublished blog posts.

His example modifies the typical "posts" controller to add in a new model (User) with a permission check (can) and a model that implements it into the PostsController to ensure that a user can view any given posting.

On his blog, Roshan Bhattarai shares a few tips on keeping your application safe by filtering user-submitted data.

Yesterday, I saw one of my friend was working on the the contact form and was filtering the user input data(posted variables) individually. He was using a function in PHP to filter the input and using tedious approach while calling the filtering function for each variables with coding each of them in single line . Today, I'm going to show you how can you filter the posted variables easily using callback function in PHP.

He shows how to create a filter_data function (for removing HTML embedded in the data) and how to implement it around your data. It could be extended pretty easily to do more than one filtering method to protect your information even more.

This recent post from the Mind Tree blog shares a few methods for testing your web application (not unit test, just general things).

Because the Web "environment" is so diverse and contains so many forms of programmatic content, input validation and sanity checking is the key to Web applications security. This involves both identifying and enforcing the valid domain of every user-definable data element, as well as a sufficient understanding of the source of all data elements to determine what is potentially user definable.

They note that the root of most problems is input validation - most applications either just don't do it or do it poorly. They include a few tips on first security the environment the application is running in (like checking the HEAD/OPTIONS values and ensuring you're only allowing known file extensions and directories). They also mention the insecurity behind HIDDEN form elements and some issues surrounding user authentication.

On the PHP::Impact blog Federico has posted a sort of reminder about a method you can use to run PHP scripts as different users on the same system - suPHP.

suPHP is a tool for executing PHP scripts with the permissions of their owners. It consists of an Apache module (mod_suphp) and a setuid root binary (suphp) that is called by the Apache module to change the uid of the process executing the PHP interpreter.

suPHP runs as an Apache module and works with the local server's permission system to restrict script access to whatever the user's allowances are. He links to this tutorial for more information on setting it up.

In this new post to the blog.szajbe.pl site a dilemma is presented - CakePHP models are not working they way one would think they should.

In CakePHP you declare what models you're going to use in a controller by defining $uses variable. You can also define it in AppController to have a certain set of models available in every controller. However be careful when doing it because you may put yourself in an unexpected situation as I did recently.

As soon as he made his script include a 'User' model in every quest, his logins stopped working. His script errored with a "Database table sessions for model Session was not found" message and refused to work. Digging deeper, he found that CakePHP merges an AppController's $uses value with the SessionControler's values. One overrides the other and your 'User' gets lost in the shuffle.

Do you have a rational explanation for such behavior? I have none. It's very unintuitive for me.

Via Terry Chay's blog:

On the Developer Tutorials Blog today, there's a new post aimed at WordPress users to help them on the path to becoming "power users" with five tips.

If you're a wordpress power user, you'll inevitably have some questions about how you can improve your blog or add new features. Here are five tips that will make life easier for people wanting to maximize their use of Wordpress.

The list is:

• Quickly Find Page/Post ID
• Custom Front Page
• Password Protect Wordpress
• Protect from the 'Digg Efect' with HTML
• Stop Hackers

Each of them with their own explanations (and links to other resources detailing how they're done).