Evert Pot responds to a recent DevShed article in a new post to his blog today.

The one major flaw in the article is that it is suggested input validation is enough protection. This is not the case.

He notes that their solution just isn't enough to really protect much of anything in your scripts. He corrects the articles where it says that mysql_real_escape_string is a good secondary line of defense by suggesting that you always use it. It is a much more effective way to remove potentially harmful characters than a regular expression of your own devise.

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.

Ivo Jansch has a reminder for developers when they're putting user data into their databases - don't use addslashes.

[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.

Ivo Jansch has a reminder for developers when they're putting user data into their databases - don't use addslashes.

[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.

Chris Shiflett points out an unexpected SQL injection possibility as presented by Alexander Andonov for PHP (involving mysql_real_escape_string).

The focus of the article is stressing the importance of filtering input and escaping output, as neither is a substitute for the other, but he does so very clearly with specific examples [...] A number of example exploits are supplied for each case, and he discusses which ones work, which ones don't, and why.

Chris also uses the post to link to Paul Reinheimer's post about add_slashes versus mysql_escape_string and his own post on the same topic.

Chris Shiflett points out an unexpected SQL injection possibility as presented by Alexander Andonov for PHP (involving mysql_real_escape_string).

The focus of the article is stressing the importance of filtering input and escaping output, as neither is a substitute for the other, but he does so very clearly with specific examples [...] A number of example exploits are supplied for each case, and he discusses which ones work, which ones don't, and why.

Chris also uses the post to link to Paul Reinheimer's post about add_slashes versus mysql_escape_string and his own post on the same topic.