Hello there, ('ω')ノ
レースコンディションとは？
わかりやすい例：
- 社内の経費申請システム
- 一人1回しか申請できないはずなのに
- 同時に複数回リクエストを送ると、二重申請できてしまう
このように「順番通りに処理されない」ことで発生する問題です。
実際によくあるパターン
- ECサイト：在庫数を超える注文
- 経費精算：二重払い
- 勤怠システム：二重打刻
- ファイルアップロード：同じファイル名で上書き
実際のチェック手順① 手動で試す
- 確認対象のシステムを開く
- 「確定」や「申請」ボタンを連打してみる
✅ 観察ポイント：
- 二重申請になっていないか？
- エラーメッセージが正しく表示されるか？
- データベース側で重複データが登録されていないか？（開発担当者と連携）
実際のチェック手順② ツールを使う
手動では限界がある場合：
- Burp Suite の Intruder 機能
- OWASP ZAP のスクリプト機能
これらを使うと「ほぼ同時に複数リクエスト」を送ることができます。
設定例：
- 同じリクエストを10回同時送信
- 特に支払処理や更新処理を対象に
チェック対象になりやすい場所
✅ お金や在庫に関わる操作
✅ 社員情報やユーザー情報の更新操作
✅ 社内限定機能の管理画面
実務でのチェック例
例：経費申請システムの場合
- 金額入力 → 申請ボタン連打
- 「二重申請はできません」と出ればOK
- 二重申請が通る → レースコンディション疑いあり
チェックリストまとめ
- [ ] ボタン連打で二重操作が発生しないか確認したか？
- [ ] 開発者用ツールやプロキシで同時リクエストを試したか？
- [ ] データベース側で重複登録がないか確認したか？
- [ ] 特に金銭や在庫管理に関わる部分を優先して確認したか？
注意事項
- 本番環境でテストする場合は必ず許可を取ること
- 実施する時間帯や影響範囲に注意すること
- 開発担当者と連携しながら進めること
まとめ
- レースコンディションは「タイミングのズレ」を突く脆弱性
- 手動＋ツールを使って同時操作を再現するのが基本
- シンプルな連打テストから始めるだけでも発見できることがある
Best regards, (^^ゞ
