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サイトをこのシステムで運営しています。一人のlinuxユーザだけがこれらすべての人々のためにPHPを実行しているとしましょう。この共有ホスト上のウェブマスターの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' );
?>
1人のユーザーだけがPHPを実行しており、このユーザーはPHP経由でアップロードした場合、システム上のファイルを変更/削除/実行することができますこれにより、PHPユーザーが所有者として添付されました。
あなたのサイトはハッキングされています。
あるいは、コーデックスに書かれているように、
多くのホスティングシステムでは、WebサーバーがWordPressファイルの所有者とは異なるユーザーとして実行されています。この場合、Webサーバーユーザーからファイルを書き込むプロセスは、実際のユーザーのアカウントではなく、Webサーバーのユーザーアカウントによって所有されるファイルを作成します。これは、複数のユーザーが異なるサイトで同じWebサーバーを共有している共有ホスティングの状況でセキュリティ上の問題につながる可能性があります。
リスクは何ですか？
設定が不適切な共有ホストでは、すべての顧客のPHPが同じユーザーとして実行されます（議論のためにApacheとしましょう）。この設定は驚くほど一般的です。
あなたがそのようなホストにいて、直接ファイルアクセスを使ってプラグインをインストールするためにWordPressを使うならば、あなたのプラグインファイルのすべてはApacheに属します。あなたのプラグインファイルに悪意のあるコードを注入するPHPスクリプトを書くことによって、同じサーバー上の正当なユーザーがあなたを攻撃することができるでしょう。彼らは自分のウェブサイトに自分のスクリプトをアップロードし、そのURLを要求します。自分のプラグインファイルを所有しているのと同じApacheとしてスクリプトが実行されるため、コードは危険にさらされています。
FS_METHOD 'direct'はそれとどんな関係がありますか？
WordPressがファイル（プラグインなど）をインストールする必要があるときは、 get_filesystem_method（） 関数を使用してファイルシステムへのアクセス方法を決定します。あなたがFS_METHODを定義しないなら、それはあなたのためにデフォルトを選びます、さもなければそれは意味がある限りあなたの選択を使います。
デフォルトの振る舞いは try になり、上記のような危険にさらされている環境にいるかどうかを検出し、安全だと思われる場合は'direct'メソッドを使用します。この場合WordPressはPHPを通して直接ファイルを作成し、それらをApacheユーザーに所属させます（この例では）。それ以外の場合は、SFTP資格情報の入力を求めるプロンプトや自分でファイルを作成するなど、より安全な方法にフォールバックします。
FS_METHOD = 'direct'は、危険にさらされていることの検出を回避し、'direct'メソッドを使用してファイルを作成するようにalwaysにWordPressに要求します。
それならなぜFS_METHOD = 'direct'を使うのですか？
残念ながら、危険な環境を検出するためのWordPressのロジックには欠陥があり、誤検知と誤検知の両方が発生します。おっとこのテストでは、ファイルを作成し、それが存在するディレクトリと同じ所有者に属していることを確認します。ユーザーが同じであれば、PHPは自分のアカウントとして実行され、安全です。そのアカウントとしてプラグインをインストールします。異なる場合、WordPressはPHPが共有アカウントとして実行されていると見なします。そのアカウントとしてプラグインをインストールするのは安全ではありません。残念なことに、これらの仮定の両方は、しばしば間違っているであろう教育的な推測です。
このような誤検知のシナリオではdefine('FS_METHOD', 'direct' );を使用します。あなたはメンバー全員が自分のアカウントを通してファイルをアップロードする信頼できるチームの一員です。 PHPは、独自の独立したユーザーとして実行されます。 WordPressはこれが危険な環境であると想定し、デフォルトで'direct'モードにしません。実際には、信頼しているユーザーとのみ共有されているので、'direct'モードは安全です。この場合、WordPressに直接ファイルを書き込ませるためにはdefine('FS_METHOD', 'direct' );を使うべきです。
「直接」が問題につながる「よく構成された」状況があります。
ファイル/ディレクトリ所有権のユーザーとは異なり、共有WPホスティングを非共有PHP実行ユーザーで構成することも可能です。そのため、user1が所有するファイルが作成され、PHPコードはphp-user1として実行されます。
このような状況では、ハッキングされたプラグインやコアコード（a）が他のユーザーのディレクトリに書き込むことはできません（あるいは許可によっては読み取ることさえできません）。 （b） this ユーザーのファイルを書くことができないので、コアやプラグインのコードにトロイの木馬のコードを追加することはできません。
そのため、ホスティングがそのように設定されている場合は、更新にFTPを使用する必要があり、 'direct'は機能しません。
Wp-config.phpで 'direct'を設定し、PHP実行ユーザーが書き込み権限を持っていない場合、Update Failedメッセージが表示され、FTP認証情報を尋ねるポップアップは表示されません。