Broken Authorization

Play Labs on this vulnerability with SecureFlag!

Broken Authorization
1. Description
2. Impact
3. Scenarios
4. Prevention
5. Testing

Description

Broken Authorization (also known as Broken Access Control or Privilege Escalation) is the hypernym for a range of flaws that arise due to the ineffective implementation of authorization checks used to designate user access privileges.

Different users are permitted or denied access to various content and functions in adequately designed and implemented authorization frameworks depending on the user’s designated role and corresponding privileges. For example, in a web application, authorization is subject to authentication and session management. However, designing authorization across dynamic systems is complex, and may result in inconsistent mechanisms being written as the applications evolve: authentication libraries and protocols change, user roles do as well, more users come, users go, some users are (not) removed when gone… access control design decisions are made not by technology, but by humans, so the potential for error is high and ever-present.

Vulnerabilities of this nature may affect any modern software present in web applications, databases, operating systems, and other technological infrastructure reliant on authorization controls.

Impact

In a successful attack, a malicious actor may be able to access unauthorized content, change or delete content, perform functions, and even assume full control of site administration. Once this level of compromise has been achieved, the damage of the attack is limited only by the privileges granted to the impersonated victim.

Indeed, the breach of a toy-making company called CloudPets illustrates the aforementioned human error. In this case, the result of non-existent authorization controls led to the leak and subsequent ransom of children’s voice messages, which had been recorded via, and stored (badly) in, the cloud.

Scenarios

From the perspective of the user, there are two main categories of authorization controls to consider:

Horizontal Authorization Controls
Vertical Authorization Controls

Horizontal Authorization Control Bypass

Bypassing Horizontal Authorization Controls describes the act of an unprivileged user gaining access to other users’ accounts that possess equal privileges.

For example, imagine an application accepting unverified data in a method call downstream to retrieve account information. An attacker could easily modify the accountId parameter in the HTTP Request to retrieve data from one or even multiple other users’ accounts.

The application uses unverified data in a method call downstream to retrieve account information:

http://vulnerableapp.com/user/account?accountId=7800001

http://vulnerableapp.com/user/account?accountId=7800002

etc.

Insecure Direct Object References, or IDOR, is a related scenario involving user-supplied input being utilized to access objects directly.

Vertical Authorization Control Bypass

Vertical Authorization Control bypasses describe the upwards use of access. That is, when a user with a certain level of privilege can indicate that they possess some higher level of access, like administrative level access, to the application.

In this example, an attacker has browsed to an administrative URL, where admin rights should be required to access the admin page.

http://vulnerableapp.com/user/account

http://vulnerableapp.com/admin/panel

If the application does not check whether the role of the session user matches the role required to access the resource, a user without admin privileges will be able to access the page by simply knowing/guessing the target URL and browsing to it.

Prevention

There are numerous basic steps developers can take to prevent Broken Authorization Control attacks, starting with an appraisal of an application’s access control requirements and then the formation of an appropriate security policy congruent with the findings. This should include an access control matrix, a clear policy of what types of users can access the system, and what these users can and can’t do with their access. Use role-based access control (RBAC) to enforce the roles at the appropriate boundaries.

For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page and API endpoint. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to the page or object.

Testing

Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization.

OWASP ASVS: 4.1, 4.2
OWASP Testing Guide: Authorization Testing