In any case I’ll shut my big mouth and let you get on with it…

Having created a somewhat different database class, I’ve been quite interested in what you’ve been doing with these articles as you’ve approached the problem from a completely different angle. Thanks to your excellent articles, I’m probably going to adapt some of my methods!

My own database class only deals with the execution of a query, dealing with errors and returning relevant information to the executed query.

There is no validation on the SQL before it is run simply because most of the time the SQL is created within another function or object. The only way that the SQL could therefore be broken, hacked or injected then is via the user input (whether that be POST, GET, SESSION, file input etc).

In my humble opinion validation routines should be run on inputted data before ANYTHING else is done with it. For this reason I have several specific filtering and validation routines to be run on ALL input variables as soon as they are called into use. This basically adds security to your PHP no matter what you’re doing - regardless of using the data for SQL generation, file manipulation, SESSION creation etc.

I guess basically what I’m saying is that making sure that user-inputted data is secure should always occur well before even considering using it in a query.

However, I also see that SPECIFIC validation for SQL operations could be handled by the database class (as you have here).

It’s down to whether you have a seperate validation and data security class or whether each of your classes has it’s own validation and data security functions built in.

Tim - I could easily see this function being in my form validation class. Right now, it is in my database class because it is called from sqlInsert() and sqlUpdate() as the query is being built. Out of curiosity, what are your reasons for keeping this type of operation away from a database class.

Jonathan - Once I change the way connections are handled with the class, this function will not be opening a new connection or adding any overhead. But I do agree with you still, and I should just go ahead and escape them myself.

SQL injection is an easily solved problem in practically every other language with a DB library - PHP’s addslashes() and building SQL queries by gluing strings together is an unfortunate exception. Consider this example from Python:

cursor.execute(""" UPDATE animal SET name = %s WHERE name = %s """, (new_name, cur_name))

The DB API handles all escaping for you, adding quotes around strings and escaping nasty characters as necessary. It looks like SafeSQL takes the same approach. In fact, so does PEAR.

And why should your database class have to worry about injection? Surely you’d be better off trapping this with your form data filtering and validation routines so that your database class never HAS to deal with this kind of hacking…