Protecting Your Data from an SQL Injection Attack

Introduction

Generally speaking, SQL injection is an attack on a website via a database attached to the site. This database might contain site content or it might contain user login and password information. A successful attack would allow the attacker complete access to the database, able to add, change, delete, and download the database content.

So how does the attack work? It works by using quote characters to end an input string prematurely, and then adding SQL statements to the input.

xkcd #327 “Exploits of a Mom” has an example of an SQL injection attack with a child named “Robert’); DROP TABLE Students; –”. The “’);” after “Robert” is a typical end to the SQL insert statement. It is followed by another SQL statement “DROP TABLE Students;” And the final “–” starts an SQL comment, thus guaranteeing that whatever the original statement was, the rest of it would be commented out.

In more detail: presumably the school has a database with a table called Students. In the normal course of things, someone would enter “Robert” into the first_name field, and Robert’s last name (let’s say it’s “Smith”) into the last_name field, and so on. The SQL statement that would be sent to the database would look like this:

INSERT INTO Students (first_name, last_name) VALUES (‘Robert’, ‘Smith’);

And one row would be inserted into the Students table. However, if instead of “Robert”, someone entered “Robert’); DROP TABLE Students; –” into the first_name field, then the following would be sent to the database:

INSERT INTO Students (first_name, last_name) VALUES (‘Robert’); DROP TABLE Students; --’, ‘Smith’);

One row would be inserted into the Students table (though last_name would be blank), and then the table Students would be deleted from the database. The last bit –’, ‘Smith’); would be interpreted as a comment and so ignored. See SQL Injection Attacks by Example for a more detailed examination of how this attack works.

The database is vulnerable anytime a user interacts with it. However, there are ways to defend against such an attack. I will discuss three of these ways:

  1. sanitize inputs
  2. use parameterized queries
  3. restrict permissions

None of these strategies is a guaranteed, will-stop-100%-of-attacks method. However, each can help lower the likelihood of a successful attack. So, these different defense strategies are not mutually exclusive, and it is best, whenever possible, to use all three.

Sanitize Inputs

The punchline of the xkcd comic has the mother saying “I hope you’ve learned to sanitize your database inputs.” One common way of sanitizing input is to escape the characters by adding another quote mark or a backslash to any quotes in the input. If the hapless school had escaped the input, then this is what would have resulted:

INSERT INTO Students (first_name, last_name) VALUES (‘Robert\’); DROP TABLE Students; --’, ‘Smith’);

The student would have a first name of “Robert’); DROP TABLE Students; –” and a last name of “Smith” and no tables would have been deleted. By escaping the single-quote with a backslash, the database interpreted it as part of the input. Characters that ought to be routinely escaped are: single quotes, double quotes, backslashes, and the NUL character. Control characters like CTRL-Z also ought to be escaped as they, too, can interfere with the interpretation of input strings.

Since this blog deals primarily with PHP, I will discuss several PHP functions that can assist.

  1. addslashes(): This function adds a backslash to single quotes, double quotes, backslashes, and NUL automatically.
  2. mysql_real_escape_string(): This is a MySQL-specific PHP function that escapes nulls, newlines, carriage returns, substitute characters, double quotes, single quotes, and backslashes. The  mysql_escape_string() function is deprecated, and should not be used, as it disregards the character set the string is in. The mysqli (mysql-improved) equivalent of mysql_real_escape_string() is mysqli::real_escape_string().

The following commands help to keep any html tags from getting into the database. Thus, if you end up displaying this data, it won’t change the html markup or add a javascript function to your page. This also helps to prevent someone from inserting a malicious script into your database.

  1. htmlspecialchars(): transforms ampersands, double quotes, less than and greater than into html entities. If the ENT_QUOTES flag is set, it also transforms single quotes. The htmlentities() function does the same thing, also encoding most Latin-1 non-ascii characters.
  2. str_replace(): can be used to replace any characters, like so:
    $string = "{user_input}";
    $bad = array('&', '"', "'", '<', '>', '\\', '%', '_');
    $good = array('&amp;', '&quot;', '&#039;', '&lt;', '&gt;', '&#092;', '&#037;', '&#095;');
    $sanitized = str_replace($bad, $good, $string);

    The backslash in $bad needs to be escaped in order to be recognized as a regular character.
  3. strip_tags() can be useful, too, as it strips the input of any html and php tags that are found.

Use parameterized queries

Parameterized queries are fun, convenient, faster, and much, much safer than merely escaping a string. Parameterized queries take an SQL statement like INSERT INTO Students (first_name, last_name) VALUES (?, ?); and then bind or assign the inputted values into the query, in essence escaping it for you. This is preferable to escaping the string yourself because it is less error-prone and you can’t forget to do it.

The mysql extension for PHP does not support parameterized queries. However, the mysqli (the ‘i’ stands for “improved”) extension (recommended for MySQL v4.1.3 and later) and the PDO extension do support parameterized queries. If you are not sure which to use, see this overview. I am partial to PDO, but mysqli is a good extension as well. I will write a future post on migrating your PHP code from mysql to mysqli.

Restrict permissions

If you are using your database to provide site content only (that is, you have no registered users), then it is a fairly simple thing to make your database read-only. That is, create a user for your database that has select permissions only and cannot insert, update, or delete any content. Use this account to connect the website with the database. That way anyone who manages to get around the escaped string in a parameterized query method cannot add, change, or delete your data through the website, accidentally or otherwise.

Of course, this is more complicated if you do have registered users. Make sure that any statements that deal with input from a user that is not logged in use a restricted, select-only account. Also, if you have your own administrative interface (a form where you enter stuff into your database rather than using phpMyAdmin or some other application), that page will need to access the database using a different account.

1 thought on “Protecting Your Data from an SQL Injection Attack”

  1. This is a very clear description of SQL injection. Very helpful in assessing how well protected some of our externally-written apps are. Thanks for writing this!

Comments are closed.