关于保护WordPress、Magento和其他广泛使用的软件的最常见建议之一是为数据库表名添加前缀或更改默认前缀。例如，经常听到将wp_WordPress 的默认前缀更改为一些晦涩的东西，例如1sdf34jSqo8_.

我的问题是：这不就是默默无闻的安全吗？如果是这样，无论如何这样做是一个好习惯吗？

我看到的优点和缺点是：

好处：

• 许多 SQL 注入攻击必然有两个步骤：识别表，然后执行其他操作。这并不能阻止诸如提交密码之类的攻击xyz' OR 1=1 --'，但它确实阻止了诸如DROP TABLE foo实际执行任何操作的查询，直到攻击者以某种方式得知表名。
• 它有助于减轻真正存在 SQLi 漏洞的噩梦零日攻击。在这些情况下，有点模糊是有帮助的。
• 通过 mod_security 或 WAF 拦截和阻止某些攻击可能会更容易一些。例如，如果我的表前缀是1sdf34jSqo8_并且该字符串出现在 GET 或 POST 数据中，我将非常怀疑该请求。但是，如果攻击者有那个字符串，我很可能已经被攻击了。实际上，从尚未通过超级用户身份验证的任何人看到该文本实际上可能是直接到寻呼机警报。
• 它允许在一个数据库中安装应用程序的多个副本，对于那些主机或服务提供商允许您拥有 1 或 2 个数据库但不限制表数量的实例（这对我来说从来没有意义，但我离题）。^*这并不是真正的安全问题，没错，但这是人们启用这样的前缀的主要原因。

缺点：

• 作为开发人员实施这是一个巨大的痛苦。这意味着代码中的每个表引用都需要在表名中添加一个常量或变量。简单的 SELECT 已经够糟糕了；架构更改和补丁可能成为真正的噩梦。这也破坏了许多 IDE 对 SQL 语句执行自动完成和拼写检查等操作的能力。
• 由于上述问题，可以说它更有可能导致错误和可能的漏洞，因为有一次你的团队中的某个人写了一个类似的声明SELECT * FROM {prefix}foo LEFT JOIN bar ...并在某处忘记了前缀。
• 显然，这至少是一种默默无闻的安全形式。这会导致马虎、过度自信等。
• 它不能解决准备好的语句和白名单尚未解决的任何问题。

我认为对“可以显示数据库的表名可以吗？”这个问题的公认答案是正确的。很好地总结了我的想法 - 如果您的数据库可以防止注入，那么您不会因为显示表名而丢失任何东西。如果在另一层存在漏洞，例如成功上传和执行的恶意脚本，那么 (1) 表前缀将很容易被发现，并且 (2) 无论如何你都会被淹没。

所以，这个问题的简短版本：这实际上是开发人员在创建应用程序时应该做的事情，还是伪装成额外的安全层只是一种不好的做法？

编辑：要清楚，我不是在问最终用户是否应该继续更改前缀，例如 WordPress 安装的数据库。我问的是，当开发人员创建使用数据库的应用程序时，开发人员是否应该首先启用这种功能。