First things first, did you know that the OWASP acronym has changed from Open Web Application Security Project to Open Worldwide Application Security Project? Neither did we! But onto the real stuff.
Today we have another entry in the OWASP Top Ten Series – Broken Access Control. This is one of the most prevalent vulnerabilities that we find during application testing. And really, it isn’t just web or mobile applications that can be vulnerable to broken access controls – everything is. So what is a broken access control?
Broken Access Control refers to vulnerabilities where a malicious actor can bypass the intended permissions on an application and perform unauthorized actions. This can include actions like viewing sensitive data, modifying data they shouldn’t have access to, or even administering user accounts without appropriate permissions.
The OWASP website details some possible Broken Access Controls as:
- Violation of the principle of least privilege or deny by default, where access should only be granted for particular capabilities, roles, or users, but is available to anyone.
- Bypassing access control checks by modifying the URL (parameter tampering or force browsing), internal application state, or the HTML page, or by using an attack tool modifying API requests.
- Permitting viewing or editing someone else’s account, by providing its unique identifier (insecure direct object references)
- Accessing API with missing access controls for POST, PUT and DELETE.
- Elevation of privilege. Acting as a user without being logged in or acting as an admin when logged in as a user.
- Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token, or a cookie or hidden field manipulated to elevate privileges or abusing JWT invalidation.
- CORS misconfiguration allows API access from unauthorized/untrusted origins.
- Force browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user.
Preventing Broken Access Control can involve:
- Using a consistent, centralized access control mechanism that’s enforced in trusted server-side code or server-less API, where it’s not possible for the client to alter their permissions.
- Denying access by default and using a “whitelist” approach where only certain actions are explicitly allowed.
- Validating every request to ensure the authenticated user has appropriate permissions for their action.
One very common type of Broken Access Controls is an IDOR. Brackish Security testers find these in the majority of web application tests they perform. Also, for the Bug Bounty hunters out there, IDORs can be very lucrative. Dig deep and learn how an application operates, and an IDOR could benefit you financially.
Here are a few links on Broken Access Controls and IDORs that have been found in real life.
https://hackerone.com/reports/1323406
https://medium.com/@mrhavit/how-i-found-an-insecure-direct-object-reference-in-tiktok-c7303addf223
https://hackerone.com/reports/42587
As always, if you need the experts to test your applications, reach out to Brackish Security – Let’s Make the Bad Guys Salty!
