我负责维护和扩展一个从2007开始的
PHP代码库,并使用原来的MysqL模块.所有用户输入都使用cast来转义,预期值为数字,MysqL_real_escape_string()使用单引号引用字符串,可能会通过INUM的字段或set_intersect()的in_array()进一步过滤SET字段.然后,当输出HTML时,所有无约束的字符串字段都将通过htmlspecialchars()或htmlentities()传递.值表示外键的情况下,该密钥首先被验证.
我相信,严格遵守这些程序,应用程序是安全的,因为它可以防止注射和其他形式的攻击. (奖励积分：我是正确的吗？如果没有,我还缺少什么？)
我相信,严格遵守这些程序,应用程序是安全的,因为它可以防止注射和其他形式的攻击. (奖励积分：我是正确的吗？如果没有,我还缺少什么？)
将此应用程序转换为MysqLi或PDO将是一项相当大的任务(并且为了避免意外破坏,而不是我想要自动化).所以最后我的问题：在使用旧的MysqL模块,哪些需要迁移到较新的模块时,是否有任何特定的漏洞无法缓解？
赏金信息：
要清楚,我希望列出一个CVE号码或PHP开发人员的声明,即MysqL模块针对所有已知的漏洞进行修补,因为这样的日期.我也假设在使用该模块时遵循最佳当前做法不会让我感到额外的攻击向量. BCP已经包含从db中取出的数据,然后将其插入新的语句.关于这一点,并没有真正解决这个问题.
我只有2个反对意见
>所有用户输入都是转义是一个严重的错误,导致second order injection.“sql的所有动态数据”是正确的方法和措辞
>你的帖子中没有提到identifiers,但我不敢相信自2007年以来,您的代码中没有查询动态标识符.
还有一个轻微的不便：在几年(3-4可能),您的PHP将开始发出E_DEPRECATED级错误.但他们可以简单地关闭.
无论如何,只是从一个API到另一个API的机械移动将不会有太大的意义.
重构您的sql处理代码只是为了利用一些抽象机制,无论是ORM,AR,QueryBuilder还是从应用程序代码中擦除原始API调用的其他技术.它不仅会使您的代码不那么blo肿,而且还将使其独立于将来会对PHP开发人员造成的任何其他错误.
回答编辑过的问题.
旧的MysqL ext中没有必要的漏洞.常用的唯一方法是易受攻击和容易出错.所以,不要在模块上寻找应变,更好地审核你的代码.如果没有使用集中式的库来进行数据库交互,那么很可能它是易受攻击的.
