LABレベル実践：Mass Assignment脆弱性のテスト方法 – `isAdmin`を使って管理者権限を奪取せよ

Hello there, ('ω')ノ

Mass Assignment脆弱性を見つけ出し、意図しないフィールド（例：isAdmin）を操作できるかどうかを検証するには、リクエスト本文にそのパラメータを直接追加して送信するテストが効果的です。

---

🧪 ステップバイステップ：Mass Assignmentの検証方法

✅ 1. 通常の更新リクエストにisAdminを追加

まずは「通常通り動作しそうな形式」でリクエストを送ってみます：

PATCH /api/users/123 HTTP/1.1
Content-Type: application/json

{
  "username": "wiener",
  "email": "wiener@example.com",
  "isAdmin": false
}

📌 期待する動作
- サーバーがこのリクエストを問題なく処理する場合 → isAdmin はバインド可能（Mass Assignment対象）である可能性がある。

---

🚩 2. 不正な値を使ってエラーを誘発

次に、無効な値 "foo" を使ってアプリの挙動を観察します：

{
  "username": "wiener",
  "email": "wiener@example.com",
  "isAdmin": "foo"
}

📌 この時に注目すべき点
- 500エラーやバリデーションエラーが出るか？ - 挙動が明らかに変わるか？（通常の更新時と違う）

👉 変化がある = サーバーがisAdminを内部処理に使っている可能性あり

---

✅ 3. 本命：isAdmin: trueで攻撃リクエスト送信

{
  "username": "wiener",
  "email": "wiener@example.com",
  "isAdmin": true
}

📌 もしアプリがこの値を受け入れているなら、ユーザー wiener に管理者権限が誤って付与される可能性あり！

---

🔍 結果の確認方法

• 管理者用ページ（例：/admin）にアクセスできるか確認
• ナビゲーションメニューに新たな「管理者機能」などが表示されるか
• 他ユーザーの情報にアクセスできるようになっていないか

---

🧠 チェックポイント

テスト	観察ポイント	意図
isAdmin: false	正常動作するか？	パラメータが存在しても問題ないかの確認
isAdmin: "foo"	エラーになるか？	サーバーがパラメータを処理しようとしている証拠
isAdmin: true	権限昇格できたか？	脆弱性の最終確認

---

✅ まとめ：Mass Assignmentテストの鉄板構成

1. GETレスポンスで隠しパラメータを発見
2. PATCH/PUTで隠しパラメータを送信
3. 不正値によるテストで挙動を観察
4. 本命値でシステムの動作確認（例：管理画面へのアクセス）

Mass Assignment脆弱性は、表から見えないけど裏では機能している重要なフィールドを操作するシンプルで強力な攻撃ベクトルです。見つけたときはインパクトが大きいため、実際のペンテストでも必ず試したいポイントです。

Best regards, (^^ゞ