In this article, we will examine the concept of access control and “broken access control” vulnerabilities with simplified examples.

What is Access Control?

The concept of “access control” means that people can access the resources within their authority which they have the right to access, and that they are not allowed to access resources that are not compatible with their authority, which they do not have the right to access.

A building where a door is used for entry and exit, only who has a key can enter. But someone has created a different entry alternative using a hammer. The door was not enough to control access and someone is surprised to this.

We can think of it as the customer area and the employee area of a commercial establishment. For example, in a restaurant, employees have access to the kitchen, cash register and customer areas, while customers only have access to the areas reserved for customers. If a customer enters an employee area and is noticed, he is asked what right he has to be there, because under normal circumstances he has no right to be there. If he managed to enter the employee area and was able to perform an action there, then we can say that there is a problem in the process of restricting access control. This is referred to as “broken access control”.

The same is true in digital environments. The difference is that the dynamics are not as clear as in a restaurant. On a shopping site, a user who is authorized to place an order should not have access to the product editing panel. He has no right to do so. This panel should be accessible to users with seller authorization.

How Does the Process of Controlling Access Work?

The process of controlling access, in its simplest form, starts by first determining the person’s authorization. The next step is to question whether the action the person wants to perform is “within his/her authorization”. If the answer is yes, the person has the right of access. If “no”, the person should not have access to that area.

Imagine a local artisan shop where employees and customers do not have visual identifiers that separate them from each other. In an environment where everyone is side by side, sometimes it is not clear who is a customer and who is an employee.

We can liken this to when we walk into a business, ask a customer whose shirt color is similar to the employees’ shirt color, and get the answer “I don’t work here”.

Welcome to the BAC Restaurant!

If we examine our restaurant example with a simplified floor plan, the blue parts represent the areas accessible to employees and the green parts represent the areas accessible to customers.

A customer should not have access to areas such as storage and safes. Employees, on the other hand, need access to the areas they are authorized to access to keep the business running. Customers need access to the dining tables to order and eat their food. They need to be able to interact with the cash register to make payments. But they should not be able to access the back of the cash register so that they cannot perform unauthorized transactions on the cash register. Looking at this floor plan, a customer has no right to access the storage in this restaurant. If they have access to the warehouse and can perform actions there, then the access control process implemented in this restaurant is broken.

Nice. But whAAAt is this?

No, the “a” key on my keyboard is not stuck. “AAA” is a logic framework in cybersecurity:

• Authentication: Verifying the identity of the user
• Authorization: Authorization to enter the restricted area
• Accounting: Holding the relevant user responsible for the results of the actions taken

Open Sesame Sesame Open – A Smart Cave

If the cave in the story of Ali Baba and the Forty Thieves in One Thousand and One Nights had a security-aware consciousness and wanted to tell us the AAA logic framework, what kind of story do you think it would be?

OPEN SESAME SESAME OPEN

Ali Baba came to the entrance of the cave.

Ali Baba said: “Open, sesame, open.” But this cave was a cave that cared about cyber security.

Cave: “Who are you?”

Ali Baba: “I am Ali Baba himself.”

Cave: “For me to believe that you are Ali Baba, you have to tell me something that only he would know. Tell me which cookie Ali Baba likes best.” [AUTHENTICATION]

Ali Baba: “I like chocolate chip cookies the best.”

Cave: “That’s right. When you enter the cave, take the torch from the entrance and carry it with you the whole time you are inside. This will be proof that I have given you permission to enter.” [AUTHORIZATION]

Ali Baba: And if I take something from the treasure, will you be able to recognize it?

Cave: The entire treasure was counted before you came in and will be counted again after you leave. The way I let you in leads to a single chest room and the doors to the other rooms are locked. [ACCOUNTING]

Ali Baba: For the first time I see a cave that has collected all the free certificates for cyber security awareness.

---

|

When we analyze the communication process, we can see that a simple level of precaution has been applied. But could someone else find out Ali Baba’s favorite cookie and lie about who it was?

Yes, someone could. If someone went further and stole gold from the treasury, would Ali Baba be guilty according to the records?

Yes, he would be. In this case, Ali Baba’s identity would have been forged and a crime would have been committed in his name. All the while, Ali Baba would probably just be sitting at home watching television.

So if an attacker knew where the treasure chambers were, could he have dug his way into all the chambers instead of entering through the door?

Yes, he could. Then there would be a “broken access control“.

Pause here for a moment and think about all the examples that could bypass the cave door. You may have noticed that there are many different tactics.

In the various examples you have read so far, you can already think of a few ways in which you can fool the authorization process. The only difference from now on will be to examine the digital versions of these tactics.

BAC Vulnerabilities in Application Security

There are various techniques that can cause BAC vulnerability in application structures. If secure coding principles are not followed, a user account can even try to access admin panels by simply entering the URL. The existence of such vulnerabilities is also a violation of the “least privilege” principle.

One of the most popular techniques to discover the BAC vulnerability is to perform request manipulations with the Burp tool. It is also a popular technique to discover BAC vulnerability in combination with other vulnerabilities. Performing manipulations on the URL can also lead to the discovery of a BAC vulnerability. According to some Rules of Engagement (RoE), chaining vulnerabilities may be considered out of scope and should be considered when testing.

BAC Examples:

ACHIEVING THE OBJECTIVE

Here, we see a dog that knows where it wants to go, trying to climb a ladder by adapting the reflexes it uses during normal walking, to climbing.

Let’s imagine a query panel in an application that can be accessed by the relevant authorized people and assume that we know the URL of this panel.

Let’s assume that the user we have is not in the user category that can access this query panel. We can try to log in from a low authorized user and go directly to the URL. This has a low probability of discovering a BAC, but not zero. If we see a place where the authorization parameter is sent to the server from the client-side, we can modify the authorization descriptor there to gain access to the URL we are targeting.

Image_Get=But_Which???

If users are presented with a path but no side paths are blocked, there’s nothing stopping them from doing what they want.

Let’s imagine a web application where we can see the invoices for the payments we have made. When I click on the invoice for my last payment, this is the link.

samplesite.com/payments?img=2311

By changing the image number ( img=5483 ), it can be attempted to view a payment belonging to another user. If another payment invoice can be successfully displayed, there is an IDOR vulnerability.

This could also be a cart identifier number on a shopping site, instead of a photo identifier number.

MORE AUTHORIZATIONS

If living beings are not sharply restricted from entering the jurisdiction of another, for whatever reason, they will certainly try to push the boundaries.

Let’s imagine that we can create groups in a web application that are relevant to the intended use of the application and that other users can join these groups and take actions according to the authorizations they are given. Applications with this kind of format can be applications like Discord or Slack and so on.

After opening the BURP tool and browsing the application for a while, we see a post request containing the example expression in the parameters inside one of the requests.
” UserType=participicator “

We can try to replace the “participicator” token with the token we see on the user who owns the room. On the user who created the room expression, we can try to write and send that expression to the participant user’s request that we are interested in.
” UserType=room_owner “

If, after sending the request, we were able to have the room owner authorization on the user who should not have that authorization, there is a BAC vulnerability arising from the fact that we bypass the access control process by manipulating the request.

EXCESS DIRT CAN CLOG FILTERS

A heavily contaminated air filter can cause the vehicle to emit blackened exhaust fumes. In this case, the filter that is supposed to clean the air cannot do its job because it is too polluted, or even makes the situation worse.

As in our first example, let’s consider a web application feature that shows all past invoices. Here we can try to display another user’s past invoices by bypassing access controls with the HTTP parameter pollution technique. This technique involves adding more parameters to the existing URL to try to achieve the intended goal. For this example, let’s assume that my user ID is “567” and my target’s ID is “123”. Let’s assume that when I view my own past invoices, the URL I’m at is something like this:

samplesite.com/invoices?user_id=567

Given that the application doesn’t allow it when I replace my own ID with the ID of the user I am targeting, what I need to do at this point is to try a different tactic. Let’s try a simple example of the HTTP parameter pollution tactic and perform a manipulation as follows:

samplesite.com/invoices?user_id=567&user_id=123

If I manage to see the other user’s past invoices when I change the URL to this state, it can be said that there is an access control violation caused by a parameter contamination vulnerability on this application.

Here, I first tried to access my own ID, which is within my authorization level, I am authorized by the application, and then I take advantage of the application’s inadequate access control procedures and show my last access point as the ID of my target user, thus realizing the vulnerability.

|
|

CAN I GET THE RECIPE FOR THE COOKIE?

I would love to know the recipe of a cookie that I have eaten and liked in at a shop, so that I can make it again at home whenever I want. You don’t know what they put in it when someone else makes it.

Applications give cookies to identify the user after logging in. They serve to enable the user to perform the actions they are authorized to perform on the application and to keep their session active. They can be personalized by using identifiers such as username and password, browser, device IP. There are different techniques for implementing cookies and you can see that they are found differently on applications according to today’s needs.

Let’s think of a web application, this web application combines the username and the date of the day after logging in, encode it with base64 and give it to the user. If I know the name of other users, I can try to decode my own user’s cookie and create their cookies with the date of that day, and if real users logged in that day, I can try to detect live cookies and perform actions on behalf of users. If these attempts are successful, there is a “weak session management” vulnerability arising from the decryption of cookies. Owasp belongs to the BAC category in terms of top 10. The weak session management process causes access control restrictions to be insufficient.

Tip: cookies are often salted to prevent them from being decrypted. But when not in use, the combination [username] + [password] can be used to craft cookies to perform actions on other users. Passing usernames and passwords in cookies is a common vulnerability.

|
|

SUGGESTIONS FOR ELIMINATING BAC VULNERABILITY

The authorizations and restrictions that the target users will have on the application should be determined during the development phase. It should not be moved to the live environment without making sure that appropriate restrictive principles are applied to the authorizations.

The application should not only depend on the input received by the user for the action to be performed, it should also check on the server side whether the action the user wants to perform is within the user’s authorization. Threat actors can use tools such as Burp to try to perform actions that developers do not allow in the user interface. Information and parameters received by the user should not be processed without being filtered or checked. On urls containing more than one parameter, rules should be set on which parameter to process. User input should never be trusted in environments that are not sufficiently restricted.

|
|

Types of Access Control Measures

• Physical: Subcategorized as electronic or structural
• Logical

|
|

Sample Questions

There is a door through which people pass by swiping a card on a digital card reader to access a restricted area. What is the type of this access restriction measure?

Answer: This is an electronic physical measure.

|
|

People can order products on a shopping website. Sellers can also upload their products to the site. A person logged in with a customer account on this website cannot see the product upload panel and when he types the url with his hand, he receives 401 Not authorized warning. This website has a control mechanism that controls the authorization level of users on the server side, allowing them to see the pages within their authorization and not allowing them to use features that are not within their authorization. What is the type of this control mechanism?

Answer: This is a logical digital measure.

|
|

But Why?

In the questions above, the examples and answers are different. Why?

Why is the card swiped into the card reader defined as an electronic physical measure, but not a logical one? Because in our example there is a restriction control that can only be passed by swiping the card. This means that someone with someone else’s card can pass that measure.

Why is the restriction measure that performs authorization control on the server side of the shopping site logical? Because it gets the authorization level of the person from the database and checks whether the feature he wants to access is within his rights. If the answer to the question “Is it within his authorization?” is “yes”, he can access the feature. If “no”, he cannot access it.

|
|

Summary:

• Authorization levels and differences are created before access control.
  
• Access control is the creation and conditioning of differences in what can be done according to the level of authorization.
  
• It arises from inadequate application of principles.
  
• “Is it within the person’s authority?” “Yes” “No”
  
• IDOR vulnerability is a vulnerability from the BAC category.