Vulnerabilities of PHP's (deprecated) mysql module vs. MySQLi & PDOs

Question

I am in charge of maintaining and extending a PHP codebase which began in 2007 and uses the original mysql module. All user input is escaped using casting for values expected to be numerical, mysql_real_escape_string() quoted using single quotes for strings, possibly being further filtered through in_array() for ENUM fields or array_intersect() for SET fields. All unconstrained string fields are then passed through either htmlspecialchars() or htmlentities() when outputting HTML. Where a value represents a foreign key, that key is verified extant first.
I believe that by following these procedures rigorously, the app is as safe as it can be against injection and other forms of attack. (bonus points: am I correct? If not, what am I missing?)

Converting this app to mysqli or PDOs would be a fairly large task (and, to avoid accidental breakage, not something I would want to automate). So finally to my question: Are there any specific vulnerabilities that cannot be mitigated when using the old mysql module, which require migration to the newer modules?

Bounty Info:
To be clear, I am hoping for a list of CVE numbers or a statement from the PHP developers that the mysql module is patched against all known vulnerabilities as of such-and-such a date. I am also assuming that following Best Current Practices in using the module does not expose me to additional attack vectors. BCPs already include escaping data taken from the db before inserting it into a new statement. Going on and on about that isn't really addressing the question.

Answer 1

I have but 2 objections

• All user input is escaped is a critical fault, leading to second order injection. "All dynamical data for SQL" is the right approach and phrasing
• there are no identifiers mentioned in your post but I can't believe you don't have a query with dynamical identifier in your code since 2007.

There is also a minor inconvenience: in a couple of years (3-4 probably), your PHP will start issuing E_DEPRECATED level errors. But they can be simply turned off.

Anyway, just a mechanical move from one API to another won't make too much sense.
Refactor your SQL handling code only to make use of some abstraction mechanism, be it ORM, AR, QueryBuilder or whatever else technology which will wipe raw API calls from the application code. It will not only make your code less bloated, but also will make it independent from whatever else whim that will strike PHP developers in the future.

To answer the edited question.

There are no essential vulnerabilities in the old mysql ext. The only way it is commonly used is vulnerable and error-prone.
So, instead of looking for strains on the module, better audit your code. If it is not using a centralized library for database interaction utilizing prepared statements, most likely it is vulnerable.

Answer 2

My answer will be somewhat off, and instead of answering your specific questions, I would rather suggest the approach that will actually help you out.

No matter what vulnerabilities could be left or could arise in the future using mysql, and no matter how solid your current codebase approaches (rather avoids for) SQLinjection (it seems to do so pretty well, though), I get the feeling you still would rather migrate to mysqli anyhow but aim for delaying in doing so by seeing short term possibilities to further hack your way around the unsafe and to-be-fully-deprecated mysql.

I would suggest refactoring. Period. Just do that. Keep in mind to refactor, and not to change or extend your codebase while doing so - it's a nasty pitfall. Eventhough it'll be some work - the refactoring, just start your refactoring process (branched of course). It will be very satisfactory on completing it. Expect some long tail issues.

I assume every functionality you describe is wrapped already, so refactoring should be fairly doable. If things had not been wrapped.. ($#@!), figure out a way to uniquely track your function calls (including context) project-wide, (possibly using regular expressions in finding them all) and replace with new unique to-be-used wrapper functions. First explore this, thoroughly. In half a day you would be able to enlist all your regular expression that you will need. So plan it first, by exploring your path first.

Fill the new wrappers with the current (old) functional code and see if all still works as was.

Then start migrating to mysqli, and rebuild your wrappers internally.

Seems to be a simple as possible approach, avoiding all the matters and questions that will stay in the back of your mind despite whatever you try do in hacking your way deeper around common mysql. I don't need to tell you about the benefits mysqli will bring, you know those already. Futhermore, it simply is good practice to every once in while actually undertake those kind of issues for once and for all. Plan, discuss, branch, try, do, test, complete, and conquer! On top off all: make sure you don't fall for the opportunities to extend your codebase and functional scope while refactoring - you will be tempted to do so: just refactor. Add, extend, or improve later.