Wp-configをWebルートの外に移動することは本当に有益ですか？
最近の最も一般的なセキュリティのベストプラクティスの1つは、 仮想ディレクトリのドキュメントルートより1ディレクトリ上のwp-config.phpを移動することです 。私はそのための良い説明を実際に見つけたことは一度もありませんが、Webroot内の悪意のあるスクリプトや感染したスクリプトがデータベースのパスワードを読み取ることによるリスクを最小限に抑えることを目的としています。
しかし、それでもWordPressにアクセスさせる必要があるため、open_basedirを展開してドキュメントルートの上のディレクトリを含める必要があります。それは単に目的全体を無効にするだけでなく、サーバーのログ、バックアップなどを攻撃者に公開する可能性もありますか？
それとも、PHPエンジンによって解析されるのではなく、wp-config.phpがプレーンテキストとしてhttp://example.com/wp-config.phpを要求している人に見せられるという状況を防ぐためだけの手法なのでしょうか。これはごくまれにしか発生しないように思われますが、ログやバックアップなどをHTTP要求にさらすことのマイナス面を上回ることはありません。
他のファイルを公開せずにホスティング設定でドキュメントルートの外に移動することはできますが、他の設定ではそうできません。
結論：この問題について何度も話し合った結果、2つの答えが出てきました。 Aaron Adamsはwp-configを動かすことを支持して好例を作り、chrisguitarguyはそれに対して好例を作ります。これらは、あなたがスレッドに不慣れで、全体を読みたくない場合に読むべき2つの答えです。他の答えは冗長または不正確です。
短い答え：はい
この質問に対する答えは曖昧なはいであり、そうでなければ完全に無責任です。
長い答え：実世界の例
wp-config.phpをWebルートの外に移動する非常に実際のサーバーからの非常に実際の例を提供することを許可します具体的にはコンテンツのキャプチャを防止しました。
不具合：
Pleskのバグに関する次の説明をご覧ください（11.0.9 MU＃27で修正済み）：
無害に聞こえますか？
さて、ここに私がこのバグを引き起こすためにしたことです：
- 別のURLにリダイレクトするようにサブドメインを設定します（例：
site.staging.server.comからsite-staging.ssl.server.com）。 - サブスクリプションのサービスプランを変更しました（例：PHP構成）。
これを行ったとき、Pleskはサブドメインをデフォルトにリセットしました。アクティブなインタープリター（PHPなど）なしで~/httpdocs/のコンテンツを提供します。
そして気づかなかった。数週間。
結果：
- Webルートに
wp-config.phpがある場合、/wp-config.phpへの要求はWordPress構成ファイルをダウンロードします。 wp-config.phpがWebルート外にある場合、/wp-config.phpへのリクエストは完全に無害なファイルをダウンロードしました。実際のwp-config.phpファイルをダウンロードできませんでした。
したがって、wp-config.phpをWebルートの外側に移動すると、実世界での真のセキュリティ上の利点になることは明らかです。
wp-config.phpをサーバー上の任意の場所に移動する方法
WordPressはwp-config.phpファイルのWordPressインストールの上の1つのディレクトリを自動的に検索するので、それを移動した場所で完了です。
しかし、他の場所に移動した場合はどうなりますか？簡単です。次のコードを使用して、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インタープリターを迂回するかどうかです…それが起こった場合、あなたはすでに問題に直面しています。サーバ。
FALSE：上記のシナリオは、侵入ではなく、構成の誤りの結果です。
引数2：PHPを誤って無効にすることはまれであるため、重要ではありません。
攻撃者がPHPハンドラーを変更するのに十分なアクセス権を持っている場合、あなたはすでに台無しにされています。私の経験では偶発的な変更は非常にまれであり、その場合はパスワードを簡単に変更できます。
FALSE：上記で説明したシナリオは、共通のサーバー構成に影響を与える共通のサーバーソフトウェアのバグの結果です。これはほとんど「まれ」ではありません（さらに、セキュリティはまれなシナリオを心配することを意味します）。
WTF：侵入中に機密情報が取得された場合、侵入後にパスワードを変更してもほとんど役に立ちません。本当に、WordPressはカジュアルなブログにのみ使用され、攻撃者は改ざんのみに関心があると思いますか？誰かが侵入した後にサーバーを復元するだけでなく、サーバーを保護することについて心配しましょう。
引数3：wp-config.phpへのアクセスを拒否するだけで十分です
仮想ホスト設定または
.htaccessを介してファイルへのアクセスを制限できます。ドキュメントルートの外部への移動と同じ方法で、ファイルへの外部アクセスを効果的に制限できます。
FALSE：仮想ホストのサーバーのデフォルトが、PHPなし、.htaccess、allow from all（本番環境ではめったにない）であると想像してください。 などの通常の操作中に設定が何らかの方法でリセットされると（たとえば、パネルの更新）、すべてがデフォルト状態に戻り、公開されます。
設定が誤ってデフォルトにリセットされたときにセキュリティモデルが失敗した場合は、さらにセキュリティが必要です。
WTF：なぜセキュリティのレイヤーを減らすことを特に推奨するのですか？高価な車にはロックが付いているだけではありません。アラーム、イモビライザー、GPSトラッカーもあります。何かを保護する価値がある場合は、正しく行います。
引数4：wp-config.phpへの不正アクセスは大したことではない
データベース情報は、実際に[
wp-config.php]の唯一の機密情報です。
FALSE：認証キーとソルトは、任意の数の潜在的なハイジャック攻撃で使用できます。
WTF：データベース資格情報がwp-config.phpの唯一のものであったとしても、攻撃者が手に入れる恐怖であるべきです。
引数5：wp-config.phpをWebルートの外に移動すると、実際にはサーバーが安全になりますless
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/ディレクトリがある場合は、常にそれらを含めることを忘れないでください。）
結論：構成ファイルは常にalways常にWebルートの外側に配置する必要があります
セキュリティに関心がある場合は、wp-config.phpをWebルート外に移動します。
最大のものはwp-config.phpには、データベースのユーザー名/パスワードなどの機密情報が含まれています。
アイデア：ドキュメントルートの外側に移動すれば、何も心配する必要はありません。攻撃者は、外部ソースからそのファイルにアクセスすることはできません。
ただし、ここに問題があります。wp-config.phpは実際には画面に何も表示しません。 WPインストール全体で使用されるさまざまな定数のみを定義します。したがって、誰かがそのファイルの内容を見る唯一の方法は、サーバーPHPインタープリターを回避する場合です-プレーンテキストとしてレンダリングする.phpファイルを取得します。それが起こった場合、あなたはすでに問題に直面しています。彼らはあなたのサーバーに直接アクセスし（そしておそらくroot権限も）、好きなことをすることができます。
先に進み、と言います。セキュリティの観点からwp-configをドキュメントルートの外側に移動してもメリットはありません-上記の理由とこれらの理由から：
- 仮想ホストの設定または.htaccessを使用してファイルへのアクセスを制限できます。ドキュメントルートの外部に移動するのと同じ方法で、ファイルへの外部アクセスを効果的に制限できます。
- ファイル許可が
wp-configに対して厳格であることを確認して、SSH経由でサーバーに（制限付きで）アクセスしても、十分な特権のないユーザーがファイルを読み取れないようにすることができます。 - 機密情報、データベース設定は、単一のサイトでのみ使用されます。そのため、攻撃者がその情報にアクセスしたとしても、影響を受けるサイトは
wp-config.phpファイルが属するWordPressインストールだけです。さらに重要なことは、そのデータベースユーザーには、そのWPインストールのデータベースに対する読み取りと書き込みの権限のみがあり、他のユーザーには何も許可されていないことです。つまり、攻撃者がデータベースにアクセスした場合、それは単にバックアップから復元（ポイント4を参照）してデータベースユーザーを変更するだけのことです - 頻繁にバックアップします。多くの場合、相対的な用語です。毎日20件の記事を投稿する場合は、毎日または数日ごとにバックアップすることをお勧めします。週に1回投稿する場合は、週に1回バックアップするだけで十分です。
- サイトはバージョン管理されています（ like ）。つまり、攻撃者がアクセスを取得した場合でも、コードの変更を簡単に検出してロールバックできます。攻撃者が
wp-configにアクセスできる場合、おそらく他の何かを台無しにしています。 - データベース情報は、実際に
wp-configの唯一の重要なものであり、注意が必要なので（ポイント3と4を参照）、大したことではありません。塩などはいつでも変更できます。発生する唯一のことは、ログインしているユーザーのCookieを無効にすることです。
私にとって、wp-configをドキュメントルートから移動すると、あいまいさが原因でセキュリティが脅かされます。これは非常にストローマンです。
私はマックスが知識豊富な答えであると思います、そしてそれは物語の片側です。 WordPress Codexにもっとアドバイスがあります ：
また、あなた（そしてウェブサーバー）だけがこのファイルを読むことができることを確認してください（それは通常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- 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
ありがとう、
絶対そうです。
wp-config.php をパブリックディレクトリ外に移動すると、phpハンドラが悪意を持って（または誤って！）変更されたときにブラウザを使用した読み取りから保護されます。
あなたのDBログイン/パスワードを読むことはサーバーが不完全な管理者の過失によってほとんど感染していないとき可能です。管理者に罰金を請求し、傾向が良く、信頼性の高いサーバーHostを入手してください。それはもっと高価かもしれませんが。
議論の都合上、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という別のファイルに移動しました。次に、あなたのwp_config.phpにPHP includeコマンドを追加します。include('/home/content/path/to/root/secure/config.php');
これは基本的に私が私の設定でやったことです。今、上記の議論に基づいて、私はまだそれが必要であるか、あるいは良い考えでさえあるかどうかを評価しています。しかし、私はちょうど上記の設定が可能であることを付け加えたいと思いました。バックアップやその他のルートファイルは公開されません。また、セキュリティで保護されたフォルダに独自のパブリックURLが設定されていない限り、閲覧することはできません。
さらに、その中に.htaccessファイルを作成することで、安全なフォルダへのアクセスを制限することができます。
order deny,allow
deny from all
allow from 127.0.0.1
アタッカーがコードを挿入することを可能にする、悪い書かれたテーマやプラグインがたくさんあります（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がそのコピーを保存しない場合）。