In a recent post to his blog, Gonzalo Ayuso shares a few tips on preventing SQL injection attacks on your applications.

Security is a part of our work as developers. We need to ensure our applications against malicious attacks. SQL Injection is one of the most common possible attacks. Basically SQL Injection is one kind of attack that happens when someone injects SQL statements in our application. You can find a lot of info about SQL Injection attack. Basically you need to follow the security golden rule: "Filter input, Escape output".

He advocates the use of the PDO abstraction layer to filter out a lot of the issues. Using its prepared statements, you can easily strip out things that just adding slashes to user input wouldn't prevent. He also includes a reminder about database permissions - allowing only certain users the ability to, for example, delete can help provide one more level of security (in other words, don't use a "super user" in production).

On PHPMaster.com today there's a new post from Alejandro Gervasio about a part of the SOLID development methods - the Liskov Substitution Principle - the idea that objects should be replaceable with instances of their subtypes without a change to the architecture of the application.

Even when the formal definition of the LSP makes eyes roll back (including mine), at its core it boils down to avoiding brittlely-defined class hierarchies where the descendants expose a behavior radically different from the base abstractions consuming the same contract.

He includes an example with a "deleted scene" from the Matrix depicting an attempted override of the PDO functionality with a subclass that, unfortunately, does not match the original's structure/method definitions. The problem was in the difference between the method signature for the "query" method. It help resolve situations like this he recommends creating a "contract" in the form of an interface your code can implement, forcing it to conform to a certain structure. Using this, he provides a rewrite of the "PdoAdapter" class to match the original signature

Ariz Jacinto has written up a new post with the commands you'll need to get PHP up and runnign with MSSQL Server's native ODBC driver working on linux (accessible through PDO).

Last month, MS announced the preview release of SQL Server ODBC Driver for Linux, a 64-bit binary driver for Red Hat Enterprise Linux 5. This is good news for companies using heterogenous platforms e.g. LAMP stack running a PHP application that connects to both MySQL and MSSQL Server. Meaning, these companies no longer have to use third-party drivers such as FreeTDS that MS doesn't support. Then a few days ago, MS released version 1 of the driver. I immediately downloaded the driver and recompiled PHP with it as a PDO (PHP Data Object) ODBC driver.

His process has five steps to it, including one for making a test script (code included) and another with a few gotchas/performance considerations to keep an eye out for when using the driver.

On PHPMaster.com today there's a new post showing you how to write custom session handlers - in their case, a database-based option that can span across multiple servers/services.

Sessions are a tool which helps the web programmer overcome the stateless nature of the internet. You can use them to build shopping carts, monitor visits to a website, and even track how a user navigates through your application. PHP's default session handling behavior can provide all you need in most cases, but there may be times when you want to expand the functionality and store session data differently. This article will show you how the default functionality works and then goes on to show you how override it to provide a custom solution.

They introduce how sessions are stored normally (based on the save path) and what the serialized contents of it would look like. They show you how to take this, normally stored on the local file system, and change it to be written to a "session" table in a MySQL database (via PDO). It includes reading, writing, updating and some garbage collection to clean out old values from the table.

Lorna Mitchell has a quick new post showing one way to handle SQL errors in PDO that could pop up because of badly written/generated SQL statements.

I love PHP's PDO (PHP Data Objects) extension; it gives a consistent, object-oriented interface to handling all kinds of relational database backends. One thing that annoys me is that the MySQL driver for PDO defaults to a silent error mode which can make SQL errors tricky to spot!

In her two code snippets she shows a failing PDO request (that fails silently) and a method for catching this issue - checking the result of the "errorCode" method to see if it equals "0" (zero). If there were errors, you can use the "errorInfo" function to get to them. This will return the SQL error code, the driver-specific error code and a driver-specific error message.

On DZone.com today there's a new post from Krzysztof Kotowicz sharing a presentation of his about protecting your application from SQL injection.

The materials teach how to use prepared statements, how to escape and write secure stored procedures. Many PHP projects are covered - PDO, Propel, Doctrine, Zend Framework and MDB2. Multiple gotchas and caveats are included. I discuss why escaping is usually the wrong choice, which practices to avoid or follow and how stored procedures sometimes offer no protection at all.

The presentation (as posted to Slideshare) starts with some of the basics - what SQL injection is and an example of how it could be used to bypass security. He covers how to use prepared statements in each of the technologies (with code snippets), methods for escaping data and how to create stored procedures that are protected from the same threats.

In a new post to his blog Martin Psinas talks about some of his pains experienced with upgrading his code to use PDO instead of the mysql extension for database interaction.

I read not too long ago that the mysql library in PHP is being deprecated as of v6.0 in favor of mysqli or PDO, so of course I had to update all of my database code keep on top of things. I spent about 5 or 6 hours over the course of 2 days familiarizing myself with the new syntax and updating my code offline. Without any testing, I decided I could go ahead and push the code "live" because I'm just that over-confident sometimes, although I did make a backup in case anything went wrong (or so I thought).

Two problems jumped out immediately - a SQL error caused by this bug and the other being a problem with preparing his statement inside of a session handling method.

In a new post on his blog Timothy Boronczyk has a recommendation for developers working in PHP with databases that have a "fetch object" method - use it correctly or avoid it all together.

Lately I'm finding a lot of instances of the mysql_fetch_object() function being used in a particular codebase I help maintain. Unfortunately, I've yet to see it used correctly. It always seems to be used to retrieve a stdClass object from a query result where mysql_fetch_array() or mysql_fetch_assoc() would be the more appropriate choice.

Most of his complaint is that, despite pulling out the data as an object, most scripts continue to use it like you would an array, looping over it. There's extra overhead generated from the object creation that could cause issues, especially with large return data sets.

The best advice I can offer is to educate yourself and others how the function should be used so its abuse isn't perpetuated. Then, be cautious when using mysql_fetch_object() correctly and understand the process it follows to create and return an object. If not for yourself, then do it for the kittens.

In this new post to his blog, Gonzalo Ayuso compares two technologies that can make working with databases in your applications simpler - PDO and the Doctrine2 DBAL layer.

In fact DBAL isn't a pure database abstraction layer. It's built over PDO. It's a set of PHP classes we can use that gives us features not available with 'pure' PDO. If we use Doctrine2 we're using DBAL behind the scene, but we don't need to use Doctrine2 to use DBAL. We can use DBAL as a database abstraction layer without any ORM. Obiously this extra PHP layer over our PDO extension needs to pay a fee. I will have a look to this fee in this post.

He includes a few simple benchmarking scripts that compare similar operations done by either, including memory usage and execution time. PDO comes out on top, obviously, because it's an extension versus a set of PHP libraries that need to be included in the application. He does include examples of a few things he likes that DBAL does that PDO doesn't by default - a transactional mode, type conversion, a simpler binding interface and the ability to nest transactions.

Shay Ben Moshe has a new post to his blog today looking at some of the benefits that using the persistent connections offered in PDO can have on your application.

PDO is an abstraction layer for database connections in PHP, and it became increasingly popular in the past few years. PDO gives us the option to use a persistent connection. If we don't use this option, a new connection is created for each request. If we do use this option, the connection is not closed at the end of the script, and it is then re-used by other script requests.

He shares the setup for his testing (hardware and MySQL configuration) and some of the results from his tests using the Apache ab tool for making web requests against an application. You'll need to download the archived file to see the results, though. It also includes the files he used to test with, comparing regular connections to the persistent ones.