不要在变通方法或半修复上花费大量时间。您尝试实施此处建议的任何内容的每一分钟，都是您可以花费实施准备好的语句的一分钟。这是唯一真正的解决方案。

如果您有 SQLi 漏洞，那么无论您如何尝试减慢攻击者的速度，攻击者最终都可能获胜。因此请注意，尽管您可能会做出改进，但最终您会输掉比赛，除非您解决问题的根本原因。

至于你到目前为止所尝试的：隐藏错误消息是一个好的开始。我建议您应用更严格的权限（见下文）。更改表名是否有帮助是有争议的，但可能不会受到伤害。

好的，那么这些权限呢？尽可能将数据库用户可以做的事情限制到表甚至列级别。你甚至可以创建多个数据库用户来锁定更多的东西。例如，仅在您实际编写时才使用具有写入权限的数据库用户。仅当您实际需要读取密码列时，才与有权读取密码列的用户连接。这样，如果您在某些其他查询中存在注入漏洞，则无法利用它来泄漏密码。

另一种选择是使用 Web 应用程序防火墙 (WAF)，例如 Apache 的 mod_security。您可以将其配置为阻止看起来可疑的请求。但是，没有 WAF 是完美的。而且配置它需要时间和精力。您最好利用这段时间来实现准备好的语句。

再说一次，不要让任何这些引诱你产生虚假的安全感。解决问题的根本原因是无可替代的。

唯一正确的方法是使用准备好的语句。

1. 如果你伪装错误信息，它会有点困难，但不会阻止攻击者。
2. 您可以限制权限，但授予用户的所有权限都可能被攻击者获得。在某些情况下，也可以从 SQL 注入执行 shell 命令。
3. 重命名表对您没有帮助。该工具sqlmap将逐个字符地为您强制使用表名。这不需要太多时间。

您也可以限制呼叫次数，以使攻击者更难攻击或对可疑呼叫发出警报并停止本手册，但解决此问题的唯一正确方法是使用准备好的语句。只需 grep 浏览您的源代码并查看具有动态内容的 SQL 语句并替换它们。

我们知道，但我们没有足够的开发人员/测试人员来确保它 100% 安全。

这是真正的问题。除非您雇用更多人或重新分配优先级，否则您并不安全。阻止 99.9% 的攻击者意味着您的数据已被泄露。创可贴解决方案是一件坏事，而且它们不起作用。当您可以解决实际问题时，不要浪费时间重构您的 SQL 访问模式。

至于代码解决方案，就像这里很多人建议的那样，使用准备好的语句是安全使用 SQL 的最简单方法。

这比尝试使用 php 自己清理参数要容易得多，而且花费的时间要少得多。只需 grep 您的整个代码库以获取与 SQL 相关的所有内容并修复它。

永远清除代码中的所有 SQL

此问题的最佳解决方案是将所有 SQL 代码作为文字字符串从您的代码中删除，并且不再引入它。相反，请使用诸如 Hibernate 或 Entity Framework 之类的ORM软件。无论如何，这个软件比原始 SQL 好用得多，并且当它最终进入数据库时​​会自动参数化你的 SQL。如果可能，请制定此政策。

如果您没有时间学习和实施这些包，或者由于其他原因无法使用它们，那么 trietend 的答案是下一个最佳选择，使用准备好的语句。这将使您免受 SQL 注入的影响。也就是说，除非您向开发人员施加任何压力以提供快速解决方案，否则他们可能会再次忘记参数化单个变量，从而使您回到起点。