The term “Access Control” can be confused with the authentication mechanism for web applications. However, despite being directly related to this mechanism, the access control utilizes the users’ identity to validate what each user, or profile, can access according to the application’s business rules. In this way, Access Control is an essential defense mechanism within applications because, if there is a vulnerability, an attacker could compromise the application completely, acquiring control over administrative functionalities and/or accessing sensitive data belonging to other users.

In this blogpost three major categories of exploitation of flaws in the access control of web applications will be detailed, they are:

● Vertical escalation of privileges;

● Horizontal escalation of privileges; and

● Direct and unauthenticated access.

Before detailing these categories, let’s take a look at other terminologies used to explain the concept of related security issues.

The term “privilege escalation”, in general, means obtaining privileges that were not assigned by the system’s business rules. As an example, a malicious user could exploit a bug, a design flaw, or a configuration error in a system to unduly elevate his own privilege. From the obtained accesses, the attacker can use the acquired privileges, for example, to steal confidential data, execute administrative commands, among other malicious actions.

Another term used in the field of web applications is “direct access to the object”, also known as Insecure Direct Object References — IDOR. This terminology is defined as a vulnerability in access control for applications that use user-supplied input to access objects directly. A direct reference to the object occurs when a developer exposes a file, directory, database record or key as an HTTP request parameter. With direct access to objects, an attacker could access resources outside their intended scope and escalate his privilege, so this problem is directly related to the topic described here.

Once the concepts are understood, we’ll then address the categories mentioned above and their respective examples, as well as possible mitigation strategies.

Vertical Privilege Escalation

This type of exploitation occurs when a user with a low privilege level can perform actions foreseen only for higher access profiles.

Imagine the scenario of a CRM (Customer Relationship Management) application in which a given employee can consult only the SSN and cell phone of registered customers. The respective request would look like this:

Image 1 — Example of a request that queries the customer’s cell phone number from the SSN

 

As can be seen, the customer’s SSN is used as a record index in the queries that are carried out in the database, for returning the respective customer’s phone to the SSN. Assuming that there is no greater control over the privilege of the profiles existing in the application in question, the aforementioned employee, with bad intentions, can simply try to add the parameter all_data with the true value in the example request. Next, we have the same request shown previously, now with the new parameter:

Image 2 — Example of a request with the parameters “ssn” and “all_data”

 

If the application returns all customer registration data whose SSN is 742–49–3251, the least privileged user performed an action to which only one administrator should have access, resulting in vertical escalation.

Horizontal Privilege Escalation

This type of exploitation occurs when, for example, a user is able to access the information of other users with the same authorization profile.

Horizontal privilege escalation attacks can use exploitation methods similar to vertical privilege escalation. To facilitate the comprehension, we’ll take e-commerce as an example. Taking as a situation that a customer accessing the “profile” functionality of the website would generate a request such as:

Image 3 — Example of a request for the profile functionality

Also, assuming that the value 17992 has the role of identifying the user, this being an object that is handled by the client-side and accepted on the server-side without due validation. Then a customer, with bad intentions, could simply modify the value 17992 and, thus, access the account registration information of other customers of the application.

Direct and unauthenticated access

Direct and unauthenticated accesses can occur due to several erroneous implementations, for example, when considering pages or routes that can be accessed without a valid session. This can happen at affected points that would be accessed in an authenticated manner, according to the business rules activated in the application, however, even with the removal of the session tokens it’s still possible to access them normally.

Another way to illustrate this problem is when an affected point is publicly accessible and was discovered through search engines, but it should only be accessed in an authenticated manner, due to the exposure of critical information.

There is also the scenario where administrators of an application publish “hidden” pages without any need for authentication, in the hope that an eventual attacker would not discover them. This publication methodology follows the principle of “security through obscurity”, which is the dependence on the secrecy of the project or implementation to provide the protection of a system, which is not a recommended practice. In this example, a simple automated process (fuzzing) can result in access to the content of the omitted pages.

The following image exemplifies two URLs that should require a valid session for their content to be accessed:

Image 4 — Example of URLs that require authentication

The URLs listed in Image 4 indicate that sensitive information can be accessed directly and unauthenticated, that is, there is no well-defined access control in the respective application.

Impact

Once there is a poor implementation of access control, an eventual attacker may gain unrestricted and privileged access to the target application, such as: Accessing exclusive areas, retrieving users’ personal information and consulting functionalities that only an authenticated user should have access to.

Correction

The main way to solve problems of privilege escalation and direct and unauthenticated access is:

· implement an access control mechanism that restricts access to the administrative areas of the application to only duly authenticated administrators, and;

· ensure that users of other profiles perform only actions that are within their authorization, in accordance with the system’s business rules.

In general, the determination of which activities are associated with each user (profile) must be maintained exclusively on the server-side, that is, the control of which functionalities can be accessed or which functions can be performed by a given user must not be made only through the pages rendered in the browser (client-side), and the users’ session must be used by the back-end to perform this control.

In addition, it is worth emphasizing, once again, that the implementation of the “security through obscurity” principle is not a good practice, since, if there is a real attacker without time restrictions, he could access any “hidden” information.

Implementing an access control mechanism in web applications requires careful planning, in order to guarantee effective access control and to define what should be public or private and who can access each of the existing functions.

Conclusion

As noted, access control in web applications is a challenge, due to the fact that there are several aspects that need to be analyzed. However, if there is a good planning, and the necessary knowledge, any concern arising from the exploitation of the respective security problems can be solved or avoided in the applications.

Finally, it’s always recommended to follow good security practices, aiming to reduce the attack surface as much as possible and bringing together a good user experience with the protection of your information.

References

STUDDARD, Dafydd; PINTO, Marcus. The Web Application Hacker’s Handbook: discovering and exploiting security flaws. 2. ed. Indianapolis: John Wiley & Sons, Inc., 2011. 853 p.