ビジネスロジック脆弱性とは？自動スキャナが見落とす業務フロー上の欠陥と対策を現場目線で解説

自社のECサイトや社内システムに自動スキャナをかけて「問題なし」と出た。WAFも導入している。それでも、攻撃者が業務フローの抜け穴を使って価格を改ざんしたり、クーポンを何度も使い回したり、他の社員のデータにアクセスしたりできてしまう——そんなケースが実際の現場で起きています。

これが「ビジネスロジック脆弱性」と呼ばれる問題です。SQLインジェクションやXSSといった技術的な脆弱性と違い、業務フローの設計上の欠陥を突く攻撃は、ツールでは検出できないことがほとんどです。

この記事では、ビジネスロジック脆弱性の定義・代表的な攻撃パターン・具体的な防御手順を、現場で使えるレベルで解説します。インフラエンジニアや社内SE、中小企業の情シス担当者が自社システムの設計を見直すきっかけになれば幸いです。

ビジネスロジック脆弱性とは？

ビジネスロジック脆弱性（Business Logic Vulnerability）とは、アプリケーションが持つ「業務上のルール・手順・フロー」の設計上の欠陥を突く脆弱性です。

コードの書き方のミスではなく、「仕様が正しく実装されていても、その仕様自体に穴がある」という点が大きな特徴です。

・技術的脆弱性（SQLインジェクション・バッファオーバーフローなど）: コードの実装ミスが原因。自動スキャナで検出可能なケースが多い
・ビジネスロジック脆弱性: 業務設計の論理的な欠陥が原因。自動スキャナではほぼ検出不可能

具体例を出すとこういったイメージです。

・ECサイトで「クーポンを何度でも適用できる」仕様になっている
・送金アプリで「マイナス金額の送金」が処理できてしまう
・パスワードリセット後も古いセッションが無効化されない
・管理者の承認フローを途中でスキップできる状態になっている
・注文確認画面を経由せずに決済ステップへ直接リクエストを送れる

OWASP（Open Web Application Security Project）でも独立したカテゴリとして扱われており、Webアプリケーション診断の現場では「手動テストでしか見つけられない脆弱性」として知られています。

攻撃の仕組み（敵を知る）

ビジネスロジック脆弱性を悪用する攻撃者は、まずターゲットとなるアプリケーションの通常フローを丁寧に観察します。「正規のユーザーとして動き、仕様の抜け穴を探す」のが基本戦術です。攻撃コードを送りつけるのではなく、正規のリクエストの値や順序を操作する点がツールでは検出しにくい理由です。

以下に代表的な攻撃パターンを、防御目的で解説します。

1. 価格・数量の改ざん

ECサイトで商品をカートに入れ、決済リクエストを途中で傍受して金額や数量のパラメータを書き換える手法です。サーバー側で「クライアントから送られた金額をそのまま信用」していると成立します。1円の商品を100,000円の商品として決済させられる（逆から言えば100,000円の商品を1円で購入される）といった被害に直結します。

2. クーポン・ポイントの二重使用

本来1回しか使えないクーポンや紹介コードを、複数のアカウントや同一アカウントで繰り返し使用する攻撃です。使用済みフラグの確認やレート制限が不十分な場合に発生します。並行リクエストを高速に送ることで、「チェック」と「消費」の間の隙間をつく競合状態（Race Condition）として発生することもあります。

3. ワークフロー迂回（手順スキップ）

「手順1 → 手順2 → 手順3」という処理フローを、手順2を飛ばして「手順1 → 手順3」に直接リクエストを送ることで迂回します。たとえば「メールアドレス確認 → パスワード設定 → ログイン」というフローで、確認ステップを飛ばしてパスワード設定に直接アクセスできてしまうケースです。サーバー側でフローの順序を検証していない場合に起きます。

4. 権限の水平移動・垂直移動

「自分のアカウントのデータを見る」リクエストのIDを書き換えて「他のユーザーのデータ」にアクセスする（水平移動）、または一般ユーザーが管理者機能に直接アクセスできてしまう（垂直移動）攻撃です。URLやリクエストのパラメータにある「user_id=123」を「user_id=124」に変えるだけで成立するケースがあります。

5. 負の値・境界値の悪用

「返品処理」で負の数量（-1個）を指定して残高を増やす、0円の商品を大量購入してポイントだけを稼ぐ、整数の最大値を超えてオーバーフローさせるといった手口です。入力値の範囲チェックが不十分な場合に発生します。

具体的な防御手順

1. 脅威モデリングで業務フローを可視化する

まず「このアプリケーションで何をされたら困るか」を業務の観点で洗い出すことが先決です。STRIDE手法などを使い、業務フロー図（シーケンス図）を書いた上で「各ステップで何を確認・検証しているか」を整理します。

「攻撃者が正規ユーザーとして操作したとき、どのステップで何ができてしまうか」という視点でフローを読み返すと、設計上の穴が見えてきます。脅威モデリングの具体的な手順については、姉妹サイトDXMaster.JPのDX推進リスク管理とあわせて考えると、経営層への説明材料にもなります。

2. サーバー側で必ず検証・再計算する

クライアント（ブラウザ・スマートフォンアプリ）から送られてくる金額・数量・ステータス・フラグは「すべて攻撃者が改ざんできる値」として扱います。

# NG例: クライアントから送られた金額をそのまま使う
amount = request.params[:amount].to_i
process_payment(amount)

# OK例: サーバー側でDBから商品情報を参照して金額を再計算する
cart_items = Cart.find_by_session(session_id)
amount = cart_items.sum { |item| item.product.price * item.quantity }
process_payment(amount)

価格・在庫・ポイント残高などの重要な値は、必ずDBを参照してサーバー側で計算し直してから処理します。

3. ワークフローの順序と状態をサーバー側で管理する

複数ステップで構成されるフロー（本人確認→注文確認→決済→完了）は、サーバー側のセッションに「現在のステップ」を保持し、前のステップが完了していなければ次のステップに進めない実装にします。

ステータス管理に状態機械（State Machine）のパターンを使うと、不正な状態遷移を設計レベルで防ぎやすくなります。

# フローのステップをサーバーセッションで管理する例
def proceed_to_payment
  # 前のステップ（注文確認）が完了していない場合はリダイレクト
  unless session[:order_confirmed]
    redirect_to order_confirm_path, alert: '注文内容を確認してください'
    return
  end
  # 決済処理を続ける
end

4. レート制限と排他制御でクーポン・ポイントを守る

クーポン・ポイント・無料トライアルなど「1人につき1回」の制限があるものには、必ずDBレベルで「使用済みフラグ」を設け、競合リクエストに備えてトランザクション＋行ロック処理を行います。

# 競合状態を防ぐためにトランザクション＋行ロックを使う（Rails例）
ActiveRecord::Base.transaction do
  # SELECT FOR UPDATE で行ロックを取得
  coupon = Coupon.lock.find_by!(code: params[:code])
  raise AlreadyUsedError if coupon.used?
  coupon.update!(used: true, used_by: current_user.id, used_at: Time.now)
  apply_discount(order, coupon)
end

5. 手動テストに業務ロジックのチェック項目を追加する

自動スキャナだけに頼らず、ペネトレーションテストや手動のWebアプリ診断に「業務ロジックのテスト」を明示的に組み込みます。ベンダーへの診断依頼時には「OWASP Testing Guide の Business Logic Testing セクション（OTG-BUSLOGIC-001～009）を診断スコープに含めること」と仕様書に明記するのが確実です。

CVSSスコアだけでは業務ロジックの危険度は測れないため、「悪用された場合の業務影響」で独自にリスク評価することも重要です。CVSSの読み方についてはCVSSとは？脆弱性スコアの読み方・優先度判断を現場目線で解説をあわせてご覧ください。

中小企業でも今日からできること

「診断を外部ベンダーに発注する予算がない」という場合でも、以下の対策はすぐに始められます。

・業務フロー図を書く: 既存システムの処理フローを図に書き起こし、「各ステップで何を検証しているか」を確認する。金額・ポイントなど重要な値の流れに注目する。
・金額・数量はサーバー側で再計算する: ECサイトや決済機能があれば、クライアントから送られる金額を無条件に信用していないか確認する。
・入力値の範囲チェックを追加する: 数量・金額・インデックスにマイナス値・ゼロ・最大値を入力してみて、正しくエラーになるか手動で確認する。
・ログで異常な操作を監視する: 同一アカウントからの短時間での大量リクエスト、通常範囲を超えた金額・数量などを検知するログ監視を設定する。
・開発・発注の要件書に追加する: 社内開発やベンダーへの発注時に「業務ロジックのテスト項目」を要件に含めるだけで品質は変わる。

OWASP Top 10の基礎的な理解があると、何をどの順で対策すべきかの優先度がつけやすくなります。OWASP Top 10とは？2021年版の全脆弱性リスト・各項目の意味と対策も参考にしてください。

よくある誤解と注意点

「WAFを導入しているから安全」は誤り

WAFはSQLインジェクションやXSSなど、リクエストパターンに特徴のある攻撃には有効です。しかしビジネスロジック脆弱性への攻撃は「正規の形式のリクエストで、値や順序だけを変える」手法が多く、WAFのシグネチャでは検出できません。WAFは必要ですが、業務ロジックの欠陥をカバーする手段にはなりません。

「脆弱性スキャナで問題なし」は安全を意味しない

自動スキャナはコードの技術的な欠陥を検出するツールです。業務設計の論理的な欠陥を評価する機能はほとんどありません。スキャンのスコープと、業務ロジックテストのスコープは別物として管理する必要があります。

「社内向けシステムだから安全」は通用しない

イントラネットや社内向けシステムでも、業務フローの欠陥は内部不正や誤操作の温床になります。特に権限の水平移動（他の社員のデータへの不正アクセス）は、認証を突破しなくても起こりえます。内部不正についてはインサイダー脅威（内部不正）とは？手口・被害例・対策も参考にしてください。

「再現が難しいから後回し」は危険

業務ロジックの脆弱性は「攻撃が成立しても証拠が残りにくい」特性を持つものがあります（正規のリクエストと区別がつかないため）。発見が遅れるほど被害が長期化するリスクがあります。

本記事のまとめ

ビジネスロジック脆弱性は「アプリを使いこなした上で仕様の穴をつく」攻撃手法です。技術的なセキュリティ対策と並行して、「このシステムで何をされたら困るか」を業務の観点から考えることが防御の第一歩になります。

「スキャナで問題なし」の後も、業務フローの目視点検と手動テストを定期的に組み込む習慣をつけることをお勧めします。セキュリティは一度やれば終わりではなく、仕様変更や機能追加のたびに見直すプロセスとして位置づけることが大切です。