OWASP Top 10: Broken Access Control

Written by

raxis-sys-admin

in

The Open Web Application Security Project (OWASP) Top 10 is intended as a guide to help security professionals prioritize the most common and urgent web application threats that they or their clients are likely to face. By collecting and analyzing data over time, OWASP is a source of both intelligence and awareness for the people responsible for building secure applications. Raxis uses the OWASP Top 10 as a baseline when assessing web applications, ensuring that our customers are guarding against each of the most common threat categories. Of course, our testing goes well beyond the items on the list, but it is an effective starting point for security assessments.

What Is a Broken Access Control?

Broken access control, not to be confused with broken authentication, happens when a user unintentionally is granted elevated permissions or access to an application, user role, or domain. But what does that mean to website users? It means that the user, whether a hacker or someone unintentionally discovering the vulnerability, gains access that was never intended, whether that is access to private information for other users or access to an admin page that allows them to perform actions few people should be allowed to do.

When a web app fails to enforce proper access controls, the results can be unauthorized disclosure of sensitive information, modification or destruction of data in the system, or the ability to perform business function the user should have no authority to perform.

This vulnerability has moved from the fifth position all the way to first in the new 2021 OWASP Top 10 update. According to the OWASP Foundation, 3.81% of the applications tested had some form of broken access control. While that may sound like a small percent, the cost is high when you realize the sensitive data & systems that could be exposed.

A Few Examples

Many web applications can have a user login page with data such as credit card, phone number, or address information. Let’s consider two users of that application, Fred and Karen. If Karen was logged into her profile, she might see a URL similar to the link below:

website[.]com/app/acctinfo?user=karen

But what happens if she can simply change “karen” on the end of the URL to “fred”? We would get the URL below:

website[.]com/app/acctinfo?acct=fred

By itself, that is not broken access control. If the application is secure, Karen would be denied access. However, if Karen was then able to see the information in Fred’s account, it would be an example of broken access control. But why stop there? Once Karen realizes she can see Fred’s personal information, she might write a script that tries common names of other people to gather thousands of credit cards to sell on the dark web.

Another example of a broken access control is the ability to access a server status or web app information page that should not be public to all users. If an unauthenticated user can access either of the two example pages below, it would be a form of broken access control.

website[.]com/server-status
website[.]com/app/getappinfo

Why would that be important? Many attacks require multiple steps, and each step that provides information helps the hacker understand if their actions are working or not. A hacker may use a server-status page to see if their attack is successful, or they may use the getappinfo page to find out what software the server is using so they know what type of attacks to try.

How to prevent Broken Access Control

Remediating broken access control is not a one-size-fits-all concept. Just like people are all unique and beautiful in their own way, and deserve to be treated fairly, not tossed aside… err [deep breath] ahem. Really sorry. Website developers must implement trusted server-side code or APIs that do not allow attackers to modify the access control checks or metadata.

The list below is a good place to start with hardening Access Controls in your environment:  

  • Implement deny-by-default on everything except public resources.
  • Minimize Cross-Origin Resource Sharing (CORS), instead implementing access control mechanisms once and reusing them throughout the application.
  • Enforce record ownership rather than accepting that the user can create, read, update, and/or delete any record.
  • Ensure file metadata and backup files are not present in web roots.
  • Disable web server directory listings.
  • Set rate limits for API and controller access to minimize the attack surface of automated attack tools.

Want to learn more? Take a look at the second part in our 2021 OWASP Top 10 Series.

More posts