在没有参数化查询的情况下防止 SQL 注入 PHP？
Preventing SQL Injection in PHP without parameterized queries?
我知道这个话题已经被讨论到死，但我希望社区能提供一些关于我们 Web 应用程序安全性的反馈。
我们有标准的 LAMP 堆栈网络应用程序，其中包含大量使用 mysqli_query 执行的数据库查询。这些查询目前没有参数化，但是使用 addslashes.
对输入进行了一些简单的转义
我的任务是让这个系统更安全，因为我们很快就会进行渗透测试。上面的权力知道参数化查询是使系统更安全的方法，但是他们不想投入时间和精力来重写应用程序中的所有查询，也不想改变我们必须使它们全部实现的框架正常工作。
所以基本上我是在问我的选择是什么？
我已经 运行 mysqli_real_escape_string 完成了输入。我已经设置了一个过滤器，它不允许像 SELECT、WHERE、UNION 这样的词被传递，我想这样会更安全。我知道 mysqli_query 一次只允许一个查询 运行 所以那里有一些安全性（从连接更新到选择的末尾）。
这里还有其他选择吗？
编辑：我可能应该补充一点，如果有人能够提供一个攻击示例，该攻击在没有参数化查询的情况下是完全不可避免的，这也会有所帮助。我们有一个如下所示的查询：
SELECT
pl.created
p.LoginName,
pl.username_entered,
pl.ip_address
FROM loginattempts pl
LEFT JOIN people p ON p.PersonnelId = pl.personnel_id
WHERE p.personnelid = $id
AND pl.created > $date1
AND pl.created < $date2
我已经将 UNION 查询替换为 $id UNION SELECT * FROM p WHERE 1 = 1 之类的东西，我可以通过不允许 SELECT/UNION 来防止这种情况，但我确信还有无数其他类型的攻击我想不出来。谁能再推荐几个？
更新
我已经说服了高于我的权力，我们需要将查询重写为参数化语句。他们估计这可能需要几个月的时间，但必须完成。赢。我觉得？
更新2
不幸的是，我无法说服我们需要将所有查询重写为参数化查询的权力。
我们提出的策略是按如下方式测试每个输入：
如果用户提供了输入 is_int 则将其转换为原样。
实数也一样。
运行 mysqli_real_escape_string 字符数据。
将查询中的所有参数更改为带引号的字符串，即
WHERE staffName = ' . $blah . '
根据 this 的回答，我们是 100% 安全的，因为我们不会在任何时候更改字符集，并且我们始终使用 PHP5.5 和 latin1 字符集。
更新 3
此问题已被标记为重复，但在我看来，该问题仍未得到解答。根据第 2 次更新，我们发现一些强烈的意见认为 mysqli_real_escape 字符串函数可以防止攻击并且显然是“100% 安全的”。此后没有提供好的反驳论据（即正确使用时可以打败它的攻击演示）。
Do I have any other options here?
没有。没有任何外部措施（如您尝试实施的措施）被证明有任何帮助。您的网站仍然存在漏洞。
I've run mysqli_real_escape_string over the inputs
恭喜，您刚刚重新发明了臭名昭著的 magic_quotes 功能，该功能被证明是无用的，现在已从语言中删除。
仅供参考，mysqli_real_escape_string 与 SQL 注入完全无关。
此外，将其与现有的 addslashes() 调用结合使用，您会破坏数据，因为其中的斜线数量加倍。
I've setup a filter which I guess makes it safer.
不是。 SQL 注入不是加几个字
此外，这种方法被称为“黑名单”，事实证明它本质上是不可靠的。黑名单本质上是不完整的，无论你能得到多少“建议”。
I know mysqli_query only allows one query to be run at once so there's some security there
没有。 SQL 注入不是要添加另一个查询。
为什么我将这个问题作为“如何防止 PHP 中的 SQL 注入？”的重复问题关闭？
因为这些问题是互斥的，不能共存于同一个站点。
如果我们同意，唯一正确的答案是使用准备好的语句，那么问“我如何保护不使用准备好的语句”的问题就没有意义了。
与此同时，如果 OP 设法强迫我们给出他们迫切想要的肯定答案，这将使另一个问题过时。如果没有它们一切都很好，为什么还要使用准备好的语句？
此外，这个特定问题也太局限了。它寻求的不是洞察力，而是 借口。除了 OP 个人之外，没有人的借口。一个让他们使用被证明是不安全的方法的借口。虽然这取决于他们，但这使得这个问题对社区基本上没有用。
- 检查每个用户输入的数据类型以及适用于正则表达式的位置（黄金法则是：永远不要相信用户输入）
- 使用准备好的语句
- 说真的：准备好的陈述:)
工作量很大，尤其是当您的应用程序状况不佳时（就像您的情况一样），但这是获得良好安全级别的最佳方式
另一种方法（我建议反对）可以是使用 mod_security 或 WAF 来过滤掉注入尝试的虚拟补丁，但首要的是：尝试编写健壮的应用程序
（虚拟补丁似乎是一种懒惰的修复方法，但实际上也需要大量的工作和测试，并且应该只在已经很强大的应用程序代码之上使用）
我知道这个话题已经被讨论到死，但我希望社区能提供一些关于我们 Web 应用程序安全性的反馈。
我们有标准的 LAMP 堆栈网络应用程序，其中包含大量使用 mysqli_query 执行的数据库查询。这些查询目前没有参数化，但是使用 addslashes.
我的任务是让这个系统更安全，因为我们很快就会进行渗透测试。上面的权力知道参数化查询是使系统更安全的方法，但是他们不想投入时间和精力来重写应用程序中的所有查询，也不想改变我们必须使它们全部实现的框架正常工作。
所以基本上我是在问我的选择是什么？
我已经 运行 mysqli_real_escape_string 完成了输入。我已经设置了一个过滤器，它不允许像 SELECT、WHERE、UNION 这样的词被传递，我想这样会更安全。我知道 mysqli_query 一次只允许一个查询 运行 所以那里有一些安全性（从连接更新到选择的末尾）。
这里还有其他选择吗？
编辑：我可能应该补充一点，如果有人能够提供一个攻击示例，该攻击在没有参数化查询的情况下是完全不可避免的，这也会有所帮助。我们有一个如下所示的查询：
SELECT
pl.created
p.LoginName,
pl.username_entered,
pl.ip_address
FROM loginattempts pl
LEFT JOIN people p ON p.PersonnelId = pl.personnel_id
WHERE p.personnelid = $id
AND pl.created > $date1
AND pl.created < $date2
我已经将 UNION 查询替换为 $id UNION SELECT * FROM p WHERE 1 = 1 之类的东西，我可以通过不允许 SELECT/UNION 来防止这种情况，但我确信还有无数其他类型的攻击我想不出来。谁能再推荐几个？
更新
我已经说服了高于我的权力，我们需要将查询重写为参数化语句。他们估计这可能需要几个月的时间，但必须完成。赢。我觉得？
更新2
不幸的是，我无法说服我们需要将所有查询重写为参数化查询的权力。 我们提出的策略是按如下方式测试每个输入：
如果用户提供了输入 is_int 则将其转换为原样。 实数也一样。 运行 mysqli_real_escape_string 字符数据。 将查询中的所有参数更改为带引号的字符串，即
WHERE staffName = ' . $blah . '
根据 this 的回答，我们是 100% 安全的，因为我们不会在任何时候更改字符集，并且我们始终使用 PHP5.5 和 latin1 字符集。
更新 3
此问题已被标记为重复，但在我看来，该问题仍未得到解答。根据第 2 次更新，我们发现一些强烈的意见认为 mysqli_real_escape 字符串函数可以防止攻击并且显然是“100% 安全的”。此后没有提供好的反驳论据（即正确使用时可以打败它的攻击演示）。
Do I have any other options here?
没有。没有任何外部措施（如您尝试实施的措施）被证明有任何帮助。您的网站仍然存在漏洞。
I've run mysqli_real_escape_string over the inputs
恭喜，您刚刚重新发明了臭名昭著的 magic_quotes 功能，该功能被证明是无用的，现在已从语言中删除。
仅供参考，mysqli_real_escape_string 与 SQL 注入完全无关。
此外，将其与现有的 addslashes() 调用结合使用，您会破坏数据，因为其中的斜线数量加倍。
I've setup a filter which I guess makes it safer.
不是。 SQL 注入不是加几个字
此外，这种方法被称为“黑名单”，事实证明它本质上是不可靠的。黑名单本质上是不完整的，无论你能得到多少“建议”。
I know mysqli_query only allows one query to be run at once so there's some security there
没有。 SQL 注入不是要添加另一个查询。
为什么我将这个问题作为“如何防止 PHP 中的 SQL 注入？”的重复问题关闭？
因为这些问题是互斥的，不能共存于同一个站点。
如果我们同意，唯一正确的答案是使用准备好的语句，那么问“我如何保护不使用准备好的语句”的问题就没有意义了。
与此同时，如果 OP 设法强迫我们给出他们迫切想要的肯定答案，这将使另一个问题过时。如果没有它们一切都很好，为什么还要使用准备好的语句？
此外，这个特定问题也太局限了。它寻求的不是洞察力，而是 借口。除了 OP 个人之外，没有人的借口。一个让他们使用被证明是不安全的方法的借口。虽然这取决于他们，但这使得这个问题对社区基本上没有用。
- 检查每个用户输入的数据类型以及适用于正则表达式的位置（黄金法则是：永远不要相信用户输入）
- 使用准备好的语句
- 说真的：准备好的陈述:)
工作量很大，尤其是当您的应用程序状况不佳时（就像您的情况一样），但这是获得良好安全级别的最佳方式
另一种方法（我建议反对）可以是使用 mod_security 或 WAF 来过滤掉注入尝试的虚拟补丁，但首要的是：尝试编写健壮的应用程序 （虚拟补丁似乎是一种懒惰的修复方法，但实际上也需要大量的工作和测试，并且应该只在已经很强大的应用程序代码之上使用）