Most PHP programmers have probably heard of SQL injection attacks – it’s when a hacker manipulates the SQL query sent to the database in a way the programmer does not expect.
For example you all too often find code like this in "PHP for Dummies" books:
mysql_query("SELECT * FROM username='$username'");
A programmer might expect $username to contain a string like "Weebl" and it’ll work fine. However, if a hacker manages to set the value of $username to something like "Weebl’ OR user_id=5" and it’d behave totally differently. Manipulated correctly, it could be used to steal confidential data or delete it.
The vast majority of people use addslashes() to prevent such attacks – this should make the string safe for input into an SQL query. However, the recommended way is mysql_real_escape_string(). Many people, myself included, use addslashes().
I came across an blog entry by Chris Shiflett today regarding the whole mysql_real_escape_string and addslashes debate. He provides an example of how you can successfully inject a single quote into a string which has addslashes() used on it which the database will treat as a single quote.
Despite the use of addslashes(), I’m able to log in successfully without knowing a valid username or password. I can simply exploit the SQL injection vulnerability.
To avoid this type of vulnerability, use mysql_real_escape_string(), bound parameters, or any of the major database abstraction libraries.
I’m unsure what conditions you need to reproduce this issue (e.g. what databases it works with, whether tables need to be configured in a specific way, etc.) but it’s a good idea to switch your code to use mysql_real_escape_string.
You could also use prepared statements in a Database Abstraction Layer (MDB2, PDO or the built-in support in mysqli); these do a pretty good job of keeping you safe from SQL injection attacks.