The first take-away from Christian Heilmann’s article on Smashing Magazine titled Web Security: Are You Part of the Problem? is that you need to make sure at least one member of your team is up to speed. Everybody else needs to appreciate the importance of what that person tells them.

The second take-away is that no matter how much the world looks like a rosy cake of graphic design skills in our industry, it isn’t. Its in the marrying of good interface design, graphic design, business acumen and coding skills that make a good website. Unfortunately we’re in a world that tends to judge almost entirely on the superficial 6 seconds after the user arrives on a website – how does it look trumps is it secure? In other words, there is always pressure to make things look good but nobody pressures about writing better code until after you’re butt-shovelled by a Russian spamster or three.

And the third take-away from Christian in this article is to trust nothing – all data needs sanitising before you use it – and that URIs should be treated with similar mistrust. This is where the crappy web person is vastly different from the great web person if you’re out there hiring, employing or getting hold of a freelancer… the crappy person being the one who comes out with phrases like but it works, doesn’t it? How often have you heard that smidgen of cop-out?

Seriously, when it comes to your business and the web professional then you need to know up front before everybody’s credit card information is compromised that the web solution more than works, it works effectively. Securely.

The following YouTube video (3 minutes) shows a straight forward MySQL injection. It should give you the idea. A read of Wikipedia’s SQL injection resource and Steve Friedl’s tips on SQL injection attacks (particularly in Mitigations towards the bottom of the page) should take you a little further. It’s amazing how many web developers remain unaware of the problem – and I freely admit it only became something on my radar about 4 years ago when a client’s guestbook was hacked this way by script kiddies in the United States. Lesson two was to always keep open source software up-to-date.

The short answer for protecting yourself from this type of user manipulation of your database can involve a few reasonably simple steps. As a first measure, you might want to use regular expressions in your programming to ensure what you receive from the user is valid input. I do admit regular expressions might be a bit hardcore for some, but there are plenty of freely available snippets out there now you know what to look for.

You also need to use functions to addslashes and stripslashes when you’re putting user generated data in and out of your database. You addslashes before you put user generated data into the database, and stripslashes when it comes back out. Although you might be better just using the newer mysql_real_escape_string function, which I’m led to believe is a little more efficient. I should point out that adding and stripping slashes alone won’t protect you, nor will simply using regular expressions. You should use both strategies together.

I’d say those two measures are the hard and fast must-haves if you’re going to keep your database safe from this type of attack. But you can go a little further given a hardcore attitude and a wanton need to stop up even more holes in your defences.

Your queries might be run with only the necessary privileges from an account that does not have permissions to add new users, delete tables or do other significant modifications. This makes a lot of sense. Also, you might consider keeping your username and password in Apache rather than within your PHP code (although I don’t have a link to that one off-hand). Another thing to consider is error suppression in PHP – the last thing you want is for a hacker to generate an error that prints out on his screen explaining exactly what tripped up your defenses. Basically, never trust any input. The PHP Manual also has a good page in there on SQL injection.

Once you’re aware of this vulnerability you tend to just code a little differently and it stops being a real issue. This mostly happens when programmers are either unaware or apathetic about basic secure programming practices. I hope this has been of some help.

// to open the database
function connectToDatabase ()	{
$link = mysql_connect("localhost", "database_name", »
                                  "database_password");
    if ($link && mysql_select_db("database_name"));
        return ($link);
	    return (FALSE);
}

// to close the database
function db_close($connecter)  {
    mysql_close($connecter);
}

It’s a good idea to keep these database connection functions in one place and then reuse them as you need, rather than repeating them everywhere.

Maintainability of your code is important even on smaller websites, if you only need to change a password in one place you’ll find life a lot easier. This code is very close to that found in PHP docs for mysql_connect, by the way. The connectToDatabase function returns a link identifier on success or FALSE on failure.

Further information in the mysql_connect documentation should take you an extra step as well.

So, in your PHP code where you want to run your SQL query all you need to do is something like the following snippet:

// connect to the database
include("down/in_some/folder/db_function_file.php");
$link = connectToDatabase();
    if(!link) {
        print "<p>database connection error</p>";
        mysql_close($link);
	exit();
}

Now run your query and put the values into variables, then explicitly close the link, and you’re done. Hopefully this snippet of advice might be useful.

echo "<p>Your $variable1; makes me want to go straight home</p>";

You should be able to see that varying amounts of complex XHTML, including backslashes throughout all the extra syntax of XHTML attributes, is going to rapidly become harder to maintain. Instead what you should be doing is closing your PHP block at an appropriate point and then outputting XHTML as it’s born and raised. If you’ve got a variable to output just insert a PHP block in there to call the variable:

<p>Your <?php echo $variable1; ?> makes me want to go home.</p>

The main reason for doing this is because the XHTML rapidly becomes unmaintainable if you’ve got to deal with all of the extra syntactic debugging involved with PHP. So, don’t go there. Continually outputting XHTML as PHP echo statements is something I’d consider a novice’s habit, and one that should be cast aside at the earliest point.

A small tip but hopefully one that might save a little grief for someone, somewhere. In short, place PHP variables into XHTML and not the other way around.