実稼働環境にデバッグシンボル（pdbファイル）をデプロイするリスクは何ですか？

例外strackトレースをログに記録するアプリケーションがあり、本番環境にデプロイするときに、これらのスタックトレースにファイル名と行番号を含める必要がありました。アセンブリを使用してデバッグシンボルを展開する方法を理解しましたが、問題を調査する過程でこの質問に遭遇しました。これは、本番環境にpdbファイルを含めることはお勧めできないことを意味します。受け入れられた回答へのコメントは、「...デバッグ情報は機密データを提供し、攻撃ベクトルになる可能性があります。アプリが何であるかによって異なります」と述べています。

では、どのような種類の機密データが公開される可能性がありますか？デバッグシンボルを使用してアプリケーションを危険にさらすにはどうすればよいですか？技術的な詳細に興味がありますが、私が本当に探しているのは、特定のアプリケーションおよび実稼働環境にデバッグシンボルを含めるリスクを評価するための実用的な方法です。言い換えれば、起こりうる最悪の事態は何でしょうか。

編集：フォローアップの質問/説明

したがって、これまでの全員の回答に基づくと、この質問は.NETアプリケーションでは少し単純化できるようです。MichaelMaddoxの回答にリンクされているJohnRobbinsブログのこのビットは、私に飛び出しました。

.NET PDBには、ソースファイル名とその行、およびローカル変数名の2つの情報のみが含まれています。他のすべての情報はすでに.NETメタデータに含まれているため、PDBファイルで同じ情報を複製する必要はありません。

私にとって、これは他の人がReflectorについて言っていることを繰り返しますが、本当の問題はアセンブリへのアクセスであるという意味です。それが決定されたら、PDBに関して行う唯一の決定は、ファイル名、行番号、およびローカル変数名を公開することを気にするかどうかです（最初にエンドユーザーにスタックトレースを表示していないと仮定します）。それとも私はこれを単純化しすぎましたか？

ここにもう1つの質問があります。

PDBデバッグファイルをライブサーバーに残すセキュリティ上の問題はありますか？

そして、PDBファイルに関する詳細情報：

PDBファイル：すべての開発者が知っておくべきこと

一般に、デプロイメントには常にpdbファイルを含めますが、そのメリットは無視できないほど大きくなります。

スタックトレースをユーザーに公開しない場合（通常は公開しないでください）、PDBファイルを展開することによる追加のセキュリティリスクは実際にはありません。

ユーザーに表示されるスタックトレースが発生すると、ユーザーはファイル名とファイル行番号を含む完全なスタックトレースを表示できます。これにより、アプリがどのように設計されているかを知ることができ、ハッキングの場合に役立つ可能性があります。

より大きなセキュリティ上の脅威は、DLLで使用すると、pdbファイルの有無にかかわらずソースコードを表示できるようになるReflectorのようなものです。

自分の組織の実稼働環境に展開している場合、それはセキュリティの問題ではありません。

ソフトウェアを他のエンティティに販売している場合、.pdbファイルを使用すると、リバースエンジニアリングに関心のある人に足を伸ばすことができます。これは問題になる場合と問題にならない場合があります。

ただし（明確にするために）、. pdbsが使用可能かどうかに関係なく、スタックトレースがクライアントに表示されることは望ましくありません。ただし、トレースをログに記録して「きれいな」エラーページをクライアントに表示するだけの場合は、問題ではありません。

攻撃者は、デバッグシンボルを使用することで、対象のグローバル変数や関数オフセットなどを特定できます。

したがって、彼はあなたのシステムが次のような機能を持っているのを見ることができました。

AddAdminUser(string name, string password);

そして、そのオフセットを知っています。プログラムが危険にさらされている場合、彼はこの関数を呼び出して自分自身に管理者権限を与えることができます。

または次のようなもの：

typedef enum {Basic, NTLM} AuthenticationMode;
AuthenticationMode g_authenticationMode;

そして、アプリケーションを安全でないモードに切り替えるためにどのビットを反転するかを知っています。

あるいは、これを理解するには、かなりのリバースエンジニアリング時間がかかります。しかし、乗り越えられないほどの時間ではありません。

だが 。。。これはすべて、攻撃者がすでにプログラムを危険にさらす可能性がある立場にあることを意味します。もしそうなら、あなたはすでに負けています。

pdbシンボルをデプロイする正当なビジネス上の理由がある場合は、先に進んでください。PDBを導入しても、安全性が低下することはありません。展開する正当な理由がない場合は、攻撃が少し簡単になるため、これを実行しないでください。

パブリックPDBファイルを作成することもできます。これらは特定の情報を取り除きますが、スタックトレースを生成して基本的なデバッグを行うのに十分なシンボルを提供します。詳細はこちら。Microsoftは、すべてのユーザーが使用できるように、パブリックPDBをシンボルサーバーに展開しています。

編集：私が言ったことのほとんどは、ネイティブコード用のPDBのデプロイに関する懸念に当てはまります-アセンブリメタデータはすでにこれをかなり伝えていますが、これらの懸念の多くは.NETにも引き継がれていると思います。

誰かがあなたのアプリケーションの完全なソースコードを「復元」することができます。オープンソースの場合は心配する必要はありません。IP（アルゴリズム、保護、ライセンス）がある場合は、おそらくお勧めできません。

Reflectorのようなツールは、PDBファイルがなくてもコードの一部を再構築できることは事実ですが、難読化が役立つ場合があります（まあ、ほんの少しだけです）。