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

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

define("FS_METHOD", "direct");

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

これは公式ドキュメントの内容です：

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

（プライマリプリファレンス）「direct」は、PHP内からのダイレクトファイルI / Oリクエストを使用するように強制します。構成が不十分なホストでセキュリティの問題が発生する可能性があります。これは、必要に応じて自動的に選択されます。

回答

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

わかりました。ファイルをアップロードする場合、このファイルには所有者がいます。 FTPを使用してファイルをアップロードする場合は、ログインすると、ファイルはFTPユーザーによって所有されます。資格情報を持っているので、FTPを介してこれらのファイルを変更できます。所有者は通常、ファイルの実行、削除、変更などを行うことができます。もちろん、これはファイルのアクセス許可を変更することで変更できます。

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

「不適切に」構成された共有ホストを使用していると仮定します。多くの人がこのシステムでPHPWebサイトを運営しています。これらすべての人々のために1人のLinuxユーザーだけがPHPを実行しているとしましょう。この共有ホストのウェブマスターの1人が悪意を持っています。彼はあなたのページを見て、あなたのWordPressインストールへの道を見つけます。たとえば、WP_DEBUGがtrueに設定されていて、

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

“Ha！”のようなエラーメッセージが表示されます。悪い子は言います。この男がFS_METHODをdirectに設定し、

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

サイトがハッキングされています。

または、コーデックスに記載されているように：

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

回答

リスクは何ですか？

構成が不十分な共有ホストでは、すべての顧客のPHPが同じユーザーとして実行されます（たとえば、apacheで説明します）。この設定は驚くほど一般的です。

このようなホストを使用していて、WordPressを使用して直接ファイルアクセスを使用してプラグインをインストールする場合は、すべてプラグインファイルはapacheに属します。同じサーバー上の正当なユーザーは、プラグインファイルに悪意のあるコードを挿入するPHPスクリプトを作成することで、あなたを攻撃する可能性があります。スクリプトを自分のWebサイトにアップロードし、その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にファイルを直接書き込むように強制する必要があります。

コメント

  • ありがとうございますあなた@マーク、それはとても役に立ちました！ get_filesystem_method()リンクを次のリンクに更新する必要がある場合があります： developer.wordpress.org/reference/functions/ …

回答

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

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

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

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

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

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です