Broken Access Control is the TOP 1 vulnerability in the OWASP ranking . We will see what it is, what effects it has, how it is done and how to prevent it.
What is Broken Access Control?
Access control is the way a system grants access to a system’s functions and information. For this, a user is authenticated, for example using username/password and then permissions are applied to give access to authorized resources. For example, in website security, access control limits the pages we can see.
This vulnerability occurs when a user can access an area that they should not be able to. In other words, vulnerabilities in access control allow flaws to be created that could be used by an attacker to view, modify or delete content to which they should not be able to access. In the worst case, it could execute unauthorized functions or even take full control of the system through administrator functions.
In particular, an access control issue in the administration interfaces could allow changes to users, data, and content on your website. Due to their power, these interfaces are often prime targets for attacks.
This attack could allow you to access hidden pages, access pages with elevated permissions (for example, site admin pages), or even view other users’ information. Next, we will see some examples.
Examples of attack scenarios
Some of the commonly used vulnerabilities are as follows.
Insecure identifiers
Most websites use some form of identifier to reference objects, users, roles, or functions.
If an attacker can guess these identifiers, and the provided values are not validated to ensure they are authorized to a user, the attacker can use them to see what they can access.
For example, in the following URL, we could modify the ID parameter that is sent.
http://site.com/user?id=7
If the application uses this ID, for example, in an SQL query without properly verifying this access, then information could be accessed that it shouldn’t.
pstmt.setString(1, request.getParameter("id"));
ResultSet results = pstmt.executeQuery( );
Forced navigation
Many sites require users to pass certain verifications before granting access to certain URLs. These controls could be bypassed by a user who skips to the page that has the security control.
For example, this can be done by trying to brute force the URL of pages with hidden access, as in the following example:
http://site.com/admin/user-management http://site.com/admin/user-admin http://site.com/admin/management
If the attacker manages to guess the URL and enters without being authenticated, then it is a failure, since someone without admin permissions would be entering a page for administrators.
Path Traverse
This attack involves providing relative path information (eg “../../target_dir/target_file”) as part of an information request. Such attacks attempt to access files that normally no one can access directly, or would otherwise be denied if directly requested. Such attacks can be delivered on URLs, as well as any other input that ultimately accesses a file (i.e. system calls and shell commands).
Permissions
Many web servers and applications use access control lists provided by the underlying platform’s file system. Only files that are specifically intended to be presented to web users should be marked as readable through the operating system’s permissions mechanism. All other files must not be readable or executable. Errors in this configuration can also leave vulnerabilities exposed. Additionally, an attacker could attempt to escalate privileges to gain administrator accounts.
Client Side Caching
Browsers often cache web pages. In this way, an attacker could access parts of a site that should be inaccessible. Developers must use various mechanisms, including HTTP headers and meta tags, to ensure that browsers do not cache pages with sensitive information.
How to prevent this attack?
- The first thing is to define a web application security policy, where the access control requirements of an application are analyzed. It must be established what types of users can access the system and what functions/content each can access. This is defined through an access control matrix where the access rules are defined.
- Using automated tools such as SAST and DAST detect the absence of access controls, but they cannot verify if what is implemented works correctly. Therefore, to test the access control mechanisms, manual verifications are required.
- In the implementation, use libraries and reliable code. If possible, enable multifactor authentication.
- Those access control mechanisms should be thoroughly tested to ensure there is no way around them. Include testing that includes functional access control and integration tests.
- Disable web server directory listing. Deny by default and always use the least possible privilege.
- Ensure file metadata (such as .git) and backup files are not present in web roots.
- Log access control failures, and alert administrators when appropriate (e.g. repeated failures).
- Limit the number of requests that correspond to automated attack tools.
Broken Access Control Challenge
Now that you know what Broken Access Control is, I want to leave you with a challenge to solve.
In a previous post, we set up a hacking lab. The victim virtual machine we installed has several web security challenges. For this challenge, enter the Kali Linux machine, in the browser go to
IP:PORT/WebGoat/
The port should be 8000 and write WebGoat respecting the capital letters.
Then look for the challenges in the Access Control Flaws menu. There you will find challenges where you have to apply what we saw in this post to solve them.
Resources with more information
https://owasp.org/www-community/Broken_Access_Control
https://owasp.org/Top10/A01_2021-Broken_Access_Control/
https://owasp.org/www-project-top-ten/2017/A5_2017-Broken_Access_Control
Follow us
Related post that may interest you
