どこに配置するかPHPセキュリティのためにファイル？
簡単な質問ですが、PHPファイルをサーバーのどこに配置しますか？これに関する良い情報を見つけることができないようです。
公開ファイルはアクセスする必要があるため、どこか/どういうわけかドキュメントルートにあるはずですが、残りのファイルやすべてのクラスなどはどうでしょうか。
PHPバックエンドで単一ページのWebアプリをリファクタリングしようとしています。ほとんどのファイルはドキュメントルート内にありますが、ドキュメントルートの上に（パスワードなどの）機密ファイルがいくつかあります。フォルダーのレイアウトにつながる自動読み込みをセットアップしようとしていましたが、この分割レイアウトは非常に煩雑に感じられますが、もっと良い方法はありますか？
私の考えでは、最小限の特権の原則に従うべきだと思います。これらのファイルを公開する必要がない場合は、公開しないでください。なぜこれが PHPの正しい方法 の最初に正しくないのですか？
私はここでApacheを使用していますが、Nodeは、ルーターに向けない限りすべてが非公開であるという点で優れています。これを処理する標準的な方法はありますか？実装する方法それはアパッチで？
パブリックファイルをpublicというフォルダーに置き、Apache仮想ホストを使用してドメイン名をこのフォルダーにポイントします。他の非パブリックファイルはパブリックフォルダーの上にあるフォルダーにある必要があり、たとえばinclude_pathで参照できます。これがほとんどのフレームワークの構造です。
基本的にあなたは正しいです。あなたが所有するサーバーでは、実際にPHPファイルをドキュメントルートディレクトリに配置する必要はありません。 index.phpファイルや、書き換えルールの対象となるその他のファイルなどのエントリポイントのみが必要です。 Webサーバーが要求処理をPHPインタープリターにハンドホバーすると、Webサーバーの DocumentRoot パスに拘束されなくなり、PHPに拘束されます。 _インタープリターの open_basedir パス（デフォルトでは設定されていないため、PHPインタープリターはシステム上の任意の場所にあるファイルにアクセスできます）。
ただし、このようなシナリオには2つの前提条件が必要です。
- 自分のサーバーを所有しています：ほとんどの共有環境では、この種の実装には適さない可能性があるディレクトリ構造とシステム全体の設定が必要です。たとえば、影響を受けるDocumentRootの上のディレクトリにアクセスできない場合や、PHP構成にいくつかの制限が適用される場合があります。
使用するWebアプリケーションがサポートしています：これは、単に「 -application」。実際、ほとんどのプロジェクトは、可能な限り幅広いユーザーと互換性のある方法で開発されているため、必要な前提条件を最小限に抑えています。
したがって、ほとんどのプロジェクトでは、Webアプリケーション全体を単一のディレクトリに配置することを検討しています。これは展開と保守が簡単で（更新するディレクトリで、複数のフォルダー間の更新レベルの不一致のリスクがありません）、独自のサーバーを使用している場合でも、共有ホスティングスペースをレンタルしている場合でも、どのような状況にも適合します。
ただし、一部のプロジェクトでは、（ある種の
include_pathセットアップパラメータを使用して）オプションとして説明するセットアップを提案できますが、これにより、開発者の観点からプロジェクトの開発と保守が難しくなる可能性があります（主に認定テストについて考えます）これにより、考慮すべき状況が増えます）重大なセキュリティ上の利点はありません。
前述のように、適切に構成されたサーバーではPHPファイルのコンテンツはWebサーバーによって決して公開されないため、このような措置はセキュリティ上の大きなメリットをもたらすことはありません。このようなファイルはPHPによって実行されます_インタプリタ。生のテキストファイルとして送信されることはありません。主な脅威は、（たとえばPHP Shellをインストールすることによって）サーバー上でコードを実行して、ディレクトリツリーをさまよっていることですが、この場合はPHPファイルがあります。 DocumentRootディレクトリの外でも役に立ちません）。
最小特権の原則は依然として真実ですが、それは単にWebサーバー、PHPインタープリター、およびPHPスクリプトファイル自体が相互作用する方法に関係します。例えば：
- 一部の実装（たとえば、Nginx + PHP-FPMなどの古典的な例）では、WebサーバーとPHPインタープリターに異なるユーザーを使用でき、どのファイルとリソースを共有するかを自由に設定できますこれらのアカウントかどうか。
- また、PHPファイルがPHPインタープリターを実行しているユーザーのみが読み取りおよび書き込みできないようにすることもできます。 PHP Suhosin patch パラメータ（ suhosin.executor.include.allow_writable_files ）は、この基準に準拠していないPHPファイルの実行を防止します。
- PHPは、上記の open_basedir も提供します。これにより、PHPスクリプトが一部のディレクトリの外部にあるファイルにアクセスできなくなります。
- 等、その他：最小特権の原則を実装してWebアプリケーションプラットフォームを保護する方法は他にもたくさんあります。一般的なものもあれば、プラットフォームやアプリケーションに固有のものもあります。
セキュリティのためにPHPファイルをどこに配置しますか？
ファイルを安全に保管するのに最適な場所はないことに注意してください。機密ファイルの安全性は、重要なファイルを開示する可能性のあるURLインジェクションを防ぐなど、適切な対策を組み合わせた結果にすぎません。
私の考えでは、最小限の特権の原則に従うべきだと思います。これらのファイルを公開する必要がない場合は、公開するべきではありません。これがPHPの最初に正しくない理由は何ですか？
ファイアウォールが推奨されない理由についてあなたが尋ねることができる同じ質問。しかし、答えは、あなたが選んだ記事はむしろ開発者向けのものだからです。開発者は、安全にする方法よりも、それを機能させる方法を心配しています。その記事で説明されているセクションを見てください。
はじめに（一般的なセットアップ、PHPのバージョンを選択...）、コードスタイルガイド（プログラミングパラダイム、名前空間、標準PHPライブラリ、Xdebug ...）、依存関係管理、PEAR （インストールなど）、コーディング慣行、依存性注入（ソフトウェア設計パターン）、データベースとの対話、テンプレート作成...
ご想像のとおり、これはアプリケーションのセキュリティ面であなたのように心配している開発者向けではなく、開発者向けです。セキュリティについて少し話す唯一のセクションはセキュリティであり、その中にはパスワードハッシュ、データフィルタリング、サニタイズに関連するサブセクションしか含まれていない可能性がありますが、まだ十分にカバーされていません。
これを処理する標準的な方法はありますか？
あなたがリンクした記事は次のように述べています：PHPを使用する標準的な方法はありません。同じことが言えます：標準的な方法はありませんPHP安全です。これは、あなたが言及した最小限の特権の原則は必須であり、これらの原則をすべて組み合わせることだけでより良い保証を与えることができるため、従う必要がある優れた安全慣行があります：
多層防御 ：セキュリティの層の観点から問題を解決する必要があります：Apacheの安全なセットアップ、安全なコーディングスタイル、ファイアウォール、効果的な 。htaccess ファイル...この原則はアプリケーションに複雑さを追加し、新しいセキュリティリスクをもたらす可能性があると主張します。この原則のスマートアプリケーションは、アプリケーションをシンプルかつ安全に保つことができます（たとえば、フォルダーへのアクセスを許可するパスコードをハッシュすることは良いですが、ソルトする方が良いです。それらはさらに良いです）。
フォルダーとファイルを指定 ホワイトリスト ：アクセスしてはならないフォルダーとファイルを一覧表示する代わりに、公開ファイル/フォルダーへのアクセスを承認し、他のすべてを拒否する必要があります。いくつかの賢明なファイル。
- 最小権限 ：リソースのアクセス許可（この場合はファイルですが、他の要素を検討することもできます）は、Webサイトのユーザーに最低レベルで付与する必要があります
- ファイルを隠すために obscurityによるセキュリティ にそれほど依存しないでください。
- Webアプリケーションの 攻撃面 を最小限に抑える
- 信頼を検出 ：セキュリティ関連情報をログに記録してリスクを特定し、アプリケーションを保護します
- 評判の高いホスティング会社でアプリケーションを保護する要素として十分であると考える人もいますが、それでも、ホスティング環境とは別に独立してアプリケーションを保護する必要があります
- アプリケーションを保護するためにサードパーティのアクターのみに依存しないでください