Webアプリケーションのロジックを突く「ビジネスロジック脆弱性」

背景と概要

Webアプリケーションのセキュリティ対策といえば、SQLインジェクションやクロスサイトスクリプティング（XSS）といった「技術的なコードの不具合」を修正することが主流でした。

しかし近年のWebアプリケーションでは、コード自体の書き方には問題がないものの、システムの「設計仕様や業務フローの想定外の隙」を突く「ビジネスロジック脆弱性（Business Logic Vulnerability）」が悪用されるケースが増加しています。自動スキャンツールでは検知しにくいため、見落とされやすい危険性を孕んでいます。

ビジネスロジック脆弱性の代表的な悪用事例

人間のロジックの想定漏れを突くため、手口は極めて多岐にわたります。

1. 決済処理・数量パラメータの不正改ざん

ECサイトの購入フローにおいて、ブラウザ側で送信されるリクエストの金額パラメータ（`price=1000`）をプロキシツールでマイナス値や「1」に変更して決済を完了させたり、クーポンの重複適用チェックの漏れを突いて無制限に割引を受ける手口です。

2. ステップの飛び越し（ワークフロー迂回）

「カート確認 → 決済情報入力 → 完了」という多段階の処理手順において、URLを直接書き換えることで「決済情報入力」の画面を飛ばして直接「完了」レスポンスを呼び出す手口です。

3. 予約・在庫保持ロジックの買い占め悪用

チケット予約サイトなどで、決済直前の「在庫キープ状態」を自動プログラムで大量発生させ、他のユーザーの購入を物理的に妨害・買い占める行為です。

自動化ツールで検知できない構造的理由

通常の脆弱性診断ツール（DAST）は、既知の攻撃パターン（`' OR '1'='1` など）を入力してエラーが発生するかを確認します。しかし、ビジネスロジック脆弱性の通信は「正常なHTTPリクエストの範囲内」で行われるため、ツールはそれが攻撃であるか正常な操作であるかを判別できません。

設計・開発段階における防衛アプローチ

仕様策定フェーズでの脅威モデリングと、サーバー側での厳格な状態管理が必要です。

1. サーバーサイドでの状態管理と再検証の徹底

金額や権限など重要なパラメータはクライアント（ブラウザ）側の入力値を決して信用せず、必ずサーバー側のデータベース情報を元に最終検証・再計算を行います。

2. 脅威モデリング（Threat Modeling）の実施

設計段階において、「もしユーザーがステップ3を直接実行したらどうなるか」「マイナスの値を入力したらどうなるか」といった異常系のユースケースを洗い出すレビューを実施します。

3. 手動によるビジネスロジック診断の導入

セキュリティ診断を外部委託する際、自動スキャンだけでなく、人間の診断員が業務フローの文脈を理解して行う「手動ペネトレーションテスト」を組み込みます。