2026.05.01 2026.05.14

【ビジネスロジック編】仕様の隙間を突く攻撃と守り方｜CTF思考フレームワーク #13

安全に生きたい編集部

📖 この記事はシリーズの一部です

「CTF思考フレームワーク」　Web脆弱性編　#13 / 公開中 10記事　→　シリーズ一覧を見る →

ビジネスロジック脆弱性は、ツールだけでは見つけにくい「人間が考える」タイプの脆弱性です。SQLインジェクションのように入力値の構文だけを見るのではなく、業務フロー・状態遷移・価格計算・クーポン・返金・本人確認など、サービスの仕様そのものに潜む隙を探します。

ECサイト、ポイント還元、サブスク、招待制度、本人確認、返金処理。ビジネスルールが複雑になるほど、想定外の組み合わせや例外処理が増えます。そこに、ビジネスロジック脆弱性が入り込む余地があります。

注意：この記事で扱う考え方は、必ずCTF・自分の検証環境・許可された診断範囲でのみ使ってください。実在するECサイト、金融サービス、ポイントサービス、サブスクサービスなどで試すことは、不正利用や規約違反、犯罪につながる恐れがあります。

ビジネスロジックの穴はスキャナだけでは見つけにくい。仕様を読んで「この順番、本当に守られてる？」と考える力が重要だよ🧠

この記事の難易度

難易度：★★★（上級）　／　所要：10〜12分　／　前提：CTF思考フレームワーク #12

Contents

👀 観察フェーズ：まず何を見る？
🤔 仮説フェーズ：攻撃者は何を考える？
🔬 検証フェーズ：どうやって確かめる？
⚔️ 攻撃フェーズ：CTFで見る典型パターン
🛡️ 防御フェーズ：どう守る？
🔑 あわせて見直したい基本対策
⚠️ よくある落とし穴
🧰 ツール早見表
🎓 本気で学びたい人へ
📚 もっと深く学びたい人へ
⚖️ 大事なお約束
📚 次に読みたい
🧪 自分で検証してみる

👀 観察フェーズ：まず何を見る？

まず業務フロー全体を俯瞰！「数量・価格・順序・条件」の組み合わせに穴がないかを見るのが鍵🔍

ビジネスロジックは、通常の利用だけでは見えにくい「例外処理」や「想定外の組み合わせ」に弱点が出ます。普通のユーザーが通らないエッジケースを確認することで、仕様の抜けや設計上のリスクを見つけられます。

数量に上限がない / 負の値が通る / 手順を飛ばせる / 値段をクライアント側から受け取っているといった設計の油断は、典型的な落とし穴です👀

「ありえない使い方」をしたとき、エラーで止まる？それとも普通に通ってしまう？そこを見るんだね😲

🤔 仮説フェーズ：攻撃者は何を考える？

ビジネスロジックの典型的な穴は4分類で考えると整理しやすいよ。

💰 仮説①：価格・数量の信頼ミス

価格、割引額、送料、数量などを、クライアントから送られてきた値のまま信用していないかを確認します。本来はサーバー側で商品ID・会員状態・クーポン条件・在庫・送料などをもとに再計算すべきです。

🔢 仮説②：境界値・異常値の扱い

負の数、ゼロ、極端に大きい数、小数、空文字、重複リクエストなど、通常の画面操作では入りにくい値を受け取ったときに、仕様どおり止まるかを確認します。型・範囲・整合性のチェックが弱いと、想定外の状態が生まれます。

⏭️ 仮説③：手順スキップ・状態遷移の抜け

本人確認、メール認証、支払い確認、承認フローなど、本来は前段のステップを完了してから進むべき処理があります。UI上は順番どおりに見えても、API側で状態遷移を確認していないと、途中ステップを飛ばされる恐れがあります。

🎁 仮説④：割引・返金・ポイント・紹介制度の組み合わせ

クーポン、ポイント還元、返金、キャンセル、紹介特典、無料トライアルなどは、単体では正しくても、組み合わせると不整合が起きることがあります。「併用不可」「1回限り」「返金時のポイント処理」などの仕様が、サーバー側で一貫して守られているかを見ます。

ビジネスロジック攻撃の本質は、「仕様書のスキマ」や「実装者が想定していないユースケース」を突くことです。だからこそ、守る側はコードだけでなく、業務フローそのものをレビューする必要があります。

コードのバグだけじゃなくて、仕様の抜けも脆弱性になるんだね💡

🔬 検証フェーズ：どうやって確かめる？

「マイナス・ゼロ・上限超え・順序逆・重複実行」を1つずつ試して、挙動を表にまとめると見えてくるよ📊

検証では、いきなり大きな操作をするのではなく、CTFやローカル検証環境で小さな条件変更を1つずつ試します。数量、金額、クーポン、状態、ユーザー権限、処理順序を変えたとき、どこで止まり、どこで通るのかを観察します。

重要なのは、「正常系だけでなく、異常系・境界値・組み合わせ」を見ることです。ビジネスロジックの穴は、たいてい正常な画面操作では見えません。

スキャナで一発検出というより、人間の脳と仕様書が一番の武器なんだね🧪

⚔️ 攻撃フェーズ：CTFで見る典型パターン

ここでは実サービスに対して試せる手順ではなく、CTFやローカル検証環境でよく出る「考え方」だけを整理します。具体的な検証は、必ず自分の環境・CTF問題・許可されたラボ内で行ってください。

ビジネスロジック攻撃の代表パターンはこの3つで整理できるよ。

① 価格・割引の信頼ミス

価格・割引・送料などを、クライアントから受け取った値のまま信頼していないかを確認するパターンです。サーバー側で再計算していない場合、想定外の金額で処理される恐れがあります。

② 手順スキップ・状態遷移の不備

本人確認、承認、支払い確認など、前段のチェックを通らずに重要処理へ進めないかを確認するパターンです。状態遷移が甘いと、未確認状態のまま高リスク処理に到達される恐れがあります。

③ 特典・返金・紹介制度の不整合

割引、返金、ポイント、紹介制度、無料トライアルなどを組み合わせたときに、想定外の利益や重複付与が発生しないかを確認するパターンです。

CTF{server_must_recompute_prices_and_validate_state}

ビジネスロジック攻撃の防御は、「サーバーが状態の正本を握り続けること」です。クライアントから来た数値や状態は、あくまで入力値であり、最終判断はサーバー側で行います。

🛡️ 防御フェーズ：どう守る？

ビジネスロジックの守りは「サーバー側で全部再計算」が鉄則！🛡️

💵 価格・数量はサーバー側で再計算

クライアントから受け取るのは、原則として商品ID・数量・クーポンコードなどの入力情報だけにします。価格・割引・送料・在庫・会員ランクによる条件は、サーバー側で都度計算します。

📐 入力バリデーションを多層に

型・範囲・整合性を3段階でチェックします。負の数、ゼロ、極端な値、想定外の組み合わせ、重複実行などは、サーバー側で早期に弾きます。

🪜 状態遷移を厳格に

ステートマシンで許可された遷移だけを許します。「未確認→送金」「未決済→発送」「未承認→返金」のような飛び級遷移は、UIだけでなくAPI側でも必ず弾きます。

🔁 返金・キャンセル・ポイント処理を一体で検証

購入・付与・返金・キャンセルは別々に見ず、一連の状態遷移として検証します。返金後にポイントが残る、キャンセル後に特典だけ残る、紹介特典が重複する、といった不整合を防ぎます。

🧾 高リスク操作は監査ログを残す

価格変更、返金、クーポン適用、送金、本人確認状態の変更などは、誰が・いつ・どの状態で実行したかを記録します。後から不正利用や仕様漏れを追える設計にします。

「技術だけじゃなく仕様の堅さ」がビジネスロジック防御の肝なんだね💪

🔑 あわせて見直したい基本対策

ビジネスロジック脆弱性の直接対策ではありませんが、セキュリティ全体を見直す際に、パスワードの使い回しも同時に改善しておくと安心です。パスワード管理ツールを使って、サービスごとに異なるパスワードを管理しましょう。

※ 上記は他社サービスへのリンクです。購入は各自でご判断ください。

⚠️ よくある落とし穴

クライアントから送られる金額・割引額をそのまま使う。
「併用不可」をフロントエンドだけで実装して、API側には反映しない。
ステップ式フローの途中ステップを「UI上は飛ばせないから安全」と思い込む。
返金・キャンセル時にポイントを戻し忘れる、または重複付与する。
紹介プログラムで本人確認・支払い手段・端末情報などを総合的に見ず、単純な条件だけで判断する。
無料トライアル終了後の自動課金タイミングと、キャンセル処理の整合性を検証していない。

🧰 ツール早見表

ビジネスロジックは、道具より「仕様読解力」が主役です。補助ツールとしては、以下のようなものが役立ちます。

ツール・資料	用途	ひと言
Burp Suite	リクエスト確認	CTF・許可された診断で、APIの流れを確認する
Postman	API手動確認	許可された範囲で、状態遷移やレスポンスを確認する
状態遷移図	業務フロー整理	許可される順序と禁止される順序を可視化する
テスト用アカウント管理表	権限・状態別の確認	未認証・認証済み・停止中などを分けて検証する
仕様書・利用規約	攻撃面の発見	実は最重要の資料。仕様と実装のズレを見る