フレームワーク ファイルをパブリック ルートの外に配置することが常に推奨されるのはなぜですか?
フレームワークには、ブラウザで開くことができるファイルがない.ini
場合があります。.inc
フレームワーク ファイルをパブリック ルートの外に配置することが常に推奨されるのはなぜですか?
フレームワークには、ブラウザで開くことができるファイルがない.ini
場合があります。.inc
ええと、 Webルート内にフレームワークソースを配置することから得られるものは間違いなくありません。したがって、ファイルを配置する場所の選択は自由であるため、最小特権の原則を採用するのが論理的です。これらのファイルへのWebアクセスは必要ないため、取得できません。
より具体的な理由は、フレームワークのソースがWebサイトで使用されているフレームワークのブランドとバージョンを簡単に開示できることです(ただし、この情報は通常、生成されたコンテンツを調べることによっても取得できます)。これにより、悪意のあるユーザーが既知または新たに発見された脆弱性を悪用しやすくなります。
Web サーバーに設定ミスがあると、スクリプト ファイル (.php、.asp など) がプレーン テキストで吐き出され、潜在的な攻撃者がすべてのソース コードと定義されたパスワードを見る可能性があるため、これはより安全です。したがって、ベスト プラクティスは、index.php ファイルのみを webroot に配置することです。これには、webroot の外部からのブートストラップ スクリプトが含まれます。
私が住んでいるラトビアには、大規模なソーシャル ネットワーク "draugiem.lv" (私たちの国では Facebook よりも人気があります) があり、数年前にすべての PHP ソース コードが不適切な構成のサーバーによって漏洩したことを覚えています。ついさっき。
他の回答で引用されている標準的な理由 (サーバーの構成ミス、最小権限の原則など) に加えて、Zend Framework を含む多くのフレームワークが、PHP 以外の形式の構成ファイルを使用できることに注意してください。.ini
、.yml
など
これらがパブリックにアクセス可能な Web ルートにある場合、サーバーの構成に応じて、それらを要求した人に直接提供されます。これらの構成ファイルには通常、db パスワード、API キーなどの機密情報が含まれているため、可能な限りアクセスできないようにすることが望ましいのは確かです。
例として、 を考えてみましょうapplication/configs/application.ini
。ドキュメント ルートがプロジェクト フォルダー レベルにある場合は、次の要求があります。
http://example.com/application/configs/application.ini
城の鍵を届けます。