Attacking Access Control for Vulnerabilities

Where do the access controls take place? They are logically built on authentication and session management within the app’s core security mechanisms. We already saw how an application first verifies a user’s identity, and after that confirms that a particular sequence of requests that it receives is originally from the same user. That is for your safety. Before we continue further, remind yourself about the cyber security tips at the best place!

Access controls mechanisms are responsible for making the key decisions we mentioned above. So what happens when they’re infected? Obviously, the attacker can get into user’s software and steal some sensitive data or anything he is searching for. For your best safety, just to be clear at the beginning, know everything you need about the internet security tips.

How do the access control vulnerabilities look like? They are actually conceptually simple. For an example, the application lets you do something you really shouldn’t be doing.

Common Vulnerabilities

There are three broad access controls categories:

-Vertical: It allows different types of the users to access the different parts of the app’s functionality. That almost always involves a division between the ordinary user and the administrator.

-Horizontal: Allowing the users to access some certain subset of a wider range of the resources of the same type. It’s like when you want to see bank account, and you can see it-but no one else.

-Context-depended: It is ensuring that the user’s access is restricted to what is permitted given the current app state. So, let’s say a user follows the multiple stages within a process. This category of access controls prevents the user from accessing the stages out of the prescribed order.

Now, let’s take a look at the three most common attacks within these categories.

  1. The first one is vertical privilege escalation. It occurs when a user can perform functions that his assigned role doesn’t permit to him.
  2. Horizontal privilege escalation is the second case. Occurring when a user can modify or just view the resources of other users with same role to which he is not entitled.
  3. And the last one, business logic exploitation. Here, the user can exploit a flaw in the app’s state machine for gaining access to a key resource.

Multistage Functions

We know that plenty of functions are implemented within the application and across several stages which involve multiple requests being sent from the client to the server. Let’s say a function added a new user who may involve choosing this option from a user maintenance menu, and after that selecting the department and the user role from drop down list. After that, he may enter a new user name or a password and any other information.

So, we said that the user can add a new user. Then, the application may verify that the requested user has the required privileges or to block access if he doesn’t.

Multiple stages are often seen in banking because that’s where the sensitive information and the money are, right?

Attacking Access Controls

You should always take a moment to review the results of your application mapping exercises before starting to probe the app to detect any access control vulnerabilities. Understanding what the app’s real requirements are in the terms of the access control will show you where will it be probably most useful for the focus of your attention.

What is the most effective way to test the effectiveness of the application’s access controls? It is also the easiest way. Well, that’s testing it with the different user accounts. In that case, you determine whether the resources and functionality that can be accessed legitimately by one account can be accessed illegitimately by the another.

There are also some tools that can help you to automate some work which is involved in this process. They make your testing quicker and of course, more reliable. And the best thing about the tools is that you will have all the focus of the human intelligence to perform effectively. For an example, Burp Suite lets you map the content of the app using the two different user context. So, then you can compare those results and see actually where the content accessed by each user is the same or is it different.

Besides this easiest way, you can also test with the multistage processes. In this case, the user must take several requests in the correct sequence with the app building a state about the user’s actions that he does.

Also, there is a testing with limited access. This is recommended if you have only one user level account. So, the poorly protected functionality may happen that is not explicitly linked from the interface of any app user. There are also other possibilities of testing, but we mentioned you the most important ones and those that are implemented the most. Also, they are the easiest to work with.

Securing Access Controls

As we’ve already said, these controls are one of the easiest areas of the web application security to understand. Yet, it is the truth that you must carefully apply a well-informed methodology when implementing them.

First of all the most important thing is to avoid several obvious pitfalls that we are going to talk about. It arises from the ignorance about the essential requirements of effective access control or flawed assumption. It is all about the kinds of requests that the user will make and against which the app needs to defend itself.

So, let’s take a closer look! You should never rely on the user’s ignorance of the application’s URLs or the identifiers which are used specify the app’s resources. For example, account numbers or the documents IDs. Always avoid that and also ensure that the app’s access controls alone are enough sufficient to prevent such an unauthorized access.

Second, never trust any user submitted parameters for signifying access rights (it may be seen like AS admin=true). Don’t even think about trusting the user who doesn’t attempt with any data that is transmitted to the client. So yes, never rely on the transmitted value without the right revalidation. Don’t assume that the user will access the app pages in the intended sequence. And why is that so? Because the users can’t access the Edit Users page. They can’t reach that X page that is linked from it.

Let’s go further, we have a more information to share for your safety. Always be sure that you drive all access control decisions from the user’s session and use a central app component to check access controls.

To ensure that there are no exceptions to the previous point, use the programmatic technique. For the administrative pages, you should further restrict access by IP address. In that way, you will ensure that only the users from the specific network range can access that functionality, regardless on their log in statuses.

What dis we learn today? A lot of useful information is here. We saw that the access control defects can manifest themselves in many various ways and that the flaws can arise from the various sources. But, we’ve also learned you about the proper handling of your account and staying safe! Hope this was helpful!