The team here at CyberWhite are going to put together a ten-part blog series on the globally recognised OWASP Top Ten list for web application security risks. This list is ordered in terms of prevalence, exploitability, detectability, and impact. 

To begin this blog series, we will start by looking at A01:2021-Broken Access Control, moving up from 5th position in the 2017 list to the top position for 2021. This change in position and risk is largely due to the prevalence of misconfigured web applications and the serious nature of the risk tied to broken access control. 

It is important to note that the content of the following blog series will aim to deliver a high-level overview of each OWASP Top Ten entry, rather than an exhaustive explanation. Should any of the posts provoke interest in a certain topic or vulnerability, CyberWhite encourages you to reach out and talk to one of our team for a more in-depth discussion. 

 

Broken Access Control – What is it? 

Access Control is enforcing policy in such a way that users are unable to act outside of the bounds of their given, intended permissions. A common example would be preventing regular users from accessing data that is specifically for users with administrative permissions.  

Failures to correctly enforce access control policies can typically lead to information disclosure, the modification or destruction of critical data, or the ability to masquerade as an authenticated user without their permission.  

Broken Access Control can often originate from: 

  •  Misconfigured permissions on a server or any frontend components.
  • A lack of strict enforcement of access policies on each user request to the server.
  • A failure to disable web server directory listing.
  • When using an API, the failure to set an appropriate rate limit against calls to said API.
  • A lack of controls minimising Cross-Origin Resource Sharing (CORS) usage.
  • Incorrectly configured or lack of rules to sanitise user input when using an SQL database to hold data. 

This list is not exhaustive but does help to highlight that minimising the risk of Broken Access Control often sits with developers during the development of a publicly accessible web server. 

 

Vertical and Horizontal Access Control. 

Vertical Access Control. 

Vertical access controls are put in place to restrict access to important functions for specific users. In this scenario, a user with administrative permissions may have the power to modify or delete a lower privileged user’s account, however a normal user would never be able to access this functionality. 

A typical scenario where a user gains access to this functionality can be found in cases of privilege escalation, where a regular user is able to gain the permissions of an administrative account. 

Horizontal Access Control. 

When implemented correctly, horizontal access control is a means of restricting access to a users’ data from other users with the same privilege level. For instance, this control is considered broken if one user can access the details of a separate users’ account balance in a service such as a banking app.  

Similarly, a web server misconfiguration may allow a user to access another’s email account and therefore read their personal correspondence without their permission.  

Horizontal broken access differs from vertical as in the scenarios described above, the user carrying out these attacks is not escalating their privileges to a higher level, merely utilising a misconfiguration to access the data of someone with similar privileges. 

Preventing Broken Access Control. 

When attempting to prevent broken access control vulnerabilities, it is important to implement and follow certain principles, including: 

  • Ensuring that session tokens are secure in their implementation, constantly validating them when a user makes a request, and ensuring that session timeouts are in place that will automatically revoke a user session token by logging them out.
  • Clearly define what each role (User, Moderator, Administrator) can and cannot do, and ensure that these rules are enforced across the entire application.
  • Enforce rate limits on API and controller access, which helps to mitigate the efficacy of tool-based attacks on the system.
  • Keeping logs of user access and subsequent activities, allowing the ability to detect unusual activities.
  • Unless a specific resource is completely intended to be accessed publicly, always deny access by default. 

When conducting penetration tests against a client’s web application, the team at CyberWhite follow the OWASP framework closely. This allows us to check applications against the OWASP Top Ten list, including Broken Access Control explored in this blog post.  

If you have any questions please reach out to Kieron  

(kieron.stead-marsh@cyberwhite.co.uk) or contact us at https://lnkd.in/e5Z_WbRM