マスアサインメント (Mass Assignment).

マスアサインメントは、フレームワーク(Rails、Spring、ASP.NET、NestJS、Django)が、明示的な許可リストなしに、受信した JSON やフォームフィールドをモデル属性へ自動マッピングする際に発生します。攻撃者は isAdmin、role、balance、tenantId などの追加プロパティを含め、サーバーがそれらを永続化してしまいます。この欠陥はバインドが暗黙的であるためレビューで見つけにくく、単一の update_attributes(params) やモデルバインダーの呼び出しが、すべての属性が書き込み可能であるという事実を隠してしまいます。CWE-915 として分類され、OWASP API Security Top 10(2019 年の A6。2023 年に API3「Broken Object Property Level Authorization(オブジェクトプロパティレベル認可の不備)」へ統合)にも登場します。

代表的な事例は、Egor Homakov による 2012 年 3 月の GitHub ハックです。SSH 鍵のフォームがホワイトリストなしに public_key[user_id] をバインドしていたため、彼は細工したフィールドを追加し、自分の鍵を Rails の組織アカウントに紐付け、rails/rails へコミットをプッシュしました。GitHub は数時間以内にパッチを適用し、この事件を機に Rails は attr_accessible によるホワイトリスト方式(後の strong_parameters)をデフォルトとするようになりました。

対策には、明示的な DTO や入力スキーマ、バインド可能フィールドの厳格な許可リスト、内部専用属性とユーザーがバインド可能なモデルの分離、想定外の JSON キーを送る否定テストなどがあります。

flowchart TD
  A["クライアントが JSON を POST<br/>{name, isAdmin:true}"] --> B[フレームワークの自動バインダー]
  B --> C{フィールドの明示的な<br/>許可リストがある?}
  C -->|なし — マスアサインメント| D[すべてのキーがモデルに書き込まれる]
  D --> E[(isAdmin=true<br/>が DB に永続化)]
  C -->|あり — DTO / strong params| F[許可されたフィールドのみバインド]
  F --> G[(特権フィールドは無視される)]