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 DeveloperDrive.com site today, there's a new post with a few reminders for PHP developers out there of things it's easy to forget when writing your applications - some common mistakes to avoid.

Despite the high expectations placed on them at times, developers are human. They were the last time we checked anyways. As humans, we are bound to make mistakes from time to time. And simple, common mistakes often slip past our filters the more comfortable we become with something. [...] But knowing what these common mistakes are and how to avoid them can really help speed up the development process and keep our clients smiling.

His list includes three big ones that, if forgotten, could end up being detrimental to your application (sooner or later) - poor housekeeping/organization of code, forgetting punctuation and forgetting to validate input from users.

On the DeveloperDrive.com site there's a recent post anyone wondering about cross-site scripting should give a read. They introduce you to the basic concept and two things you can do to help prevent them.

This little fable describes the most common vulnerability found in web sites, the Cross Site Scripting (XSS) attack. According to a report from WhiteHat Security 83 percent of websites they tested have had at least one serious vulnerability and 66 percent of all websites with vulnerabilities are susceptible to XSS attacks making it the most common vulnerability web developers face. To fix this, it takes 67 days on average. Tools like WebScarab and Paros Proxy can be used to scan sites for possible vulnerabilities.

They offer two simple pieces of advice that it's all too easy to forget when developing applications - validate all user input to ensure it's what it should be and escape any untrusted output (even sometimes your own!) before pushing it out to the page.

On the Amazium blog Jeroen Keppens has a recent post looking at some of tools available to you when needing to filter input and escape output in your applications. This post specifically covers filtering on command line applications.

When you need data input in a web context, you send a GET/POST request to your script. On the command line, things work differently. In this blog post, we will talk obout input and output in php-cli.

The post is broken up into a few different sections:

• Handling arguments
• File descriptors
• Interactive input
• Resources mentioned in the post

Tools mentioned include everything from getopt and PEAR's' Console_Getopt out to using file descriptors and working with readline.

In a new post to his blog Brandon Savage talks about how some of your current validation rules (and restrictions on input values) could be causing blind spots in your application that you don't even know are an issue.

Our blind spots about validation can and do harm real users if they're poorly or incompletely thought out. What might seem like a completely rational limit to us might hurt a real user who needs to exceed that limit, through no fault of their own. How many women are "BETTYJEAN" because their first name "can't" have a space in it?

He makes a few suggestions developers can do to help the situation and get their current project's validation back out into 20-20 vision:

• Accept valid data in any form provided by the user.
• Where possible, use well-developed validation libraries.
• Do not place artificial limits on valid data.
• Do place valid limits on specific data.

Sameer Borate has a recent post to his blog looking at an important part of any application - filtering input from the user and output before its used. In his examples he uses a library called Inspekt (from Ed Finkler) to make the job a lot easier.

Most web security glitches are caused by insufficient input filtering and validation. Despite a large number of validation libraries being available, input sanitization is usually bypassed due to sheer laziness or the idea that your site is somehow immune from bad input data. Inspekt is one such library that has a small footprint and is very easy to integrate into your application.

He goes through the installation (a require_once) and a few examples of how to "cage" incoming data from a sample form with two hidden fields. He shows how to use the library to access the filtered versions of the values and how to run some tests on the data (like checks for alphanumeric, valid hostname, between two values, valid phone number, etc). He also briefly mentions "super cages" that can be used over and over.

Dan Horrigan, one of the members of the development team for the Fuel PHP framework has a recent post to his blog of an overview of the the security features of the framework and how it handles things like input and output filtering.

There are many ways to handle security in a web application, and many things to think about. This is by no means an in-depth look on application security. It is meant to be an overview of how to use the security features included in FuelPHP.

The framework lets you set up application-wide input filtering in your configuration file, making it a nice "set it and forget it" kind of thing you don't have to include in each form. There's three types of filtering - xss_clean, htmlentities and strip_tags. For output, he mentions the "e()" method that escapes your output and strips all HTML tags to prevent XSS attacks.

On the php|architect blog today John Mertic looks at a validation library that's been created to filter and handle user input for your application without too much effort on your part - Validation from a group called Respect.

It's simply called Validation, and it is a very simple and straightforward PHP 5.3 based validation library. The goal for them is to make validation easy and painless, using clever constructs like chaining and enabling developers to create reuseable components.

He shows a sample of how it all works by creating a validator that checks to be sure a given value is numeric. He also shows how you can chain the validation methods to create more complicated rules and even check for a set of value types (ex. numbers 1-10 or the string "NO"). You can find the code for Validate on their github repository.

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.