ユーザーに表示されるエラーメッセージにスタックトレースを含める必要がありますか？
私は職場で少し議論をしていて、誰が正しいのか、何をするのが正しいのかを理解しようとしています。
コンテキスト：お客様が会計やその他のERPものに使用するイントラネットWebアプリケーション。
ユーザーに（エラーが発生したときに）表示されるエラーメッセージには、スタックトレースを含め、できるだけ多くの情報が含まれているべきだと思います。もちろん、ニースの「エラーが発生しました。以下の情報を開発者に送信してください」から始めてください。
おそらく、クラッシュしたアプリケーションのスクリーンショットが、簡単に入手できる唯一の情報源になることが多いと思います。確かに、クライアントのシステム管理者を把握したり、ログファイルの場所を説明したりすることはできますが、これはおそらく遅く、痛みを伴います（クライアントの担当者との会話はほとんどです）。
また、すべての例外で必要なものを見つけるためにログファイルを探し回る必要がない開発において、即時かつ完全な情報を持つことは非常に役立ちます。 （しかし、それは構成スイッチで解決できます。）
残念ながら、ある種の「セキュリティ監査」があり（ソースなしでどのようにそれを行ったかはわかりませんが...何でも）、彼らはセキュリティの脅威としてそれらを引用する完全な例外メッセージについて不満を述べました。当然、クライアント（少なくとも私が知っている1つ）はこれを額面どおりに受け止め、メッセージのクリーンアップを要求します。
潜在的な攻撃者がスタックトレースを使用して、以前は把握できなかったことを把握する方法を確認できませんでした。何か例はありますか？私はこの愚かな考えと戦うべきだと思いますが、おそらく私はここで愚か者なので、...
誰が正しいのですか？
私はDBまたはファイルのいずれかでアプリケーションログを作成し、そのようなすべての情報をログに記録する傾向があります。その後、エラーに関連するログ項目を識別するエラー番号をユーザーに与えることができるため、エラーを取り戻すことができます。このパターンは、ユーザーがあなたと一緒にエラーを発生させなくてもエラーを追跡できるため、問題がどこにあるかをよりよく理解できるので便利です。
サイトがクライアントの環境にインストールされていて、アクセスできない場合は、オンサイトのIT部門に連絡して、エラー番号に基づいて抽出を送信できます。
考えられるもう1つのことは、システムがエラーの詳細をメールボックスにメールで送信することです。これにより、問題がいつ発生するかを知ることができます。
基本的に、何かが正しくないときに根性を漏らすシステムがあっても、技術者以外のユーザーに自信を与えることはできません-何かが非常に間違っていると思うように怖がらせる傾向があります（たとえば、BSODのどの程度を理解し、どのように行うかあなたは誰かが現れたときに感じます）？
スタックトレース：
.Netでは、スタックトレースは完全なトレースをコアのMSソースアセンブリに表示し、使用しているテクノロジの詳細と可能なバージョンも明らかにします。これは、侵入者に悪用される可能性のある弱点に関する貴重な情報を提供します。
はい、たくさんあります。
スタックトレースは明らかにすることができます
- 使用する暗号化アルゴリズム
- アプリケーションサーバー上の既存のパスとは
- 入力を適切にサニタイズしているかどうか
- オブジェクトが内部でどのように参照されるか
- フロントエンドの背後にあるデータベースのバージョンとブランド
...リストはどんどん続きます。基本的に、大規模なアプリケーションでのすべての設計決定mightはセキュリティに関連するものであり、それらのほとんどすべてがメソッド名またはモジュール名によって提供されます。心に留めておいてください。送信された環境が安全である場合（たとえば、インターネットに接続するWebサイトではなくイントラネット）にスタックトレースを表示しても意味がないというわけではありませんが、セキュリティのコストは間違いなくゼロではありません。 。
ことは、自分で物事を簡単にすることは私たちの主な仕事ではありません。エンドユーザーにとって使いやすいものにすることが私たちの仕事です。私たちにとって、スタックトレースは、開発者に提供する非常に有用な情報のように見えます。ユーザーにとっては、まったく意味のない意味不明なもののように見えます。他の方法で伝えても内面化されません。システム管理者からその情報を取得するのが難しいと思う場合は、エンドユーザーから情報を取得することはさらに悪いことです。
セキュリティに関する限り、それがデスクトップアプリケーションである場合は、ポイントがあるかもしれません。その場合、スタックトレースを出力しても、攻撃者が知らないことは何もありません。 Webアプリでは、攻撃者はその情報をまだ入手できません。あなたは確かに攻撃をlotにする内部の詳細を明らかにしています。
両方の懸念ソースをバイパスして、例外レポートを自動的に送信してみませんか？そうすれば、人々がエラーを報告しないことについて心配する必要さえありません。
IT Security SEのこの質問 を見てください。つまり、スタックトレースは、攻撃者が処理するためのより多くの情報を提供する可能性があります。攻撃者が持つ情報が多いほど、攻撃者がシステムに侵入する可能性が高くなります。スタックトレースが常に非表示になっているという事実に基づいてセキュリティを設定することはしませんが、その情報を攻撃者に提供する必要があるという意味でもありません。
とにかく、適切なバックエンドロギングからほとんどの利点を得ることができます。これはやや便利ではありませんが、システムの安全性を危険にさらしたり、顧客を混乱させたりする価値はないでしょう。
次の理由により、スタックトレースを表示しないことを検討する場合があります。
安全保障
スタックトレースを表示すると、ハッカーである可能性のある攻撃面が明らかになります。イントラネットはハッキングの影響を受けません。あなたが責任を負うアプリケーションのためにネットワークがハッキングされた場合、それはあなたに悪影響を及ぼすでしょう
ユーザー体験
ユーザーの最良のエクスペリエンスのために、追跡トレースは情報が多すぎます。はい、エラー状態に関する適切な情報を記録し、エンジニアが注意を払う必要があります。ただし、自動化できることを実行するようにユーザーに要求することは、ユーザーにとって最善ではありません。
あなたの評判
スタックトレースがWebサイトに表示される場合は常に、見た目が悪いです。ほとんどの人はそれが何であるかについて何も知らないので、彼らはウェブサイトが彼らに友好的ではないように感じさせます。それが何であるかを知っている人にとっては、それはアプリケーションがよく考えられていなかったことを示しているかもしれません。 ASP.Netなどの一部のフレームワークではスタックトレースがデフォルトであるため、不適切に記述された多くのアプリケーションではスタックトレースが頻繁に表示されます。
短い回答：エクストラネットまたはインターネットサイトでは、スタックトレースを表示しない方が賢明です。イントラネットでは、スタックトレースを表示することの利点は、それを非表示にすることの利点を上回ります。
長い答え：
職場でも同じことが起こりました。以前は、アプリが失敗すると、騒々しく失敗するはずだと思っていました。
しかし、彼らは私に、潜在的なハッカーがスタックトレースから多くのことを推測できることを説明しました。
証明は必要ないと思います。 ハッカーがあなたのプラットフォームについて知っているほど彼にとって良いであり、ハッカーがあなたのプラットフォームについて知っているほどあなたにとって良いであることは明らかです。
また、企業はハッカーがどのようにしてシステムに侵入したかを明らかにすることを熱望していません。
一方、それはイントラネットです、そして私は何が問題があったかを即座に知ることの利点ログファイルを検索しなければならないことは大きな利点であり、セキュリティ上のリスクがあると思います会社の境界内にスタックトレースを表示することは、彼らが言っているほど高くはありません。
配信された製品では、このタイプのエラーの予想される数はゼロでなければなりません。 customerに対するこの情報の有用性はゼロです。どちらの場合も、スタックトレースを表示する理由はありません。有用なコンテキストがある場合は、スタックトレースとしてではなく、わかりやすい方法で提示する必要があります。
一方、実際の発生数がゼロでない場合は、この情報が必要であり、顧客に頼って送信してはなりません。彼らの時間の99.99％はそうしません。顧客からの "ok"のみで情報を自動的に送信するバグ再ポイントシステムをインストールする必要があります。