Broken Object Property Level Authorization - 2023 OWASP Top 10 API Security Risks

Summary

The video discusses broken object property level authorization vulnerabilities, where users gain unauthorized access to or modify data they shouldn't. These vulnerabilities include mass assignment (where users override server-side properties) and excessive data exposure (where applications leak sensitive information). To mitigate these issues, the video recommends designing APIs to expose only necessary data, implementing the CQRS pattern to separate read and write operations, and enforcing strong access controls to restrict user actions. Overall, the focus is on secure API design and minimizing data exposure to prevent unauthorized actions and breaches.

Takeaways

• 😀 Broken Object Property Level Authorization refers to unauthorized access to object properties that users shouldn't be able to access, modify, or read.
• 😀 This vulnerability merges two issues from the 2019 edition: Mass Assignment and Excessive Data Exposure.
• 😀 Excessive Data Exposure involves leaking more information than necessary to users, potentially exposing sensitive data like medical records.
• 😀 Mass Assignment occurs when users can override server-side or read-only properties, such as manipulating the status of an unpaid order in an e-commerce system.
• 😀 A broken object property level authorization vulnerability occurs when users can modify data they shouldn't be able to, leading to security risks.
• 😀 To prevent such vulnerabilities, it's important to design APIs that only expose the data needed to solve the intended problem, rather than exposing all available data.
• 😀 Limiting data exposure in APIs prevents unauthorized access to sensitive properties that might be used to manipulate other endpoints.
• 😀 One approach to mitigating this issue is using patterns like Command Query Responsibility Segregation (CQRS) to separate reading and command-based operations in the API.
• 😀 Different schemas for reading and writing operations can help limit the exposure of sensitive data and reduce the risk of broken object level authorization.
• 😀 Ensuring that only necessary data is exposed and operations are appropriately divided can significantly reduce the chances of security breaches like broken object property level authorization.

Q & A

What is broken object level authorization?

Broken object level authorization refers to a vulnerability where users are able to access resources or properties within objects that they shouldn’t have access to, modify, or read. It typically occurs when a user gains unintended access to properties or actions associated with an object that don’t belong to them.

How does broken object level authorization manifest in real-world scenarios?

In real-world scenarios, broken object level authorization can allow users to read, modify, or delete data they shouldn't have access to. For example, in a medical application, a user may access sensitive patient records that should be restricted based on their role or permissions.

What vulnerabilities from 2019 are brought together in the 2023 vulnerability discussed?

The 2023 broken object level authorization vulnerability brings together two vulnerabilities from 2019: mass assignment and excessive data exposure.

What is excessive data exposure?

Excessive data exposure occurs when an application inadvertently exposes more data than necessary to users. This can lead to sensitive information being accessible to users who should not have permission to view it. An example would be leaking patient details that are not intended to be publicly accessible in a healthcare app.

What is mass assignment in the context of broken object level authorization?

Mass assignment refers to the ability of a user to override server-side properties, including read-only fields that should not be modifiable. For instance, in an e-commerce application, a user may try to change the status of their unpaid order to 'paid', which should not be allowed.

Can you give an example of how mass assignment can be exploited?

An example of mass assignment exploitation would be when a user places an order in an e-commerce system, and, through an API, they manage to modify the 'status' property of their order from 'unpaid' to 'paid', even though they have not made a payment.

What role does API design play in preventing broken object level authorization issues?

Proper API design is crucial in preventing broken object level authorization by ensuring that only the necessary data is exposed. The API should be designed to prevent the exposure of sensitive or internal server-side properties that could be manipulated by unauthorized users.

What strategies can be used to mitigate broken object level authorization?

Some strategies to mitigate broken object level authorization include ensuring that APIs only expose the data necessary for solving a specific problem, limiting access to sensitive properties, and using design patterns like CQRS (Command Query Responsibility Segregation) to separate read and write operations.

What is the CQRS pattern, and how does it help with broken object level authorization?

CQRS stands for Command Query Responsibility Segregation, which separates read operations (queries) from write operations (commands). By using different schemas for reading and writing, it becomes easier to restrict access to sensitive data and prevent unauthorized changes to the system.

What are the key takeaways from this discussion on broken object level authorization?

Key takeaways include the importance of secure API design, limiting the exposure of sensitive data, using patterns like CQRS to separate read and write access, and understanding how vulnerabilities like mass assignment and excessive data exposure can lead to broken object level authorization.