Hello there, ('ω')ノ
Mass Assignment（一括代入）脆弱性の特徴として、開発者が意図していない内部フィールドまでリクエストで操作できてしまう点があります。そのため、APIレスポンスに含まれるオブジェクトの構造を観察することで、隠れたパラメータを特定するヒントを得ることができます。
🔍 Mass Assignmentによって生まれる隠しパラメータの見つけ方
✅ 1. PATCH/PUTなどの更新系APIをチェックする
通常、PATCH /api/users/ のようなエンドポイントでは、ユーザーが更新できる特定のフィールドだけがドキュメントに記載されています。
例: PATCHリクエスト（ユーザーによる更新操作）
{ "username": "wiener", "email": "wiener@example.com" }
この時点では、「username」と「email」しか操作できないように見えます。
✅ 2. GETなどで取得できる「全項目」をチェックする
次に、同じ対象ユーザーをGETで取得してみると、より多くのフィールドが含まれていることがあります。
例: GET /api/users/123 のレスポンス
{ "id": 123, "name": "John Doe", "email": "john@example.com", "isAdmin": "false" }
💡 ここに注目！
id：ユーザーID（通常変更不可）isAdmin：管理者フラグ（UIでは変更できないが…）
👉 これらのフィールドがレスポンスに含まれているということは、内部的にはユーザーオブジェクトの一部であり、自動マッピングされる可能性があるということ！
🧪 3. PATCHリクエストで隠しフィールドを操作してみる
上記を踏まえて、PATCH /api/users/ に対して以下のようなリクエストを送信してみます：
{ "username": "wiener", "isAdmin": true }
🔁 レスポンスの変化や、GETリクエストで再確認することで、変更が反映されたかを確認！
→ 成功すればMass Assignment脆弱性が存在し、isAdmin フラグの改ざんに成功しているということ！
🔑 重要なヒント
| 観察ポイント | 狙い方 |
|---|---|
| GETレスポンスに含まれるが、PATCHには記載されていないパラメータ | それらがMass Assignment対象か試す |
| 値がtrue/falseなどのフラグ系 | 管理者、認証、公開設定の可能性あり |
id, role, status, permissions などのフィールド名 |
アクセス制御や機能制限に直結していることが多い |
文字列形式のブール値（例: "isAdmin": "false"） |
システム的には true に変えて試すべき対象！ |
✅ まとめ：APIから見える隠しパラメータを暴く技術
- GETレスポンスで取得できる全フィールドを観察する
- PATCH/PUTリクエストで、それらを追加して試す
- 変更が反映されるかどうかを確認し、Mass Assignmentの有無を判断する
- Burp IntruderやParam Minerを使えば自動化も可能
このようにして「表からは見えないけど内部では存在するパラメータ」を見つけ出すことで、APIの奥に潜む脆弱性にアクセスできます。特にIDや管理者権限を含むパラメータは、システム乗っ取りにつながる重大なリスクを生むので、丁寧に調査しましょう。
Best regards, (^^ゞ
