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.
No comments:
Post a Comment