The Stubbles framework team has released the latest version of their framework today - Stubbles 0.1.0:

The Stubbles team is proud to announce the release of Stubbles 0.1.0. This release is a first alpha version and contains the basic features of Stubbles like the Extended Reflection API, XML handling with XMLStreamWriter and XMLSerializer, Logging, Event handling, support for filtering and validating user input and session handling. The release additionally contains parts of packages that we announced to be in the next milestone 0.2.0.

The Stubbles framework is one that seeks to "combine your favorite features from other programming languages and frameworks" and is flexible enough to allow for easy interfacing with other frameworks/components like PEAR or the Zend Framework.

The Zend Developer Zone has posted two more handy security tips - one concerning file/directory naming and the other about input validation.

From the first tip:

Don't rely on obscure names to keep your application safe. You should always check permissions, test for vulnerabilities with testing tools and keep an eye on your log files for suspicious activity. When designing your applications and web sites though, don't make it easy for bad people to do bad things. Don't use default or common names for your files and directories.

And from the second:

It's a sad fact of life but users are evil. Users want nothing more than to find a way to exploit your application. As soon as you let your guard down and start thinking "I'm only selling small stuffed animals so how evil can my users really be?" you've lost the battle.

You can catch up on these and the other previous security tips on this page on the Zend Developer Zone website.

The Zend Developer Zone has a new tutorial posted today by Pierre dealing with one of the things becoming (and should have always been) important to PHP developers - filtering input. Specifically, it deals with using the Filter extension built into PHP 5 to take care of anything malicious or incorrect that the user might throw at the application.

Security becomes the top priority (or activity) of many PHP developers. Its place and importance keeps growing in every single project, open source or commercial. Every conference provides a talk about security and you can read PHP security on the magazine cover pages.

The article is broken down into different sections, including:

• Don't trust external data
• Why Filter?
• How does it work?
• Prerequises/Installation/Considerations

And, of course, what would a tutorial be without some examples. Pierre shows a simple form that filters, a sanitizing form, and some more complex processing using a callback.

Following up from the previous article on the Metapundit.net blog, there's part two of the "Code Smells" series - a look at bad things to do in your code (to make it "smell").

This (and any subsequent posts in the series) will be more limited in scope - a single bad example and a corresponding solution.

This time, the spotlight is on parameterised queries - inserting the variables directly into a SQL statement string versus filtering them or inserting them via a custom query() function. He points out that there's no need to create this kind of filtering/database handling class on your own, though - there's already been one created by the fine folks of PEAR (using the autoExecute function

Jacob Santos has posted a new entry on his blog today with his own take on regular expressions and their collaboration with the Filter extension in PHP.

Regular Expressions are a powerful way to parse and evaluate strings. They can be fun sometimes, but there is rarely an indication of the reason why they fail.

I knew it would be satisfying, once I seen this (the Filter extension) in passing on the php.net site. It uses the procedural method, which I think fits perfectly. If you try to throw objects at a novice than most aren't likely to use what you give. It is really simple to use, so there is no longer any excuse for an developer to not be using it, if using PHP 5.2+.

He gives examples of email validation methods both with and without the Filter extension, making it abundantly clear which is easier - a simple call to filter_data validates with no muss or fuss.

On PHPBuilder.com today, there's a new tutorial that looks at a method to protect your PHP applications with the filters the Open Web Application Security Project provides.

OWASP (Open Web Application Security Project ) released a top ten list for web application security vulnerabilities in 2003 and 2004; you can find the latest information about their Top Ten Project here.

Most of the top ten vulnerabilities including (A1) Unvalidated Input, (A2) Broken Access Control, (A4) Cross Site Scripting (XSS) Flaws, and (A6) Injection Flaws, can be avoided by using these filters.

They walk through the installation before talking about the types of filters at your disposal - paranoid, SQL, system, HTML, int/float, UTF-8, and LDAP. The check() function looks at the inputted value to see if it passes the test (the other option the function takes).

They also give an example of combining filters as well, making more secure validation even easier.

Davey Shafik has created a cheat sheet useful for any developer out there using a database, one to remind you of the filtering and escaping techniques to use before putting data into your database or outputting it to your site.

After having two conversation on escaping data for MySQL? insertion within 5 minutes of each other in ##php@freenode, I decided to created a cheat sheet on Filtering & Escaping in general.

I think what most people are not aware of is that not just outputting to the browser is output. So it querying a database, or calling one of the exec functions, or even using the mail function (not mentioned on the cheat sheet, perhaps for v2.

You can grab the cheat sheet here in a PDF format.

Spam has grown into one of the worst problems on the internet today. It effects everyone, even those that guard their email addresses with their lives. Information spreads so fluidly in the bits and bytes of everyday communication, that it's almost inevitable for your address to get out. Once it's out, you'll know, getting emails from people you don't know offering things you don't want. One tool spammers can use, unfortunately, are the unsecured forms on your own site. Thankfully, there's articles like this one from PHPBuilder.com that can help you safeguard your site against these attacks.

Insecure PHP scripts have provided great opportunities for spammers to abuse other's resources to send out their spam. In particular, it's the mail() function that can be abused. I myself was the target a few months ago when I noticed spam being sent from an old form on my server that I'd forgotten about. This month's article looks at techniques that can be used to harden your mail form, and reduce the chances of it being misused.

They set up the simple example script and show you how to exploit it to follow the wishes of potential spammers. They offer a few suggestions on hardening the form - filtering for a correct email address, checking for "bad strings" in the contents of the form, and looking for a REQUEST_METHOD value in the $_SERVER array. The methods aren't fool-proof, but they can help to dramatically reduce your chances of being the source of a lot of people's annoyance.

In this latest tutorial on DevShed today, they look at methods to enforce the types of objects in a PHP4 environment.

When you are writing an object-based web application in PHP, you want to prevent your classes from being convoluted with input objects of the incorrect type. These input objects can cause the application to throw a fatal error. In this article, you will learn how to enforce object types in PHP 4.

By the end of this series, hopefully you'll have a clear idea of how to force object types inside of your PHP application, in this way avoiding further problems related to the so-called code contamination.

They start off with the creation of an (X)HTML widgets class to render certain page elements. Then, they show you the creation of a class to render the page and display them in a full document. There are examples of what happens when type checking isn't done and how to enforce the types inside of your class.

Pierre has posted his second look at working with the imagepng function today over on his blog.

Bernhard Seefeld was testing the new compression option for imagepng and was wondering why there is still a relative big difference in image sizes.

In my first attempt to create smaller images, I only allowed to change the compression, it was not sufficient to get really lite pictures.

After a short look to the libpng codebase (and the horrible imagick doc), I added a last argument to imagepng, the filtering mode.

He includes code later in the post, showing how to use this filtering option to make even smaller images (an option included from PHP 5.1.3 and up).