最近の最も一般的なセキュリティのベストプラクティスの1つは、vhostのドキュメントルートより1つ上のディレクトリを移動wp-config.phpすることです。そのための良い説明を実際に見つけたことはありませんが、Webroot内の悪意のあるスクリプトまたは感染したスクリプトがデータベースのパスワードを読み取るリスクを最小限に抑えるためだと思います。

ただし、WordPressにアクセスさせる必要があるため、展開open_basedirしてドキュメントルートの上のディレクトリを含める必要があります。それは単に目的全体を無効にするだけでなく、サーバーログ、バックアップなどを攻撃者にさらす可能性もありませんか？

または、技術は、PHPエンジンによって解析されるのではなく、wp-config.phpリクエストしている人にプレーンテキストとして表示される状況を防止しようとしているだけhttp://example.com/wp-config.phpですか？これはごくまれにしか発生しないように思われ、logs / backups / etcをHTTPリクエストにさらすことのマイナス面を上回ることはありません。

他のファイルを公開せずにホスティング設定でドキュメントルートの外に移動することは可能ですが、他の設定ではできませんか？

結論： この問題について何度も何度もやり直した後、2つの答えが出てきました。Aaron Adamsはwp-config の移動を支持して良いケースを作成し、chrisguitarguyはそれに対して良いケースを作成します。これらは、スレッドに不慣れで、すべてを読みたくない場合に読むべき2つの答えです。他の答えは、冗長または不正確です。

短い答え：はい

この質問への答えは明白なはいです、そうでないと言うのは完全に無責任です。

長い答え：実世界の例

私の非常に実際のサーバーから非常に実際の例を提供することを許可しますwp-config.php。Webルートの外に移動すると、そのコンテンツがキャプチャされなくなります。

不具合：

Pleskのバグに関する次の説明をご覧ください（11.0.9 MU＃27で修正済み）：

サブスクリプションをホスティングプランと同期した後、Pleskがサブドメインの転送をリセットする（117199）

無害に聞こえますよね？

さて、このバグを引き起こすために私がしたことは次のとおりです。

1. 別のURLに（例えばリダイレクトするようにサブドメインを設定するsite.staging.server.comにはsite-staging.ssl.server.com）。
2. サブスクリプションのサービスプラン（PHP構成など）を変更しました。

これを行うと、Pleskはサブドメインをデフォルトにリセット~/httpdocs/します。インタープリター（PHPなど）をアクティブにせずにのコンテンツを提供します。

そして気づかなかった。数週間。

結果：

• wp-config.phpウェブルートでは、への要求は、/wp-config.phpWordPressの設定ファイルをダウンロードしているだろう。
• wp-config.phpWebルートの外、要求/wp-config.phpを完全に無害なファイルをダウンロードしました。実際のwp-config.phpファイルをダウンロードできませんでした。

したがって、wp-config.phpWebルートの外部に移動すると、現実の世界で真のセキュリティ上の利点があることは明らかです。

wp-config.phpサーバー上の任意の場所に移動する方法

WordPressは、WordPressのインストールの上の1つのディレクトリをwp-config.phpファイルに自動的に検索するので、そこに移動した場合は完了です！

しかし、他の場所に移動した場合はどうなりますか？簡単です。wp-config.php次のコードを使用して、WordPressディレクトリに新規を作成します。

<?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ファイルの実際のパスに変更してください。）

で問題が発生した場合は、PHP設定のディレクティブにopen_basedir新しいパスを追加するだけopen_basedirです。

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

それでおしまい！

反対の議論を選ぶ

wp-config.phpWebルートの外部への移動に対するすべての議論は、誤った仮定にかかっています。

引数1：PHPが無効になっている場合、それらは既に

誰かが[ wp-config.php]のコンテンツを見る唯一の方法は、サーバーのPHPインタープリターを迂回するかどうかです…その場合、あなたはすでに問題に直面しています。サーバーに直接アクセスできます。

FALSE：上記で説明したシナリオは、侵入ではなく構成の誤りの結果です。

引数2：PHPを誤って無効にすることはまれであるため、重要ではありません

攻撃者がPHPハンドラを変更するのに十分なアクセス権を持っている場合、あなたはすでに台無しにされています。私の経験では偶発的な変更は非常にまれであり、その場合はパスワードを簡単に変更できます。

FALSE：上記で説明したシナリオは、共通のサーバー構成に影響を与える共通のサーバーソフトウェアのバグの結果です。これはほとんど「まれ」ではありません（さらに、セキュリティはまれなシナリオを心配することを意味します）。

WTF：侵入中に機密情報が取得された場合、侵入後にパスワードを変更してもほとんど役に立ちません。本当に、WordPressはカジュアルなブログにのみ使用され、攻撃者は改ざんのみに関心があると考えていますか？誰かが侵入した後にサーバーを復元するのではなく、サーバーを保護することについて心配しましょう。

引数3：へのアクセスを拒否するwp-config.phpだけで十分

仮想ホストの設定を介してファイルへのアクセスを制限したり.htaccess、ドキュメントルートの外部に移動するのと同じ方法でファイルへの外部アクセスを効果的に制限したり できます。

FALSE：仮想ホストのサーバーのデフォルトがno PHP、no .htaccessであると想像してくださいallow from all（実稼働環境ではほとんど異常ではありません）。パネルの更新など、日常的な操作中に何らかの方法で構成がリセットされると、すべてがデフォルトの状態に戻り、公開されます。

設定が誤ってデフォルトにリセットされたときにセキュリティモデルが失敗した場合は、さらにセキュリティが必要です。

WTF：なぜセキュリティの層を減らすことを特に推奨するのでしょうか？高価な車にはロックが付いているだけではありません。アラーム、イモビライザー、GPSトラッカーもあります。何かを保護する価値がある場合は、正しく行います。

引数4：への不正アクセスwp-config.phpは大したことではない

データベース情報は、実際に[ wp-config.php]の唯一の機密情報です。

FALSE：認証キーおよびソルトは、潜在的なハイジャック攻撃の数に使用できます。

WTF：データベースの資格情報がの唯一のものであったとしても、攻撃者が手に入れるwp-config.phpことを恐れる必要があります。

引数5：wp-config.phpWebルートの外部に移動すると、実際にはサーバーの安全性が低下します

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ルートの外側に移動します。

最大のものは、wp-config.phpデータベースのユーザー名/パスワードなどの機密情報が含まれていることです。

アイデア：ドキュメントルートの外側に移動すれば、何も心配する必要はありません。攻撃者は、外部ソースからそのファイルにアクセスすることはできません。

ただし、ここwp-config.phpに問題があります。実際には画面に何も印刷しません。WPインストール全体で使用されるさまざまな定数のみを定義します。したがって、誰かがそのファイルの内容を確認する唯一の方法は、サーバーのPHPインタープリターを回避する場合です。つまり、.phpファイルをプレーンテキストとしてレンダリングします。それが起こった場合、あなたはすでに問題に直面しています。彼らはあなたのサーバーに直接アクセスし（そしておそらくroot権限も）、好きなことをすることができます。

先に進んで、セキュリティの観点からドキュメントルートの外側に移動するメリットはないwp-configと言います -上記の理由とこれらの理由から：

1. 仮想ホストの設定または.htaccessを使用してファイルへのアクセスを制限できます。ドキュメントルートの外部への移動と同じ方法で、ファイルへの外部アクセスを効果的に制限できます。
2. wp-configSSH経由でサーバーに（制限付きで）アクセスしても、十分な特権のないユーザーがファイルを読み取れないように、ファイルのアクセス許可を厳しくすることができます。
3. 機密情報、データベース設定は、単一のサイトでのみ使用されます。そのため、攻撃者がその情報にアクセスしたとしても、影響を受けるのはwp-config.phpファイルが属するWordPressインストールだけです。さらに重要なことは、そのデータベースユーザーには、そのWPインストールのデータベースに対する読み取りと書き込みのアクセス許可のみがあり、他には何も許可されていないことです。つまり、攻撃者がデータベースにアクセスした場合、それは単にバックアップからの復元（ポイント4を参照）とデータベースユーザーの変更の問題です
4. 頻繁にバックアップします。多くの場合、相対的な用語です。毎日20件の記事を投稿する場合は、毎日または数日ごとにバックアップすることをお勧めします。週に1回投稿する場合は、週に1回バックアップするだけで十分です。
5. サイトはバージョン管理下にあります（このように）。つまり、攻撃者がアクセスした場合でも、コードの変更を簡単に検出してロールバックできます。攻撃者がにアクセスできる場合、wp-configおそらく他の何かを台無しにしています。
6. データベース情報は、実際にはの唯一の重要な情報でありwp-config、注意が必要なので（ポイント3および4を参照）、大したことではありません。塩などはいつでも変更できます。発生する唯一のことは、ログインしているユーザーのCookieを無効にすることです。

私にとって、wp-configドキュメントのルートから抜け出すことは、あいまいさによるセキュリティの悪臭を放ちます-これは非常にストローマンです。

マックスは知識のある答えだと思いますが、それは物語の片側です。WordPressのコーデックスは、より多くの助言を持っています：

また、あなただけ（および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ディレクトリ内のファイルの既定のアクセス許可）を使用します。

誰かが私たちに輝いてほしいと頼みました、そして私はここで返信します。

はい、wp-config.phpをサイトのルートディレクトリから分離すると、セキュリティ上の利点があります。

1- PHPハンドラーが何らかの方法で破損または変更された場合、DB情報は公開されません。そして、はい、サーバーの更新中に共有ホストでこれが数回発生するのを見ました。はい、その期間中にサイトは壊れますが、パスワードはそのままです。

2-ベストプラクティスでは、構成ファイルをデータファイルから分離することを常に推奨しています。はい、WordPress（または任意のWebアプリ）でそれを行うのは困難ですが、上に移動すると少し分離されます。

3-誰でも？-sをファイルに渡してソースを表示できるPHP-CGIの脆弱性を思い出してください。http://www.kb.cert.org/vuls/id/520827

最後に、これらは小さな詳細ですが、リスクを最小限に抑えるのに役立ちます。特に、誰でもデータベースにアクセスできる共有環境にいる場合（必要なのはユーザー/パスだけです）。

ただし、サイトを適切にセキュリティで保護するために実際に必要なものの前に、小さな注意散漫（時期尚早な最適化）が入らないようにしてください。

1-常に最新の状態に保つ

2-強力なパスワードを使用する

3-アクセスを制限します（許可を介して）。これについての投稿があります：

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

おかげで、

絶対そうです。

wp-config.phpをパブリックディレクトリの外に移動すると、phpハンドラーが悪意のある（または誤って！）変更されたときにブラウザーを使用した読み取りから保護します。

不十分な管理者のせいでサーバーがほとんど感染していない場合は、DBログイン/パスワードを読み取ることができます。管理者に罰金を課し、より適切で信頼性の高いサーバーホストを取得します。それはもっと高価かもしれませんが。

引数のために、wp_config.phpファイルを移動しても、必ずしも親ディレクトリにのみ移動する必要があるわけではないことを明確にしたいだけです。/ root / htmlのような構造があり、htmlにはWPインストールとすべてのHTMLコンテンツが含まれているとします。wp_config.phpを/ rootに移動する代わりに、/ root / secure ...のようなものに移動できます。これは、htmlディレクトリの外部にあり、サーバーのルートディレクトリにもありません。もちろん、PHPがこの安全なフォルダーでも実行できることを確認する必要があります。

/ root / secureなどの兄弟フォルダーでwp_config.phpを探すようにWPを構成できないため、追加の手順を実行する必要があります。/ root / htmlにwp_config.phpを残し、重要な部分（データベースログイン、ソルト、テーブルプレフィックス）を切り取り、config.phpという別のファイルに移動しました。次にinclude、次のようにwp_config.phpにPHP コマンドを追加します。include('/home/content/path/to/root/secure/config.php');

これは、基本的にセットアップで行ったことです。さて、上記の議論に基づいて、私はそれが必要であるか、それとも良いアイデアであるかをまだ評価しています。ただし、上記の構成が可能であることを追加したいだけです。バックアップやその他のルートファイルは公開されません。また、セキュリティで保護されたフォルダーが独自のパブリックURLでセットアップされていない限り、閲覧できません。

さらに、以下で.htaccessファイルを作成することにより、安全なフォルダーへのアクセスを制限できます。

order deny,allow
deny from all
allow from 127.0.0.1

atatckerがコードを挿入することを可能にする多くの悪い記述されたテーマとプラグインがあります（Timthumbのセキュリティ問題を思い出してください）。攻撃者になる場合、なぜwp-config.phpを検索する必要があるのですか？このコードを挿入するだけです：

var_dump( DB_NAME, DB_USER, DB_PASSWORD );

wp-config.phpを非表示にすることができます。WordPressがすべての機密情報をグローバルにアクセス可能にする限り、wp-config.phpを非表示にするメリットはありません。

wp-config.phpの悪い点は、機密データを保持していることではありません。悪い点は、機密データをグローバルにアクセス可能な定数として定義することです。

更新

define()機密データをグローバル定数として定義することの問題とその理由を明らかにしたいと思います。

Webサイトを攻撃する方法はたくさんあります。スクリプトインジェクションは、Webサイトを攻撃する唯一の方法です。

サーバーに、攻撃者がメモリダンプにアクセスできる脆弱性があると仮定します。攻撃者は、メモリダンプですべての変数のすべての値を見つけます。グローバルにアクセス可能な定数を定義する場合、スクリプトが終了するまでメモリに残る必要があります。定数の代わりに変数を作成すると、変数が不要になった後にガベージコレクターがメモリを上書き（または解放）する可能性が高くなります。

機密データを保護するためのより良い方法は、使用後すぐに削除することです。

$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がそのコピーを保存しない場合）。

セキュリティ上の利点とは別に、コアWordPressファイルをサブモジュール/外部として保持しながら、WordPressインスタンスをバージョン管理下に置くこともできます。これが、Mark JaquithがWordPress-Skeletonプロジェクトをセットアップした方法です。詳細については、https：//github.com/markjaquith/WordPress-Skeleton#assumptionsをご覧ください。