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.

One novice mistake is to forget, or decide not to, close database connections. And another is to keep opening new database connections for every query.

A more seasoned approach to running queries is to open the door once, grab what you really need, and close it again as you leave. If you’re using those variables on another page then store them for ongoing use in a session, a cookie or pass them as a URL encoded string in name / value pairs.

So my small tip for the day is that if you’re going to run SQL queries in your PHP keep the process as simple and mechanical as possible. Open a connection, query the database, and close the connection on your way out.

So the first query just closes all comments and pings on every article. The second opens comments and pings on twenty articles – change the number on the end to suit your needs. So to close them:

update wp_posts set comment_status='closed', ping_status='closed' where comment_status='open' or ping_status='open'

and to reopen them:

update wp_posts set comment_status='open', ping_status='open' where comment_status='closed' or ping_status='closed' order by wp_posts.ID desc limit 20;