Imposters In Space, Errrr, Web Applications…Broken Access Controls!
- Jen C
- Nov 6
- 3 min read
We’re going to take a deeper dive into Access Controls! Let’s jump right in. Broken access controls are the number one vulnerability according to OWASP and the most serious. This may sound harsh, but the truth is that a malicious attacker has exploited a weak access control point in one of our web applications, taking advantage of a vulnerability. Broken access controls have been responsible for data breaches, identity theft, financial losses, and reputational damage to companies.
Access control determines “who or what” can “view or use” a resource. Access control can range from as simple as a door, locks, and fences to as complex as biometrics and badge systems. In our applications, there are constraints on who or what is authorized to perform these actions, which are dependent on authentication and session management.
Authentication: Are you who you claim to be? Can we believe you? We have to confirm it.
Session management: Identifying and managing your identity, permissions, and other information during a session via HTTP requests, and ensuring that it’s the same user
Access control: Are you authorized to perform the action you are trying to perform?
We can’t help but be a little sus’…as we should be! But what happens if we’ve missed a step in development and we have broken access controls?
Broken access controls are common and critical, and just no good. Since humans make access control design decisions, well, there’s always the human error factor.
They can also be missing access controls entirely. A missing function level access control, or MFLA, allows unauthorized access to functionality. These flaws in the authorization logic will enable an attacker to access restricted functionality or even escalate privileges if they are an existing user! When an application doesn’t have the right authorization checks in place for sensitive endpoints, the attackers can hop in and advance their permissions and execute functions at a higher access level—no bueno. Web applications should rely on RBAC, or role-based access control techniques such as admin, user, etc. This is checked when a user attempts to log in, and the permissions are verified. A missing object-level access control, or OLAC, enables control over who can access files and passwords.
Another type of broken access control is using input from untrusted sources. An attacker can modify environment variables, hidden form fields, cookies, or other input values to gain access. One way to avoid this is to not rely on user-submitted input as part of the authentication process. Prevent untrusted input from entering the application.
The last broken access control that I'll cover relates to API access control and authentication for APIs. Authentication access control can be insufficient, incorrect, or missing. Insufficient could be where we forget to verify a password/credentials. An example of an incorrect authentication is relying on user-supplied inputs for authentication. Missing authentication is a blatant failure to implement authentication for a particular function within the application, resulting in unauthorized access.
How can we combat broken access controls? We can in a number of ways:
By not relying on hidden URLs or APIs. If you’re not familiar with “security by obscurity approach”, and why it’s not recommended in this case, you can read more about that here. This should never be relied on for access control.
Do not rely on user-supplied parameters as a form of authentication (like cookies, HTTP referrer headers, IP address verification, etc.).
Validate permissions on every request. Yep, every request. Every time.
Use deny by default principle. No one can access it by default except a few who are granted access. This should be at the code level.
Use the principle of least privilege. By default, users receive the minimum level of required permissions to perform their functions/tasks.
Conducting regular access control audits and security reviews. This would include roles and privileges assigned to each user, as well as the process for granting and revoking rights. Is there a user who keeps trying to access areas they shouldn’t be able to access repeatedly? Maybe they’re looking for a weakness? Sounds a little sus’. We need to stay on top of it with thorough audits and testing of those access controls!
Proper error handling and logging. Think of generic error messages that inform the user they can’t access the resource, rather than revealing information about the resource or the reason for denial. It’s also good to log whenever someone tries to successfully AND unsuccessfully log in to the web application, make changes, access information, etc. This helps when looking at that sus’ behavior and determining if it’s legit or not.
Overall, we can combat broken access controls through regular security testing, good design up front, implementation of access controls, and continuous monitoring and updating of all security measures.
Comments