Hi everyone! Hope you are having an awesome day 🤗
Today, I am going to be talking a little bit about Mass Assignment, which has a pretty straightforward concept in my opinion. API6:2019 is also one of my favorite issues when it comes to OWASP API Security TOP 10, so I hope you all like it!
🏞️ Just Some Background
Let's say that we have an endpoint which is meant to be used in order to change your personal information, and this endpoint expects an HTTP request like the following one:
PUT /users/info HTTP/1.1
Host: api.example.com
Authorization: Bearer sup3r_t0k3n_h3r3{
"firstName": "Naruto",
"lastName": "Uzumaki",
"email": "dattebayo＠mail.com",
"phoneNumber": "12345-6789",
}
Ideally, by looking at this request, we might assume that there is a mechanism in the API to filter what is coming and finally guarantee that only this specific user attributes are going to be changed, not anything else. A possible (and simplified) approach for that would be like this pseudo code:
userData := request.get([
'firstName',
'lastName',
'email',
'phoneNumber'
])...
wasSucceeded, error := User::update(userData, userId)
...
return response(200,{success: true})
😱 Here's The Problem!
Not rarely at all, API endpoints are built in generic ways, and very often we may find endpoint implementations that doesn't take into account the possibility of an user insert into the request some attributes that were not originally meant to be there. A great example would be if we changed a little bit the previous code, and made it be like this:
userData := request.getAll()
...
wasSucceeded, error := User::update(userData, userId)
...
return response(200,{success: true})
Now that it uses everything which is coming from the request in order to update the user, basically it's possible to change all the attributes that exist for the User entity, like for example, a hypothetical attribute called ìsAdmin.
If this attribute isAdmin exists, and it's used to define an "user role", an attacker may abuse this flaw in order to make itself an admin with a simple HTTP request such as the one down below:
PUT /users/info HTTP/1.1
Host: api.example.com
Authorization: Bearer sup3r_t0k3n_h3r3{
"isAdmin": true
}
And there we have API6:2019! 🙈
A similar case would the GraphQL example which I presented in the API3:2019 post. Technically, this case would not fit inside the Mass Assignment concept, because API6:2019 involves being able to store or modify data and not just see it, but the exploiting scenario is quite the same.
📚 External materials
As my goal with this series is to just explain what each flaw is, I would like to suggest what I used to learn about API6:2019, so you understand better the details of it:
https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa6-mass-assignment.md
Top comments (0)