Broken access control refers to common weaknesses in software applications that can lead to users bypassing the authorization needed to execute certain functions. This includes creating, deleting, accessing, or updating records. It’s important to control who has access to particular features of your system to prevent attackers from getting a hold of sensitive resources.

Authentication vs Authorization

Let’s understand the first two confusing terms!!

The difference between authorization and authentication, and then move on to how attackers try to break authorization, and what techniques they use to gain access to protected web sites.

Authentication means logging into an application user account. For this to happen smoothly, An Application needs to verify user identity before letting a user in.

Authorization differs in that even if a user is authenticated into a system, he/she may not be authorized to perform certain functions within the application.

Think of your office building. Your keycard(Access Card) can authenticate your identity, but it may not authorize you to access every room in the building.

So when it comes to the Internet, most web applications have more than one type of user, just like how office buildings have more than one type of employee. Because of this, certain application functions may only be available depending on the roles and responsibilities of that user.

It would not be safe to give everyone access to all functionality or data of a system, so we separate them based on various roles like users and administrators. Admins typically have permissions like managing content, users, and pages. In contrast, users might only have permission to view and change their profile, account info, and transactions depending on the application.

Privilege Escalation

Privilege escalation can be a serious security breach. It involves a user gaining unauthorized access to data or functionality that isn’t meant for their level of access. Let’s look at an example of Vijay accessing Finance Manager, a tool she uses to manage his online banking and finances.

Take a look at the browser address bar Here, a number refers to someone’s profile Also, there is a greyed-out admin link on the page. If Vijay were mischievous, what might she try 1 to bypass access control?

if Vijay tried changing the profile number to 6000, or any other number, he could access the profile of another user. In this case, he accesses user 6000’s profile revealing their credit card numbers.

he could do the same for every person who uses Finance Manager This is known as a horizontal privilege escalation exploit because Vijay was able to access users on the same level of access as his own.

Stop here !! but what about the greyed-out admin link? Vijay decides to loot at the web page’s source code and notices that the admin link has been hidden by using HTML comments Even though the developers wanted to make the link unclickable, they didn’t do a good job of hiding the link’s URL in the source code.

Vijay enters the new URL and finds that she now has access to the administrator pages and can manage projects, users, finances, and create reports This means anybody with the link could access these pages with or without authorization This is called a vertical privilege escalation exploit because Vijay was able to access higher levels of functionality and view sensitive data.

Insecure Direct Object Reference

Insecure direct object references are caused by not validating user input that affects business logic. It happens when hackers modify values, like URIs, to create unexpected consequences.

If we take a look at the parameters in the URL for profile and type, we can see that they contain values If an attacker changes these values, they might be able to access unauthorized features of the system as well as gain additional privileges or gain access to data they aren’t authorized to view.

You can think of a direct object reference as a one-to-one mapping between an actual object (the record), and a value in the application (the reference)

Below an example of the web application, as we looking at the URL in the web page, we see a value assigned to “user” This value is a direct reference because it maps to records in a database that can be directly accessed by the application.

If we change the value of “user”, we can access other user profiles. If the malicious user changed the ID of the user, he/she could access someone else’s account, and maybe even make changes to that account.

Let’s look at how files can be directly referenced through the information in URIs Here, we can see a filename of a bank statement, If we changed this value, we could access another person’s statements.

A mischievous person might try to break out of the folder structure containing PDF files and dig deeper into the web server’s file system with some knowledge of directory and folder structures, someone could even request another sensitive file or system resource.

For example, if we change the path in the URL to /etc/password file, instead of the PDF, the application displays all of the passwords and users on the webserver.

Missing Function Level Access Control

A function level refers to the functions available to someone based on their role. So function level access control prevents people in a system from using functionality and resources they shouldn’t have access to If these controls are missing, attackers can exploit functions or everyday people can misuse them.

This vulnerability is an authorization issue because the application doesn’t properly restrict access to privileged functions. Two examples of how a user could take advantage of this weakness is by forced browsing and parameter manipulation. Forced browsing is when someone can find or guess the URL of a higher-level action or area of the application. Parameter manipulation is when someone can change the input to use actions that should be hidden, or in a way that a developer never intended.

Forced browsing is when someone can find or guess the URL of a higher-level action or area of the application. Parameter manipulation is when someone can change the input to use actions that should be hidden, or in a way that a developer never intended.  

If hackers know the links to your site, they might be able to access Its pages directly without logging In.

How does someone figure out URLs they can’t see? They can use their browser history, proxy logs, or page printouts. Never assume that just because a resource isn’t visible an attacker won’t find it.

Countermeasures Against Broken Access Controls

Implement Server-Side Checks

It’s important to assume that all input from users is malicious. Whether an exploit is intentional or accidental, the input should be validated or revalidated to prevent unexpected consequences.

The first step to prevent parameter manipulation by using a central security check to protect against malicious input like injection, and another check to validate business rules. Be aware that client-side validation should only be used for performance or user experience, but it’s not a reliable validation method otherwise.

It can be helpful to create a chart that defines a policy for your organization and applications for which parameters are accessible to users, and the types of server-side checks being performed against them.

The different parameters require different types of input validation. The application system should have a centralized security module to manage validation for parameters and be aware that some parameters may require additional exceptions.

Implement Server-Side Session Variables

Another, defense against parameter manipulation is to avoid using URL parameters. Most modern languages have ways to store data within a user’s current session, so URL values can’t be exposed or tampered with.

If parameters are sensitive and you don’t want anyone modifying them while still keeping track of them, you can use session variables. Storing information in session variables stores them on the server-side for each user, and prevents hackers from tampering with URL parameters in the first place.

Page-Level Authorization

Page-level authorization verifies that a user is able to access a resource before making it available to them. For example, in a typical scenario a browser accessing a website, the Whole system has the browser, application server configuration, and files that are accessible on the webserver. The application server configuration determines which pages are restricted or allowed. The policy states that the user is allowed to access the page, so the site renders in the browser.

If a page is restricted due to a policy or hardening process, the application server configuration will reject the request from being served. Page-level authorization is usually controlled through web server configuration, the application framework, or operating system controls.

Risk of Page-Level Authorization

In this example, a user has access to read the “account.jsp” page. Notice that there is a function parameter in the URL associated with the page called “action”. An attacker could manipulate the “action” parameter to perform a different action, like “delete”.

Programmed Authorization

Where page-level authorization limits access to individual pages and other static resources, programmed authorization limits access to the logic within these pages using code. Page-level authorization isn’t enough when it comes to defending authorization for various functions. For example, when users are given access to an API, they can sometimes access hidden API calls or functions.

Using programmed authorization, you can define roles for our users like an administrator, manager, and user, and then make the application behave differently for each role. You can also make controls more fine-grained, such as by deciding who has permission to read, modify, and delete. However, one downside to this method is that because you have to code each role, you can’t easily add it on to an application after it’s been developed.

It’s important to note that you are not limited in using page-level authorization over programmed authorization, or vice-versa. The two are commonly used together for a stronger defense.

Key Take Away from this Article

Broken access control can lead to users bypassing authorization to use functions like creating, accessing, and deleting records. Attackers can do this by manipulating web URL parameters, and might even have access to administrator features.

One of the ways you can protect against these exploits is by using server-side checks and variables to prevent attackers from tampering with parameters. You can also use page-level authorization to verify users before they can access a page or programmed authorization to define roles and privileges for users.