DevShed.com has a new tutorial posted today looking at how to sanitize data in your application, specifically data coming from the user, when calling shell commands.

Neglecting to sanitize user input that may subsequently be passed to system-level functions could allow attackers to do massive internal damage to your information store and operating system, deface or delete Web files, and otherwise gain unrestricted access to your server. And that's only the beginning.

He starts with a "real world" example of non-filtered data that could pass through a "rm" command and erase your entire drive. He offers two solutions for preventing this sort of hack using the escapeshellcmd and escapeshellarg functions.

On Reddit.com there's a recent post that asks the question How do YOU sanitize input in your PHP applications?

I am developing some software for my high school using HTML, CSS, MySQL, and most importantly PHP. [...] So I pose this question, what is YOUR favorite way to sanitize input for inserting, updating, or selecting from a database? Also, is there any way you prefer to verify that input is of a certain type, and only of that type ie, if you're expecting an int or a string, how would you make sure you are receiving one?

Answers on the post touch on things like:

• parametrised queries for databases
• filter_var/filter_types
• Sanitized versus "database-safe"
• using PDO
• avoiding the false sense of security things like mysql_escape_string and mysql_real_escape_string

On the Dream In Code forums there's a recent post showing you how to prevent mail() header injections when taking user input, like from a form.

PHP's mail() function is a very useful and powerful function, even to the point that it is very easy to exploit. A way hackers exploit this function is a method called email header injection. [...] I'm sure most of you can already tell that's not going to be pretty since we didn't check the user input and so forth. PHP provides us with functions such as filter_var which will validate user input and either return false if the validation fails or return the filtered data.

He includes an example of using this filtering methods to check the user input for malicious information - validating that the "to" address is a valid email (FILTER_VALIDATE_EMAIL) and a sanitize() method that removes things like newlines, carriage returns and a few other characters.

On the Smashing Magazine site today Phillip Tellis has a new article advocating a common thread in PHP application development (really, any application development) - sanitizing user input to help keep you and your application's user safe.

In this article, I'm joined by my colleague Peter (evilops) Ellehauge in looking at input filtering in more depth while picking on a few real examples that we've seen around the web. As you'll see from the examples below, insufficient input validation can result in various kinds of code injection including XSS, and in some cases can be used to phish user credentials or spread malware.

Several examples are included show things like unfiltered use of PHP's superglobals, incorrectly quoted HTML attributes and some commonly overlooked areas like title tag injection and javascript analytics handling. They also talk about the different contexts the data might need to be filtered on - HTML, attributes, URLs, javascript, CSS and others.

Padraic Brady has a new post on his blog talking about a new proposal he's made for the Zend Framework about filtering and sanitizing HTML content.

For a while now, I've been keen to build a HTML Sanitisation solution for PHP. Where else would I end up putting it other than in Zend Framework? As I've explored in past articles [1] [2], HTML Sanitisation in PHP is a very inconsistent practice. [...] Isn't it possible to create a sanitiser that is both secure by default and performs well?

He talks about his Wibble tool that's become the base of his idea for a filtering feature built into the framework. It mainly uses the PHP DOM functionality and HTML Tidy for speed and parsing and was benchmarked as performing better than the HTMLPurifier tool. If you're interested, check out his proposal for its inclusion in the Zend Framework 2.0.

Padraic Brady has a new post to his blog today about something that has caused a lot of pain over the years for developers (not just PHP ones either) - HTML sanitization.

In this article, I take a look at some of the solutions PHP developers rely upon to perform HTML Sanitisation. Mostly because few others have done it or written about such solutions in any great detail (at least publicly). HTML Sanitisation has a very low profile in PHP. It's rarely mentioned, usually not understood all that well, and examining some of the solutions in this area with more deliberate attention is worth doing.

He introduces the subject, just to catch everyone up to speed, and describes some of the common problems developers have butted up against. He shows three different candidates for helping you filter the HTML input more effectively:

• PEAR's HTML_Safe
• htmLawed
• Kses (in WordPress)
• HTMLPurifier

Each comes with a description of what the tool is and some of the pros and cons of using it.

On the Genius Engineering blog today they share a library they've created to help filter out possibly malicious content coming from the user - HTML content, valid or not.

Some time ago, Genius Engineering decided to unify the manner in which we encode values that contain user input. We previously depended upon the PHP built-in htmlentities() and some simple wrappers around it for our encoding needs, but this function alone can't safely sanitize tainted data in all contexts. [...] While there is plenty of information about these issues and what must be done to fix them, there is a distinct dearth of libraries in PHP to properly encode strings for all of the situations.

They include a few code examples of how to use their sanitizing library [tar.gz] to filter HTML overall, HTML attributes and filter strings for use in Javascript.

Adam Jensen has a new post to his blog today looking at a solution he's created to be able to access the raw input a user has entered.

I've run into a minor problem, and I'm not sure my solution is particularly ideal. See, the Zend_Form approach described above does a great job of implementing Chris Shiflett's Filter Input, Escape Output principle...user input is filtered for invalid HTML before it's ever saved to the model, and can then be escaped as appropriate in the view layer. But what happens if you need to be able to retrieve the user's original unfiltered input later?

While working with the raw data could be dangerous, he has created a custom model that, through the getters and setters and doing validation/sanitization and the presentation layer rather than behind the scenes. It's not ideal but he's willing to take suggestions...

On the Insane Security blog there's a new post recommending (despite the title of the post) the use of something that comes standard to every PHP5 release - the filter extension - and how it can help you protect your application and its data.

Yesterday while browsing some security tagged discussions on stackoverflow.com I've noticed someone mentioned some filter_ prefixed PHP functions. At first I thought they were some custom written ones, but on a quick check it turned out that there really where this functions. I was shocked. Anyway, let's digg into it...

The post covers all of the filters (validate, sanitize and "other") as well as the functions the extension includes like filter_has_var, filter_input and filter_var.

This recent post to Mattias Geniar's blog takes a look at an alternative to trying to catch every single thing that could be filtered on user input with a regular expression - the filter_var function.

Just about the biggest time-sink on any project, is the amount of input validation that needs to be done. You _have_ to assume your visitor is a maniac serial killer, out to destroy your application. And you have to prevent it. [...] Thus starts our never-ending battle for user input validation. We can't allow it all so we check every value presented to us. But using PHP's filter_var function, this can be made 100x easier!

He includes the long list of filtering types that the function has to offer including sanitizing strings, working with special characters and validating input like email addresses, URLs and IP addresses.