Hello there, ('ω')ノ
1. 複数ステップ処理のアクセス制御ミス
多くのWebアプリは、重要な操作を複数のステップに分けて実行します。 例：管理者がユーザー情報を更新する場合
- ユーザー情報のフォームを表示（Step 1）
- 変更内容を送信（Step 2）
- 確認画面で確定（Step 3）
典型的な脆弱性
- Step 1, Step 2 では適切な権限チェックをしているが、Step 3 ではチェックを省略
- 開発者は「Step 3 は必ず Step 1 と Step 2 を経由する」と思い込み、直接アクセスを想定していない
- 攻撃者はStep 3 のリクエスト形式を知り、最初のステップを飛ばして直接送信することで権限を回避できる
2. Refererベースのアクセス制御
一部サイトは、アクセス制御にRefererヘッダーを使います。 例：
/adminページは厳格にチェック/admin/deleteUserページは Referer に/adminが含まれていれば許可
問題点
- Refererヘッダーはクライアント（攻撃者）が自由に設定可能
- 攻撃者は
/admin/deleteUserに直接リクエストを送り、Referer を偽装するだけで実行できる
攻撃例
GET /admin/deleteUser?username=carlos HTTP/1.1 Host: vulnerable-website.com Referer: https://vulnerable-website.com/admin
3. 位置情報ベースのアクセス制御
金融サービスや動画配信などで、利用者の地理的な場所によってアクセスを制限することがあります。
回避方法
- VPNを利用してIPアドレスを別の国に偽装
- Webプロキシを経由
- ブラウザの
navigator.geolocationを偽装
4. 防止策（設計原則）
- 隠すだけ（Obfuscation）では守れない URLや機能を見えなくしても、直接アクセスできれば意味がない
- デフォルト拒否（Deny by Default） 公開目的でないリソースは全て拒否設定から始める
- アプリ全体で統一的なアクセス制御機構を利用 ページごと、機能ごとにバラバラに実装しない
- コードレベルで権限宣言を必須化 どのリソースに誰がアクセスできるかを明示し、デフォルトは拒否
- アクセス制御の監査・テストを徹底 特に、直接アクセスやステップスキップが可能かを確認する
Best regarsd, (^^ゞ
