**Note: The content in this article is only for educational purposes and understanding of cybersecurity concepts. It should enable people and organizations to have a better grip on threats and know how to protect themselves against them. Please use this information responsibly.**
Broken object property level authorization is a security vulnerability that occurs when an application fails to enforce proper access controls on individual properties within an object. This type of flaw allows unauthorized users to access, modify, or delete properties they should not have permission for, potentially leading to severe data breaches and system compromises.
How It Happens
- Inadequate Access Controls: Often, applications implement access control at the object level but overlook the need for property-specific authorization checks. This oversight can result in users being able to manipulate properties that should be restricted.
- Mass Assignment: Similar to mass assignment vulnerabilities, broken property level authorization can occur when an application blindly accepts user inputs and binds them to object properties without proper validation. Attackers exploit this by including properties they are not authorized to manipulate.
- Lack of Property Filtering: Applications that do not filter out or validate properties on a per-property basis can inadvertently expose sensitive data or allow unauthorized changes. This is especially problematic when using automated frameworks that simplify data binding but lack granular control over individual properties.
A. Excessive data exposure
Developers often lazily return entire objects and rely on clients to filter data rather than cherry-picking specific attributes. This oversight in design can enable attackers to extract sensitive information that should have been properly restricted simply by making direct API calls. Handling or storing personally identifiable information (PII) is sometimes unavoidable. Applications often need to return a user’s information or even that of others when authorized. It’s essential to manage this data carefully, as mishandling it can have serious repercussions, including identity theft and reputational damage.
Walkthrough:
- Initialize with Sample Data
Start by sending a request to the /createdb endpoint to set up the database with sample data. This will give you a foundation for testing.
- Register a New User
Use the /users/v1/register endpoint to create a new user account.
{
“username”: “stratosally”,
“password”: “stratos”,
“email”: “stratosally@gmail.com”
}
- Authenticate the User
Log in using the /users/v1/login endpoint with the credentials of the newly registered user.
{
“username”: “stratosally”,
“password”: “stratos”
}
- Store the JWT
After a successful login, you’ll receive a JSON Web Token (JWT) in the response. Copy this token and save it as a new collection variable (make sure to click Save).
“jwt_stratosally”: ” eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3MjYxMDU5NjgsImlhdCI6MTcyNjEwNTkwOCwic3ViIjoic3RyYXRvc2FsbHkifQ.4zZQBlU7RAysWLApxqEiqgsX5GkQTskA8tHy2Hiq5B8″
- Configure Authorization
Navigate to the Authorization tab. From the Type dropdown menu, select Bearer Token and set the saved variable as the token value.
Token: {{jwt_stratosally}}
- Use the JWT for Subsequent Requests
This token will be included in the Authorization header for future API calls whenever you need to authenticate the user.
- Access Debug Data
Investigate the /users/v1/_debug endpoint to retrieve data for all users. This endpoint might be included in the production API by mistake. It provides sensitive information, including user emails, passwords, and usernames, along with an admin parameter indicating if the user has administrative privileges.
B. Mass Assignment
Mass assignment is a vulnerability that allows users to modify all properties of an object, including the ones that should only ever be indirectly modified. For example, a user should have the ability to update their cart by adding and removing items, but their credit balance should only indirectly change as a result of them making payments or spending money. This issue can arise when the API automatically maps client parameters to internal object properties without filtering them through an allowlist of permissible properties for updates. For example, users may be able to update their basic details, such as their address, with a PUT request. A malicious user looking to make a quick buck may replay this request with an additional property, such as their account balance, and assign themselves an arbitrary amount of money.
Walkthrough:
- Discovering the Parameter
We have identified an admin parameter. Let’s see if we can leverage this to create an admin user.
- Register a New User with Admin Privileges
Return to the /users/v1/register endpoint to create another user. This time, include “admin”: true in the request body as shown below.
{
“username”: “test”,
“password”: “test”,
“email”: “test@gmail.com”,
“admin”: true
}
- Verify the New Admin User
You will notice that the request is accepted. To confirm, send a request to the /users/v1/_debug endpoint, which retrieves all user details.
The newly created user will appear at the bottom of the response list with the admin status set to true.
By understanding and addressing broken object property level authorization, developers and security professionals can better protect their applications from unauthorized access and modifications, ensuring the integrity and confidentiality of sensitive data.
