Discussion (and consensus): Database compatibility

registered · Posted: Tue Aug 29, 2006 1:00 pm

This is reposted from previous thread, but I want to provide its own discussion thread as well as voting. I hope this will start building on the changes from the Patched files, into a basis for RavenNuke and any other phpNuke distributions.

Should we try and escape data entering the database in its own native functions?
mysql_escape_string

If so, do we do it for all database layers? Or break the database compatibility by only going MySQL?

Or do we stick with the generic approach of addslashes (which is what phpBB does)?

I'm inclined to use addslashes only, just because it is convenient and seems to work fine, and it will not break database compatibility.

registered · Site Admin Joined: Jun 04, 2004 Posts: 6437

I agree, for the same reasons.

Posted: Wed Aug 30, 2006 2:50 am

I voted to drop support for anything other than mySQL.
I'm no expert but to my tiny brain I'm thinking that providing cross database layer compatibility would, somewhere down the line casue a conflict between 'doing what is right' for security reasons and 'doing what is convenient' to maintain the multiple database layer compatibility.

Why should we have to compromise if we don't have to?

registered · Posted: Wed Aug 30, 2006 9:07 am

I actually voted for the addslashes, although, I do so simply out of convenience and not eough time to try and figure out a better solution. I had read Chris Snyder's book on PHP Security and in his book he eludes to addslashes being inadequate. Then he goes and also says that mysql_escape_string, although better in his opinion, is still not "full proof", but then he does not give the reader anything else! I was so disappointed. He didn't even say WHY.

So, this led me to just take the "easy way out". However, what if we did a "hybrid"? Maybe mysql_escape_string is used in the mySQL abstraction layer, and then addslashes is still used in all the others. We just strip out of the PHP-Nuke code all of the current methods of using "addslashes" that is soley being used for preparing the sql string for DB access and then let the abstraction layer handle the "prep".

I'll save my lengthy analysis and discussion points for I think the other thread dealing more directly with "filtering".

Posted: Wed Aug 30, 2006 9:09 am

P.S. If we can do this, it also makes it really easy to change later if we find better ways to accomplish.

HOWEVER, just thought of a problem: what about all those add-on blocks, modules, etc. that are not written in the same manner?

Hhhhmmmm... we may have to replicate the whole db abstraction layer... again... to where we have the "new" and the "old" remains for compatibility. Oh, the quandry that a bad design throws us into...