您所听到的关于 WordPress 安全性的一切都是错误的。

我叫 Cory Marsh，在爱达荷州和加利福尼亚州从事网络安全工作已超过 25 年。在那段时间里，我听到了很多听起来不错但实际上并不能改善您的安全状况的安全建议。

其中许多建议都源于对 PHP 和 Web 工作原理的误解。由于大多数 WordPress 网站都托管在 Linux 上，因此本文重点介绍针对在典型 Linux 网络托管上运行的 WordPress 网站的常见建议。

Unix 文件系统上的每个文件都具有读、写和执行权限。可以为文件所有者、文件组和其他人（通常称为“公共”或“其他”）设置这些权限。当人们认为公共写访问意味着任何远程互联网用户都可以编辑文件时，误解就开始了。

大多数 WordPress 站点使用 Nginx、Apache 或 LiteSpeed 等 Web 服务器以及 PHP-FPM 等 PHP 服务器。这些通常作为同一网络用户在本地运行。他们使用本地用户权限，而不是一些直接面向互联网的公共权限。

对于通过公共文件权限修改文件的远程系统，它需要远程文件系统访问，例如公共安装的 NFS 共享。这不是典型的托管提供商公开 WordPress 的方式。您仍然应该保持权限一致并减少不必要的写入访问，但公共 Unix 权限并不是许多清单暗示的直接远程编辑风险。

我不想在托管提供商的营销游戏中撒盐，但我很少看到 WordPress 网站因为过时的操作系统软件包而受到损害。除了 ImageMagick 等不寻常的例外情况之外，普通 PHP 代码可以直接访问的操作系统包并不多，从而导致常见的 WordPress 妥协。

PHP 是执行攻击者与之交互的动态应用程序代码的系统。在典型的 Linux WordPress 主机上，攻击者更有可能利用易受攻击的插件、主题或未经身份验证的端点，而不是内核或系统包漏洞。

WordPress 有一个数据库表前缀。默认为 wp_。此行为来自 WordPress 历史，包括多站点和多用户模式，其中单独的表需要单独的前缀。

如今，更改前缀几乎没有什么安全价值。现代恶意软件和自动利用工具可以发现或推断前缀。许多 wp-to-shell 漏洞利用路径的存在表明，在现代人工智能辅助恶意软件时代，这个值并不是一个严重的边界。

从生成器标签中隐藏 WordPress 版本号通常会使安全扫描器更难准确报告您的版本。大多数自动攻击不会首先检查 Web 服务器或 WordPress 版本。他们将漏洞发送到他们能找到的每个目标。

如果该网站容易受到攻击，它就会受到损害。如果它不易受攻击，攻击者就会继续前进。在某些情况下，首先检查版本甚至可以向安全软件发出警报，并在真正的漏洞利用之前禁止攻击者的 IP。

6G、7G 或常用的 WAF 等防火墙规则集可以阻止某些 Web 攻击。它们通常对部分跨站点脚本和 SQL 注入很有用，尽管即使在这些方面，记录也是混杂的。如果他们阻止得太积极，就会阻止良好的流量。如果它们阻止得不够，那么价值就有限。

AWS、Cloudflare 和 Sucuri 等提供商的内联 WAF 产品可以出色地应对他们了解的攻击类别。问题是许多现代 WordPress 攻击并不是经典的 XSS 或 SQL 注入。它们的访问控制被破坏了。

访问控制损坏意味着开发人员在允许危险操作（例如将文件上传到 API 端点）之前忘记要求有效的管理员或授权用户。基于签名的 WAF 可能不知道请求将在 PHP 内部执行什么操作。它会看到请求，寻找已知模式，并可以让漏洞利用通过。

为了获得真正的保护，防止访问控制被破坏，您需要运行时保护来监视请求的执行并阻止未经身份验证的请求执行危险操作。 BitFire for WordPress 等工具包含 RASP 功能，可以通过阻止上下文中的危险操作来防止对易受攻击的插件和主题的利用。

并非所有常见建议都是不好的。您应该实施合理的文件权限。您应该保持操作系统更新以实现兼容性、修复和性能改进。你应该运行一个好的WAF，因为它可以阻止一些真正的攻击。

只是当下一个插件漏洞影响您的网站时，不要指望这些建议本身能够拯救您的网站。