If you're a web developer, you've probably written any number of scripts designed to validate the input entered into a web form. More than likely, then, you'd like something that will make that job easier. Enter the Code Igniter PHP framework. In this fourth part of a nine-part series on this framework, you'll learn how to use it to do basic validation on a web form.

Making and validating forms in CodeIgniter is a pretty simple process thanks to the built-in validation features of the framework. They show you how to create a form and how to implement the validation and output error messages when an issue comes up.

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.

PHP doesn't have a built-in way to do this, and at first I was a little confused as to how I could reach this information. It turns out that this can be read from the incoming stream to PHP, php://input.

Pulling from that stream gave her the raw data she needed (nicely urlencoded too) that she could parse out and use. She includes a simple example that has a check for the REQUEST_TYPE in the _SERVER superglobal to see how the request should be handled (PUT versus GET).

This article walks through the brainstorming stage of planning for what is in this instance, a hypothetical user-centric web application. Although you won't be left with a complete project '" nor a market ready framework, my hope is that each of you, when faced with future workloads, may muse on the better practices described. So, without further ado...Are you sitting comfortably?

The tutorial is broken up into a few sections based around an example with a few points of failure (about book information). They work through the thought process behind the code, using the $_REQUEST variables correctly, preventing SQL injections, filtering the HTML output and a sample code download for you to see how it's all tied together.

Forms are how your users talk to your scripts. To get the most out of PHP, you must master forms. The first thing you need to understand is that although PHP makes it easy to access form data, you must be careful of how you work with the data.

The first part of the tutorial is focused on something many applications don't worry about - the security and integrity of the data submitted to them. They talk about things like filtering and various other checks to ensure that the data you're getting is good. They also mention the method for putting submitted values into PHP arrays, checking for valid values, using multiple submit buttons and an example of some of these methods all put together - validating a credit card number.

Want a custom one to share with someone you care about. Fill out the form here. It's a subtle effect though, they'll need to read it. Valid characters for names are just alphabetics and the underscore, sorry.

The custom output is a great little addition to the site - put in person one's name and person two's name and it updates the image to show the new parameters. Ah, geek love...

I've uploaded the 0.3 release of Inspekt, the input filtering and validation library for PHP4 and 5. With this release, Inspekt completes the goals of the original specification for the OWASP SpoC007 project. I believe it is ready for "real-world" use.

Along with the new code being released there's also more documentation, API docs, a PEAR channel and a mailing list.

[Addslashes] is not the best way to escape data. The most important reason is security. addslashes can lure you into a false sense of security. As Chris Shiflett points out, there are situations that addslashes doesn't escape. Use mysql_real_escape_string instead.

Ivo also talks about the advantages of using the right function and suggests another even more secure way too - PDO.

The idea itself is simple. When data comes into your application, it must be filtered prior to it actually being used for any reason. This means all data. Form values, URL values, and yes, even the values in the forever useful $_SERVER superglobal. [...] Before leaving your application, data should be properly escaped with the specific output medium in mind.

Previously he showed how, using an interceptor method in PHP5, you could build "collections of data". He uses the same sort of method here, appling custom filters to the data based on the output call. Code is included for both the filtering interface and two example filters - one for SQL and the other for HTML.

You can also grab the code if you just want to play with that.

After the success of my "a bit of fun" challenge, a few people asked for some more challenges. So I was answering a question on a mailing list that I'm a member of and I thought it would be a good topic for a little challenge and help sharpen everyone's regular expression skills.

This time, his challenge involves taking the input, rail start/end locations from an array and, via the PHP script given (no regular expression in it, of course) make the output, a sort of JSON formatted message. It's already been answered, but if you want to, try it yourself first then read the answer below the post.