将wp-config移到Web根之外真的有好处吗？

#1 楼

简短答案：是

这个问题的答案是肯定，否则就不负责任了。


长答案：一个真实的例子

允许我从一个非常真实的服务器中提供一个非常真实的示例，其中，将wp-config.php移到Web根目录之外专门阻止了其内容被捕获。

错误：

看看以下有关Plesk中错误的描述（已在11.0.9 MU＃27中修复）： ）


声音无害，对吗？

好吧，这是我触发此错误的方法：


Set设置一个子域以重定向到另一个URL（例如site.staging.server.com到site-staging.ssl.server.com）。
更改了订阅的服务计划（例如其PHP配置）。

当我这样做时，Plesk将子域重置为默认值：提供~/httpdocs/的内容，没有任何解释器（例如PHP）处于活动状态。

而且我没有注意到e。数周时间。

结果：


在Web根目录中使用wp-config.php，对/wp-config.php的请求将下载WordPress配置文件。在Web根目录之外的wp-config.php，一个请求/wp-config.php下载了一个完全无害的文件。无法下载真实的wp-config.php文件。

因此，很明显，将wp-config.php移出Web根目录可以在现实世界中带来真正的安全优势。


如何将wp-config.php移至服务器上的任何位置

WordPress会自动在WordPress安装上方的一个目录中查找wp-config.php文件，因此，如果已将其移至该位置，您就完成了！ br />
但是，如果您将其移动到其他地方怎么办？简单。使用以下代码在WordPress目录中创建一个新的wp-config.php：

<?php

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

/** Location of your WordPress configuration. */
require_once(ABSPATH . '../phpdocs/wp-config.php');

（请确保将以上路径更改为重新放置的wp-config.php文件的实际路径。）

如果您遇到open_basedir问题，只需在您的PHP配置中将新路径添加到open_basedir指令中：

open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

就这样！


解决相反的论点

每个反对将wp-config.php移到Web根之外的论点似乎都基于错误的假设。

论点1：如果禁用了PHP，他们已经在


某人看到
[wp-config.php]的内容的唯一方法是，他们是否绕过了您的服务器PHP解释器…
如果发生，您已经遇到麻烦：他们可以直接访问您的服务器。


错误：我上面描述的情况是配置错误的结果，而不是入侵的结果。

论点2：偶然禁用PHP的情况很少见，因此无关紧要


如果攻击者具有足够的权限来更改PHP处理程序，那么您
已经搞砸了。偶然的更改在我的经历中非常罕见，
那样的话，更改密码就很容易。通用服务器软件中的错误，会影响通用服务器配置。这几乎是“罕见的”（此外，安全性意味着要担心这种罕见情况）。

如果在入侵过程中获取了敏感信息，则在入侵后更改密码几乎无济于事。真的，我们是否仍然认为WordPress仅用于休闲博客，并且攻击者仅对污损感兴趣？让我们担心保护我们的服务器，而不仅仅是在有人进入服务器后恢复它。

论点3：拒绝访问wp-config.php足够好


您可以限制访问通过虚拟主机配置或
.htaccess访问文件-有效地限制了外部访问文件的方式，与移出文档根目录的方式相同。


否：假设您的虚拟主机服务器默认值为：否PHP，否.htaccess，allow from all（在生产环境中很少出现）。如果您在例行操作期间以某种方式重置了配置（例如面板更新），则所有内容都将恢复为默认状态，并且您处于暴露状态。

如果意外设置导致安全模型失败重置为默认值，您可能需要更高的安全性。

为什么有人特别建议减少安全性？昂贵的汽车不仅有锁，而且还有锁。他们也有警报器，防盗器和GPS追踪器。如果有什么值得保护的地方，请正确解决。

论点4：未经授权访问wp-config.php没什么大不了的。


数据库信息实际上是其中唯一敏感的东西。
[wp-config.php]。


错误：身份验证密钥和盐可以用于多种潜在的劫持攻击。

即使具有数据库凭据是wp-config.php中唯一的东西，您应该害怕攻击者将他们放到手。

论点5：将wp-config.php移到Web根目录之外实际上会使服务器的安全性降低


您仍然必须让WordPress访问[wp-config.php]，因此您需要
扩展open_basedir，以包括文档根目录上方的目录。


FALSE：假设wp-config.php位于httpdocs/中，只需将其移至../phpdocs/，然后将open_basedir设置为仅包括httpdocs/和phpdocs/。例如：

open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

（请记住，始终包含/tmp/或用户tmp/目录（如果有的话）。）


结论：配置文件应始终始终位于Web根目录之外。

如果您关心安全性，则应将wp-config.php移至Web根目录之外。

#2 楼

最大的问题是wp-config.php包含一些敏感信息：您的数据库用户名/密码等。

因此，您的想法是：将其移到文档根目录之外，您不必担心任何事情。攻击者将永远无法从外部来源访问该文件。但是，麻烦之处在于：wp-config.php从未在屏幕上实际打印任何内容。它仅定义在WP安装过程中使用的各种常量。因此，某人看到该文件内容的唯一方法是绕过服务器PHP解释器-他们得到.php文件以纯文本形式呈现。如果发生这种情况，那么您就已经麻烦了：他们可以直接访问您的服务器（并且可能具有root权限），并且可以执行他们喜欢的任何事情。

我要继续说，没有从安全角度来看，将wp-config移到文档根目录之外的好处-出于上述原因，这些原因是：


您可以通过虚拟主机配置或.htaccess限制对文件的访问-有效地限制外部访问文件的方式与移动到文档根目录之外的方式相同
您可以确保对wp-config的文件权限严格，以防止没有足够特权的任何用户读取文件，即使他们获得了（限制）通过SSH访问服务器。
您的敏感信息（数据库设置）仅在单个站点上使用。因此，即使攻击者获得了该信息的访问权，它也会影响的唯一站点将是wp-config.php文件所属的WordPress安装。更重要的是，该数据库用户仅具有读取和写入该WP安装数据库的权限，而没有其他权限-无权授予其他用户权限。换句话说，如果攻击者获得了对数据库的访问权限，则只需从备份中还原（请参阅第4点）并更改数据库用户即可。
您经常备份。通常是一个相对术语：如果您每天发布20篇文章，则最好每天或每隔几天备份一次。如果您每周发布一次，则每周备份一次就足够了。
您已将网站置于版本控制下（例如这样），这意味着即使攻击者获得了访问权限，您也可以轻松地检测到代码更改并将其滚动背部。如果攻击者可以访问wp-config，则他们可能已将其他信息弄乱了。没什么大不了的。盐等可以随时更改。唯一发生的事情是，它会使登录的用户cookie失效。

对我来说，将wp-config从文件安全的根源中转移到晦涩难懂的地方-这真是一个稻草人。 />

#3 楼

我认为马克斯（Max's）是一个知识渊博的答案，那是故事的一方面。 WordPress Codex有更多建议：


另外，请确保只有您（和Web服务器）可以读取此文件
（通常意味着400或440许可） 。

如果您将服务器与.htaccess一起使用，则可以将其放在该文件中（位于最顶部的
），以拒绝访问该文件的任何人：

<files wp-config.php>
order allow,deny
deny from all
</files>

请注意，在wp-config.php上设置400或440权限可能会阻止插件写入或修改它。例如，一个真正的案例就是缓存插件（W3 Total Cache，WP Super Cache等）。在这种情况下，我将使用600（/home/user目录中文件的默认权限）。

#4 楼

有人要求我们照亮，我会在这里回复。

是的，将wp-config.php与站点的根目录隔离会带来安全益处。

1-如果您的PHP处理程序被破坏或以某种方式修改，则您的数据库信息将不会被公开。是的，在服务器更新期间，我在共享主机上看到了几次这种情况。是的，在此期间该站点将被破坏，但是您的密码将保持不变。

2-最佳做法始终建议将配置文件与数据文件隔离。是的，使用WordPress（或任何Web应用程序）很难做到这一点，但是将其向上移动确实有点孤立。

3-记住PHP-CGI漏洞，任何人都可以通过？ -s到文件并查看源。 http://www.kb.cert.org/vuls/id/520827

最后，这些都是小细节，但它们确实有助于最大程度地降低风险。特别是如果您处于共享环境中，那么任何人都可以访问您的数据库（他们只需要一个用户/密码）即可。

但是，不要让小干扰（过早的优化）摆在您面前为确保站点正确安全，确实有必要：

1-始终保持更新状态

2-使用强密码

3-限制访问权限（通过权限）。我们在此处发布了有关此内容的帖子：

http://blog.sucuri.net/2012/08/wordpress-security-cutting-through-the-bs.html

感谢，

#5 楼

绝对可以。

将wp-config.php移到公共目录外时，当php处理程序被恶意（或不小心！）更改时，可以防止使用浏览器读取它。

读取当几乎没有通过la脚的管理员的故障感染服务器时，可以使用DB登录名/密码。向管理员收取罚款，并获得趋向更好和更可靠的服务器主机。虽然那可能会更贵。

#6 楼

为了便于讨论，我只想澄清一下，移动wp_config.php文件并不一定意味着您只需要将其移动到父目录即可。假设您有一个类似/ root / html的结构，其中html包含WP安装和所有HTML内容。不用将wp_config.php移至/ root，您可以将其移至/ root / secure ...之类，它既位于html目录之外，也不在服务器根目录中。当然，您需要确保php也可以在此安全文件夹中运行。

由于无法将WP配置为在/ root / secure之类的同级文件夹中查找wp_config.php，因此您必须采取其他步骤。我将wp_config.php留在/ root / html中，并剪掉敏感部分（数据库登录名，salt，表前缀）并将其移至名为config.php的单独文件中。然后，将PHP include命令添加到wp_config.php中，如下所示：include('/home/content/path/to/root/secure/config.php');

这实际上是我在设置中所做的。现在，基于以上讨论，我仍在评估是否有必要甚至是一个好主意。但是我只是想补充一点，上面的配置是可能的。它不会公开您的备份和其他根文件，并且只要未使用自己的公共URL设置安全文件夹，就无法浏览。

此外，您可以限制对安全文件夹的访问通过在其中创建.htaccess文件来创建文件夹：

order deny,allow
deny from all
allow from 127.0.0.1

#7 楼

有很多不良的书面主题和插件，可以让atatcker注入代码（记住Timthumb的安全性问题）。如果我将成为攻击者，为什么还要搜索wp-config.php？只需插入以下代码即可：

var_dump( DB_NAME, DB_USER, DB_PASSWORD );

您可以尝试隐藏wp-config.php。只要WordPress使所有敏感信息都可以全局访问，隐藏wp-config.php就没有任何好处。

wp-config.php中的不利之处在于它不能保存敏感数据。不好的部分是将敏感数据定义为全局可访问常量。

更新

我想解决define()的问题以及为什么定义敏感数据是一个坏主意数据作为全局常量。

攻击网站的方法有很多。脚本注入只是攻击网站的一种方法。

假设服务器存在一个漏洞，攻击者可以通过该漏洞访问内存转储。
攻击者将在内存转储中找到所有内存的所有值。变量。如果定义了全局可访问常量，则它必须一直保留在内存中，直到脚本结束。
创建变量而不是常量，垃圾回收器很有可能在处理完之后覆盖（或释放）内存。不再需要该变量。

保护敏感数据的一种更好的方法是在使用敏感数据后立即将其删除：

$db_con = new stdClass();
$db_con->db_user = 'username';
$db_con->password = 'password';
$db_con->host = 'localhost';

$db_handler = new Database_Handler( $db_con );

$db_con = null;

使用敏感数据，分配给null将覆盖内存中的数据。攻击者必须在$db_con包含敏感数据时立即获取内存转储。在上面的示例中，这是很短的时间（如果类Database_Handler不保存其副本）。

#8 楼

很抱歉撞破一个旧的帖子，但是这不仅是一个显而易见的解决方案。我们知道将wp-config.php文件移出wordpress路由目录有一些安全好处。有些人会认为好处是微不足道的，而其他人则不会。
另一方面，将文件移出默认位置可能会有一些缺点，例如破坏一些没有功能来寻找wp-的插件。在其他位置的config.php文件。
对我来说，最明显的事情是在wordpress路由目录之外创建一个secret-info.php文件，其中包含所有用户名和密码的变量，即
$ userName = “ user”;
$ databasePassword =“ 12345”;
将wp-config.php文件保留在默认的wordpress路由目录中，从wp-config.php中删除用户名和密码值，但保留其他所有内容。然后只需在wp-config.php中要求secret-info.php即可简单地引用$ userName和$ databasePassword变量，即
require（'PATH-TO-FILE / secret-info.php'）;
似乎要做的事情很明显，我在这里错过了什么吗？

#9 楼

除了安全性优点外，它还允许您将WordPress实例保持在版本控制下，同时将核心WordPress文件保留为子模块/外部。这就是Mark Jaquith设置其WordPress-Skeleton项目的方式。有关详细信息，请参见https://github.com/markjaquith/WordPress-Skeleton#assumptions。