OWASP Top Tenの新しいリスクカテゴリ：予期せぬ事態への備え

OWASPが2025年版Top Tenを公開したことで、企業は新たなリスクカテゴリーに特別な注意を払う必要が出てきました。その中には、「知らないことが最大の脅威になる」という事実を改めて突きつける、全く新しいカテゴリーも含まれています。

新カテゴリーである「例外的な状況の不適切な処理」は、組織が異常事態や予測不能な状況を未然に防ぎ、検知し、対応する準備ができていない場合に何が起こり得るかを示しています。OWASPによると、この脆弱性は、アプリケーションが異常な事態を阻止できなかったり、問題発生時にそれを特定できなかったり、あるいは予期せぬ事態に対して対応が不十分、または全く対応できない場合に発生します。

企業が「想定外」の事態に備える必要があるという考え方は、現代の高度に分散・相互接続されたシステムの現実を反映しています。OWASPが指摘しているのは、決して未知の問題ではありません。「例外的な状況の不適切な処理」には、24の共通脆弱性タイプ（CWE）が含まれています。これらは不適切なエラー処理、イベントのオープン失敗、論理エラーなど、異常な条件下で発生しうるものです。例えば、不十分な入力バリデーション、処理関数の高レベルなエラー、例外処理の一貫性の欠如（または不在）などが原因となります。OWASPが述べるように、「アプリケーションが次に何をすべきか確信が持てない瞬間、それは例外的な状況が不適切に処理されたことを意味します」。

こうした例外的な状況はシステムを予測不能な状態に陥らせ、システムクラッシュや予期せぬ挙動、長期的なセキュリティ脆弱性を引き起こす可能性があります。このような混乱を防ぐ鍵は、本質的に「最悪の事態を想定し、予期せぬことが起きたときに備えて計画を立てておくこと」にあります。

[動画を見る]

例外的な状況とTop Tenの進化

Webアプリケーションセキュリティにおける最も深刻なリスクをまとめた4年ごとのTop Tenリストは、これまで比較的安定しており、カテゴリーの順位変動や4年に1〜2件の追加がある程度でした。2025年版には2つの新しいエントリーがあり、その一つが第10位の「例外的な状況の不適切な処理」です。もう一つは第3位の「ソフトウェアサプライチェーンの失敗」で、これは以前のカテゴリーである「脆弱で古いコンポーネント」（2021年版第6位）を拡張し、より広範なソフトウェア侵害を含めたものです。（ちなみに、「認証不備（Broken Access Control）」は依然として第1位のリスクとして君臨しています）。

新カテゴリーを構成する例外的な状況は、論理バグからオーバーフロー、不正取引、メモリ、タイミング、認証、認可の問題など、多岐にわたる脆弱性を引き起こす可能性があります。これらの脆弱性は、システムの機密性、可用性、完全性に影響を及ぼします。OWASPによれば、攻撃者はアプリケーションの不完全なエラー処理を悪用して、こうした脆弱性を突くことができます。

予期せぬ状況への対応に失敗する例として、サービス拒否（DoS）攻撃中にファイルがアップロードされ、アプリケーションが例外を検知したにもかかわらず、その後のリソース解放に失敗するケースが挙げられます。その結果、リソースがロックされたまま、あるいは利用不可となり、リソース枯渇を引き起こします。また、多段階の金融取引において攻撃者が介入した場合、エラー検知時に取引をロールバックしないシステムでは、ユーザーの口座から資金が流出する恐れがあります。取引の途中でエラーが検知された場合は、「フェイルクローズ」、つまり取引全体をロールバックして最初からやり直すことが極めて重要です。途中で取引を復旧させようとすると、取り返しのつかないミスにつながる可能性があります。

フェイルクローズとフェイルオープン

では、この2つのアクションにはどのような違いがあるのでしょうか。明確にしましょう。

フェイルオープン：システムが「フェイルオープン」する場合、問題が発生しても動作を継続するか、「開いた」状態を維持します。これは稼働を維持することが非常に重要な場合には有用ですが、セキュリティの観点からはリスクを伴います。

フェイルクローズ：システムが「フェイルクローズ」する場合、問題が発生すると自動的にシャットダウンするか、安全な状態になります。これは不正アクセスを防ぐ助けとなるため、セキュリティの観点からはより安全です。

予期せぬエラーへの対応

この種のリスクを防ぐには、未知の事態を想定した計画から始まります。それには、システムエラーが発生した際にそれを検知し、問題を解決するための手順を講じることが含まれます。ユーザーには適切に通知し（攻撃者に重要な情報を漏らさないように注意しつつ）、イベントをログに記録し、必要に応じてアラートを発信できるようにしておく必要があります。

以下は、SQLクエリのエラーとサイトのインストールパスが公開されてしまい、攻撃者にインジェクションポイントを特定されるきっかけとなる例です。

警告: odbc_fetch_array() はパラメータ 1 にリソースを期待していますが、D:\app\index_new.php の 188 行目でブール値が渡されました

理想的なシステムには、見落とされたエラーを捕捉するためのグローバル例外ハンドラに加え、監視や可観測性ツール、あるいは継続的な攻撃の兆候となり得る繰り返されるエラーやパターンを検知する機能が必要です。これにより、エラー処理における企業の弱点を突こうとする攻撃を防ぐことができます。

例えば標準的なJava Webアプリケーションの場合、Servlet仕様バージョン2.5以降で使用可能なweb.xmlデプロイメント記述子レベルで、グローバルエラーハンドラを設定できます。

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

ns="http://java.sun.com/xml/ns/javaee"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
‍
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"

‍‍version="3.0">
...
  <error-page>
     <exception-type>java.lang.Exception</exception-type>
     <location>/error.jsp</location>
</error-page>
...
</web-app>
‍

この短いコードブロックは、Java Webアプリケーションの裏側で何らかの問題が発生した際の動作を定義します。ユーザーに分かりにくいエラーメッセージや真っ白な画面を表示する代わりに、問題を静かに捕捉し、カスタムエラーページ（この場合はerror.jsp）へ誘導します。

これは一般的なjava.lang.Exception型を処理するように設定されているため、アプリケーション全体のマスターエラーハンドラとして機能します。つまり、どこでエラーが発生しても、ユーザーは技術的な詳細情報を見せられることなく、一貫した親しみやすいエラーページにリダイレクトされます。

予期せぬ事態の防止

理想を言えば、組織は例外的な状況が発生しないよう、可能な限り予防策を講じるべきです。例えば、レート制限、リソースクォータ、スロットリングなどの制限を実装することで、サービス拒否攻撃やブルートフォース攻撃に対抗できます。同一のエラーが繰り返される場合は、自動ログや監視の妨げにならないよう、統計データとしてのみ扱うのが賢明です。システムには以下の要素も組み込むべきです。

厳格な入力バリデーション。 適切に構成されサニタイズされたデータのみがワークフローに入るようにします。これはデータフローの初期段階、理想的にはデータを受信した直後に行うべきです。

エラー処理のベストプラクティス。エラーが発生したその場所で捕捉します。効率的に対処し、ユーザーにはログの保持を明確に伝え、必要に応じてアラートを送信します。見落としを防ぐためにグローバルエラーハンドラを併用するのが理想的です。

一般的なトランザクションの安全性。これも必須です。常に「フェイルクローズ」を徹底し、問題が発生した場合はトランザクション全体をロールバックしてください。中途半端な修正は、より大きな問題を引き起こす可能性があります。

一元化されたログ記録、監視、アラート。グローバル例外ハンドラと組み合わせることで、インシデントの迅速な調査とイベント処理の均一化が可能になり、コンプライアンス要件への対応も容易になります。

脅威モデリングやセキュア設計レビュー。プロジェクトの設計段階で実施します。

コードレビューや静的解析。さらに、最終システムに対するストレステスト、パフォーマンステスト、ペネトレーションテストを実施します。

「例外的な状況の不適切な処理」は新しいカテゴリかもしれませんが、サイバーセキュリティの基本原則に関わるものであり、企業が予期せぬ事態に備える必要性を強調しています。どのような例外が発生するかは予測できなくても、発生すること自体は避けられません。重要なのは、すべてを同様に処理する準備をしておくことであり、それにより不可避な事態が発生した際の検知と対応が容易になります。

SCW Trust Score™ ユーザーの皆様へ：

学習プラットフォームのコンテンツをOWASP Top 10 2025標準に合わせて更新する過程で、フルスタック開発者のTrust Scoreにわずかな調整が生じる場合があります。ご不明な点やサポートが必要な場合は、カスタマーサクセス担当者までお問い合わせください。