サーバーアプリケーションのスタックトレースは脆弱性ですか？
programmers.stackexchange.comに関する私の質問 に関連して。
物事がクラッシュしたときにアプリケーションがユーザーに完全なスタックトレースを表示するのはセキュリティリスクですか？私たちのアプリケーションが通過したいくつかのセキュリティ監査はそうだと言います。同意しません。それが攻撃者にどのように役立つかはわかりません。
もちろん、「できるだけ少なく」という原則もありますが、それも常識とのバランスが必要ですし、悪用されるリスクよりも、情報を手軽に入手できることのほうが得策だと思います。
これについての研究はありますか？これがセキュリティリスクであることを示唆する証拠はありますか？または、これは上記の原則を過度に適用したものですか？
スタックトレースは情報漏えいであり、実装に関する情報が明らかになります。深刻な脆弱性ではありませんが、攻撃者がシステムに関する特定の情報を入手することは可能です。また、デバッグベースのアプローチを使用して、サイトの欠陥を悪用することもできます。
スタックトレース自体が脆弱性であると主張する人もいるかもしれません。これは、このような方法でサイトをクラッシュさせることはできないためです。
セキュリティへの影響を無視すると、スタックトレースを表示することは、顧客に自信を与えることにはなりません。彼らは、サイトが壊れている（それが実際にそうである）と想定し、トランザクションが機能するかどうか、あるいはサイトがハッキングされているとさえ考えるかもしれません。
スタックトレースは通常、それ自体の脆弱性ではありません。ただし、ソフトウェアの設計に関する一部の情報が漏洩する可能性があり、これは攻撃者に役立つ可能性があります（データベースのバージョン、テーブル名、コードファイル名などを明らかにする）。したがって、通常、スタックトレースを明らかにすることはお勧めできません。
これに対処する標準的な方法は、本番サーバーでスタックトレースをオフにすることです。外部に公開されていないデバッグビルドでスタックトレースをオンにして、クラッシュのデバッグに役立てることができますが、本番環境に移行するときは、スタックトレースをオフにしてください。
web2py web framework には この問題に対処するためのさらにエレガントな方法 があります。 web2pyが訪問者にスタックトレースを明らかにすることはありません。代わりに、キャッチされない例外が発生した場合、web2pyは新しい「チケット」を作成し、訪問者にチケット番号を公開し、そのチケットに関連するエラーの詳細（スタックトレースなど）を内部データベースに保存します。通常の訪問者はチケットの詳細を見ることができませんが、管理者は見ることができます。管理者は、すべてのチケットのリストを確認できます。さらに、管理者はチケット番号を指定して、そのチケットの詳細を調べ、スタックトレースなどを確認できます。セキュリティの観点からは、これは優れたアプローチです。
（ちなみに、web2pyは洗練されたフレームワークであり、デフォルトでセキュリティをオンにして開発者が簡単にできるように多くの考慮を払っています。web2pyは、セキュリティの落とし穴をなくし、サービスをデフォルトで安全にすることを試みます。安全にする必要があるWebサービスを再構築するには、web2pyを見てください！）
はい、そうです。
最高のものは、私が偶然見つけたものでした[〜＃〜] all [〜＃〜] Webサーバー上のデータベース資格情報。うん、リモートでDBにアクセスしてクエリを実行できます。これはおそらく、誰かがDROP "databasename"のように厄介なことを実行できることを意味します。
もう1つ私が所有者に通知したのは、スタックトレースが管理ログイン名と暗号化されていないパスワードを示したログセッションです。
ほとんどのスタックトレースは、誰かが悪意のある活動に役立つ情報の漏洩にすぎず、最初の2つの例ほど露骨ではありません。