The internet is NOT a safe place. Wonderful in its own right, sure, and useful in more ways than one. But the cyberspace is also filled to the brim with malicious agents: thieves, hackers, countless different criminals looking to prey on the weak and the vulnerable. Don’t be alarmed just yet though. As long as you know what you’re up against, you’ll have more than a fighting chance against intruders. And, in 2022, odds are, you’ll be up against broken access control (BAC) threats.
In fact, dethroning SQL injections, BAC has risen to the top of OWASP’s top 10 web application security risks. Yes, according to the biggest non-profit software security foundation, 3.81% of the tested apps were susceptible to broken access control threats (which is A LOT, by the way).
But let’s take multiple steps back. What’s access control? And, subsequently, what’s broken access control? How does it ‘break’ per se and are you vulnerable to it? All good questions, so let’s jump right into it.
Broken Access Control: Explanation and Examples
As you can guess from the name, broken access control is a security threat where intruders are able to gain access to unauthorized data. Access control, on the other hand, covers policies and mechanisms that ensure specific users have access to specific components and these components alone.
To break it down (no pun intended), you look at any system, and that system will have different people playing different roles. You want them to be able to do so freely (to a degree), but you seldom want everyone involved to be able to access the entire system. That’s where access control comes into play.
Of course, when it’s broken, and anyone can access anything they want, all hell breaks loose. Bypassing intended permissions, intruders become able to disclose sensitive information, modify and outright delete all data, or perform business functions that you wouldn’t want them to perform.
And, with broken access control being the #1 web app security threat in the world today, we’ve seen countless successful BAC examples. From small-time firms falling victim to it due to relying on unverified data to the biggest online empires taken to the cleaners by hackers force-browsing target URLs.
Before looking at specific examples, though, we shall figure out what access control is in the software world and what breaks it.
What is Broken Access Control?
Broken access control is a failure on the web app’s part to carry out and maintain pre-established access policies. What are these policies? From the web applications’ perspective, access control falls into three main categories:
- Administrative access control. In this case, we’re discussing the access protocols that are defined and put in place to enforce the general security policy. In general, this type falls into two subcategories: personnel protocols and business protocols. To give you a few more specific examples, these would include everyday policies, hiring procedures, and background checks.
- Technical access control. On the opposite side, also known as logical access control, are the software- and hardware-based restrictions. These create multiple extra protection layers to safeguard the system (or its resources) from unauthorized access. These implementations usually include items like passwords, smart cards, different digital keys, protocols, firewalls, and more. As you’d expect, they help a lot when it comes to increasing the system’s API security.
- Physical access control. This is the part that covers video cameras, gates, fences, security guards, and locks that limit access to specific environments. As the name suggests, physical access control focuses on the non-tech side of the equation. Needless to say, this category is just as important as the previous two, but we’ll be discussing the ‘tech’ perspective first and foremost today.
How Access Control is Carried Out
As far as the technical side is concerned, access control is split into three groups: read-only files, readable and writable data, and executable resources. But, depending on the file type that you’re working with at the time, these can vary a lot. That being said, you always want them to be carried out through the approved (beforehand) operating procedure. To be more precise, the system should enforce precise multi-step protocols.
First, it should identify the subject’s ID. This ID tells the system who has requested access.
The next step is identifying the person behind the request, usually done via some authentication process.
Assuming the authentication step doesn’t halt it, the next step is checking the request against the access control list. This is where the system makes sure the person behind the request has the authority to access the resources they’re requesting. Also, the system determines the access level that this person should be granted.
Last but not least, the system should always include audit mechanisms that would find and examine potential flaws and weaknesses. With these, you should be able to detect ways someone might bypass the access restrictions before they do it.
What Breaks Access Control
To understand how to protect the system, you need to understand how to break the system first, right? Right. With that in mind, let’s lay it all on the line and find out what breaks access control.
First things first, there are multiple ways servers can provide and deny rights to request certain resources. These include session cookies, JWT tokens, and more. As we’ve established above, when users request access to specific resources, the system first makes sure they can access these resources before executing the request. The ‘making sure’ part might be carried out through GET calls as well as different HTTP methods like POST/PUT/DELETE. That’s where the problem lies. Because developers must secure every single endpoint with every possible HTTP method, it’s easy to miss at least one (or more) entry.
In other words, access control ‘breaks’ when intruders are able to successfully request access to something they shouldn’t have access to. More often than not, this happens when the developers don’t secure the authorization protocols. The most common example would be endpoints on sites that throw 403 forbidden errors that then can be bypassed by adding an X-Forwarded-For: “127.0.0.1” header.
Another typical example would be the old directories from the development phase that should have been deleted or protected but haven’t.
The more inexperienced users might also store passwords in plain text in the system. So, when the system (usually the computer) is compromised, the hackers also might be able to gain access to different systems using these passwords.
Other times, people rely on weak passwords that, even without accidental exposure, can be easily cracked, enabling broken access control.
And this is without intentional attacks on access control, which is a whole different animal.
Broken Access Control Examples
The possible attack vectors that hackers can adopt to break access control are too many to count. That being said, they usually work through the same principles.
Failure to Restrict URL Access
The most common access control attack occurs when a URL bypasses authentication, tricking the system into believing that it’s already been authenticated. Using format as well as pattern knowledge, hackers are able to write the URL for privileged pages that haven’t been configured right.
To give you an example, imagine a small fish logging in. Its main page would look something like this:
| 1 2 3 | https://webdevsagainsthackers.net/fish_login.html |
Do you spot anything fishy (intended this time around)? The URL shows fish_login.html as the main page.
All the hackers have to do in this case to receive full-blown shark access is put the URL like this:
| 1 2 3 | https://webdevsagainsthackers.net/shark_login.html |
At this point, the attackers have been able to obtain shark access by doing nothing but changing the URL. Easy? Sure. But effective against inexperienced devs nonetheless.
Insecure Direct Object References (IDOR)
This one is a little more complicated. You see, there are multiple ways malicious agents can access the brunt hard coding in a web app. Parts of that code might reveal how your database’s organized when it comes to formatting, pattern, and more. With just these few pieces, skilled hackers can expose more information to further probing.
In the following access, you log into your account on a website and you are looking at its main page. In the address bar, you see a URL like this:
| 1 2 3 | https://webdevsagainsthackers.net/index.php/view?account=4200 |
What do we have here? Something that looks like a long account list, and you’re number 4200 in the database.
At first glance, nothing suspicious. But all a malicious agent has to do to access other users’ accounts is put a different account number in there. Sometimes (more often than it should be), the administrator(s) account(s) are assigned to the first 1-10 numbers. So, you spin it like this:
| 1 2 3 | https://webdevsagainsthackers.net/index.php/view?account=1 |
and the wrong users might be able to access administrator accounts.
“Wait a second, that doesn’t look (nor sound) that different from the previous attack?” You’re right. But also wrong.
The difference here is that, in this instance, the hackers are exploiting object references. Most web apps use default page names based on the MVC (model, view, and controller) setup. Because that’s the case, hackers might be able to access these web applications’ source code.
Consider the About Us section that most websites have. The address below shows all pages end with .htm (or something along that line):
| 1 2 3 | https://webdevsagainsthackers.net/against/default.aspx?content=about_us.htm |
The hackers know that the default.aspx.cs part is the main page and might want to investigate further.
Using a null byte (./) attack, they can trick the browser’s code into believing that the URL’s complete. The string following the null byte lets attackers reveal what’s inside any written-in file:
| 1 2 3 | https://webdevsagainsthackers.net/against/default.aspx?content=%20./default.aspx.cs%00.htm |
In this example, the hackers have been able to access a full page of source code from default.aspx.cs. Of course, it is possible with any default page name.
Direct object references might pop up in an error code too. All the hackers have to do is manipulate entries into finding out what exceptions/errors might pop up and what they might say. It gives them more information that they need to search in the URL.
Real-Life BAC Examples
Again, considering that BAC is the topmost software security threat today, even the biggest media juggernauts have not been spared in the past. These are just a few examples:
Snapchat. Gibson Security has spotted access control vulnerabilities in the Snapchat system that were initially dismissed as inconsequential. No more than a week passed and brute force enumerations had revealed 4.6 million usernames and phone numbers. Needless to say, the affected users were not happy with the data leak, not one bit.
Facebook Business Pages. Laxman Muthiyah has found that malicious users could issue a request to assign admin permissions to themselves for certain Facebook pages. Because Facebook didn’t ensure secure access control measures, all hackers had to do is use a request like this:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | Request :- POST //userpermissions HTTP/1.1 Host : graph.facebook.com Content-Length: 245 role=MANAGER&user=&business=&access_token= Response :- true |
and they would make themselves administrators of the page. As you can guess, with this newfound privilege, they could deny access to the actual administrators/managers of the page.
How to Prevent BAC
To ensure effective access control, you first need to make sure the system enforces it via trusted server-side code or server-less API. In doing so, you’ll be able to prevent the hackers from modifying the access control check or metadata.
Other than that, the following steps will help you prevent broken access control:
- Check permissions and make sure they’re on point. Of course, the trick is to be thorough, checking each and every file. When in doubt, follow the least privilege principle: make sure that only the people who need to be able to edit specific files have write access to these files.
- Disable client-side caching on restricted pages. Otherwise, unauthorized users might be able to re-access these pages.
- Avoid the so-called presentational access control mechanisms. Just ‘cause there’s no visible button that takes users to restricted pages doesn’t mean that attackers won’t be able to find it. It’s basically security through obscurity, which is a principle that DOES NOT hold up against serious hackers. Instead, lock sensible pages behind authentication.
- Deny access to all functions by default. This way, you’ll have an easier time keeping permissions on point. Also, make sure you use access control lists as well as role-based authentication practices.
- Don’t name target pages with meaning. When you do that, you’re helping intruders identify them. Instead, use key-value pairs that reference the objects.
Quick Summary
You don’t earn the #1 spot on the software security threats’ chart without doing serious damage and enabling even more damage in the future. Unless we haven’t made it abundantly clear already – you have to respect the broken access control threat, or you might not like the alternative. Still, provided you know what you’re dealing with, how to prevent it, and how to fight BAC, you should be okay.
Secure access control: The ultimate BAC prevention cheat sheet
