Question

I am switching to PDO from traditional mysql_query() parameterized queries to make use of it’s security advantages and I have a few questions. First off, does anything need to be done as far as magic_quotes? This web app will be installed on systems of different configurations and some will (unfortunately) have them on while others will be off. Previously I was doing the whole if statement to addslashes() when it’s off to input data… what needs to be done with PDO queries like these:

$dbh = new PDO("mysql:host=$db_server;dbname=$db_database", $db_username, $db_password);
$sth = $dbh->prepare("SELECT * FROM `users` WHERE `username` = :username ");
$sth->bindParam(':username', $_POST['username']);
$sth->execute();
if($row = $sth->fetch()){
    // Yup
}
$dbh = null;

Also, how necessary is it to close the database handler in the end? What is the detriment of not doing so? Is PDO a good option for a CMS that will be installed on many different server setups? Is PDO ubiquitous enough where it will be enabled on most servers?

Thanks in advance!

Answer 1

This web app will be installed on systems of different configurations and some will (unfortunately) have [magic quotes] on while others will be off.

As I noted in a comment on another answer, the PHP manual has an entire section on dealing with dealing with the horror that is magic quotes. You can usually either disable it locally in an .htaccess or correct the data as it comes in. I personally would not do business with a hosting provider that has it enabled by default.

Previously I was doing the whole if statement to addslashes() when it’s off to input data

Yikes! addslashes is not adequate protection. When using the old MySQL extension, you need to use mysql_real_escape_string after setting the character set. Failing to do this can leave you open to a huge vulnerability.

… what needs to be done with PDO queries like these:

Other than setting the connection character set, nothing! PDO will use real prepared statements when it can. This means that it will first send the query with placeholders to the server so it can process it, then it will later separately send the arguments over. This makes the query immune from SQL injection.

(Some databases don’t support prepared statements with PDO. For these, PDO will process the query, replacing the placeholders with quoted, escaped values. The result is the same — immunity from SQL injection.)

Also, how necessary is it to close the database handler in the end? What is the detriment of not doing so?

Just like the other PHP database handlers, there is no need to close the connection — when the script ends, the connection will close. (Don’t even think about persistent connections.)

Is PDO a good option for a CMS that will be installed on many different server setups? Is PDO ubiquitous enough where it will be enabled on most servers?

PDO became standard in PHP 5.1, but that doesn’t mean it’s always available. Most Linux distributions split out all of PHP’s database access options so that installing them also installs the mandatory libraries. Sometimes, incompetent or inexperienced hosting providers won’t install the PDO packages to go along with the other database access options, not realizing what they are doing. This is usually corrected by simply asking them to enable PDO, and switching to another host if they are unwilling or unable.

Many modern frameworks prefer building on top of PDO, but make other options available. For example, Zend Framework’s Zend_Db has adapters for PDO, mysqli, and a few others. If you fear PDO won’t always be available, using an adapter layer might work well for you. (Like most ZF components, Zend_Db doesn’t rely heavily on other ZF components, meaning you can easily bundle it with your code.)