PHP(已弃用)mysql模块与MySQLi和PDO的漏洞

Question

我负责维护和扩展从2007年开始并使用原始mysql模块的PHP代码库.所有的用户输入是用铸造为预计数值转义,mysql_real_escape_string()使用单引号的字符串,可能正在通过进一步过滤引述in_array()为ENUM字段或array_intersect()用于SET字段.然后,所有无约束的字符串字段都会通过输出HTML htmlspecialchars()或htmlentities()输出HTML.如果值表示外键,则首先验证该键是否存在.
我相信通过严格遵循这些程序,该应用程序可以防止注入和其他形式的攻击.(奖励积分:我是否正确？如果没有,我错过了什么？)

将此应用程序转换为mysqliPDO将是一项相当大的任务(并且,为避免意外破坏,我不希望自动化).最后我的问题是:在使用旧mysql模块时是否存在无法缓解的特定漏洞,这需要迁移到较新的模块？

赏金信息:
为了清楚起见,我希望有一个CVE编号列表或来自PHP开发人员的声明,该mysql模块将针对所有已知漏洞进行补丁.我也假设在使用模块后遵循最佳实践并不会让我接触到额外的攻击向量.BCP在将数据插入新语句之前已经包含从数据库中获取的数据.继续谈论这个并没有真正解决这个问题.

Answer 1

我有两个异议

• All user input is escaped是一个严重的错误,导致二阶注入."SQL的所有动态数据"都是正确的方法和措辞
• 您的帖子中没有提到标识符,但我不相信自2007年以来您的代码中没有动态标识符查询.

还有一个小小的不便:在几年内(可能3-4个),您的PHP将开始发出E_DEPRECATED级错误.但他们可以简单地关闭.

无论如何,从一个API到另一个API的机械移动不会太有意义.
重构您的SQL处理代码只是为了利用一些抽象机制,无论是ORM,AR,QueryBuilder还是其他任何可以从应用程序代码中擦除原始API调用的技术.它不仅会使您的代码变得不那么臃肿,而且还会使它独立于将来打击PHP开发人员的任何其他想法.

回答编辑过的问题.

旧的mysql ext中没有必要的漏洞.它常用的唯一方法是易受攻击且容易出错.
因此,不要在模块上寻找压力,而是更好地审核您的代码.如果它没有使用集中式库来使用预准备语句进行数据库交互,那么很可能它很容易受到攻击.