On DevShed today there's a new tutorial looking at a method for protecting your application (your MySQL/PHP application) forms from malicious attacks like SQL injections.
It has been known for a while that if a form is unsecured, malicious code in the form of MySQL injection will be initiated to attack the site. HTML forms such as drop down menus, search box, check boxes are all susceptible entry points of this type of abuse. This article will explain what happens in this kind of attack, and how to prevent it.
Robert Basic has a new blog post looking at the filtering extension included with most PHP5 distributions.
Filter extension? Maybe it's nothing new for some of you, but it is for me. I've never heard of it before. So I quickly hopped over to PHP.net and the Filter chapter of the manual.
The filter extension (included as of PHP 5.2) helps clean up and validate user input - really any input - like number matching, regular expressions and email addresses. He includes some examples of filtering strings, email and integers as well as ways to sanitize the same strings, ensuring they are valid and clean values.
Sameer has posted his "easy way" to validate user input coming in over a POST request:
Validating POST data from a form is a common requirement for a developer. If the number of form fields are few than the validation is a small matter. But the case is different when the form contains more than 15 or 20 fields and some of the fields are mandatory. The following code will give you an idea of how to easily validate mandatory fields, whatever the number of fields.
His method prefixes the form fields with a certain string (in his case "c_") and uses that to loop through and act as a hook to check only the form values that were submitted (and nothing else that happens to be in the $_POST array). Any number of checks could be added on to this simple example including type checks, length and validating off of another field - like a password confirm match.
DevShed finishes off their series on database security in PHP applications with this look at protecting your application and data from the threat of SQL injections.
In this article we will continue to explore various attacks that can be made on a database and how to prevent these attacks. We will also build the last page of our site.
Their example script is a login for a secured area of the site and contains a possible place for an injection - non-validated user input. With something as simple as making the username a single quote, an attacker could find out more about your database structure and use that to get further into your systems. To avoid it, they recommend validating with the mysql_real_escape_string function as a first line of defense.
I came across an instance using Zend_Form recently where the level of flexibility offered was a bit of a double-edged sword. In order to provide maximum flexibility per form element instance, each has not only their own filter, validator, and decorator instances, but also a plugin loader instance for each of these three types of plugins. These add up quickly when you have a form with several hundred elements in it.
To prevent bloated code and redundant plugin definitions, he subclasses the Zend_Form component into a Custom_Form class that defines central plugin loaders for all of the elements so that when an element is created and a plugin is used, it will always pull from the centralized location rather than a (possibly different) custom one defined on the element.
Kevin Waterson has posted a new tutorial to the PHPro.org website today stepping you through the automation of handing reciprocal links.
This tutorial looks at the process of reciprocal links. That is, links generated from websites that have links to your own page. These links back to a page can be detected from the HTTP REFERER which, in PHP, can be detected via the super global variable $_SERVER['HTTP_REFERER']. Care should be taken when using this variable as it is set from userland and, as such, should not be trusted.
His method stores the linking information (gathered from the referrer) and calls an addLinks method that checks to ensure the page format is valid and that it's a real site before putting it into the table. Complete code for this, a fetch method and a simple database layer to put it on top of are included.
In this new tutorial from DevShed, they continue the series looking at developing a simple web application with security being one of its primary goals.
In the last article we started to build our site and then continued to explore the login script. In this article we will continue to explore the script but will also discuss in detail the process of authentication and its security implications. We will eventually look at some of the common attacks that are perpetrated by malicious users.
This fourth part of the series adds the authentication piece to the puzzle - a simple system that does some form validation and checks the input against a MySQL table (users). Full code explanation and example usage is included.
The IBM DeveloperWorks site has posted some advice that can help keep you, your application and your data safe from security-related attacks.
Security in a PHP application includes remote and local security concerns. Discover the habits PHP developers should get into to implement Web applications that have both characteristics.
Francois Zaninotto submitted a tutorial he's written up about creating a YAML validation script with PHP.
As of today, there is no simple way to validate the syntax of a YAML file in PHP. But with two simple tricks, it takes only a few dozens of lines of code to build a robust validator capable of checking the syntax of any YAML file against a given schema.
He points out that Ruby has a tool for this (kwalify) but PHP doesn't. He creates his own with the help of the sfYaml component from the symfony framework, translating the YAML data into something PHP can parse more easily - XML. He passes this through an XSL parser and uses the DOM XML schemaValidate function to check it against the given schema.
Ken Guest, in a response to another post from a different blogger, has posted some of his own validation replacements for the regular expression method the other blogger chose.
I've noticed that Richard Heyes, who professes himself to be a php guru, deleted my comment on his "Some common regular expressions" posting which simply pointed out his expressions didn't quite do the job and suggested a few PEAR packages that should be used instead of the expressions that he proffered
His examples have the benefit of what he calls "defense in depth" - the functionality to catch a bit more than just a regular expression can alone. His examples include PEAR_Validate for email addresses, Net_CheckIP2 for IP addresses and the Validate_UK package for the sort code and telephone numbers.
