Hello there, ('ω')ノ
🎯 概要
ビジネスロジックの脆弱性は、アプリケーションが提供する機能の性質や業界特有の要件に起因するため、その影響は広範かつ深刻です。特にオンラインショップの割引機能のように、ユーザーの操作に基づいて価格が変動するロジックは攻撃対象として狙われやすく、論理的な抜け穴が悪用されるケースが多発しています。
🧪 典型例：不適切な割引条件の検証
シナリオ：
- 合計注文額が \$1000 を超えると10%の割引が適用されるショッピングサイト。
- 攻撃者は割引を得るために複数の商品をカートに追加し、割引が適用された後に不要な商品を削除。
- 最終的に割引条件を満たしていないにもかかわらず、割引が維持されたまま注文を完了。
問題点：
- 割引適用後にカート内容が変更されたにもかかわらず、サーバー側で再検証が行われていない。
⚠️ よくある業界特有の論理的脆弱性
| 業界 | 脆弱な機能 | 悪用例 |
|---|---|---|
| ECサイト | 割引・送料無料条件 | 条件成立後に商品削除で利益確保 |
| サブスクリプション | 初月無料 | キャンセル＆再登録を繰り返す |
| SNS | フォロワー誘導機能 | リンクの操作で意図せずフォローさせる |
| 教育プラットフォーム | 試験スキップ機能 | クッキー改ざんで認定を得る |
| 金融サービス | 利用限度額設定 | 初期の残高が保持されず条件回避 |
🔍 脆弱性発見のアプローチ
どんな行動が有利になるか？
- 割引、無料特典、優先アクセスなどを得るための条件を把握。
その条件はいつチェックされているか？
- ロジックが適用されるタイミングの前後を狙って検証。
条件を満たした後で操作を変更できるか？
- 「条件成立 → 状態変更（削除/キャンセル）」という操作の組み合わせでバグを探す。
開発者が期待していない操作の流れは？
- ワークフローを逆行したり、中間ステップを飛ばしたりしてみる。
🛠 ツールの活用
- Burp Suite Repeater や Proxy を使って、リクエストの順序やパラメータの値を手動で変更し、フロントエンドでは許されない操作をサーバーに送信してみる。
- 状態変更が「クライアントでのみ確認されている」場合は大チャンス。
✅ まとめ
ビジネスロジックの脆弱性は、表面的には正常に見えても、実際には設計段階の想定の甘さによって深刻なセキュリティ問題を引き起こします。特に業界特有の要件や機能を理解せずにテストを行うと、見逃される脆弱性が多く存在します。
ペネトレーションテストやバグバウンティでこの種のバグを見つけたいなら、業界の仕組みに対する深い理解と、ユーザー行動に対する柔軟な視点が不可欠です。理解すればするほど、他の人が見落としたバグを発見できる可能性は高まります。
Best regards, (^^ゞ
