Rafael Dohms has an interesting new post to his site today looking at a library he's developed (inspired by the Symfony Validation library) to help filtering values with rules defined in annotations.

PHP does not have native Annotations support, however many projects have been using doc blocks to add value and semantics to code, like PHPUnit, Doctrine and Symfony. The Doctrine did a really good job in making available a Annotation parser kit, which allows you to bring the power of annotations into you own project. This opens up a few possibilities.

He shows the current use of the Validation library with a sample check of a $name variable for "not blank". His tool, DMS, extends this functionality and gives you access to both custom filtering methods and standard PHP functions to filter the resulting variable value. He includes an example showing two variables with filters StripTags, StripNewlines and Trim as well as the code to execute the filtering. You can get the library either ready to integrate with Symfony/Doctrine or as a standalone tool.

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.

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.