web-dev-qa-db-ja.com

例外が発生したときにクラスとメソッド名をログに記録することはセキュリティ上の欠陥ですか？

私は以下を持っています：

public class doCheck(){

    public void performCheck(){
        try {
            perform all checks......
        }
        catch(Exception e){
            logger.error("Exception occured in class doCheck in method performCheck");
            thrown new MyNewException(e.getMessage());
        }
    }
}

クラスとメソッド名をログに記録しても安全ですか？

javasecurityexception-handling
8
blue-sky

それはあなたのコードベースが隠されているかどうかに依存します。製品をクライアントに出荷する場合、クライアントはJavaバイトコードを簡単に検査できるため、クラス名をログに記録しても、ユーザーが入手できない情報は明らかになりません。

サーバー側のアプリケーションの場合も同様です。しかし、それはmayがそのようなログをクライアントに表示するためのセキュリティホールになります。これが、ほとんどのWebアプリケーションフレームワークが開発構成と本番構成を区別する理由です。開発中にエラーが発生した場合、デバッグ情報がユーザーに表示されます。本番環境では、この情報はサーバーに記録されますが、Webブラウザーやクライアントには表示されなくなります。

8
Konrad Rudolph

@Konradが直接的な質問に回答しましたが、例外処理には1つのマイナーな問題と2つの深刻な問題があります。あなたが最初にcodereview.SEに投稿したので、ここにそれらがあります：

  1. スローする前に例外をログに記録しても意味がありません。処理する場所でログに記録し、TIを処理する予定がない場合は、気にしないでください。
  2. 例外を記録する場合は、例外を記録します。単に「例外が発生しました」と言うのではなく、人々が例外とは何かを推測することを期待してください。すべての一般的なロギングフレームワークは、2つの引数を持つメソッドを提供します。1つ目はメッセージ、2つ目はスロー可能です。
  3. メッセージだけで例外を再スローすることも同じ問題ですが、より悪い例です。例外スタックトレースをログに表示したくない理由を（かろうじて）理解できます。しかし、新しい例外をスローすると、実際の問​​題が何であるかを知る方法はまったくありません。特にあなたが捕まり、投げ直すという習慣を続けているなら。

では、4つ目の問題を追加します。例外が発生した場所をログに記録しますが、例外が発生したときに何をしていたか、またはコンテキスト情報を提供しません。実際の例外をログに記録すると（ポイント＃1）、どこで発生したかがわかります。さらに重要なのは、「ファイルfoo.txtを開けません」のようなことです。

6
parsifal

これは特に安全ではないので、このクラスで非表示にしたい重要なものがない限り、またはクラスがクリティカルパスの一部である場合（安全なハンドシェイクや「非表示」機能など）は、これを問題とは見なしません。まったく。

さらに、ここではJavaここで話します。クライアントでJavaを実行しているクライアント側のアプリについて話している場合、彼らはいつでも変更できます自分のJREを使用して独自のデバッグルーチンを追加したり、カスタムクラスローダーを使用したり、クラスに好きな方法でアクセスしたりすることができます。が、統計的にありそうもない悪意のあるユーザーによって引き起こされる損失に対してこれを達成するために必要な時間と労力を考慮すると、通常は費用効果が高くありません。

ログをクライアントに（たとえば、ユーザーのブラウザーに）出力する可能性があるサーバー側のソフトウェアについて話している場合、それはおそらくそれほど大きな問題ではありませんが、修正するのはすでに簡単です：コンテナーの構成それに応じて、代わりにロギングフレームワークまたはマルチプレクサを使用して、デバッグ目的でサーバー上の適切なファイルに出力します。このようにして、デバッグに役立つレコードを保持しますが、潜在的に役立つ情報を損なうことはありません。

しかし、一般的には、これはおそらく問題にはなりません。開発者が作業内容を出力することが多いため、デバッグメッセージに入力する内容が問題になる可能性があります（ユーザー名、パスワード、ソルト、セキュリティトークンのデバッグ出力を明確に表示したくない場合） ）。

1
haylem