web-dev-qa-db-ja.com

不十分なエラー処理のソースコードレビュー

本日、セキュリティチームから報告を受けました。レポートには、以下の脆弱性と説明が含まれています。

1）不十分なエラー処理：過度に広いスロー

Program1.Javaのメソッドは一般的な例外をスローするため、呼び出し側がエラー処理と回復を適切に行うことが難しくなります。

2）不十分なエラー処理：非常に広範なキャッチ

EXAMPLE1.Java行146のcatchブロックは、例外の幅広い範囲を処理し、プログラムのこの時点で処理されるべきではない異なる問題または問題をトラップする可能性があります。

）不十分なエラー処理：空のキャッチブロック

Somefile.JavaのメソッドSomeMethod（）は、33行目の例外を無視します。これにより、プログラムが予期しない状態や条件を見落とす可能性があります。

上記のレポートを読んだ後、私の心にいくつかの疑問が浮かび上がりました。

  1. これらはセキュリティとどのように関連していますか？私の理解によると、上記の問題はコード品質の問題のようです。

  2. それらが実際のセキュリティの脅威である場合、攻撃者はどのようにこれを悪用することができますか？

  3. 上記の問題を軽減するには、どのような保護対策が必要ですか？

web-applicationappsecjava
29
useradmin1234

これらの問題はセキュリティではなくコードの品質に関連しており、それらのどれも明らかな方法で悪用されることはないと思います。私はそれらを「脆弱性」とは呼びません。

しかし、脆弱性はバグから生まれ、バグは悪いコード品質から生まれます。不適切なエラー処理は、予期しない結果（バグなど）につながる可能性があり、運が悪ければ脆弱性につながる可能性があります。

例外処理に関連するいくつかの例を次に示します。

  • 例外をまったく処理しないと、プログラムがクラッシュする可能性があります。これは、サービス拒否攻撃に使用される可能性があります。サーバーをクラッシュさせる悪意のある要求でサーバーをオーバーフローさせるだけで、正当な要求を処理する代わりに、再起動に時間を費やします。
  • エラーメッセージがHTTP応答で渡される場合、未処理の例外により機密情報が開示される可能性があります（ Rich Moss によって指摘されます）。
  • すべてをキャッチする過度に広いcatchステートメントは、セキュリティクリティカルな例外が隠されてしまう可能性があります。

実際の例については、 Wordの「例外」でフィルタリングされたこのCVEリスト を確認してください（ Ben Hocking で推奨）。

解決策は、例外処理の最善の方法に従うことです。セキュリティの問題というよりはプログラミングの問題なので、ここでは詳しく説明しません。

49
Anders

これらはセキュリティとどのように関連していますか？私の理解によると、上記の問題はコード品質の問題のようです。

これらはコード品質の問題です。名前から、彼らはFortifyからまっすぐであるように見えます。 Fortifyにはコード品質の問題を探す機能があり、セキュリティチームがスキャンの実行中にこれらのルールを有効にしているようです。

それらが実際のセキュリティの脅威である場合、攻撃者はどのようにこれを悪用することができますか？

記載されている問題のいずれも、意味のある方法で悪用できるとは思いません。私が予測できる唯一の影響は、これによりコードのデバッグが非常に困難になることです。

上記の問題を軽減するには、どのような保護対策が必要ですか？

問題は自明です。例外処理のベストプラクティスに従います。

11
hax

悪者は標的システムについて可能な限り学ぶことから攻撃を開始します。不適切に処理された例外は、機密情報を呼び出し側クライアントに明らかにする可能性があります。

REST APIなど）では、通常の正常なGET応答には、要求されたオブジェクトと200 HTTPステータスコードが含まれますが、サーバーの実装についてはほとんど含まれません。非GET要求の応答存在するオブジェクトは404 HTTPステータスコードを返し、レスポンスボディを返さないようにする必要があります。

例外シナリオでは、500（サーバーエラー）ステータスコードが返され、応答の本文には例外のソースに関する情報（接続の問題、データベースの一意のキー違反など）が含まれる場合があります。このタイプの応答には、スタックトレース、サーバーテクノロジー、ソフトウェアライブラリ、ベンダー名など、悪意のあるユーザーが使用できるシステム。適切な例外処理により、このデータが呼び出し元クライアントに公開されないようにするか、ソフトウェアのレイヤーをトラバースして不要なログに保存することができなくなります。

データの急増は安全なシステムの敵の1つであることを忘れないでください。より多くの例外の詳細が冗長ログに保存されると、攻撃対象がそのデータを拡大することがわかります。そのため、ログやサーバーの応答から余分なノイズを排除してください。

セキュリティレビュアーからのメッセージは、通常のフローのようなすべてのknown例外シナリオを処理することです。 過度に広い範囲のスローは、コードが型付き例外の代わりに一般的な例外をスローしていることを示します過度に広い範囲のキャッチを処理するために型付き例外としてキャッチする必要があります。 REST APIの例では、この例外がサーバー側の既知または頻繁なタイムアウトの問題である場合、呼び出し元は空の応答を返すことを選択し、ユーザーに再試行またはアクティビティの確認を指示することができます。対照的に、「<script ..>」のように無効なデータが提供される例外では、追加レベルのアラート、ユーザーロックアウト、空の応答が必要になる場合があります。

5
Rich Moss

私はコード監査、このようなセキュリティ分析、そして倫理的ハッキングの実行を10年半にわたって扱ってきたので、私の経験のいくつかを共有させてください。

私は、コードレビューを容易にするだけでなく、安定性、保守性、セキュリティの面でも、コード品質の高水準を達成することを主張するロールモデルと見なしたすべてのボスとチームリーダーを経験しました。チームのように例外処理を行う開発者は、経験がほとんどないか、時間がほとんどないか、単に気にしません。そして、この種の遅延コーディングは災害につながる可能性があります。

私の目で最も目立つのは、問題番号3の空のキャッチです。これは、ログに記録することさえせずに、通過するエラーをマスクします。次のことが起こったとします。

try {
    // start a transaction
} catch (Exception ex) {
}
finally {
    // commit the transaction
}

ビジネスに無効なデータをデータベースに入れている可能性があります。より複雑な例として、fundsというプロパティfundsを持つタイプAccountがあるとします。 ---）は符号なし整数です（金額が0未満のアカウントを許可したくないため）：

try {
    // moving funds between accounts
    Transaction.start();
    accountA.funds += amount;
    accountB.funds -= amount; // throws an overflow exception if funds < amount
} catch (Exception ex) {
}
finally {
    Transaction.commit();
}

最終結果は、アカウントAに送金されても、アカウントBから差し引かれない場合があります。

これはあなたにとってあなたのチームの下で愚かに聞こえるかもしれませんが、私が働いてきたいくつかの会社ではレガシーコードでそのようなことを扱わなければなりませんでした。ソリューションにこの種のコードが含まれていると言っているのではありませんが、怠惰なスタッフや不満を抱いているスタッフがいても、そのようなコードを見つけても驚くことはありません。そして、あなたが行ったようなレポートを取得している場合、コードベースが完全に安全であることを決して信頼しないでください。

一歩先に進んで、悪いエラー処理が多くの人々にとってその日を本当に悩ませた例を挙げましょう。歴史上最も高価なコーディングエラーの1つは、 Ariane 5ロケットの最初のテストフライト のエラーでした。

1996年6月4日に行われたAriane 5の最初のテスト飛行（Ariane 5 Flight 501）は失敗しました。制御ソフトウェアの不具合のため、ロケットは打ち上げから37秒後に自己破壊しました。水平バイアスを表す変数に格納される64ビット浮動小数点値から16ビット符号付き整数値へのデータ変換は、浮動小数点値が大きすぎて16ビットで表すことができないため、プロセッサトラップ（オペランドエラー）を引き起こしました符号付き整数。このソフトウェアは元々、Ariane 4向けに作成されたもので、効率の考慮（ソフトウェアを実行するコンピューターの最大ワークロード要件は80％でした）により、4つの変数が handler で保護され、他の3つは水平バイアスを含みます。変数は、「物理的に制限されているか、または安全に大きなマージンがあった」と考えられていたため、無保護のままにされました。

鉱山を強調します。私の記憶が正しければ、3億7000万ドルの失敗でした。確かに、あなたはおそらくNASAやDARPAのコーディングをしていないので、不適切なコーディングによる損失は、機械の爆発ではなく、手直しのためのスタッフの時間であるはずです。しかし、損失はまったく同じ損失であり、少しだけ注意してそれらを回避できる場合は、少なくともそれを考慮した方がよいでしょう。

5
Renan

この種のコード品質の問題は、実装方法によってはセキュリティの問題につながる可能性があります。これが、開発の初期段階でこの種の問題を検出するためにSASTツールが配置されている理由です。

エラー処理を改善する必要があります。

2
Winnnn

特異性の欠如は、プログラムを通る可能性のあるより多くのパスがあり、より多くのパスがあるほど、セキュリティを含むそのプロパティを検証することが難しくなることを意味します。これにより、セキュリティに対する信頼が低下します。

特に、広範なキャッチは、ユーザーが意図したよりも多くの場所からキャッチブロックに強制的にジャンプすることを可能にする可能性があります。そのため、最初に、これが可能かどうかを確認する追加の作業があり、可能であればすべてのそれ以降のすべての結果を把握するために働きます。さらに、これはその後のすべての変更に検証の負担を追加します。少なくともいくつかの追加の検証を行う必要があるか、いくつかの基本的な原則に従った場合よりもコードの検証が不十分であることを受け入れるため、結果がめったにないことを言うのは防御策ではありません。

0
sdenham