business-logic-testing について
Business Logic Testingは、アプリのルールや状態を持つワークフローの欠陥を探すセキュリティテスト用スキルです。前提の検証、手順や状態遷移の悪用、並行処理、金額関連のテストを導き、業務への影響に沿って結果をまとめます。
主な機能
- 01想定フローと前提の整理
- 02手順の省略や入れ替えのテスト
- 03状態遷移の検証
- 04一度限りの処理に対する並行テスト
- 05価格、返金、上限のテスト
活用シーン
- 01購入と決済ルールの評価
- 02クーポンや引き出しの競合テスト
- 03返金額が支払額を超えるか確認
- 04並行リクエストでユーザー上限を検証
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/business-logic-testingを入力して読み込まれたか確認します。
同梱ファイルreferences/logic-attack-patterns.md
詳細
ビジネスロジックテスト（発見／悪用 — プロの腕の見せどころ）
概要
アプリの「どのようなコードで書かれているか」ではなく、「アプリで何ができるか」の欠陥を見つけます。これは、有効なリクエストによって無効な結果が生じる問題です。たとえば、0ドルで購入できる、返金を2回受けられる、必須の手順をスキップできるといったものです。こうした問題はそれぞれがビジネスルール固有のものなので、スキャナーでは見つかりません。
基本原則： アプリが強制するのは「想定された」フローです。あなたは、依然として「動作する」あらゆる「想定外」の経路をテストします。「この機能は何を前提としているのか。その前提を崩したらどうなるのか？」と考えましょう。
該当する場合／スキップする場合
- 該当する場合： アプリに複数ステップのワークフロー、金銭／クレジット／利用枠、状態を持つプロセス、または悪用可能なビジネスルールがある。
- スキップする場合： ルールも状態もない、ステートレスな単一アクションのユーティリティの場合 → 該当なし（まれなケースです。ほとんどのアプリには何らかのロジックがあるため、スキップする前によく確認してください）。
- 該当しない場合： 「business-logic-testing: N/A — no stateful workflow/rules」と報告して終了します。
⚠️ 認可
自分のアプリ／テストデータを使用してください。ロジックの悪用は金銭や状態を動かす可能性があるため、本番以外の環境を使用してください。
手法
- 想定されたフローを理解する — 各手順、ルール、前提を整理します（順序：追加 → 支払い → 発送、ルール：数量 ≥ 1、前提：価格はサーバーから取得する）。
- 各前提を検証する — 負の値／ゼロ／極端に大きな値、手順のスキップや並べ替え、サーバー側で管理すべきクライアント提供値、アクションの繰り返しを試します。
- ステートマシンを攻撃する — 順序を無視した状態に到達したり、終端状態に戻ったりします。
- 並行処理を攻撃する — 「1回限り」のアクションを多数並列で実行します（競合状態／TOCTOU）。
- 数量と金銭を攻撃する — 価格、合計額、通貨、割引、端数処理、制限を改ざんします。
具体的なパターンの一覧は references/logic-attack-patterns.md を参照してください。
クイックリファレンス — 典型的なロジックの欠陥
| パターン | 例 |
|---|---|
| パラメーターの改ざん | サーバーが信頼するリクエスト内の price、total、qty、userId、status を変更する |
| 負の値／オーバーフロー | qty=-1 でクレジットが付与される。極端に大きな値でオーバーフローする。0 で課金を回避できる |
| ワークフローのバイパス | 「支払い」／「検証」を行わずに「確認」／「ダウンロード」へ直接進む |
| ステートマシンの悪用 | すでに発送済みの注文をキャンセルする。クローズ済みのチケットを再開して権限を得る |
| 競合状態／TOCTOU | 1枚のギフトカード／クーポン／出金を並列処理でN回引き換える |
| リプレイ | 署名付き／1回限りのリクエスト（支払いコールバック、OTP、冪等性キー）を再送する |
| 割引／返金の悪用 | クーポンを併用する、支払額を超えて返金を受ける、一部返金を繰り返す |
| 制限のバイパス | 並列リクエストや複数のセッションを使い、ユーザーごとの上限を超える |
競合状態テスト（効果が高く、見落とされがち）
「回数制限のある」アクションを同時に（順番にではなく）何度も送信し、成功回数が1回を超えるか確認します。たとえば、1回限りのクーポンを20件のリクエストで並列に引き換えます。ツール：Burp Turbo Intruder、または同一のリクエストを一斉に送信する並列 curl／スクリプト。
出力
想定されたルール、それを破ったリクエスト、ビジネスへの影響（金銭的損失、制限のバイパス、権限の獲得）を説明する検出事項を記載します。深刻度は実社会への影響に基づき、多くの場合は「クリティカル」です。
引き継ぎ
active-pentest を使用してステージング環境で安全に再現します。vulnerability-chaining で認証／アクセス制御の問題と組み合わせ、security-hardening で修正します（サーバー権威の値、アトミックなトランザクション／ロック、冪等性キー、サーバー側での状態検証）。
よくある間違い
- コードの臭いを探す — ロジックのバグは「有効な」リクエストに潜んでいるため、「ルール」を把握する必要があります。
- バグが並行処理時にしか発生しないのに、アクションを順番にテストする。
- クライアント送信の価格／合計額／上限を信頼する — サーバー側ですべて再計算し、そのとおりに動作することをテストしてください。
- クーポン、紹介、ロイヤルティポイント、トライアル、返金などの「地味な」機能を無視する — これらは悪用の格好の標的です。