2

doSomething文字列引数の有効性をチェックする一般的なメソッドを書いているとしましょう:

public void doSomething(String argument) {
   if(!checkArgument(argument)) {
      // Argument is not valid
      throw new IllegalArgumentException("Argument " + argument + " is not valid");
   }

   ...

メッセージに潜在的に任意のテキストを含む可能性のある例外をスローすることは安全ですか? または、プログラムを公開して偽造やその他のセキュリティ問題を記録できますか?

そのような場合を処理するためのベストプラクティスはありますか?

4

4 に答える 4

1

通常は安全ですが、コードが管理下のシステム (Web サーバーなど) で実行されている場合、例外をエンド ユーザーに表示できるようにするかどうかを決定する必要があります。例外のエラー メッセージに内部情報を表示することは、システムの構築方法に関する情報を明らかにする可能性があり、攻撃者が例外を強制することで脆弱性を調査できるため、情報漏えいの一形態です。これはデスクトップ アプリケーションの場合は当てはまらない可能性があります。これは事実上ユーザーの制御下にあるためですが、Web またはインターネット ベースのアプリケーションには特に注意が必要です。

ただし、カスタム エラー ハンドラー ページにロジックを追加して、派生し MyUserExceptionClassた例外の詳細のみを表示し、エンド ユーザーがエラーを修正できる場合にのみ使用するポリシーを作成することができます。この場合、おそらくメッセージ自体のみを表示し、スタック トレースやその他の詳細を出力したくないでしょう。この場合、エンド ユーザーに関連する場合は、例外メッセージに引数名の詳細を含める必要があります。

diethreetimesの答えのポイントに対処するために、これらは例外スロークラスまたは例外クラス自体に関係するべきではありません。サニタイズされていないデータを使用するクラスは、出力されるコンテキストのためにサニタイズする必要があります。

例えば

  1. HTML ページに出力する場合、HTML は、例外スローの時点ではなく、出力の時点で例外メッセージをエンコードします。
  2. エラー ログ クラスは、サニタイズされていないテキストをログの正しい形式にサニタイズする必要があります。文字制限がある場合、または CSV 形式のファイルである場合、このクラスは、メッセージ内のコンマと引用符がこの時点で適切にフォーマットされていることを確認する必要があります。
  3. データベースに書き込まれる場合、パラメーター化されたクエリを使用して情報をデータベースに正しく書き込むのは、データ アクセス レイヤー次第です。
于 2013-08-28T10:22:40.037 に答える
1

SilverlightFox の回答にはおおむね同意します。インジェクションの脆弱性が発生した時点で心配してください (そして、発生しないことを確認してください)。

ただし、機密性の問題は、例外を伴う現実の問題です。他の場所では (グローバルがない限り)、単一のレイヤー インターフェイスを介した相互作用を扱っています。例外を持ち込むと、非局所的な問題が発生します。

例えば：

  • SSN は、厳格な管理が必要なデータの標準的な例です。一部の低レベルの解析ライブラリは、文字列の詳細で例外をスローする場合があります。それは丸太に引っかかって押し込まれるかもしれません。一般的な解析コードもログ記録コードも SSN について認識していませんが、最終的に SSN の脆弱性を導入しています。
  • 例外メッセージを Web ページ (コメントに入れることもありますが、これは役に立ちません!) に入れる Web サイトは、攻撃者にとって役立つ可能性がある Web サイトの実装に関する情報を開示します。Web サイトはこれを行うべきではありませんが、実際に行っています。したがって、例外をスローし、いずれ Web アプリに組み込まれる可能性があるコードについては、慎重に検討する必要があります。
  • プロセス間、マシン間、またはオペレーティング システムからプロスへの例外など、伝播される例外には、機密情報が含まれている可能性があります。
  • モバイル コードがある場合、機密情報が権限の低いコードに移行する可能性があります。ここでのファイル パスは明らかな候補です。

また、変更可能なデータを例外に追加することは、安全のためにディープ コピーが必要なため、お勧めできません。Throwable1.4 が自分自身を「便利に」変更可能にしたのは残念です。

于 2013-08-29T14:10:39.233 に答える
1

それは、例外がスローされた後に例外をどうするかによって大きく異なります。一般的に、これはおそらく悪い考えだと思います。経験則として、サニタイズされていない引数を「使用」しないでください。これにより、可能性があるいくつかの攻撃シナリオを次に示します。

  1. これは Web ページ用であり、このエラーをユーザーに表示しています。この場合、攻撃者は特にXSS攻撃を実行する可能性があります。
  2. このエラーはログに出力されます。ここでは安全に見えるかもしれませんが、攻撃者はファイル システムへのアクセス権をいくらか (すべて制限されています) 持っています。このメカニズムを使用して、将来の使用のためにコードを保存したり、ログ (またはファイル システムの他の側面) を損傷したりする可能性があります。これは、引数がバイトごとにファイルに書き込まれる場合に特に当てはまります。
  3. このエラーはデータベースに保存されます。ここで十分なスキーマ情報があれば、攻撃者はデータベース全体を変更または破壊できる可能性があります。

これだけでは、攻撃者が情報を盗むには不十分かもしれませんが、他のバグと組み合わせると、マシンの制御を取得するために使用される可能性があります。ただし、基本的なサニタイズを行うことで、これらの問題のほとんどを回避できます。

  1. @assylias が示唆するように、長さチェックを実行します。
  2. 引数内のすべての文字が英数字であることを確認してください (または、引数にあると予想されるものは何でも)。
  3. 英数字が制限的である場合は、html/javascript/sql 構文文字 (例: '<'、'>'、';') を含まないホワイトリストを通過します。通常、これらの文字はいずれにせよデバッグのために存在する必要はありません。
于 2013-08-26T21:43:44.137 に答える
0

引数をログに記録し、部分文字列を例外に含めることができます。

セキュリティに関する懸念については、アプリケーションとインフラストラクチャのアクセス制御モデルに依存します。

  1. サーバーにアクセスできない場合は、ログを記録することをお勧めします。少なくとも、例外の原因となった引数を確認できます。
  2. セキュリティがより重要な問題である場合は、例外の詳細を分析用のパラメータとともにデータベース テーブルに格納することをお勧めします。
  3. 夢中になりたい場合は、データベースの列を暗号化できます。

いずれにせよ、どの引数が例外を引き起こしたかを見てみたいと思います。

乾杯 ！！

于 2013-08-26T21:38:03.390 に答える