A10:2025 例外的な状況への不適切な対応 (Mishandling of Exceptional Conditions)

背景 (Background.)

「例外的な状況への不適切な対応」は、2025年版の新カテゴリです。本カテゴリは 24 の CWE (共通弱点一覧) で構成されており、不適切なエラー処理、論理エラー、安全でない失敗処理(フェイルオープン) (Failing open)、およびシステムが遭遇しうる異常な状況に起因するその他の関連シナリオに焦点を当てています。このカテゴリには、以前は「コード品質の低さ (Poor code quality)」に関連付けられていたいくつかの CWE が含まれています。それは私たちにとってあまりに一般的すぎました。私たちの意見では、このより具体的なカテゴリの方が、より良い指針を提供できると考えています。

本カテゴリに含まれる注目すべき CWE には、機密情報を含むエラーメッセージの生成 (CWE-209)、必須パラメータの処理失敗 (CWE-234)、不十分な特権の不適切な処理 (CWE-274)、NULLポインタ参照 (CWE-476)、および安全でない失敗処理 (CWE-636) が含まれます。

スコアテーブル (Score table.)

紐付けられた CWE 数	最大出現率	平均出現率	最大網羅率	平均網羅率	平均加重悪用スコア	平均加重影響スコア	出現総数	CVE 総数
24	20.67%	2.95%	100.00%	37.95%	7.11	3.81	769,581	3,416

説明 (Description.)

ソフトウェアにおける例外的な状況の不適切な取り扱いは、プログラムが異常かつ予測不能な事態を防止、検知、および応答することに失敗したときに発生し、クラッシュや予期しない挙動、そして時には脆弱性を引き起こします。これには、以下の 3 つの失敗のいずれか、または複数が関与しています。すなわち、アプリケーションが異常な状況の発生を「防止」できないこと、発生している状況を「識別」できないこと、あるいは、その状況に対して後から「応答」が不適切、あるいは全く行われないことです。

例外的な状況は、入力検証の不足、不十分、または不完全さや、発生した関数ではなく上位階層で行われる遅すぎるエラー処理、あるいはメモリ、特権、ネットワークの問題といった予期せぬ環境状態、一貫性のない例外処理、あるいは例外が全く処理されずシステムが未知かつ予測不能な状態に陥ることによって引き起こされます。アプリケーションが「次の命令をどうすべきか」確信を持てなくなったときはいつでも、例外的な状況の処理に失敗しています。見つけにくいエラーや例外は、長期にわたってアプリケーション全体のセキュリティを脅かす可能性があります。

例外的な状況の処理を誤ると、ロジックの不具合、オーバーフロー、競合状態 (Race conditions)、不正な取引、あるいはメモリ、状態、リソース、タイミング、認証、および認可に関する問題など、多くの異なるセキュリティ脆弱性が発生する可能性があります。これらのタイプの脆弱性は、システムまたはそのデータの機密性、可用性、および完全性に悪影響を及ぼす可能性があります。攻撃者は、アプリケーションの欠陥のあるエラー処理を操作して、この脆弱性を突いてきます。

防止方法 (How to prevent.)

例外的な状況を適切に処理するには、そのような状況を計画しておく必要があります（最悪の事態を想定 (Expect the worst) する）。すべてのシステムエラーを、それが発生した場所で直接「キャッチ (Catch)」し、それを処理しなければなりません（つまり、問題を解決し、その問題から確実に回復するために意味のある何かを行うことを意味します）。処理の一環として、エラーをスローすること（ユーザーに理解可能な方法で通知する）、イベントをログに記録すること、および正当であると判断した場合にはアラートを発行することを含めるべきです。また、何かを見落とした場合に備えて、グローバルな例外ハンドラーを設置しておくべきです。理想的には、継続的な攻撃を示す繰り返されるエラーやパターンを監視し、何らかの応答、防御、またはブロックを発行できる、監視 (Monitoring) または可観測性 (Observability) のツールや機能を備えることです。これは、私たちのエラー処理の弱点に焦点を当てたスクリプトやボットをブロックし、それらに応答するのに役立ちます。

例外的な状況をキャッチして処理することで、プログラムの基盤となるインフラストラクチャが予測不能な状況に対処したまま放置されないようにします。いかなる種類のトランザクションであっても、その途中でエラーが発生した場合は、トランザクションのすべての部分をロールバックしてやり直すことが非常に重要です（フェイルクローズ (Fail closed) とも呼ばれます）。途中でトランザクションを回復しようとすると、回復不可能な間違いを犯してしまうことがよくあります。

可能な限り、レート制限 (Rate limiting)、リソース制限 (Resource quotas)、スロットリング (Throttling)、およびその他の制限を追加して、そもそも例外的な状況が発生するのを防いでください。情報技術において無制限なものは何一つあってはなりません。それはアプリケーションのレジリエンス (Resilience)（回復力）の欠如、サービス拒否、ブルートフォース攻撃の成功、および莫大なクラウド利用料に繋がるからです。特定のレートを超える同一の繰り返されるエラーについては、それらがいつ、どの程度の頻度で発生したかを示す統計としてのみ出力することを検討してください。この情報は、自動化されたロギングや監視を妨げないように、元のメッセージに追加されるべきです（A09:2025 セキュリティログとアラートの不備参照）。

これに加えて、厳格な入力検証（受け入れなければならない潜在的に危険な文字については無害化 (Sanitization) またはエスケープを行う）、および「集約された (Centralized)」エラー処理、ロギング、監視、アラート、ならびにグローバル例外ハンドラーを含めるべきです。一つのアプリケーションに例外的な状況を処理するための複数の関数を持たせるべきではなく、一箇所で、毎回同じ方法で実行されるべきです。また、このセクションのすべてのアドバイスについてプロジェクトのセキュリティ要件を作成し、プロジェクトの設計フェーズで脅威モデリング (Threat modeling) や安全な設計レビューを実施し、コードレビューや静的解析を実施し、最終的なシステムに対してストレス、パフォーマンス、およびペネトレーションテストを実行すべきです。

可能であれば、組織全体で例外的な状況を同じ方法で処理すべきです。そうすることで、この重要なセキュリティ制御におけるエラーのコードレビューや監査が容易になります。

攻撃シナリオの例 (Example attack scenarios.)

シナリオ #1：例外的な状況の誤処理によるリソースの枯渇 (サービス拒否) アプリケーションがファイルのアップロード時に例外をキャッチするものの、その後にリソースを適切に解放しない場合に発生する可能性があります。新しい例外が発生するたびにリソースがロックされるか利用不可のままになり、最終的にすべてのリソースが使い果たされます。

シナリオ #2：不適切な処理またはデータベースエラーによる機密データの露出 ユーザーにシステムの完全なエラーを明らかにしてしまうケースです。攻撃者は、機密性の高いシステム情報を利用してより優れた SQL インジェクション攻撃を作成するために、意図的にエラーを発生させ続けます。ユーザーへのエラーメッセージに含まれる機密データは偵察 (Reconnaissance) 活動に利用されます。

シナリオ #3：金融取引における状態の破損 攻撃者がネットワークの中断を介して多段階のトランザクションを妨害することによって引き起こされる可能性があります。トランザクションの順序が「ユーザーアカウントの引き落とし、宛先アカウントへの入金、トランザクションのログ記録」であったと仮定します。途中でエラーが発生したときにシステムがトランザクション全体を適切にロールバック（フェイルクローズ）しない場合、攻撃者はユーザーのアカウントを枯渇させたり、あるいは攻撃者が宛先に何度も送金できてしまう競合状態が発生したりする可能性があります。