オープンソースのアプリで詳細な例外ページを無効にすることの用途は何ですか？
Webアプリのフレームワークは通常、productionモードまたはdevelopmentモードのいずれかで実行できます。 2つのモードの主な違いの1つは、例外の処理方法です。開発モードでは、ブラウザーは通常、スタックトレースとともに詳細な例外情報を送信されますが、productionモードは、より詳細な情報がない一般的な（カスタマイズ可能ですが）エラーページのみを提供します。
フレームワークのドキュメントでは、通常、このため、本番環境で開発モードを使用しないよう警告します。 これは.NET Coreの例です：
警告アプリが開発環境で実行されている場合にのみ、開発者例外ページを有効にします。アプリが本番環境で実行されているときに、詳細な例外情報を公開しないでください。
そして、これは Django docs からの同様の警告です：
DEBUGをオンにしてサイトを運用環境に展開しないでください。デバッグモードの主な機能の1つは、詳細なエラーページの表示です。
DEBUGがTrueであるときにアプリで例外が発生した場合、Djangoは、すべての環境など、環境に関する多くのメタデータを含む詳細なトレースバックを表示します現在定義されているDjango設定（settings.pyから）。
前述のセキュリティ対策の背後にある理由を理解できていませんか？
私が理解している場合、推論は次のようになります。詳細なエラーページは、潜在的な攻撃者がアプリのソースコードに関する詳細を発見できるようにする=弱点を見つける可能性=悪い。 あいまいさによるセキュリティの定義ではありませんか？
さらに、アプリがオープンソースである場合、そのような手段の使用は何ですか？詳細な例外ページを無効にすると、攻撃者はソースコードの詳細を見つけることができなくなるはずですが、これらは-設計による-パブリックGitHubリポジトリに存在します。この場合、私はアプリを開発モードで実行することもできます。少なくとも、ユーザーが予期しないバグを発見した場合、このバグを修正するのに役立つ詳細な情報を提供できると思いますか？
上記で引用したドキュメントの警告の背後にある理由が正しければ、オープンソースのウェブアプリの開発自体がセキュリティの脆弱性であることを意味します！攻撃者がソースコードをいくつかの詳細を見つけることを許可する場合、それは非常に大きな問題であるため、興味のある人にソースコードを単純に渡すことはさらに悪いことです。それでも、AFAIKのオープンソースは、無効で本質的に安全でないモデルとは見なされていません。
ここで何が欠けていますか？詳細な例外ページを無効にする必要があるのはなぜですか？
より良い攻撃を仕掛けるために使用できる攻撃者に実装の詳細を明らかにする可能性があります。不適切なエラー処理に関するO WASPページからの引用 ：
エラーメッセージで詳細が十分に説明されていない場合でも、そのようなメッセージの不整合は、サイトの動作方法や隠されている情報に関する重要な手がかりを明らかにする可能性があります。たとえば、ユーザーが存在しないファイルにアクセスしようとすると、通常、エラーメッセージに「ファイルが見つかりません」と表示されます。ユーザーが許可されていないファイルにアクセスする場合、「アクセス拒否」を示します。ユーザーはファイルが存在することさえ知らないはずですが、このような不整合があると、アクセスできないファイルの有無やサイトのディレクトリ構造がすぐにわかります。
デバッグモードを有効にする際に考慮すべき点がいくつかあります。
情報漏えい：フレームワークのバージョン番号、構成値、APIキー。 Djangoは、例外ページから機密に見える設定値を取り除くための基本的な保護を備えていますが、この機能に依存するべきではありません。
メモリリーク：一部のフレームワークは、拡張デバッグ情報をメモリに保持して、リクエストの事後分析を可能にします。これにより、本質的にメモリリークが発生し、攻撃者がWebアプリケーションをクラッシュさせる可能性があります。例 Django ORMは、DEBUG = Trueの場合に接続で行われたすべてのSQLクエリを保存します 。
リモートコード実行：一部のデバッグフレームワークでは、サーバーサイドコードを実行して、例外後にスタック内のオブジェクトをイントロスペクトできます。たとえば、 Werkzeug Debugger です。
パフォーマンス：これらのデバッグ情報を収集すると、パフォーマンスが大幅に低下する可能性があります。プロダクションモードで1秒未満で実行されるいくつかのDjangoビューがあり、Django-debug-toolbarでSQLロギングとDEBUGモードをオンにすると、1分近くかかります。
これらすべてに共通のスレッドがあります。つまり、デバッグ指向の機能は通常、セキュリティが実際には問題にならないlocalhost環境で使用するように設計されています。
あなたが引用した1つの例を取るために、currently defined Django settingsは、サイトに設定した値を意味します。これらの設定が存在するという事実は秘密ではありません。それらに与えた値（ 管理者のリスト など）は、.
私はあなたの誤解がこの推論にあると思います：
詳細なエラーページにより、潜在的な攻撃者がアプリのソースコードに関する詳細を発見する可能性があります
実際の問題は、詳細なエラーページにより、潜在的な攻撃者がアプリの現在の構成に関する詳細を発見できるようになることです。
別の問題は、攻撃者がアプリのソースコードに関する詳細をどのように見つけるかです（たとえば、どのアプリがそのアプリのどのバージョンを実行しているか、たとえば、より脆弱なバージョンが使用されているかどうかを確認するなど）。そして、はい、詳細なエラーページが役立ちますが、それを行う他の方法もあります。
また、ソフトウェア（つまり、クローズドソースソフトウェア）のソースコードを非表示にすること自体が「あいまいさによるセキュリティ」であることに注意します。
機密情報や有用なヒントを攻撃者に開示しないようにすることは、そうすることをお勧めします。デバッグ情報を他の人に表示することは実際には脆弱性ではありませんが、いずれにしても脆弱性と見なすことができます。つまり、デバッグ情報は攻撃者にとって興味深いものを表示する場合と表示しない場合がありますが、安全に再生するには無効にすることをお勧めします。デバッグ情報がneverを表示することを本当に100％確信していますか？答えは「本当に100％ではない」に違いないので、オフにした方がいいでしょう。
これが私が作成した非常に単純な例です：
WARNING: $accounts is not numeric, $accounts is an array;
$accounts = ([email protected], [email protected], ...)
なんらかの理由で、そのようなエラーが表示されたとします。エラー：ユーザーのアカウントが漏洩します。もちろん、フレームワークXが変数の内容をダンプしないこと、フレームワークYがそのようなバグを持つことができないこと、そのような間違いを犯すことは決してないことなど不可能だと言うかもしれません。一般的にあなたに決して起こらないのですか？安全にプレイしてオフにしてください。簡単で費用もかかりません。