wp-configをWebルート外に移動することは本当に有益ですか?


135

最近の最も一般的なセキュリティのベストプラクティスの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つの答えです。他の答えは、冗長または不正確です。


質問内で選択した回答をプラグインし、他のすべての回答を拒否する必要はありません。以下に示すように、人々に意味のある回答を投票するために、stackexchange投票システムが使用されますが、質問者は「受け入れられた回答」メカニズムと独自の上下票を使用する必要があります。
クズカイ14年

6
私はこれまでに尋ねた質問の99%についてはそうしていませんが、この特定のケースでは適切だと思いました。質問には8つの回答があります。そのうちのいくつかはかなり長く/複雑であり、一部は不正確な情報が含まれているか会話に何も追加していないにもかかわらず、多くの賛成票があります。スレッドを初めて読む人にとっては、半権威のある結論を提供することが役立つと思います。いつものように、読者は自分の意思を自由に決めることができます。私はOPとして自分の意見を述べているだけです。
イアンダン14年

1
@Kzqai:「スタック交換投票システム」は民主的なプロセスであり、参加者はしばしば1)OPが実際に何を求めているか、解決しようとしているか不明であり、2)特定の回答の妥当性を理解していません。回答が少しずつ寄せられ、票が投じられた後、支援を提供した回答をOPに明確にしてもらうことは非常に役立ちます。結局のところ、OPは知っている唯一の人であり、もっと多くのOPがそうすることを望んでいます。はい、人々は「人々に意味のある答えを投票します」が、OPに彼にとって意味のあるものについて最後の言葉を持たせましょう。
Mac

回答:


127

短い答え:はい

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


長い答え:実世界の例

私の非常に実際のサーバーから非常に実際の例を提供することを許可します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ルートの外側に移動します。


1
Apache、Linux、または管理者の頭脳にバグがある場合は、いずれにしてもトーストになります。シナリオでは、サーバー上の他の場所よりもWebサイトのルートで誤設定が発生する可能性が高い理由を説明できません。誤って設定apacheのは、おそらく/config.phpと同じように簡単にアクセスすることができます/../config.php
マーク・Kaplun

1
あなたは「いずれにしてもトースト」ではありません。バグが原因でWebルートがデフォルトにリセットされる可能性非常に高く実証できる場合もあります。この場合、「トースト」ではなく、wp-config.php安全です。そして、本質的に不可能なほど非常にありそうにないので、バグが原因で、Webルートがを配置した正確なディレクトリに任意にリセットされる可能性がありますwp-config.php
アーロンアダムス

1
@IanDunn実際にはwp-config.php、任意の場所に移動するのは簡単です。回答に指示を追加しました。wp-config.php実際の場所を参照するWordPressディレクトリにダミーを作成するだけです。
アーロンアダムス

3
この応答はスポットオンです。ウェブホスティング会社でドライブアレイに障害が発生しました。すべてが言われ、完了したら、システムを部分的に復元しました。一連のcPanel / WHMスクリプトを使用して、誤って実行したhttpd.confファイルを再構築したことが判明しました。幸いなことに、ドキュメントルートの外部にwp-config.phpが既にありましたが、もしなければコンテンツを取得するためにそこにいました。はい、まれですが、前述のように、まれなケースは心配する必要があるものです。また、「単純な心の人々は失われるだろう」と述べることは、LESSセキュリティを持つことの悪い言い訳です。
ランスクリーブランド

1
それは良い点です、アーロン。このコメントスレッドや他のコメントスレッドで言及した理由については、まだ少し懐疑的ですが、元々思っていた以上のメリットがあると確信しました。少なくとも、きちんと行われれば、それが何も傷つけるとは思わない。私はそれを宣伝するほとんどの人がその理由を理解していないようであり、それを教える方法はしばしばhttpdocsの上のディレクトリが公開されることにつながるという事実に問題がありますが、あなたはあなたの答え。
イアンダン

40

最大のものは、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ドキュメントのルートから抜け出すことは、あいまいさによるセキュリティの悪臭を放ちます-これは非常にストローマンです。


2
ええ、それは私がずっと考えてきたことです。私が唯一ではないことを知ってうれしいです:)誰かが説得力のある反論を持っている場合に備えて、質問をもう1日または2日開いておきたいと思いますが、これまでのところこれは正しい答えのようです私。
イアン・ダン

3
軽微な修正:wp-config.phpファイルをドキュメントルートから移動してもセキュリティ上の利点はありません。他にもセキュリティ関連ではなく、通常とは異なる設定にのみ適用される利点があります。
オットー

4
可能性のある神話を暴くために-それは不可能です、何かがサーバー側で間違っているかもしれません-その場合、PHPコードが画面に印刷されますか?
スティーブンハリス

3
@IanDunnしかし、最高の答えは、その階層から完全に別の階層に移動することを提唱するものであり、ログなどに関する懸念に対処します。他のセキュリティ対策は有益であり、セキュリティを心配しないように安心させようとします。誰もが彼らの家は強盗されるまで安全だと思います。その後、彼らはより良い仕事をします。一部の人々は、たとえセキュリティが低いとしても、決して強盗に遭うことはありませんが、セキュリティを低くすることは良いアドバイスではありません。
AndrewC

4
これらは良い点ですが、これらに関する私の最大の問題は、それらが予防的議論ではなく、治療的議論であることです。これらのほとんどは、A)誰かがdbユーザーを正しく処理したと仮定し、B)バックアップを持っているため、それが大したことではない方法について話します。woocommerceのようなものを使用している場合、またはデータベースに機密情報を保存している場合はどうなりますか?その後、あなたはめちゃくちゃです。
Goldentoa11 14年

25

マックスは知識のある答えだと思いますが、それは物語の片側です。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ディレクトリ内のファイルの既定のアクセス許可)を使用します。


5
マックスの答えです。彼に+1。私は単にそれを拡張しようとしています。
its_me

1
アーハン・クリシュ、あなたは雄牛の目を打った。追加していただきありがとうございます。
マックスユーディン

htaccessを使用してwp-config.phpへのHTTPリクエストを拒否する場合、ドキュメントルートの外部に移動するのと同じ結果が得られますが、logs / backups / etcを公開しませんか?
イアン・ダン

4
@IanDunnドキュメントルートが何であるかによって異なります— (1) wordpressがのディレクトリでホストされている場合、ディレクトリの外public_htmlに移動wp-config.phpすると、ディレクトリに移動しますpublic_html。この場合、htaccessルールを使用してwp-config.phpへのHTTPリクエストを拒否する必要があります。(2) WordPressがpublic_htmlディレクトリの下に直接インストールされている場合、1つ上のレベル=> /home/userディレクトリに移動します。この場合、ファイルはドキュメントルート外にあるため、非常に安全です。それでも、ファイルのアクセス許可を600(またはさらに厳しい440または400)に設定できます。
its_me

@IanDunn私が言ったように、これは私の基本的な理解であり、私はセキュリティの専門家ではありません。:)
its_me

17

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

はい、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

おかげで、


皆さん、ご意見をお寄せいただきありがとうございます。私たちは、他の回答とそれらのコメントのそれらのポイントのほとんどですでにヒットしていると思います。1)はい、これは可能ですが、まれです。2)はい、これには利点がありますが、最小限のものです。3)はい、これは可能ですが、そのタイプの脆弱性が再び発生する可能性は低く、それに対する保護は、モグラをプレイする、または空港で靴を脱ぐようなものです。一度靴。それは反動的であり、将来の利益を得る可能性は低い。
イアン・ダン

さまざまな議論の中で、質問は「利点はありますか?」から洗練されました。「OK、いくつかの利点がありますが、それらはリスクを上回っていますか?」私が言及している主なリスクは、PHPがWebルート外のスクリプトにアクセスできるようにするために、openbase_dirスコープを拡張する必要があるという事実です。多くのホスティング設定(Pleskを使用する設定を含む)は、Webルートより上のディレクトリに、ログ、バックアップ、Webルートから隔離されるはずのプライベートFTPエリアなどを保存します。そのため、PHPにそのディレクトリへのアクセスを許可すると、深刻な脆弱性になる可能性があります。
イアン・ダン

15

絶対そうです。

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

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


4
攻撃者がPHPハンドラを変更するのに十分なアクセス権を持っている場合、あなたはすでに台無しにされています。私の経験では偶発的な変更は非常にまれであり、その場合はパスワードを簡単に変更できます。これらのことを考慮して、open_basedirスコープが拡張されているため、ログ/バックアップ/などを公開するリスクに見合うだけの価値があるとまだ考えていますか?
イアン・ダン

1
私が持っていたことがありません-rwx高いよりも、ディレクトリへのアクセスをpublic_htmlので、私は精通していたことはありませんopen_basedir。私のログは別のディレクトリにあるので、バックアップもそうです。それがすべての共有ホストにあると思います。
マックスユーディン

ホストは大きく異なります。標準のディレクトリ構造はありません。Plesk(共有ホスト用の最も一般的なコントロールパネルの1つ)は、ログを/var/www/vhosts/example.com/statistics/logsに配置し、ドキュメントルートは/var/www/vhosts/example.com/httpdocsです。wp-config.phpを/var/www/vhosts/example.com/wp-config.phpに移動するには、スクリプトにexample.comディレクトリ全体へのアクセス権を付与する必要があります。
イアン・ダン

好奇心から、ログとバックアップはドメインのディレクトリにない場合、どこに保存されますか?コントロールパネルなどからアクセスしますか?
イアン・ダン

1
はい、コントロールパネルから。
マックスユーディン

8

引数のために、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

マイケル、それを共有してくれてありがとう。ただし、実際の環境で試して、機能することを確認しましたか?私が思うにopen_basedirディレクティブは全体の取り木にアクセスするためにので、/root/secureから/root/html、あなたが設定する必要があるだろうopen_basedir/root
イアン・ダン

あなたのアイデアの作品を作るために、私はあなたがセットアップディレクトリ構造等に必要と思う/root/httpdocs/config/accessiblehttpdocsなどのログを保持し、バックアップ、。WordPressとすべてのコンテンツを保持configwp-config.phpaccessible保持します。ドキュメントルートをに再マッピングするには、vhost configなどを変更する必要がありaccessibleます。ただし、デフォルトのセットアップでwp-configへのHTTPリクエストを拒否するだけの利点はありません。
イアン・ダン

1
php.net/manual/en/ini.core.php#ini.open-basedirによると、「Windowsでは、ディレクトリをセミコロンで区切ります。他のすべてのシステムでは、ディレクトリをコロンで区切ります。Apacheモジュールとして、親ディレクトリからのopen_basedirパスが自動的に継承されるようになりました。」そのため、複数のディレクトリを設定でき、それらを単一のツリーに配置する必要はありません。
マイケル

私はそれをテストしましたが、あなたは正しいようです。ただし、Apacheを介したファイルへのアクセスを単に拒否することで、これがどのようなセキュリティ上の利点をもたらすかはまだわかりません。
イアン・ダン

@IanDunnはアーロン・アダムスの答えにも対処
AndrewC

4

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を使ってフィールドデイを開催できます。システムにウイルスを喜んでインストールするのと同じです。wp-config.phpを移動しないというこの引数は無意味です。これは、車に車の爆弾を故意に設置すると、車のアラームを無用に設定することになると言っているようなものです。技術的には本当ですが、WTF?!?
ランスクリーブランド

2
いいえ、それは無意味ではありません。質問は次のとおりです。wp-config.phpを非表示にしてデータベースアカウントを保護できますか。答えは明らかです。いいえ。「車のアラームで車を爆弾から守ることはできますか?」と尋ねた場合と同じです。データベースアクセスまたはftpアクセスを保護することに関して、wp-configを隠すことによる他の利点はありません。両方ともグローバルスコープにあります。攻撃者がコードを挿入せずにグローバル変数にアクセスする方法は他にもあると確信しています。
Ralf912

元の質問に「wp-config.phpを非表示にしてデータベースアカウントを保護できますか」と表示されません。元の質問は「wp-config.phpを移動するのは理にかなっています」でした。答えは絶対にイエスです、IMO。外出時に玄関をロックするかどうかを尋ねるようなものです。「誰かが簡単に窓を破ってとにかく入ることができるので、なぜわざわざできる」と言うことは、質問の基本的なポイントに答えません。IMOは、「wp-config.phpを移動するのに余分な労力をかける価値はありますか?はい。少なくとも、怠zyなハッカーを排除します。
ランスクリーブランド

2
最も一般的なセキュリティのベストプラクティスの1つです。非常に(非常に)重要なポイントを見逃しました。攻撃者は何に興味がありますか?そして、wp-config.phpをどのようにスタイリングするかではありません。攻撃者は、wp-configで定義した値に関与しています。フロントドアで例をつかむ:wp-configを非表示にすることは、フロントドアをロックするのと同じですが、保護されていないすべての金を庭に保管します。wp-configで定義されているすべての値はグローバルに定義されています。したがって、それらはすべて wp-configの外部からアクセス可能です。wp-configを非表示にしても、値はまだ存在しています。
Ralf912

1
それを移動することを支持する人々は、ホストで実行されている他のPHPコードにさらされる可能性があるシナリオではなく、HTTPリクエストを介してプレーンテキストでwp-config.phpを表示できるシナリオから保護しようとしていると思います。
イアンダン

-1

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


8
彼は、ドキュメントルートの外ではなく、ドキュメントルートにセットアップしているため、この質問には関係ありません。質問で尋ねられた手法では、WordPressインストールフォルダーの1つ上のディレクトリだけでなく、vhostのドキュメントルートのwp-config.php 1つ上ディレクトリを移動することを指定しています。全体のポイントは、HTTPリクエストで読み取れるフォルダーの外に取得することです。
イアン・ダン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.