wp-configでFS_METHODを「direct」に設定する場合、どのようなセキュリティ上の懸念がありますか？

手動インストールまたはワンクリックインストールオプションがないため、WP Smush Proプラグインをインストールできないという問題が最近発生しました。

私はこの投稿に出会い、設定を微調整することを提案しましたwp-config.php。推奨される設定を追加しましたが、最も重要と思われる設定は次のとおりです。

define('FS_METHOD', 'direct');

私が知りたいのは、私が設定FS_METHODすることに関して実際に懸念するべきことは何directですか？プラグインをインストールする他の方法はありますか？

これは公式文書が述べていることです：

FS_METHODは、ファイルシステム方式を強制します。「direct」、「ssh2」、「ftpext」、または「ftpsockets」のみにしてください。通常、更新の問題が発生している場合にのみ、これを変更する必要があります。変更しても解決しない場合は、元に戻す/削除します。ほとんどの状況では、自動的に選択された方法が機能しない場合、「ftpsockets」に設定すると機能します。

（プライマリ設定）「direct」は、PHP内からDirect File I / Oリクエストを使用するように強制します。これは、適切に構成されていないホストでセキュリティの問題を引き起こすことにつながります。

これが、WordPress File APIのアイデアを理解した方法です。それが間違っている場合は、投票してください:)

はい。ファイルをアップロードする場合、このファイルには所有者がいます。FTPでファイルをアップロードする場合、ログインすると、ファイルはFTPユーザーが所有します。資格情報があるため、FTPを介してこれらのファイルを変更できます。所有者は通常、ファイルを実行、削除、変更などできます。もちろん、ファイルのパーミッションを変更することでこれを変更できます。

PHPを使用してファイルをアップロードする場合、PHPを実行しているLinuxユーザーがファイルを所有しています。このユーザーは、ファイルを編集、削除、実行などできるようになりました。これは、システムでPHPを実行しているユーザーだけがあなたである限り問題ありません。

「設定が不十分な」共有ホストにいると仮定しましょう。多くの人がこのシステムでPHP Webサイトを実行しています。これらすべての人々のためにPHPを実行しているLinuxユーザーは1人だけだとしましょう。この共有ホスト上のWebマスターの1人に悪意があります。彼はあなたのページを見、あなたのWordPressインストールへの道を見つけます。たとえば、WP_DEBUGはtrueに設定されており、次のようなエラーメッセージがあります。

[warning] /var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php on line 1

「ハ！」悪い男の子は言います。この男がに設定FS_METHODしdirectていて、次のようなスクリプトを書いたら

<?php
unlink( '/var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php' );
?>

PHPを実行しているユーザーは1人だけであり、このユーザーは悪意のあるユーザーによっても使用されているため、PHP経由でアップロードした場合、システム上のファイルを変更/削除/実行できます。

あなたのサイトはハッキングされています。

または、コーデックスにあるように：

多くのホスティングシステムでは、WebサーバーがWordPressファイルの所有者とは異なるユーザーとして実行されています。この場合、ウェブサーバーユーザーからファイルを書き込むプロセスは、実際のユーザーのアカウントではなく、ウェブサーバーのユーザーアカウントが所有する結果ファイルを作成します。これにより、複数のユーザーが異なるサイトで同じWebサーバーを共有している共有ホスティングの状況で、セキュリティの問題が発生する可能性があります。

リスクは何ですか？

構成が不十分な共有ホストでは、すべての顧客のPHPが同じユーザーとして実行されます（apache議論のために言いましょう）。このセットアップは驚くほど一般的です。

このようなホスト上で、WordPressを使用して直接ファイルアクセスを使用してプラグインをインストールする場合、すべてのプラグインファイルはに属しますapache。同じサーバー上の正当なユーザーは、プラグインファイルに悪意のあるコードを挿入するPHPスクリプトを作成することで、あなたを攻撃することができます。彼らは自分のウェブサイトにスクリプトをアップロードし、そのURLをリクエストします。apacheプラグインは、プラグインファイルを所有しているのと同じスクリプトとして実行されるため、コードは正常に侵害されます。

何んFS_METHOD 'direct'それを行う必要がありますか？

WordPressがファイル（プラグインなど）をインストールする必要がある場合、get_filesystem_method（）関数を使用してファイルシステムにアクセスする方法を決定します。定義しない場合FS_METHODはデフォルトが選択されますが、そうでない場合は、意味がある限り選択が使用されます。

デフォルトの動作では、上記のような危険な環境にあるかどうかを検出しようとし、安全であると思われる場合は'direct'メソッドを使用します。この場合、WordPressはファイルをPHP経由で直接作成し、apacheユーザーに属します（この例では）。そうでない場合は、SFTP資格情報の入力を求めたり、ファイルを作成したりするなど、より安全な方法にフォールバックします。

FS_METHOD = 'direct'WordPressにリスクのある検出をバイパスし、常に'direct'メソッドを使用してファイルを作成するように要求します。

次に、なぜ使用しFS_METHOD = 'direct'ますか？

残念ながら、リスクのある環境を検出するためのWordPressのロジックには欠陥があり、偽陽性と偽陰性の両方を生成します。おっと。このテストでは、ファイルを作成し、そのファイルが存在するディレクトリと同じ所有者に属していることを確認します。ユーザーが同じ場合、PHPは自分のアカウントとして実行され、プラグインをそのアカウントとして安全にインストールできると仮定しています。それらが異なる場合、WordPressはPHPが共有アカウントとして実行されていると想定し、そのアカウントとしてプラグインをインストールすることは安全ではありません。残念なことに、これらの仮定はどちらも教育的な推測であり、しばしば間違っています。

次のdefine('FS_METHOD', 'direct' );ような誤検知シナリオで使用します。あなたは、信頼できるチームの一員であり、メンバー全員が自分のアカウントを介してファイルをアップロードします。PHPは、独自の別個のユーザーとして実行されます。WordPressは、これがリスクのある環境であると想定し、デフォルトでは'direct'モードになりません。実際には、信頼できるユーザーとのみ共有され、そのような'direct'モードは安全です。この場合、define('FS_METHOD', 'direct' );WordPressにファイルを直接書き込むように強制するために使用する必要があります。

「直接」が問題につながる「適切に構成された」状況があります。

ファイル/ディレクトリ所有者ユーザーとは異なる、非共有PHP実行ユーザーで共有WPホスティングを構成することもできます。したがって、user1が所有するファイルになり、PHPコードはphp-user1として実行されます。

そのような状況では、ハッキングされたプラグインまたはコアコード（a）は、他のユーザーのディレクトリに書き込むことはできません（権限に応じて、読み取ることさえできません）。（b）このユーザーのファイルを書き込むことができないため、トロイの木馬コードをコアまたはプラグインコードに追加できません。

そのため、ホスティングがそのように設定されている場合、更新にFTPを使用する必要があり、「直接」は機能しません。

wp-config.phpで「direct」を設定し、PHP実行ユーザーに書き込み権限がない場合、Update Failedメッセージが表示され、FTP資格情報を要求するポップアップは表示されません。