Hello there, ('ω')ノ
🎯 1. アクセス制御の脆弱性とは？
アクセス制御の脆弱性とは、本来アクセスできないはずのリソースや操作が、ユーザの立場（例：一般ユーザ、管理者など）に関係なく行えてしまう問題です。
🔓 例：
- 一般ユーザが 管理者ページにアクセス できる
- ユーザAが ユーザBの情報を取得・更新 できる
- ログインしていない状態で 保護されたデータにアクセス できる
🧭 2. チェックすべきページ・機能一覧
| 種別 | ページ・機能の例 | 備考 |
|---|---|---|
| 👤 プロフィール編集 | /user/edit?id=123 など |
他ユーザのIDに書き換えてアクセスできるか |
| 📁 管理画面 | /admin/, /dashboard, /settings |
一般ユーザでもアクセスできないか |
| 📦 注文履歴・購入情報 | /order/view?id=555 |
他人の注文履歴を閲覧できるか |
| 📝 データ削除・更新API | POST /deleteUser など |
一般ユーザで実行できてしまわないか |
| 🔐 ロール依存の機能 | 管理者・編集者・ゲストなどで制限される機能 | ロール変更による機能操作の可否 |
🎯 3. 挿入・操作すべきポイント
| 操作対象 | やるべきこと |
|---|---|
| URLのID・パラメータ | 他のユーザのIDやデータに書き換える（例：id=1000） |
| Cookie / セッション情報 | ロールを偽装できるCookieがあるか確認 |
| APIリクエストのボディ | JSON内のuser_idを書き換えて他人のデータを操作できるか |
| 画面上に出てこない機能URL | ブラウザで直接入力してアクセスできないか試す |
🛠️ 4. 診断方法（手順）
- ユーザを2つ用意（例：user1, user2／adminと一般ユーザ）
- ログインして動作を記録（Burp Suiteなどで）
- 他のユーザのIDやデータに書き換えて再送信
以下のような反応がないかチェック：
- 本来アクセスできない情報が見える
- 処理が成功してしまう
- エラーメッセージが返らず正しく動く
🧪 5. 簡易テスト例
URL書き換え：
https://example.com/user/view?id=1002 ↓ id=1001 や id=1 に変更して試す
APIリクエスト変更：
POST /updateOrder HTTP/1.1
Content-Type: application/json
{
"order_id": "123",
"user_id": "1"
}
🧾 6. サンプルケース
例：ユーザ編集ページ
- ログイン後、
/user/edit?id=10にアクセス - 自分のID以外（例：
id=1）を入力しても編集ページが表示される → 脆弱性あり
例：管理者画面
- 一般ユーザで
/admin/dashboardにアクセス - 403 Forbidden でない or 表示される → 脆弱性あり
⚠️ 7. 注意点・ベストプラクティス
- 📌 IDorパラメータだけでなく、ロールによる機能制限の欠如にも注目
- 🔐 ロール変更や昇格が可能なパラメータ（例：
role=admin）にも注意 - 🧍♂️ ユーザごとのアクセス制限テストはユーザを複数作って行う
- 🚫 WAFやJavaScriptで制限されていても、バックエンドで制限されていなければ脆弱性あり
🧰 8. 補助ツール
- Burp Suite（RepeaterやComparerでリクエスト比較）
- Postmanやcurl（手動でAPI呼び出し変更）
- 2アカウント作成が可能なテスト環境
✅ 検査対象かどうかを見極めるキーワード
id=,user_id=,account=,order_id=,role=,admin,owner_id- 「マイページ」「詳細」「編集」「削除」などの動作が含まれる場所
Best regards, (^^ゞ
