パーミッションに関してミニマリズムに従うべき一般的な理由はたくさんありますが、LAMP ウェブホストのコンテキストでは、すぐに思い浮かぶ理由はいくつかあります
- 共有ホスティング プラットフォームで、ホストを共有している他のユーザーがスクリプトを読み書きできるようになりました。
- 専用ホストでは、不正なプロセスがファイルの読み取り/書き込みを行ったり、誤ってファイルを削除したりする可能性があります。バックグラウンドでユーザー nobody として実行されているカスタム ロギング プロセスがあり、その結果
rm -rf /しようとするバグがあるとします。 .誰も書き込み権限を持つべきではないファイルはほとんどないため、一般的にこれは無害ですが、この不正なプロセスはあなたのファイルを一緒に持っていきます. - あなたのウェブサイトを改ざんするには、誰かが
nobodyとさえ言っても、任意のユーザーとしてアクセスするだけで済みます またはそのようなダミーアカウント。通常、攻撃者はさらにユーザー レベルのエスカレーション攻撃を実行して、何らかの損害を与えることができる場所にたどり着く必要があります。これは本当の脅威です。一部の重要でないサービスがダミー アカウントで実行されている可能性があり、脆弱性が含まれている可能性があります。
1 つのアカウントに侵入するだけでよいため、悪意のあるアクティビティに対する Web サイトの脆弱性プロファイルが大幅に増加します。
任意のログインでシステムにアクセスできる人は、「このウェブサイトは本当に安全でないので、クレジット カード情報を教えてください」と読むようにページを変更するなど、ページに対して何をしても構いません。
編集:(コメントを明確にして対処するため)
多くのサーバーには、人生において複数の目的があります。彼らは複数のサービスを実行しています。それぞれに一意のユーザーを割り当て、それに応じてファイルのアクセス許可を管理することにより、これらのサービスを互いに慎重に分離すると、はい、誰かがアカウントの資格情報を侵害した場合でも、問題は解決されませんが、彼らが与えることができる損害はその 1 つのサービスに限定されます。 .汎用アカウントが 1 つだけあり、ファイル システム全体を 777 に設定すると、1 つのアカウントが侵害されてマシン上のすべてが危険にさらされます。
サーバーが Apache/PHP の実行のみに専念しており、人生で他の目的を果たさず、Apache/PHP が実行されているアカウントが 1 つしかない場合、その 1 つのアカウントが侵害されることは、マシン全体が侵害されたのと同じくらい良いことです。アプリケーションの観点から (システム ファイルは引き続き保護され、PHP の実行に使用されるアカウントによって書き込み不可である必要がありますが、管理者アカウント/ルートに対してのみ可能である必要があります)。
ファイルを書き込むことができ、それが実行可能である場合、マシン上で実行されるもの (実行可能ファイルまたはスクリプト) に変更し、PHP の shell_exec を使用してその実行可能ファイルを実行できます。 shell_exec を許可しないように構成されている場合は、構成も変更される可能性があります
1 つのシナリオを次に示します。
<オール>system() を持つ php ファイルの 2 つのファイルをアップロードします。 それをシェル スクリプトに呼び出します。このディレクトリが 777 の場合、誰でも (php スクリプトが実行されるユーザー apache を含む) 実行できることを意味します。そのディレクトリとおそらくディレクトリ内のファイルに実行ビットが設定されていない場合、上記のステップ 3 は何もしません。
コメントから編集:重要なのは PHP ファイルのパーミッションではなく、 system() です Linux ユーザー apache (または apache を実行するように設定したもの) によって Linux システム コールとして実行される PHP ファイル内の呼び出しであり、実行ビットが重要な場所です。