Hello there, ('ω')ノ
🎯 1. Race Conditionとは？
Race Condition（競合状態）とは、サーバ側で処理の順番やタイミングが適切に制御されていない場合に、 複数のリクエストが意図せず同時に実行されてしまう問題です。
🧠 ざっくり言うと：
「同時に送ったら、本来1回しか許されない処理が何回も通ってしまった！」
💥 起こり得る影響の例
| 攻撃例 | 内容 |
|---|---|
| 💰 二重支払い・返金 | 購入や返金処理が複数回通る |
| 🎁 ボーナス・クーポンの複数獲得 | 本来1回だけのキャンペーンを繰り返し実行可能 |
| 🗑️ 同時削除によるエラー誘発 | サーバデータの一貫性が壊れる |
| 🛒 在庫処理の崩壊 | 在庫数を超えた注文が通る |
🧭 2. チェックすべき機能・処理例
| 機能・ページ | 内容 |
|---|---|
| 🎁 ポイント・クーポン発行 | 発行リクエストを複数回同時送信 |
| 💳 支払い・返金 | 二重リクエストで二重処理されないか |
| 📦 商品購入・予約 | 購入処理が一度きりか確認 |
| 📝 アカウント変更 | メールアドレス・ロール変更が競合していないか |
| ⏱️ 限定操作 | 回数制限付きAPI（1日1回など） |
🛠️ 3. 診断手順
- 影響ありそうな操作（1回限定・残高変動・ステータス変更）を探す
- Burp Suite や Repeater を使って 同じリクエストを保存
- 複数スレッドで同時送信（Concurrently） する
- 結果を比較して「本来1回しかできない処理」が複数成功するか確認
🧪 4. 診断ツールと方法
✅ 簡易ツールでの同時リクエスト送信例（Burp Suite Intruder）
- 該当POSTリクエストをIntruderに送信
- パラメータを固定し、スレッド数を増加（例：10スレッド）
- 同時に同一リクエストを複数送信
- ステータスコードやレスポンスに違いが出ないか確認
✅ curlや自作スクリプトでのテスト（例：bash）
for i in {1..10}; do
curl -X POST https://example.com/api/apply-coupon -d "code=ABC123" &
done
wait
→ 結果が10回通っていたら脆弱性
🔁 5. よくある競合チェック項目
| 操作 | 期待される正しい動作 | 脆弱な動作 |
|---|---|---|
| クーポン適用 | 1回のみ有効 | 複数回適用される |
| ポイント使用 | 一度だけ減算される | 複数回使える |
| 残高処理 | 1回のみ減算 | 合計以上に使用される |
| 商品在庫 | 売り切れで失敗 | 売り切れても成功する |
⚠️ 6. 注意点・ベストプラクティス
| ポイント | 内容 |
|---|---|
| サーバの応答速度が遅い操作が狙われやすい | データベース書き込みや外部API通信など |
| ステータスコードが全て200でも安心しない | 実際に中身がどう変わったか比較する |
| CSRFトークン・JWTなどの検証は無意味 | 同じトークンを何度も使うことが前提だから |
🧰 7. 補助ツール
- Burp Suite Intruder（並列送信）
- Turbo Intruder（Burp拡張）：高性能並列リクエスト送信
- custom bash / Pythonスクリプト：curlベースでも十分
- Race-the-Web：競合状態に特化した自動化ツール
✅ 8. 診断成功のサイン（サンプル）
🎁 クーポン適用のレスポンス
200 OK - クーポン割引 ¥100 適用されました
→ 同じクーポンで 10回全て成功 → ❌ 脆弱性あり
🔐 9. サーバ側の対策（参考）
| 方法 | 内容 |
|---|---|
| データベーストランザクション | 原子性（Atomic）な処理にする |
| リクエストロック | ユーザ単位・リソース単位で同時実行を禁止 |
| 一時的なフラグ管理 | 「この処理中」の状態を一時的に保存し、2重送信を排除 |
| 限度回数チェック | クーポン適用回数、支払い回数にカウント制限を設ける |
📌 よくあるヒント
- 限定ボタン／1回限りの操作
- 処理に数秒かかるエンドポイント
- 「今だけ！」「先着順！」のような文字
- 成功後のレスポンスが曖昧・重複確認がない
Best regards, (^^ゞ
