addslashes() allows SQL injection attacks

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().

The Problem 

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. 

6 thoughts on “addslashes() allows SQL injection attacks

  1. Thanks for the post, I have done it with addslashes() and you are right.

    1. the updated version of the function is mysqli_real_escape_string or mysqli::real_escape_string for support of Object Oriented.

    by the way if anyone is using Magic Quotes
    This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 6.0.0. Relying on this feature is highly discouraged.

  2. I didn’t know if you read it, but it says :

    “This type of attack is possible with any character encoding where there is a valid multi-byte character that ends in 0x5c, because addslashes() can be tricked into creating a valid multi-byte character instead of escaping the single quote that follows. UTF-8 does not fit this description.”

    So you need to fit this condition in order “to reproduce this issue”.


  3. I tried the sql injection attack but i was not successful. But still if so many peoples are saying that addslashes are not safe then we should try to switch to mysql_real_escape_string.

  4. it doesn’t work in real life. Chris Shiflett shows the example below:

    $_POST[‘username’] = chr(0xbf) .
    chr(0x27) .
    ‘ OR username = username /*’;

    So, in real life when you fill a form with chr(0xbf)chr(0x27) or %bf%27 all will be a string.. like “%bf%27”.. so, in real world the example above will be a string, and appling a addslashes will be “char(0xbf).chr(0x27).\’OR username = username \/*\’;” So, you will compare username with this big string and get error.. Chris Shiflett shows a poof of concept that’s doesn’t work in real life, but PoC is important to shows what will be a problem, sometimes PoCs is very applicable on real applications, sometimes not so easy to use.

Leave a Reply

Your email address will not be published. Required fields are marked *