Authorization

OWASP – A5:2017

Authorization controls refer to an application's functionality for verifying user roles and permissions. Authorization controls ensure safe access to the application, the data within, the ability to change the system, and more. Every functional piece of the application should have a set of authorization controls that encompass the use cases surrounding it, and prevents unauthorized users from accessing the protected functionality.

Horizontal Authorization

OWASP – A3:2017

A horizontal authorization control prevents users from accessing data or functionality for other users in the same or similar role. For example, a user of a message board application should not be able to post messages under other users' accounts. When a horizontal authorization bypass occurs, the application loses the ability to segment user data and to audit dangerous user activity.

Cross-account attacks

Using two accounts, verify (across all relevant routes) that a user cannot read, modify, or delete content or settings for another user.

Cross-organization attacks

If the application supports organizational features, use accounts in two separate organizations to verify that users (across all relevant routes) cannot read, modify, or delete content or settings for an organization they are not a member of.

Insecure direct object references

Applications frequently use the actual name or key of an object when returning or modifying data for that object. Because non-malicious users will never attempt to directly access objects they do not have access to, authorization controls for these types of routes are often overlooked. However, if an attacker can guess or steal valid identifiers, they can abuse this lack of authorization to retrieve or modify information for the relevant object. This vulnerability is known as an Insecure Direct Object Reference (IDOR).

For each route that takes a parameter referring to the absolute identity of an object, verify that the route authorizes both the general role of the user and the ability of the user to perform the relevant action for the targeted object. This should be the case even if the identifier is unguessable, as explained in Toxic Tokens: Using UUIDs for Authorization is Dangerous by Tanner Prynn.

Vertical Authorization

A vertical authorization control prevents users from accessing functionality for higher-privileged roles. For example, regular users should not be able to access administrator functionality.

Cross-role attacks

A common application vulnerability occurs when a route fails to check that a user's role permits them to perform a specific action, resulting in attackers being able to perform actions outside of the intended authorization model. For each role in the application, check that the role can only perform the intended actions, focusing on low-to-high-privileged attacks such as administrative functionality.

Privilege escalation

If a user can modify their role through an authorization vulnerability or take over a higher-privileged account, the issue is known as privilege escalation. Audit the application's role checking and management code to ensure low-privileged users cannot change their own or other accounts' roles.

Logical Authorization

A logical authorization control prevents users from bypassing the application's logical limitations. For example, a user of a stock trading application should not be able to buy a stock without enough money in their account.

Business logic bypasses

Verify that input and access limitations imposed by the business on the application (such as daily transaction limits, sequencing of tasks, or access to premium features) are explicitly checked for each relevant route.

Rate limiting

If the application performs rate limiting, verify that the rate limiting is effective and cannot be trivially bypassed (for example, by stripping cookies or signing out and signing in).

Rate limiting is generally only effective against unsophisticated, untargeted attacks. Engineering teams can help provide useful context on whether a lack of rate limiting is relevant for any specific application functionality. Rate limiting is most useful for highly sensitive, unauthenticated actions (login and account recovery). However, efforts to detect attacks and proactively protect users, or to implement and promote multi-factor authentication are almost always more worthwhile.

Next Section

Continue to Frontend Attacks.