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


8

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

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());
        }
    }
}

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

回答:


8

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

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


はい。ログ自体が安全であることを確認することが重要です。外部ユーザーはアクセスできず、絶対に変更することはできません。
Donald.McLean

2
要約すると、クラス/メソッドのロギングは良いことです。ログ(またはスタックトレース)のエスケープを許可することは悪いことです。
Qwerky

6

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

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

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


1

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

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

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

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

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.