SKILL: ビジネスロジック脆弱性 — エキスパート攻撃プレイブック

AI ロード指令: ビジネスロジックの欠陥はスキャナーでは検出できず、バグバウンティでは高報酬です。このスキルは、競合状態、価格操作、ワークフローバイパス、クーポン/紹介乱用、負の値、ステートマシン攻撃をカバーしています。これらは自動化ではなく、人間の推論が必要です。特定の悪用技術(支払い精度/オーバーフロー、CAPTCHA バイパス、パスワードリセット欠陥、ユーザー列挙)については、コンパニオンスキル SCENARIOS.md をロードしてください。ワークフローアプローチ自体(モデリング → ステートマシン → 攻撃面マトリックス → 人間の判断)については METHODOLOGY.md をロードしてください。モジュール別のチェック項目については CHECKLIST.md をロードしてください。

コンパニオンファイル

ファイル	ロードする場合
METHODOLOGY.md	5段階のワークフロー、攻撃面 5×N マトリックス、人間の判断決定木が必要な場合
CHECKLIST.md	ターゲットをモジュール単位で実行中(ログイン / 登録 / 支払い / IDOR / プライバシー)で、すべての項目に「なぜ+検証」が欲しい場合
SCENARIOS.md	支払い精度/オーバーフロー、CAPTCHA バイパス、パスワードリセット、列挙、フロントエンドバイパスを詳しく掘り下げる場合

拡張シナリオ

以下が必要な場合も SCENARIOS.md をロードしてください:

• 支払い精度と整数オーバーフロー攻撃 — 32 ビットオーバーフロー→負の値、小数丸め悪用、負の送料
• 支払いパラメータ改ざんチェックリスト — 価格、割引、通貨、ゲートウェイ、return_url フィールド
• 条件付き競合実践パターン — 並行クーポン適用、Burp グループ送信でのギフトカード二重支出
• CAPTCHA バイパス技術 — 検証リクエストの削除、パラメータの削除、クッキー削除でカウンターをリセット、tesseract で OCR
• 任意パスワードリセット — 予測可能なトークン(md5(username))、セッション置換攻撃、登録上書き
• ユーザー情報列挙 — ログインエラーメッセージの違い、エンドポイント間でのマスクデータ再構成、base64 uid クッキー操作
• フロントエンド制限バイパス — 複数クーポン用の配列パラメータ(couponid[0]/couponid[1])、disabled/readonly 属性の削除
• アプリケーション層 DoS パターン — 正規表現バックトラッキング、WebSocket 乱用

---

1. 価格と値の操作

負の数量 / 価格

多くのアプリケーションは「数量 > 0」を検証しますが、通貨では検証していません:

負の数量でカートに追加: -1
数量を更新: -100
{
  "quantity": -5,
  "price": -99.99     ← 受け入れられる可能性
}

影響: アカウントへのクレジット、無料アイテム、逆方向の銀行振込を受け取ります。

小数点数量 — 「0元购」ケース

実際の講師主導ケース: e コマース アプリが、バックエンドがクライアントの浮動小数点値を信頼していたため、小数の quantity を受け入れました:

// カートアイテム:
{"id": 114016, "skuQty": 0.02}
// 元の価格 ¥500 → 最終価格 ¥10
// フードデリバリーアプリでのバリエーション:
// FoodNum=0.01 → 68元 商品 实付 0.68元

これが機能する理由: サーバーは 単価 * 数量 を乗算し、quantity ∈ Z+ を強制しません。そのため 2% のスライス注文は 2% の価格を支払いますが、完全なアイテムが発送されます。再現するには、カート送信を傍受 → skuQty / FoodNum を 0.02 に設定 → チェックアウトを完了します。

必須フィールドの削除 — 無料層への強制

スポーツアクティビティ登録: 有料賞品が関わる場合、サーバーは "payType": "paid" を返しますが、クライアント要求を編集して prizeIdList を完全に削除した場合、サーバーは "payType": "free" にフォールバックし、お金がかかるはずだった成功した登録を作成します。

// オリジナル
{"prizeIdList": ["6264e6948fe587000113e2d9"], ...}
// 修正済み — 配列全体削除
{"prizeIdList": [], ...}
// サーバーレスポンス:
{"ok": true, "payType": "free"}

これはパラメータ存在信頼バグです — バックエンドは「フィールドが存在しない」を「強制する有料アイテムがない」と見なすため、修正はフィールドを必須にし、サーバー側でコンテンツを検証することです。

整数オーバーフロー

quantity: 2147483648   ← INT_MAX + 1 は 32 ビットで負にオーバーフロー
price: 9999999999999   ← 浮動小数点精度を超える → 0 に丸める

実際のケース: amount=999999999 を設定するとオーバーフロー パスをトリガーし、システムが最終支払い金額として 0 を保存しました。オーバーフロー テストをトリガーする前に必ず調整してください — 支払いサービスをクラッシュさせることがあります。

丸め操作

アイテム価格: $0.001
1000 アイテムを注文 → 各々は切り下げ → 合計 = $0.00

実際の「半額チャージ」バグ: 入力 ¥0.019 をトップアップします。支払いゲートウェイは ¥0.01 のみを課金します(セント単位で切り下げ)が、ウォレットは ¥0.02 をクレジットします(切り上げ)。サイクルあたりの純利益は ¥0.01 で、無料残高増加用に繰り返します。

通貨為替レート遅延

1. 通貨 A でレート X を使用して入金
2. レートが変更
3. 新しいレートで通貨 A で引き出し → レート差から利益

プロモ積み重ねによる無料アップグレード

割引コード、紹介クレジット、ウェルカムボーナスの組み合わせをテストします:

プロモ適用: FREE50  → 50% 割引
プロモ適用: REFER10 → 追加 10%
ロイヤルティポイント適用 → 追加割引
合計: -$5 (無料 + クレジット)

---

2. 競合状態

概念: 2 つの操作が最初の操作がチェック-更新サイクルを完了する前に同時に実行されます。

二重支出 / 二重引き換え

# 同時に同じリクエストを送信(ミリ秒単位):
# Burp Repeater「グループに送信」または競合状態ツールを使用:

POST /api/use-coupon    ← 20 個の並列リクエストを送信
POST /api/redeem-gift   ← 同じクーポンコード、並列
POST /api/withdraw-funds ← 同じ残高、並列

# チェックと更新が非原子的の場合:
# スレッド 1: check(balance >= 100) → TRUE
# スレッド 2: check(balance >= 100) → TRUE (スレッド 1 が差し引く前)
# スレッド 1: balance -= 100
# スレッド 2: balance -= 100 → 両方成功 → 二重支出

Burp Suite での競合状態テスト

1. リクエストをキャプチャ
2. リピーターに送信 → 20 回以上複製
3. 「グループを並列で送信」(Burp 2023+)
4. チェック: 複製が成功しましたか?

Turbo Intruder — 番号ごとの SMS レート制限バイパス

実際のケース: 通常のリクエストが "该号码短时间内申请发送短信次数过多，拒绝发送" を返す場合、Turbo Intruder を使用して高い並行性で同じペイロードを送信すると、単純なカウンターが無効になります:

def queueRequests(target, wordlists):
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=30,
                           requestsPerConnection=10,
                           pipeline=False)
    for i in range(30):
        engine.queue(target.req, target.baseInput, gate='race1')
    engine.openGate('race1')

結果: 電話ごとのリミッターはレースになり、多くのリクエストがスリップスルーし、複数の異なる検証コードが生成されます(実際の SMS スパムケース)。根本原因: カウンターのインクリメントは読み取りに対して非原子的です。

マルチデバイス同時 VIP サブスクリプション

実際のケース: サービスは初月のみ割引を提供しています。複数のデバイス(A、B、C)で支払いシートを開き、支払いが完了する前に各々を順番に完了します。サーバーは最初のリクエストで「新規ユーザーですか?」をチェックするだけなので、その後のすべてのリクエストは割引を継承し、VIP 期間が積み重ねられます。

通常: 下单 → 支付 → 充值会员 → 第二次下单 → 服务端校验 "已是新人" → 拒绝
バイパス: 設備A: 支払いページに進入 (割引資格をロック)
          設備B: 支払いページに進入 (並列ロック)
          設備A: 支払い完了 → VIP +1月 (割引価格)
          設備B: 支払い完了 → VIP +1月 (まだ割引価格)

同じトリックは「补差价升级会员」で機能します — 並列トップアップにより期間クレジットが複製されます。

アカウント登録競合

同時に同じメールで登録 → 2 つのアカウント作成 → データ分離が破損
パスワードリセット トークン競合 → 同じトークンを 2 回再利用
メール検証競合 → 複数のメール アドレスを検証

レース経由でのリミット バイパス

「1 回のみクレイム」割引、フリー、「最初の注文」ボーナス:
→ 10 個の並列 POST /claim リクエストを送信
→ レース ウィンドウ: すべてが「既にクレイムされた?」チェックを通過 (いずれの書き込みも前)

---

3. ワークフロー / ステップスキップ バイパス

支払いフロー バイパス

通常のフロー:
  1. カートに追加
  2. 配送情報を入力
  3. 支払い(カード/ウォレット)を入力
  4. 確認をクリック → 支払い課金
  5. 注文確認

攻撃: ステップ 5 に直接スキップ
POST /api/orders/confirm {"cart_id": "1234", "payment_status": "paid"}
→ サーバーはクライアント送信 payment_status を信頼していますか?

多段階検証スキップ

パスワードリセット フロー:
  1. メールを入力
  2. トークンを受け取る
  3. トークンを入力
  4. 新しいパスワードを設定 (ステップ 3 の有効なトークンが必要)

攻撃: ステップ 3 を完了せずにステップ 4 に進む:
POST /reset/password {"email": "victim@x.com", "token": "invalid", "new_pass": "hacked"}
→ サーバーはトークンが適切に検証されたかチェックしていますか?

または: 古い/期限切れのフローからトークンを試す → まだ受け入れられますか?

2FA バイパス

通常のフロー:
  1. ユーザー名 + パスワードを入力 → 成功
  2. 2FA コードを入力 → ログイン

攻撃: ステップ 1 の成功後、/dashboard に直接進む
→ 2FA が完了する前にセッションが作成されていますか?
→ /dashboard は 2FA 完了チェックを必須としていますか、それとも「認証済み」フラグのみですか?

フィルタ パス切り詰めバイパス — ..// と ;

Java Web クラス監査からの実際のケース: 手動実装された Servlet Filter はクエリ文字列を検査してログインをチェックします。2 つの信頼できるバイパス:

パストラバーサル切り詰め (../):
  保護済み:   http://target/FilterDemo/index.jsp        → 302 /login に
  バイパス:   http://target/FilterDemo/../../index.jsp  → 200 (フィルタは "../../" を見て、URL パーサーが折りたたむ)

セミコロン切り詰め (;):
  保護済み:   http://target/admin/doLogin.action        → 302 /login に
  バイパス:   http://target/;/admin/doLogin.action      → 200
                              ^
                              Servlet コンテナは ; 後のセグメントを「パスパラメータ」として扱い、
                              request.getRequestURI() を使用するフィルタは "/;/admin/doLogin.action" を見て、
                              保護されたプレフィックス "/admin/" に一致しないため、リクエストを通す。
                              ただし、ディスパッチャーは実際の /admin/doLogin.action ハンドラーにルーティング。

修正: セキュリティ チェック用に request.getRequestURI() を使用しないでください。正規化されたサーブレット マップパスの request.getServletPath() を使用してください:

// 脆弱
String uri = request.getRequestURI();   // /;/admin/doLogin.action
// 安全
String path = request.getServletPath(); // /admin/doLogin.action

Java コードを監査する場合、Filter/startsWith/indexOf("/admin") パターンと組み合わせた request.getRequestURI() を grep してください — これらは即座に疑わしいです。

実名認証リプレイからのリセット

意図的にリアルネーム認証に失敗して編集フローを再開する不正なパス:

1. 意図的に間違った cardNumber で実名認証を送信
   → サーバーは「code:200, msg:success, ok:true」を返しますが、フローは「驳回 / 等待审核」を表示
2. サーバーが状態を「却下」とマークしますが、ユーザーをロックしないため、UI は
   アカウントを「身元編集」状態に戻します
3. 別の(おそらく盗まれた)身元で再送信
   → 実名バインディングが無限に繰り返され、反中毒ロックを無効にし、アカウント再販売を可能にします

防御: 却下された実名送信はアカウントをロックするか、人間の確認を要求する必要があり、エディターにループバックしません。

支払いなしの配送

  1. カートにアイテムを追加
  2. 配送先住所を入力
  3. 支払い方法を選択 (クレジット カード)
  4. プロモ コードを適用 (100% 割引またはギフト カード)
  5. 最終金額: $0
  6. 注文完了

攻撃: 100% 割引コードを適用 → 実際の支払いが処理されない → アイテムが発送される

---

4. クーポンと紹介乱用

クーポン積み重ね

テスト: 複数のクーポン コードを適用できますか?
テスト: 「SAVE20」+ プロモが 100% を超えるようにスタックしますか?
テスト: クーポンを適用し、アイテムを削除し、割引を適用したままにし、別のアイテムを追加

紹介ループ

1. アカウント_A を作成
2. アカウント_A の紹介コードでアカウント_B を登録 → 両方がクレジットを取得
3. アカウント_B の紹介コードでアカウント_C を登録
4. 使い捨てメールで無期限
→ 無限クレジット生成

クーポン = 可変価格アイテムの固定ドル金額

クーポン: $5 オフ (任意の注文)
$3 相当のアイテムを購入、-$5 クーポンを使用 → 純利益 -$2 (クレジット残高)

---

5. アカウント / 権限ロジックの欠陥

メール検証バイパス

1. メール A で登録(正当、確認済み)
2. メール B に変更(攻撃者のメール、未確認)
3. 確認済みアカウントとして使用 — サーバーは再確認を強制していますか?

または: メールを被害者のメールに変更 → 検証なし → アカウント請求

パスワード リセット トークン バインディング

1. アカウントのパスワード リセットをリクエスト → トークンを取得
2. メール アドレスを変更(アカウント設定)
3. 古いパスワード リセット トークンを再利用 → 古いメールでまだ機能していますか?

または: victim@target.com のリセットをリクエスト
    トークンは被害者に送信されますが確認: URL は予測可能なトークン パターンを明かしていますか?

OAuth アカウント リンク乱用

1. 被害者のメールを持っている(ただし、パスワードではない)
2. 被害者のメールで登録 → 同じメールでアカウントを取得
3. OAuth(Google/GitHub)をアカウントにリンク
4. 被害者は Google でログイン → サーバーがメール一致を検出 → あなたのアカウントに統合

クッキー置換 — 水平/垂直権限昇格

監査ビデオからの教科書 IDOR デモ:

1. スーパー管理者としてログイン → リクエストをキャプチャ、クッキーをコピー(JSESSIONID/トークン)
2. ログアウト、プレーン ユーザーとしてログイン → 同じエンドポイントへの別のリクエストをキャプチャ
3. プレーン ユーザー リクエストを再生しますが、クッキー値を管理者のトークンで交換
4. レスポンスが管理者のみのデータを返す場合 → 垂直昇格
   別のユーザーのデータを返す場合 → 水平昇格

一般的な関連バグ: /oa/emp/list はクッキーがない場合、HTTP 302 を /login に返しますが、プレーン ユーザー クッキーが送信される場合、完全なデータで 200 を返します — つまり、唯一のチェックは「ログイン済み?」で、「このエンドポイントの認可?」ではありません。

データベース不一致からの権限残余

微妙なケース(2 番目の監査クラスから): 管理 UI は、ロール X が権限 user:list を取り消されたことを示していますが、SQL データを照会:

SELECT * FROM sys_menu WHERE role_id = 2;
-- 同じ menu_id 「user:list」の 2 つの行

UI の「権限を削除」は 1 行のみ削除しました。複製行により API はアクセス可能なままです。確認方法:

SELECT menu_id, COUNT(*) FROM sys_menu GROUP BY menu_id, role_id HAVING COUNT(*) > 1;

教訓: UI が権限取り消しを示していますが API がまだ機能する場合 → RBAC テーブルで複製/孤立した権限を確認してください。

弱いランダム パスワード リセット トークン

Windows 上の PHP / レガシー スタックは rand() を使用し、RAND_MAX = 32768 です。リセット リンクが SYSTEM_HOME/resetpassword.php?id=md5(rand()) を使用する場合、キー空間全体を事前計算できます:

$a = 0;
for ($a = 0; $a <= 32768; $a++) {
    $b = md5($a);
    echo $b . "\r\n";
}

結果の辞書に対して /resetpassword.php?id=<hash> を反復してください — 有効なリセット ページを返すと、被害者のパスワードを変更できます。rand()、mt_rand()(シード化なし)、Random()(C# のデフォルト シード)などを呼び出すトークン生成を監査してください。

---

6. API ビジネスロジックの欠陥

オブジェクト状態操作

order.status = "pending"
→ PUT /api/orders/1234 {"status": "refunded"}   ← 自己トリガー返金
→ PUT /api/orders/1234 {"status": "shipped"}    ← 配送なしで配送済みをマーク

トランザクション再利用

1. 支払いを開始 → transaction_id を取得
2. 購入を完了
3. 2 回目の購入に同じ transaction_id を再利用:
   POST /api/checkout {"transaction_id": "USED_TX", "cart": "new_cart"}

リミット カウント操作

1 日の転送制限 = $1000
→ $999 を転送、キャンセル、$999 を転送 (キャンセルでリミットが更新されない)
→ 並列転送 (リミット チェックの競合)
→ 異なる支払いタイプがリミット カウンターを共有していない

Java Web「フィルタなし、Spring Security なし」アンチパターン

監査に適した指標: spring-boot-starter-security を含まず、ゼロの Filter クラスを持つ Spring Boot プロジェクト。これは、各メソッドで開発者がセッションを手動でチェックしない限り、すべてのコントローラーが guest に対してオープンであることを意味します。再現:

# ソース ツリー内
find . -name "*.java" -exec grep -l "Filter" {} \;     # おそらく空
find . -name "*.java" -exec grep -l "@PreAuthorize\|@Secured" {} \;

両方が空の場合、ほぼすべての API が認可されていません。監査デモから:

public Result score(@RequestParam("Integer userId") Integer userId) {
    Score score = scoreService.selectScoreByUserId(userId);
    return Result.success(score);
}

userId がセッションのログイン ユーザーと一致するかのチェック → 水平 IDOR はありません。さらに悪いことに、同じエンドポイントはクッキーなしで機能します — グローバルに認証を強制するものがないためです。

Spring Security antMatchers 対象範囲ギャップ

監査ビデオは、部分的に保護された Spring Security 構成も示していました:

.antMatchers("/system/user/info").authenticated()
.antMatchers("/system/menu/**").hasRole("admin")

一般的なエラーは、ルール範囲が狭すぎることです — つまり、/system/user/info は保護されていますが /system/user/list は保護されていない、または /system/menu/** は管理者のみですが /system/dept/treeData はオープンです。コントローラー アノテーション(@PreAuthorize("@ss.hasPermi('system:user:list')"))を SecurityConfig に対してクロスチェックしてください — すべての注釈付きエンドポイントは SecurityConfig ルールにもマップされる必要があります。不一致はリファクター後に一般的です。

---

7. サブスクリプション / 階層の混同

無料階層: 機能 X にアクセスできない
有料階層: 機能 X にアクセスできる

攻撃:
- 有料トライアルにサインアップ → 機能 X を有効にする → 無料に段階的に引き下げる
  → 段階的に引き下げるときに機能 X が無効になりますか?
  → 機能 X を使い続けることができますか?

または:
- JS バンドルから プレミアムエンドポイント リストを検査
- 無料アカウント トークンで プレミアム エンドポイントを直接呼び出す
→ サーバーは UI のサブスクリプションをチェックしますが API ではありませんか?

直接メディア URL リーク — VIP リソース バイパス

フィットネス/学習アプリからの実際のケース: クライアントがコース詳細をリクエストする場合、JSON レスポンスに生の メディア URL が埋め込まれます:

GET /gerudo/v2/liveCourse/625020ce8f002700010554c1/detail HTTP/1.1
{
  "previewPullUrl": "http://app-live.../live/app-live_625020ce8f002700010554c2_Preview.flv"
  ...
}

すべての詳細 / プレビュー / 再生レスポンスで次のキーワードを検索:

.flv  .m3u8  .mp4  .mp3  videoUrl  downloadUrl  streamUrl  previewPullUrl

各ヒットに対して、URL を匿名で再生してください(curl、VLC、https://bilibili.github.io/flv.js/demo/ の flv.js デモ)。セッションなしで URL が再生される場合、VIP ゲートが破損しています。防御: 生のリソース パス ではなく、ユーザー/IP/Referer にバインドされた署名付き、短い TTL URL を使用してください。

リソース ID 置換 — 無料 → 有料コース

関連バグ: 無料コース詳細は {"id": "60caa21e853f5c1651b27c1b", ...} を返します。URL の ID を既知の有料コース ID で置き換えます。レスポンス構造が同じで、再生可能な URL が含まれる場合 → プレミアム コンテンツに対する IDOR。防御: 単に「ログイン済み?」ではなく、各詳細呼び出しでオーナー関係を確認してください。

---

8. ファイル アップロード ビジネスロジック

純粋なロジック欠陥を超えた完全なアップロード攻撃ワークフローについては、以下もロードしてください:

• upload insecure files

アップロード サイズ制限: 10MB
→ 10MB をアップロード → クライアント側で圧縮 → サーバーが展開 → ボム?
(Zip ボム: 1KB zip → 1GB ファイル = サービス拒否)

アップロード タイプ制限:
→ 「データ インポート」用に .csv をアップロード → 数式を注入: =SYSTEM("calc")
  (Excel マクロ コンテキストでの CSV インジェクション)
→ アバターをアップロード → サーバーが変換 → コンバーター攻撃(ImageMagick、FFmpeg CVE)

ストレージ パス予測:
→ /uploads/USER_ID/filename
→ ID + ファイル名を知ることで他のユーザーのファイルを上書きできますか?

---

9. テスト アプローチ

各ビジネス プロセス:
1. 意図されたフロー(ハッピー パス)をマップ
2. 尋ねてください: 「ステップ N をスキップしたらどうなるか?」
3. 尋ねてください: 「負の数/ゼロ/MAX 値を送信したらどうなるか?」
4. 尋ねてください: 「このステップを 2 回繰り返したらどうなるか?」(冪等性)
5. 尋ねてください: 「B の代わりに A を実行してから B を実行したらどうなるか?」
6. 尋ねてください: 「2 人のユーザーが同時にこれを実行したらどうなるか?」
7. 尋ねてください: 「信頼された」ステータス フィールドを変更できますか?」
8. 財務/リソース影響の角度から考える → 最高の報酬

正式な 5 段階のワークフロー — ビジネス モデリング → ステート マシン → 攻撃面マトリックス → チェックリスト駆動テスト → 人間の判断 — については、METHODOLOGY.md をロードしてください。これには単一ページの決定木(Q1 ~ Q7)が含まれています「リクエストを見つめていて、まず何を試すべきかわからない」場合。

---

10. 高影響チェックリスト

ログイン / 登録 / パスワード回復 / 支払い / クーポン / 注文 / IDOR / プライバシー / VIP / URL リダイレクト / クッキー & トークン / レース / コメントのなぜ および 検証 列を含む完全なモジュール単位リスト — CHECKLIST.md をロードしてください。

以下の凝集トップ影響アイテムは「30 分しかない場合、まずこれらを実行してください」セットです:

e コマース / 支払い

□ 負の数量 / 小数点数量 (skuQty=0.02、FoodNum=0.01) カートで
□ 必須フィールドを削除 (prizeIdList を削除) 無料層に強制
□ amount=999999999 整数オーバーフロー → 最終 0
□ 複数の競合するクーポン配列パラメータ経由で適用
□ レース状態: ギフト カード二重支出 / 同じクーポン
□ 支払いステップをスキップして注文確認に直接移動
□ サーバー信頼クライアント ステータス フィールド (payment_status=paid、success:true)
□ リターンなしで返金(配信されたアイテムで返金をトリガー)
□ マルチデバイス同時 VIP サブスクリプション / 补差价升级
□ 通貨丸め マイクロ仲裁 (¥0.019 課金 → ¥0.02 ウォレット クレジット)

認証 / アカウント

□ パスワード ステップ後の直接 URL アクセスで 2FA バイパス
□ フィルタ バイパス: ../../パス トラバーサル切り詰め、;パス パラメータ切り詰め
□ メール変更後のパスワード リセット トークン再利用
□ 弱いランダム リセット トークン: Windows PHP で md5(rand())、予測可能なシード
□ メール検証バイパス(検証後のメール変更)
□ メール マッチ経由の OAuth アカウント乗っ取り
□ 既存の未検証メール で登録
□ クッキー置換 (管理者 → ユーザー / ユーザー → 別のユーザー)
□ 実名認証「故意に間違いを入力して」リプレイからのリセット

サブスクリプション / リミット / リソース

□ ダウングレード後のプレミアム機能へのアクセス
□ 並列リクエスト経由でレート/使用リミットを超える(Turbo Intruder)
□ 無限クレジットのための紹介ループ
□ 無料トライアル ≠ 時間制限 (トライアル後の強制なし)
□ サブスクリプション チェックなしのプレミアム エンドポイントへの直接 API 呼び出し
□ 無料コース ID を有料コース ID に交換 (リソースで IDOR)
□ JSON での直接メディア URL 露出 (.flv / .m3u8 / .mp4 レスポンス)
□ サーバー側 RBAC 残余 (sys_menu 複製行)
□ Java Web ノー フィルタ / Spring Security antMatchers ギャップ

---

11. 統合チェックリスト (2 時間フル スイープ)

セクション 10 のリストは「30 分の金儲け」です。このリストは次のレイヤーです: 数時間あり、すべての 9 つのビジネス サーフェスにわたる防御グレードのスイープが必要な場合。 これは表面別に整理され、各表面内の攻撃メカニズム別なので、 列下で読んで「このエンドポイントで何種類のバグが存在する可能性があるか」 行全体で読んで「この攻撃が他の場所で適用される」。

アイテムごとの完全な 項目 / なぜ / 検証 三つ組(再現ステップとアイテムごとのツール付き)については、CHECKLIST.md をロードしてください。このセクションは高速スキャンの項目行のみを保持します。

11.1 ログイン / 認証

□ ユーザー名列挙(応答差経由) (msg / ステータス コード / タイミング)
□ ユーザー名列挙 SMS 送信応答経由 (送信対比未登録)
□ ブルート フォース ロックアウトなし (失敗ログインにレート制限なし)
□ デフォルト / 弱い認証情報 (admin/admin、root/123456) バックエンド & インフラ
□ 2FA バイパス パスワード ステップ後の直接 URL / 2FA トークン リプレイ経由
□ クライアント信頼ログイン フラグ (status=success、response body での is_login=true)
□ サード パーティ / SSO コールバック IDOR (コールバックで uid を変更して乗っ取り)
□ バイオメトリック ライブネス バイパス (静止写真 / 事前録画ビデオ リプレイ)
□ ログイン/登録でのオープン リダイレクト (return_url、redirect、callback パラム)
□ ハードウェア キー署名リプレイ / 偽造 (USB キー、PKI 証明書)

11.2 登録

□ ユーザー名 / 電話 / メール列挙「既に存在する」応答経由
□ パスワード強度 クライアント側のみで強制 (123456 をサーバー側で設定)
□ 複数ステップ登録スキップ (最終ステップを直接 POST、メール検証ミス)
□ 検証コード強制されず (空 / ランダム / 固定値が通過)
□ SMS / メール コード リプレイ (同じコード 2 回使用また はユーザー間)
□ ログアウト後に同じユーザー名で再登録、古いデータ / 権限を継承
□ N 類似の仮想アカウント経由の詐欺防止バイパス (同じデバイス、異なるメール)
□ 複数ステップ登録リプレイ保護欠落 (送信ステップでノンス なし)

11.3 パスワード回復 / リセット

□ リセット ターゲット改ざん (uid / メール / 電話 送信ステップ)
□ リセット トークン予測可能 (タイムスタンプ派生、弱いハッシュ、短いランダム)
□ クロス ユーザー トークン再利用 (A のreset_token、B のパスワードを変更)
□ ログイン ユーザーのパスワード変更エンドポイントで古いパスワード チェックが見つかりません
□ コード検証ステップをスキップ、最終リセット エンドポイントに直接ヒット
□ リセット リンク / 回答 / トークン HTML または JS ソースに漏洩
□ リセット トークン有効期限なし / 使用後無効化されない
□ リセット コード base64 のみ「難読化」応答
□ マルチステップ フロー全体にわたる矛盾した身元 (ステップ 2 のreset_token、ステップ 4 で再利用可能)
□ メール/電話リバインド後の古いセッション取り消されず

11.4 セッション / トークン

□ セッション固定: ログイン前のセッション ID はログイン後も有効
□ トークン ユーザー/IP/デバイスにバインドされず (クッキー盗む → どこでも使用)
□ 鍛造トークン: 弱いアルゴリズム md5(ユーザー名 + タイムスタンプ)、サーバー ソルトなし
□ 古いトークン ログアウト / 有効期限後も受け入れられます (ブラックリストなし)
□ クッキー改ざん (クッキーで信頼されるサーバー側の uid / ロール / is_admin)
□ ステート マシン リプレイ (「赤パケットを請求」を リプレイ → 再請求)
□ ワンタイム トークンのアンチリプレイなし (CSRF トークン、OTP、ノンス)
□ 機密認証情報 (トークン、回答、キー) フロント エンド JS にハードコード
□ 再認証なしの公開 Session ID から特権セッション作成
□ トークン クロス環境で機能 (異なる IP、異なる UA、検証なし)

11.5 支払い / 注文

□ 金額改ざん: amount = 0.01 / 0 / 負 / 0.001
□ 数量改ざん: quantity = -1 / 0.01 / 1.5 / 999999999
□ 整数オーバーフロー: quantity * price は 0 または負にラップ
□ 浮動小数点精度悪用 (複数小数、累積丸め)
□ 通貨コード スワップ (CNY → JPY/RUB で同じ数値)
□ クーポン / 割引フィールド 鍛造 (coupon_id、discount=、free_shipping=true)
□ アイテム ID スワップ: チェックアウトで product_id をより安い SKU に置き換え
□ 署名 / サイン フィールド バイパス (署名パラムをドロップ、古い署名を使用)
□ 支払い コールバック 鍛造 (status=paid を内部コールバックに投稿)
□ 支払いリクエスト リプレイ → 複数出荷 / 複数クレジット
□ レース / 並行処理: オーバーセル、ギフト カード二重支出、二重クーポン引き換え
□ 商品を失わない返金 / 仮想権
□ VIP 期間改ざん (days=999、months=120、period=-1)
□ 受信アカウント リダイレクト (merchant_id / receiver_account が引き出しでスワップ)
□ 負の送料 / 手数料フィールド 合計を減少 (shipping_fee = -500)
□ 並行トップアップ後の返金ドレイン (レース ウィンドウで返金 > トップアップ)
□ 価格ルール遷移ウィンドウ (時間 T で価格変更、T-ε で古いルールでリプレイ)
□ 通貨丸め マイクロ仲裁 (0.019 の請求 → 0.02 ウォレット クレジット)
□ マルチ チャネル矛盾 (オンライン対現金配達対残高支払い)

11.6 IDOR / 認可

□ 水平 IDOR: uid / order_id / resource_id を被害者に交換
□ 垂直 IDOR: リクエストで ロール / タイプ / レベル フィールドを管理者に設定
□ 隠しフィールド改ざん (HTML / JS 状態のデータ ユーザー ID)
□ メール / 電話 古いバインディングを検証せずにリバインド
□ UID vs セッション トークン一貫性が見つかりません (トークンは A に属する、uid は B として送信)
□ 予測可能 / シーケンシャル リソース ID (ギフト ID、共有リンク ID)
□ リソース 列挙 注文 / クーポン / 共有 / トリップ詳細 エンドポイント
□ マルチ エントリ矛盾: Web ブロック、モバイル API は実行しません
□ ステート マシン 違法遷移 (支払い/配送なしでクレームを報酬、支払い前に配送)
□ 隠された / 文書化されていない 管理者 エンドポイント 管理者認証なしでアクセス可能
□ クロス ロール 関数呼び出し (ユーザーがマーチャント API、ライダー API などを呼び出し)
□ 同時アクション経由の権限 (リクエスト ロール昇格 レース状態)

11.7 CAPTCHA / 検証コード

□ コード プレーンテキストで HTTP レスポンスで返される (本文 / ヘッダー / JS var)
□ レシーバー改ざん: 攻撃者制御の電話 / メール パラムに変更
□ 空 / 固定コード受け入れられました (000000、空白、「テスト」)
□ コード フィールドを完全にドロップ → リクエストは成功
□ クロス アカウント再利用 (A の有効なコード B のフローで受け入れられた)
□ ワンタイム強制なし (同じコード 有効期限まで再利用可能)
□ ブルート フォース 4 ~ 6 桁コード (試行制限なし、ロックアウトなし)
□ SMS / メール 爆弾 (IP ごと / 電話ごと / グラフィカル CAPTCHA なしの レート制限なし)
□ フロント エンドのみ「送信成功」ステータス (サーバー失敗、FE 成功)
□ コード セッションにバインドされず (A 用に生成されたコード、B のセッションで使用)

11.8 ファイル アップロード

□ Content-Type バイパス (Content-Type: image/jpeg、body は PHP)
□ 拡張子トリック: ダブル ext (.php.jpg)、ケース ミックス (.Php)、null バイト、;パス
□ ファイル パス トラバーサル (filename=../../webshell.php)
□ ファイル コンテンツ ポリグロット (PHP / シェル埋め込み画像)
□ Office XML リパック (unzip docx → XML を注入 → rezip → アップロード)
□ XXE via .xml / .dtd アップロード エンドポイント
□ バックエンド のみ アップロード (管理者ログイン → アップロード → exec)
□ アップロード レース: アップロード + AV スキャン / クリーンアップ前に並列アクセス
□ ZIP ボム (1KB → 1GB サーバー、展開 DoS)
□ CSV 数式インジェクション (=SYSTEM("calc")、=cmd|'/c calc'!A1)
□ ストレージ パス 予測可能 / ユーザー全体で上書き可能 (/uploads/UID/file)
□ 画像コンバーター / パーサー CVE (ImageMagick、FFmpeg、pillow)

11.9 CSRF / SSRF / XXE

□ XXE ファイル読み込み (<!ENTITY x SYSTEM "file:///etc/passwd">)
□ XXE ブラインド OOB 経由 (パラメータ エンティティ → DNSLog / Burp Collaborator)
□ SSRF 画像インポート / ウェブフック / プレビュー URL 経由 (file://、http://127.0.0.1)
□ SSRF FTP / gopher / jar / php ラッパー / dict プロトコル経由
□ XML パーサー 危険なラッパー 有効 (php://expect、expect://)
□ アウト オブ バンド 検出 ブラインド インジェクション (DNSLog はサーバー ヒットを確認)
□ CSRF ステート 変更エンドポイント (トークン、SameSite、origin チェック なし)
□ 支払い / 引き出し CSRF オート送信隠しフォーム経由
□ ログイン CSRF (被害者を攻撃者アカウントへログイン強制)
□ JSONP / JSONP コールバック 悪用 CSRF 読み込みプリミティブ

このセクションを使用する方法

1. ターゲットのサーフェスに関する関連 1 ~ 2 個のサブセクションを印刷またはスクリーンショット
2. 各 □ マーク: 適用されない / 脆弱なし / 脆弱 / 再チェックが必要。
3. バグを証明した正確なエンドポイント + パラメータ + ペイロードをマークしてください (またはそれが存在しないことを証明)、レポートが再現可能であるため。
4. 項目が予期しないことをトリガーする場合、METHODOLOGY.md Q1~Q7 決定木と相互参照してください — ツリーは どの隣接する項目も脆弱である可能性があるかを示します。
5. アイテムごとのディープ ペイロード / curl 対応コマンド / Burp スクリーンショット については、 CHECKLIST.md(完全な三つ組)と SCENARIOS.md(実際のケース)をロードしてください。