スタックトレースは、ユーザーに表示されるエラーメッセージに含める必要がありますか？

私は職場で少し議論があり、誰が正しいのか、何が正しいのかを理解しようとしています。

コンテキスト：顧客が会計やその他のERPに使用するイントラネットWebアプリケーション。

（物事がクラッシュした場合）ユーザーに表示されるエラーメッセージには、スタックトレースなど、できるだけ多くの情報を含めるべきだと思います。もちろん、それはまず、「エラーが発生しました。開発者に以下の情報を送信してください」という大きなわかりやすい手紙で始める必要があります。

私の推論では、クラッシュしたアプリケーションのスクリーンショットがしばしば唯一の簡単に入手できる情報源になるということです。確かに、クライアントのシステム管理者の把握を試みたり、ログファイルの場所を説明したりすることができますが、それはおそらく遅くて苦痛です（ほとんどの場合、クライアントの担当者と話すのはそうです）。

また、すべての例外で必要なものを見つけるためにログファイルを探し回る必要のない開発では、即時かつ完全な情報を持つことが非常に役立ちます。（ただし、これは構成スイッチで解決できます。）

残念ながら、ある種の「セキュリティ監査」があり（ソースなしでどのように行われたかはわかりませんが...何でも）、彼らはセキュリティの脅威としてそれらを引用する完全な例外メッセージについて不平を言いました。当然、クライアント（私が知っている少なくとも1人）はこれを額面通りに受け取っており、現在はメッセージのクリーンアップを要求しています。

潜在的な攻撃者がスタックトレースを使用して、以前は理解できなかったものを把握する方法を理解できません。これまでにこれを行った人の例、証拠はありますか？私たちはこの愚かな考えと戦うべきだと思うが、おそらく私はここで愚か者だから...

誰が正しい？

私は、DBまたはファイルにアプリケーションログを作成し、そのような情報をすべてログに記録する傾向があります。その後、エラーに関連するログ項目を識別するエラー番号をユーザーに与えることができます。このパターンは、ユーザーが気にせずにエラーを追跡できるため、問題がどこにあるのかをよりよく把握できるので便利です。

サイトがクライアントの環境にインストールされていてアクセスできない場合、オンサイトIT部門に連絡して、エラーnoに基づいて抽出物を送信できます。

考えられるもう1つのことは、システムがエラーの詳細を自分の目に見えるメールボックスに電子メールで送信することです。

何かが正しくないときに内臓をこぼすシステムを基本的に持っているからといって、技術的でないユーザーに自信を抱かせることはできません。 1つが現れたときに感じますか？）

スタックトレース：

.Netでは、スタックトレースはコアMSソースアセンブリまでの完全なトレースを表示し、使用しているテクノロジーの詳細と、可能なバージョンも明らかにします。これにより、侵入者は悪用される可能性のある脆弱性に関する貴重な情報を得ることができます。

はい、たくさんあります。

スタックトレースは明らかにすることができます

• 使用する暗号化アルゴリズム
• アプリケーションサーバー上の既存のパスは何ですか
• 入力を適切にサニタイズしているかどうか
• オブジェクトが内部的に参照される方法
• フロントエンドの背後にあるデータベースのバージョンとブランド

...リストは延々と続く。基本的には大規模なアプリケーション内のすべての設計上の決定がありますセキュリティ関連のこと、そしてほとんどすべての方法またはモジュール名によって離れて与えてもよいです。念のために、それは、送信先の環境が安全な場合（たとえば、インターネットに面したWebサイトではなくイントラネット）にスタックトレースを表示しても意味がないことを意味しませんが、セキュリティコストは間違いなくゼロではありません。

大切なのは、自分自身で物事を簡単にすることが私たちの主な仕事ではないということです。エンドユーザーの作業を容易にすることが私たちの仕事です。スタックトレースは、開発者にとって非常に有用な情報のように見えます。ユーザーにとっては、まったく役に立たない完全な意味不明のように見えます。別に伝えても、彼らはそれを内面化しません。システム管理者から情報を取得するのが難しいと思う場合、エンドユーザーから情報を取得することはさらに悪いことです。

セキュリティに関して言えば、それがデスクトップアプリケーションである場合にはポイントがあります。その場合、スタックトレースを印刷しても、攻撃者がまだ知らないことは何も提供されません。Webアプリでは、攻撃者はその情報を利用できません。実際、攻撃をはるかに簡単にする内部の詳細を公開しています。

両方の懸念ソースをバイパスして、例外レポートを自動的に送信してみませんか？そうすれば、人々がエラーを報告しないことを心配する必要すらありません。

見てみましょうITセキュリティSEのこの質問を。要するに、スタックトレースは、攻撃者により多くの情報を提供することができます。攻撃者の情報が多いほど、システムに侵入する可能性が高くなります。スタックトレースが常に隠されているという事実に基づいてセキュリティを設定することはしませんが、それはその情報を攻撃者に提供する必要があるという意味でもありません。

とにかく、適切なバックエンドロギングからほとんどの利点を得ることができます。少し便利ではありませんが、おそらくシステムの安全性を危険にさらし、顧客を混乱させる価値はありません。

次の理由により、スタックトレースを表示しないことを検討してください。

セキュリティ

スタックトレースを表示すると、ハッカーになる可能性のある攻撃対象が明らかになります。イントラネットはハッキングの影響を受けません。あなたが責任を負うアプリケーションのためにネットワークがハッキングされた場合、それはあなたにひどく反映されるでしょう

ユーザー体験

ユーザーの最高のエクスペリエンスを得るには、追跡トレースは情報が多すぎます。はい。エラー状態に関する適切な情報を記録し、エンジニアが注意を払う必要があります。ただし、自動化できることをユーザーに依頼することは、ユーザーにとって最善ではありません。

あなたの評判

スタックトレースがWebサイトに表示されるたびに、見た目が悪くなります。ほとんどの人はそれが何であるか考えていないので、ウェブサイトは彼らにとって友好的ではないと感じています。それが何であるかを知っている人にとっては、それはアプリケーションがよく考えられなかったことを示しているかもしれません。ひどく書かれたアプリケーションの多くは、ASP.Netなどの一部のフレームワークのデフォルトであるため、スタックトレースを頻繁に表示します。

簡単な答え：エクストラネットまたはインターネットサイトでは、スタックトレースを表示しないのが理にかなっています。イントラネットでは、スタックトレースを表示することの利点は、それを隠すことの利点を上回ります。

長い答え：

同じことが職場で私にも起こりました。以前は、アプリが失敗した場合、騒々しく失敗するはずだと考えていました。

しかし、彼らは私に、潜在的なハッカーがスタックトレースから多くのことを推測できると説明しました。

証明の必要はないと思います。ことは明らかであるより多くのハッカーは、より良い彼のために、ご使用のプラットフォームについて知っているし、その少ないハッカーは、より良いあなたのために、ご使用のプラットフォームを知っています。

また、企業はハッカーが自社のシステムに侵入した方法を開示することを望んでいません。

一方、それはイントラネットであり、ログファイルを検索しなければならないことで何がうまくいかなかったかをすぐに知ることの利点は大きな利点であり、会社の境界内にスタックトレースを表示することのセキュリティリスクはそれほど高くないと思います彼らは言っています。

提供された製品では、このタイプのエラーの予想数はゼロでなければなりません。顧客に対するこの情報の有用性はゼロです。両方の点で、スタックトレースを提示する理由はありません。有用なコンテキストがある場合は、スタックトレースとしてではなく、顧客にわかりやすい方法で提示する必要があります。

一方、実際の発生回数がゼロでない場合は、この情報が必死に必要になるため、顧客に送信してもらう必要はありません。時間の99.99％はそうではありません。顧客からの「OK」だけで、自動的に情報を送信するバグ報告システムをインストールする必要があります。