On the SitePoint PHP blog they have a post that "reintroduces PDO" or as they describe it, the "right way to access databases in PHP". The PDO functionality in PHP provides extra handling around database connections and queries as well as making it easier to connect to multiple types of databases with similar code.

PDO is the acronym of PHP Data Objects. As the name implies, this extension gives you the ability to interact with your database through objects. [...] PHP is rapidly growing, and it is moving toward becoming a better programming language. Usually, when this happens in a dynamic language, the language increases its strictness in order to allow programmers to write enterprise applications with peace of mind.

In case of PHP, better PHP means object-oriented PHP. This means the more you get to use objects, the better you can test your code, write reusable components, and, usually, increase your salary. Using PDO is the first step in making the database layer of your application object-oriented and reusable.

He starts by answering the question most ask about PDO versus mysql/mysqli by pointing out that PDO is more OOP friendly, it allows for parameter binding and the fact that the mysql extension is no longer supported. He shows how to check and ensure PDO is installed on your setup and, if not, how to add it in (for both linux and Windows systems). The tutorial then walks you through using PDO: making the connections to the server, running queries and returning the results. This includes a section on prepared statements and bound parameters and their benefits including SQL injection prevention.

The Code Yellow site has recently posted an article pointing out an issue that's all too common in PHP frameworks, more specifically those that bundle some kind of ORM into their functionality. They wonder if your framework is telling you everything about what they're doing to prevent SQL injection.

We've discovered that SQL injection is to this day not a fully solved problem, even in most popular frameworks. In this post, we'll explain how these frameworks fail at escaping parts of a query, culminating in the discovery of a critical vulnerability in the popular Laravel framework which affects a large percentage of applications.

He starts with an illustration using the FuelPHP framework and the protection it offers from garden variety SQL injection attempts. Unfortunately, things start to break down when it gets much past this typical case. They found this same issue to be a wide-spread problem in many PHP frameworks and tools including the Laravel, CodeIgniter and CakePHP frameworks, each with their own ORMs. He also talks about issues with blacklisting and whitelisting and how, sadly, most of the frameworks just don't support it for model data filtering. There's a mention of some of the work they've done to help try and fix the issue (including patches and contacting authors) and some recommendations of how to correctly quote identifiers in SQL statements.

Anthony Ferrara has posted about the latest installation in his video tutorial series he's been producing on various programming topics. In this latest video he covers the use of prepared statements in your database interactions.

The fourth video in the Programming With Anthony series is live! In this video, we'll explore the basic principles of prepared statements, and why you should use them instead of using escaped input directly in queries.

You can watch this latest video over on YouTube. You can also check out the previous videos in the series while you're there covering paradigms, encryption and references.

From Greebo.net there's a recent post that looks at converting the current database functionality in your application over to the MySQLi functionality and making use of prepared statements as a later of protection for your queries.

Okay, you’ve got like a zillion SQL queries in your PHP app, and probably 95% of them have a WHERE clause, and you need to make them safe so people will still download and use your app. Because if you don’t fix your injection issues, I will rain fire on your ass. These are the steps you need to take to convert to prepared statements.

The guide is two steps you'll need to make the transition - "PHP 4 is dead. Upgrade to PHP 5" and "make sure your hoster has MySQLi". The major part of the update is under the first point where he gives code examples and suggestions to follow about how to "harden" your environment to prevent and issues that lax SQL methods might have caused and a simple example of a move from MySQL to MySQLi.

In this new post from Wez Furlong, he looks ar some of the things that the native MySQL client library does (the silly things) and recommends an alternative with the PDO libraries.

Among the things he mentions functionality (dealing with prepared statements) like "native prepared statements cannot take advantage of the query cache" and "native prepared statements cannot execute certain types of queries". The gives a simple line of code to make the database functionality (in PHP 5.1.3 and later) use the native PDO query parser to be loaded versus the one for the standard MySQL client libraries.

In this new post from Wez Furlong, he looks ar some of the things that the native MySQL client library does (the silly things) and recommends an alternative with the PDO libraries.

Among the things he mentions functionality (dealing with prepared statements) like "native prepared statements cannot take advantage of the query cache" and "native prepared statements cannot execute certain types of queries". The gives a simple line of code to make the database functionality (in PHP 5.1.3 and later) use the native PDO query parser to be loaded versus the one for the standard MySQL client libraries.

Ilia Alshanetsky also has hos own look today at the "mysql_real_escape_string versus addslashes" debate that's going on, looking more at why there's even an issue here (with addslashes).

Chris has written a compelling piece about how the use of addslashes() for string escaping in MySQL queries can lead to SQL injection through the abuse of multibyte character sets. In his example he relies on addslashes() to convert an invalid multibyte sequence into a valid one, which also has an embedded ' that is not escaped. And in an ironic twist, the function intended to protect against SQL injection is used to actually trigger it.

The problem demonstrated, actually goes a bit further, which even makes the prescribed escaping mechanism, mysql_real_escape_string() prone to the same kind of issues affecting addslashes().

He shows code examples, creating a simple SQL injection that uses mysql_real_escape_string to cause the same issue - all based around the default characterset that the MySQL server uses. His suggested solution? Prepared statements... (like what things such as PDO offer)

Ilia Alshanetsky also has hos own look today at the "mysql_real_escape_string versus addslashes" debate that's going on, looking more at why there's even an issue here (with addslashes).

Chris has written a compelling piece about how the use of addslashes() for string escaping in MySQL queries can lead to SQL injection through the abuse of multibyte character sets. In his example he relies on addslashes() to convert an invalid multibyte sequence into a valid one, which also has an embedded ' that is not escaped. And in an ironic twist, the function intended to protect against SQL injection is used to actually trigger it.

The problem demonstrated, actually goes a bit further, which even makes the prescribed escaping mechanism, mysql_real_escape_string() prone to the same kind of issues affecting addslashes().

He shows code examples, creating a simple SQL injection that uses mysql_real_escape_string to cause the same issue - all based around the default characterset that the MySQL server uses. His suggested solution? Prepared statements... (like what things such as PDO offer)