83

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

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

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

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

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

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

4

4 に答える 4

59

ここで、もう 1 つの質問を見てみましょう。

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

PDB ファイルの詳細情報:

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

一般に、私は常に展開に pdb ファイルを含めます。その利点は無視するには大きすぎます。

スタック トレースをユーザーにまったく公開しない場合 (一般的には公開するべきではありません)、PDB ファイルをデプロイすることによる追加のセキュリティ リスクは実際にはありません。

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

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

于 2009-08-20T17:00:39.857 に答える
15

自分の組織の運用環境にデプロイする場合、セキュリティの問題ではありません。

ソフトウェアを他のエンティティに販売している場合、.pdb ファイルは、リバース エンジニアリングに関心のある誰かに有利になる可能性があります。これは、問題になる場合とそうでない場合があります。

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

于 2009-08-20T16:56:14.623 に答える
11

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

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

AddAdminUser(string name, string password);

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

または次のようなもの：

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

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

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

しかし 。. . これはすべて、攻撃者がすでにプログラムを侵害できる立場にあることを意味します。もしそうなら、あなたはすでに負けています。

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

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

編集: 私が言ったことのほとんどは、ネイティブ コード用の PDB の展開に関する懸念に適用されます。これらの懸念の多くは、アセンブリ メタデータが既にかなりの量を伝えているにもかかわらず、.NET にも引き継がれていると思います。

于 2009-08-20T16:59:05.977 に答える
2

誰かがあなたのアプリケーションの完全なソース コードを「復元」できます。オープンソースなら心配いりません。何らかの IP (アルゴリズム、保護、ライセンス) がある場合、それはおそらく良い考えではありません。

確かに Reflector のようなツールは、PDB ファイルがなくてもコードの一部を再構築できますが、難読化が役に立ちます (ほんの少しだけ)。

于 2009-08-20T16:52:59.950 に答える