Mass Assignment - Authentication - User Registration
Lab environment — not a production system
Screenshots and raw traffic are not translated; text within them may be in another language.
crAPI/Evidence/[PASS] Mass Assignment - Authentication - User Registration
01 — Notes
Test notes
Vulnerability
Description
Impact
CWE
OWASP
Scenario
Endpoint
Affected feature
Remediation
Proof of concept
View source note (English)
Vulnerability: [PASS] Mass Assignment - Authentication - User Registration
Description:
Tested whether the registration endpoint is vulnerable to mass assignment by injecting privileged fields (role=admin, isAdmin=true) into the signup body.
Impact:
No impact: the server ignores privileged fields, so no privilege escalation occurs.
CWE:
CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes (tested, not vulnerable)
OWASP:
API3:2023 - Broken Object Property Level Authorization (negative test)
Scenario:
Normal: standard registration. Exploitation: signup + role=admin/isAdmin. Result: login shows the role remains user -> PASS (control holds, CIA not violated).
Endpoint:
POST http://127.0.0.1:8888/identity/api/auth/signup
Affected Feature:
User Registration (crapi-identity)
Remediation:
Keep the allow-list of fields the client may set during registration (the current state is correct).
POC:
1) (Screenshot 1) NORMAL: signup with standard fields -> 200.
2) (Screenshot 2) EXPLOITATION: signup with the addition of role=admin & isAdmin=true -> 200 (registered).
3) (Screenshot 3) RESULT: log in to that account -> the JWT role remains "user" -> privileged fields were ignored (control holds).
02 — Screenshots
Screenshots (3)
Normal flow: registration using the standard fields, without the role field.
Exploit attempt: add role=admin and isAdmin=true to the signup body to request elevated privileges.
Result (PASS): logging in to the new account shows role="user". The server ignored the privileged fields, so the exploit attempt failed. No impact on confidentiality, integrity or availability was observed in this test.
03 — Requests and responses
HTTP captures
Some credential values are masked in this public HTML view. This does not mean every sensitive value or linked file has been redacted.
POST /identity/api/auth/signup HTTP/1.1
Host: 127.0.0.1:8888
Content-Type: application/json
{"name":"MassAssign Tester","email":"[REDACTED-EMAIL]","number":"+19990111","password":"[REDACTED-LAB-VALUE]"}HTTP/1.1 403
Server: openresty/1.27.1.2
Content-Type: application/json
Content-Length: 71
{
"message": "Number already registered! Number: +19990111",
"status": 403
}Normal flow: registration using the standard fields, without the role field.
POST /identity/api/auth/signup HTTP/1.1
Host: 127.0.0.1:8888
Content-Type: application/json
{"name":"MassAssign Tester","email":"[REDACTED-EMAIL]","number":"+19990222","password":"[REDACTED-LAB-VALUE]","role":"admin","isAdmin":true}HTTP/1.1 403
Server: openresty/1.27.1.2
Content-Type: application/json
Content-Length: 71
{
"message": "Number already registered! Number: +19990222",
"status": 403
}Exploit attempt: add role=admin and isAdmin=true to the signup body to request elevated privileges.
POST /identity/api/auth/login HTTP/1.1
Host: 127.0.0.1:8888
Content-Type: application/json
{"email":"[REDACTED-EMAIL]","password":"[REDACTED-LAB-VALUE]"}HTTP/1.1 401
Server: openresty/1.27.1.2
Content-Type: application/json
Content-Length: 88
{
"token": null,
"type": "",
"message": "Given Email is not registered! ",
"mfaRequired": false
}
# JWT payload -> role: "user" (BUKAN admin)Result (PASS): logging in to the new account shows role="user". The server ignored the privileged fields, so the exploit attempt failed. No impact on confidentiality, integrity or availability was observed in this test.