sast-businesslogic

ビジネスロジックの脆弱性検出

コードベースにおけるビジネスロジックの脆弱性を見つけるため、対象を絞ったセキュリティ評価を実施します。このスキルでは、サブエージェントを用いた3段階のアプローチを採用します。脅威モデリング（ドメインを理解し、攻撃シナリオを作成する）、バッチ単位での検証（シナリオが悪用可能かどうかを3件ずつ並行して確認する）、統合（各バッチの結果をまとめる）です。

前提条件：sast/architecture.md が存在している必要があります。存在しない場合は、先に分析スキルを実行してください。

---

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

ビジネスロジックの脆弱性は、アプリケーションが意図したワークフロー、ルール、制約を操作することで、インジェクションやメモリ破損といった技術的な欠陥を悪用せずに、意図しない結果を引き起こせる場合に発生します。攻撃者はアプリケーション自体の機能を利用しますが、開発者が想定していなかった方法でそれらを使います。

中心となるパターンは次のとおりです。アプリケーションは、構文的に正しく、認証・認可も通過する入力を受け付けますが、その入力はコードで強制されていないビジネスルールに違反しています。

ビジネスロジックの脆弱性に該当するもの

• 購入エンドポイントに負の数量を送信し、請求される代わりに入金を受ける
• 1回限りの割引クーポンを、並行リクエストで複数回適用する
• 後のステップのリクエストを再送し、複数ステップの購入手続きで支払いステップを省略する
• 評価の上限が5であるはずの映画評価エンドポイントに、9999の評価を投稿する
• 負の金額を送金し、受取人から送金者へ資金を移動させる
• 2つ目のアカウントを使って自分を紹介し、紹介ボーナスを獲得する
• 無効化されていない1回限りのリセットトークンやバウチャーを再利用する
• 在庫確認と予約の間の競合状態により、在庫切れの商品を購入する
• 無料プランにダウングレードした後も、プレミアムサブスクリプション機能にアクセスする
• 他の入札者が脱落した後、高額入札を撤回してオークションに勝つ

ビジネスロジックの脆弱性に該当しないもの

以下をビジネスロジックの問題として報告しないでください。

• SQL インジェクション、XSS、RCE、XXE、SSRF、SSTI：これらはインジェクションや技術的な欠陥です。別のスキルで扱います
• 認証の欠如：エンドポイントでログインが一切必要ない場合、これは「未認証アクセス」です
• IDOR：IDを変更して他のユーザーのリソースにアクセスすることです。これは別のアクセス制御の分類です
• ブルートフォース／レート制限：ログインに対する一般的なレート制限の回避は、特定のビジネスルールの迂回を可能にする場合を除き、ビジネスロジックの欠陥ではありません

---

ビジネスロジックの攻撃カテゴリ

脅威モデリングの指針として、以下のカテゴリを使用してください。すべてのカテゴリがすべてのアプリケーションに当てはまるわけではありません。アーキテクチャの概要に基づいて、関連するカテゴリを特定してください。

1. 価格と支払いの操作

• 購入エンドポイントでの負またはゼロの価格
• リクエストボディでの任意の価格上書き（価格フィールドの一括割り当て）
• 通貨や単位の混同（例：セントとドル）
• 金額計算における浮動小数点精度の悪用
• 合計金額がマイナスになる割引の適用

2. 数量と数値制限の違反

• 負の数量（−5個を注文して入金を受ける）
• ユーザー単位または注文単位の上限を超える数量
• 数量または残高の計算における整数のオーバーフロー／アンダーフロー
• 範囲が制限されたフィールド（評価、スコア、割合）での範囲外の値

3. ワークフローと複数ステップのプロセスの回避

• 順次実行されるプロセスで必須ステップ（支払い、メール認証、本人確認）を省略する
• 以前に成功したフローの完了トークンを再送してステップを回避する
• 先行するステップを完了せずに、後続段階のエンドポイントへ直接アクセスする
• 中間状態を経由せずに終端状態への遷移を送信する（状態機械の違反）

4. クーポン、割引、バウチャーの悪用

• 1 回限りの使用制限が適用されていないクーポンを複数回適用する
• 組み合わせて使うことを想定していない割引を併用する
• 有効期限が切れたクーポンやバウチャーを使用する
• 有効なクーポンコードを生成または推測する

5. 競合状態と並行処理の悪用

• 二重使用：残高を一度だけ消費するために、購入リクエストを 2 件同時に送信する
• クーポンの同時利用により、許可された金額を超えるクレジットを消費する
• 在庫に対する TOCTOU（確認時と使用時）：両方のリクエストで確認が通り、どちらの予約も成功する
• 残高を超える並行出金／送金リクエスト

6. 返金とチャージバックの悪用

• デジタル商品を消費またはダウンロードした後に返金を請求する
• すでに一部返金済みの注文に対して、さらに一部返金を請求する
• （サーバー側でロジックが適用されていない場合）物理商品を返品せずに返金を受ける

7. 報酬、紹介、ロイヤルティの悪用

• 2 つ目のアカウントを使って自分を紹介し、紹介ボーナスを獲得する
• 複数のアカウントを作成して、サインアップボーナスを何度も獲得する
• 不自然な活動を通じてロイヤルティポイントを稼ぐ
• 譲渡不可の報酬を共有または譲渡する

8. サブスクリプションと利用権の回避

• ダウングレードまたは解約した後も、有料／プレミアム機能にアクセスする
• トライアル期間を悪用する（トライアルアクセスのために新しいアカウントを繰り返し作成する）
• サブスクリプション作成時にのみ機能フラグやプランを確認し、機能へのアクセス時には確認しない
• セッション開始時にキャッシュした利用権を、プラン変更後に再評価しない

9. オークションと入札のロジック

• 競合する入札が拒否された後に、落札した入札を取り下げる
• サクラ入札：管理下にあるアカウントで人為的に価格をつり上げる
• 最低落札価格の適用を回避する
• 同時リクエストを利用して入札を操作する

10. 在庫とストックのロジック

• 在庫確認が欠落しているため、在庫切れの商品を購入する
• 同時リクエストを利用して、利用可能数を超える在庫を予約する
• 返金時に在庫を戻さないロジックにより、在庫数がマイナスになる
• 幻の在庫：商品が購入可能に見えるが、注文を履行できない

11. 時刻と日付のロジック

• 期限付きオファーの期限切れ後も利用する（期限の確認がクライアント側で行われる、またはサーバー側の確認が不十分）
• 取引や予約の日付を過去に遡らせる
• 「猶予期間」のロジックを悪用して、特典を無期限に延長する
• サーバーがクライアントから送信されたタイムスタンプを信頼している場合に、システムクロックを操作する

12. 送金と残高のロジック

• マイナス額を送金する（送金者が受取人から金銭を受け取る）
• ボーナスや手数料のロジックを悪用するために自分自身へ送金する
• サーバー側の確認が欠落しているため、利用可能な残高を超えて送金する
• 多数の少額取引を通じて丸め誤差を悪用する

---

実行

このスキルはサブエージェントを使用して 3 つのフェーズで実行されます。sast/architecture.md の内容をすべてのサブエージェントにコンテキストとして渡してください。

フェーズ 1：脅威モデリング — ドメイン分析と攻撃シナリオの生成

次の指示でサブエージェントを起動します。

目標：コードベースを分析してビジネスドメインを理解し、このアプリケーション固有のビジネスロジックに対する具体的で優先順位付けされた攻撃シナリオの一覧を作成します。結果を sast/businesslogic-threats.md に書き込んでください。

コンテキスト：プロジェクトのアーキテクチャ概要が提供されます。それを使って、アプリケーションの機能、備えている機能、適用されるべきビジネスルールを理解してください。ドメインの理解に専念し、まだ脆弱性の検証は行わないでください。

ステップ 1 — ビジネスドメインと機能を特定する：

sast/architecture.md を読み、その後コードベースを調べて、次の問いに答えてください。

• このアプリケーションは何をするものですか？（EC、マーケットプレイス、SaaS、ソーシャルプラットフォーム、フィンテック、ゲーム、予約サービスなど）
• どのような金銭的または取引関連の機能がありますか？（決済、サブスクリプション、クレジット、トークン、ウォレット、請求書、返金）
• どのような数量上の制限やルールがありますか？（評価、スコア、数量、利用制限、クォータ）
• どのような複数ステップのワークフローがありますか？（チェックアウト、オンボーディング、KYC、予約、オークション）
• どのようなプロモーション機能や特典機能がありますか？（クーポン、紹介、ロイヤルティポイント、ボーナス、バウチャー）
• どのようなロールやティアの区別がありますか？（無料と有料、ユーザーとプレミアム、トライアルとフル）
• どのような在庫や容量の制約がありますか？（在庫、座席、枠、帯域幅）

機能を見つけるには、次を検索してください。

• ルート／エンドポイントの定義とその名前
• モデル／エンティティ名（Order、Payment、Subscription、Coupon、Wallet、Bid など）
• ビジネスルールに関連するフィールド名（price、quantity、balance、rating、score、limit、quota、expiry、status）
• バリデーションロジックや制約関連のコード

ステップ 2 — 攻撃シナリオを作成する：

関連するビジネスドメイン領域ごとに、具体的な攻撃シナリオを作成してください。各シナリオは次の条件を満たす必要があります。

• このコードベースに固有 — 実際のエンドポイント、モデル、または機能を明記する
• 実行可能 — 攻撃者が具体的に何を送信／実行するかを説明する
• 根拠に基づく — シナリオが現実的である根拠となるコードやデータモデルを参照する

以下の攻撃カテゴリをチェックリストとして使用してください。このアプリケーションに関連するカテゴリのみ含めてください。

• 価格／決済の改ざん：ユーザーはリクエストで任意の価格を送信できますか？クライアントから送られた価格を信頼していますか？
• 数量／値の範囲外入力：ユーザーは負の数量、ゼロ、または定義された上限を超える値を送信できますか？
• ワークフローのバイパス：複数ステップのプロセスで必須のステップをユーザーが省略できますか？
• クーポン／割引の不正利用：クーポンを複数回、または有効期限後に使用できますか？
• 競合状態：共有リソース（在庫、残高、クーポンの使用状況）に対する確認後実行のパターンはありますか？
• 返金の不正利用：商品が消費された後でも返金を要求できますか？
• 特典／紹介の不正利用：紹介特典や登録ボーナスを繰り返し獲得できますか？
• 権限のバイパス：プレミアム機能はアクセス時に確認されますか、それともサブスクリプション時にしか確認されませんか？
• 送金／残高ロジック：負の送金や自分自身への送金ができますか？
• 日時ロジック：期間限定オファーはサーバー側で適用されていますか？
• 在庫ロジック：在庫は予約前にアトミックに検証されますか？

出力形式 — sast/businesslogic-threats.md に書き込んでください。

# ビジネスロジック脅威モデル：[Project Name]

## アプリケーションのドメイン
[アプリケーションの機能と主要なビジネス機能を2〜3文でまとめる]

## 特定したビジネス機能
- [機能 1]：[簡潔な説明、関連するモデル／エンドポイント]
- [機能 2]：...

## 攻撃シナリオ

### 1. [短いタイトル。例：「クレジット獲得を目的とした負の数量での購入」]
- **カテゴリ**：[例：数量および数値制限違反]
- **対象**：[エンドポイントまたは機能。例：`POST /api/orders`]
- **説明**：[攻撃者の操作と、期待する結果を説明する]
- **関連コード**：[関連ロジックが記述されているファイルと行の範囲]
- **適用されるべきビジネスルール**：[アプリケーションが実施すべき動作]
- **リスクレベル**：[高／中／低]

### 2. ...

[フェーズ 2 でのバッチ処理に必要なため、すべてのシナリオに ### 3.、### 4. ... のように連番を付けてください。]

## 該当しないカテゴリ
[チェックリストのうち、このアプリケーションに関連しないカテゴリとその理由を列挙する]

フェーズ 2：検証 — シナリオが悪用可能かどうかを確認する（バッチ処理）

フェーズ 1 が完了したら、sast/businesslogic-threats.md を読み、攻撃シナリオを最大 3 件ずつのバッチに分割します。バッチごとにサブエージェントを1 つずつ並列で起動します。各サブエージェントは割り当てられたシナリオのみを検証し、結果をそれぞれのバッチファイルに書き込みます。

バッチ処理の手順（サブエージェントではなく、オーケストレーターであるあなたが実施します）：

1. sast/businesslogic-threats.md を読み、番号付きのシナリオセクション（### 1.、### 2. など）の数を数えます。
2. 最大 3 件ずつのバッチに分割します。例：シナリオが 8 件の場合、3 つのバッチ（1～3、4～6、7～8）に分けます。
3. 各バッチについて、脅威ファイルから該当するシナリオセクションの全文を抽出します。
4. すべてのバッチサブエージェントを並列で起動し、それぞれに割り当てたシナリオのみを渡します。
5. 各サブエージェントは sast/businesslogic-batch-N.md（N は 1 から始まるバッチ番号）に書き込みます。

各バッチサブエージェントには、次の指示を与えます（バッチごとの値に置き換えてください）：

目標：割り当てられた各攻撃シナリオについて、ビジネスルールがコード内で適切に適用されているか、または攻撃が悪用可能かを判断してください。ビジネスロジックの脆弱性を見つけることが目標です。結果は sast/businesslogic-batch-[N].md に記述してください。

割り当てられたシナリオ（脅威モデリングのフェーズから）：

[割り当てられたシナリオのセクション全文を、元の番号を保持してここに貼り付けてください]

コンテキスト：プロジェクトのアーキテクチャ概要が提供されます。それを使って、検証パターン、ORM の使用方法、ビジネスルールが通常どこで適用されるかを理解してください。各シナリオで参照されているコードパスを追跡してください。

ビジネスロジックの欠陥に該当しないもの — ここでは報告しないでください：

• SQL インジェクション、XSS、RCE、XXE、SSRF、SSTI：別のスキルで扱います
• 認証の欠如：認証なしアクセス
• IDOR：別のアクセス制御の分類です
• 一般的なブルートフォース攻撃：ビジネスルールを明確に迂回する場合を除きます

各シナリオについて、以下を確認してください：

1. ビジネスルールはサーバーサイドで適用されていますか？

• 制約はバックエンドのハンドラー、サービスレイヤー、または ORM／データベースで検証されていますか？
• それとも、クライアントサイド（フロントエンドのフォーム検証、JavaScript の min/max 属性）でのみ検証されていますか？
• クライアントサイドのみの検証は悪用可能です。

2. 検証は完全で、すべてのエッジケースを網羅していますか？

• 該当する場合、負の値をチェックしていますか？
• 下限だけでなく、上限もチェックしていますか？
• 同時リクエストに対応していますか（チェックはアトミックですか、それとも TOCTOU の隙がありますか）？
• 使用時点で再検証していますか。それとも前の段階での検証のみですか？

3. ワークフロー迂回シナリオの場合：

• 各ステップで、前提となる必須ステップが完了していることを検証していますか？
• ステップの完了フラグはサーバーサイドに保存されていますか（リプレイ可能な Cookie やセッションだけに保存されていませんか）？
• 前のステップを経ずに、終端エンドポイントを直接呼び出せますか？

4. クーポン／バウチャーのシナリオの場合：

• クーポンはトランザクションと同時に（同じ DB トランザクション内で）アトミックに使用済みとして記録されますか？
• 同時引き換えは保護されていますか（SELECT FOR UPDATE、楽観的ロック、アトミックな比較交換など）？
• 引き換え時に有効期限がサーバーサイドでチェックされていますか？

5. 競合状態のシナリオの場合：

• 在庫／残高のチェックと減算はアトミックに（単一の DB トランザクション内、または行レベルロックを使って）実行されますか？
• 重複した同時リクエストを防ぐ冪等性キーや重複排除ロジックはありますか？

6. 権利／サブスクリプションのシナリオの場合：

• 機能へのアクセス時点で、ユーザーの現在のプラン／ティアがチェックされていますか？
• それとも、ログイン／セッション開始時にキャッシュされ、その後は再評価されませんか？

7. 送金／残高のシナリオの場合：

• 送金額が正であることをサーバーサイドでチェックしていますか？
• 送金元に十分な残高があることをサーバーサイドでチェックしていますか？
• 競合状態を防ぐため、これらのチェックはデータベーストランザクション内で行われていますか？

分類：

• 悪用可能：ビジネスルールが存在しない、迂回可能、またはクライアントサイドでのみ適用されています。
• 悪用の可能性あり：ルールは存在するものの、抜け穴があります（競合状態の隙、未対応のエッジケース、条件の迂回可能性）。
• 悪用不可能：適切なサーバーサイドの適用があり、エッジケースも網羅されています。
• 手動レビューが必要：確信を持って判断できません（複雑なロジック、外部サービスへの依存など）。

出力形式 — sast/businesslogic-batch-[N].md に記述してください：

# Business Logic Batch [N] Results

## Findings

### [EXPLOITABLE] Scenario title
- **Category**: [Attack category]
- **File**: `path/to/file.ext` (lines X-Y)
- **Endpoint**: `METHOD /path`
- **Business Rule Violated**: [アプリケーションが適用すべきルール]
- **Issue**: [不足または不具合のある検証についての明確な説明]
- **Impact**: [攻撃者が実現できること — 商品の無償取得、金銭的損失、不公平な優位性など]
- **Proof**: [適用の欠如を示すコードパス]
- **Remediation**: [このシナリオに対する具体的な修正]
- **Dynamic Test**:

[実稼働アプリで検出結果を確認するための手順または curl コマンド。 正確な HTTP メソッド、エンドポイント、ヘッダー、リクエスト本文を含めてください。 脆弱性を確認できるレスポンスまたは副作用を説明してください。]

### [LIKELY EXPLOITABLE] Scenario title
- **Category**: [Attack category]
- **File**: `path/to/file.ext` (lines X-Y)
- **Endpoint**: `METHOD /path`
- **Business Rule Violated**: [適用すべきルール]
- **Issue**: [存在する適用上の抜け穴または競合状態]
- **Concern**: [部分的な適用があるにもかかわらず、悪用の可能性が高い理由]
- **Proof**: [脆弱または部分的なチェックを含むコードパス]
- **Remediation**: [具体的な修正]
- **Dynamic Test**:

[確認のための手順または curl コマンド。例：2 件の同時リクエストを送信する。]

### [NOT EXPLOITABLE] Scenario title
- **Category**: [Attack category]
- **File**: `path/to/file.ext` (lines X-Y)
- **Business Rule**: [アプリケーションが適用すべきルール]
- **Protection**: [サーバーサイド検証、DB 制約、アトミックなトランザクションなど、適用方法]

### [NEEDS MANUAL REVIEW] Scenario title
- **Category**: [Attack category]
- **File**: `path/to/file.ext` (lines X-Y)
- **Uncertainty**: [自動解析で状態を判断できなかった理由]
- **Suggestion**: [手動で調査または動的にテストする内容]

フェーズ 3：マージ — バッチ結果の統合

フェーズ 2 のすべてのバッチサブエージェントが完了したら、sast/businesslogic-batch-*.md ファイルをすべて読み込み、内容を 1 つの sast/businesslogic-results.md に統合します。オーケストレーターであるあなたが直接作業します。サブエージェントは必要ありません。

マージ手順：

1. sast/businesslogic-batch-1.md、sast/businesslogic-batch-2.md、... のファイルをすべて読み込みます。
2. 各バッチファイルのすべての検出事項を収集して 1 つのリストにまとめ、元の分類とすべての詳細フィールドを維持します。
3. エグゼクティブサマリー用に、すべてのバッチの合計数を集計します。
4. 次の形式を使用して、統合レポートを sast/businesslogic-results.md に書き込みます。

# Business Logic Analysis Results: [Project Name]

## Executive Summary
- Scenarios analyzed: [total across all batches]
- Exploitable: [N]
- Likely Exploitable: [N]
- Not Exploitable: [N]
- Needs Manual Review: [N]

## Findings

[All findings from all batches, grouped by classification:
 EXPLOITABLE first, then LIKELY EXPLOITABLE, then NEEDS MANUAL REVIEW, then NOT EXPLOITABLE.
 Preserve every field from the batch results exactly as written.]

5. sast/businesslogic-results.md の書き込み後、すべての中間バッチファイル（sast/businesslogic-batch-*.md）を削除します。

---

重要な注意事項

• sast/architecture.md を読み込み、その内容をコンテキストとしてすべてのサブエージェントに渡します。
• フェーズ 2 はフェーズ 1 の完了後に実行する必要があります。フェーズ 2 は脅威モデリングの出力に依存します。
• フェーズ 3 はフェーズ 2 のすべてのバッチの完了後に実行する必要があります。フェーズ 3 はすべてのバッチ出力に依存します。
• バッチサイズはサブエージェントごとにシナリオ 3 件です。合計シナリオ数が 1～3 件の場合はサブエージェントを 1 つ使用します。10 件の場合はサブエージェントを 4 つ使用します（3+3+3+1）。
• すべてのバッチサブエージェントを並列で起動します。順番に実行してはいけません。
• 各バッチサブエージェントには、脅威ファイル全体ではなく、割り当てられたシナリオのテキストのみを渡します。これにより、各サブエージェントのコンテキストを小さく、焦点の絞られたものにできます。
• ビジネスロジックの欠陥だけに厳密に焦点を当てます。ここではインジェクションのバグ、認証の迂回、IDOR の問題を指摘しないでください。
• フェーズ 1 の脅威モデリングはアプリケーション固有のものにしてください。実際のコードベースに基づかない一般的なシナリオは役に立ちません。
• 有効な保護策はサーバー側の検証だけです。クライアント側の検証、フロントエンドのフォーム制約、「正の値でなければならない」と記載された API ドキュメントは、セキュリティ制御にはなりません。
• 金融処理における競合状態は、正確なタイミングが必要に見える場合でも重大度が高い問題です。自動化ツール（Turbo Intruder、並行する curl）を使えば、簡単に悪用できます。
• 判断に迷う場合は、「悪用不可能」ではなく「手動レビューが必要」に分類します。セキュリティ評価では、誤検知よりも見逃しのほうが深刻です。
• ORM とデータベースレベルの制約（CHECK 制約、一意インデックス、ロックを伴うトランザクション）に注意してください。これらは、アプリケーションコードだけでは確認できない強制力を提供する場合があります。
• 中間ファイルをクリーンアップします。最終版の sast/businesslogic-results.md を書き込んだ後、sast/businesslogic-threats.md とすべての sast/businesslogic-batch-*.md ファイルを削除します。