What Is Broken Access Control?
Let’s say you have a web application with four levels of functionality for four groups of people.
Your first group will have minimum access, the second group will have a little more, the third group will have even more. Finally, the fourth group will have access to all the sites.
In web development jargon, these levels are called roles. I won’t bore you with the details, but if you’d like to know more about them and other types of access control, check out this OWASP cheatsheet.
Let's say there are four different roles.
Role | Access Level |
guppy | 1 |
fish | 2 |
dolphin | 3 |
whale | 4 |
You will have to create access for each role. Make sure that the guppy, fish, and dolphin don’t access to all the sites that the whale can access. The whale can access everything a guppy, fish, and dolphin can. Also, the fish can’t access a lot of things the dolphin can.
You can see where this is going.
Access control is setting up your web application to make sure that the users of the web application can only access the sites that are designated under that role.
The super villain who wants to break your web application look for exactly that; a way to gain access to pages using some techniques and tricks. Let’s put on our OWASP capes and study the enemy!
Attacks on Access Control
Failure to Restrict URL Access
Common attacks occur when a URL bypasses authentication with the guise of having already been authenticated. Hackers use format and pattern knowledge to write the URL for privileged pages that have not been securely configured.
For example, let’s look at an attack using the roles we had above:
A guppy logs in, and their main page looks like this:
https://webdevfightshacker.bla/guppy_login.html
Do you notice that there is a pattern here? It shows guppy_login.html as the main page.
What do you think the super villain who wants whale access would do?
https://webdevfightshacker.bla/whale_login.html
Now they managed to get whale access simply by changing the URL. That was way too easy, wasn’t it?
A good secure developer like you would make sure that the sensitive pages require an authentication check, right? Also, you might not want to name your pages to make them so easy to figure out.
Let’s look at another attack.
Insecure Direct Object References (IDOR)
A malicious user has techniques to access a lot of the hard coding in a web application. Some of this code can reveal how a database is organized with regards to formatting and pattern. Providing a few pieces of the puzzle can allow an unauthorized user to use their knowledge to expose information for further probing.
One example would be if you access your account on a site and you’re on the main page. You notice that the URL address looks like this:
https://webdevfightshacker.bla/index.php/view?account=3453
Hmm… it looks like there's a long list of accounts, and I’m number 3453 in the database.
So what will a malicious person do if they wanted to mess around with other people’s accounts? They put in another account number! Sometimes, the administrator accounts are number one, so this could give the wrong people access to an administrator account:
https://webdevfightshacker.bla/index.php/view?account=1
Now this sounds very similar to a previous attack...
What’s the difference?
In the above example, each account is considered an object. When making a direct reference to this object in the URL by adding account=1, you are giving the hacker a clue as to how your web application and database are set up. If there is a way to find out specific terminology used in your database, it can add another piece in the puzzle for the hacker to formulate an attack.
A null byte attack takes advantage of the object references. Default page names can be based on the model, view, and controller (MVC) setup that a lot of web applications use.
This allows the trickster to use this knowledge to pull up some of your page's source code! Let’s look at a website with a menu link called About Us. This shows that all of the pages end in .htm or similar.
webdevfightshacker.bla/fight/default.aspx?content=about_us.htm
The trickster also knows that the default.aspx.cs is the main page, and wants to look at it for more info.
A null byte ( ./ ) tricks the browser into thinking that the URL is complete. The string that follows the null byte can provide the trickster an opportunity to show the contents of any file that is written in.
webdevfightshacker.bla/fight/default.aspx?content=%20./default.aspx.cs%00.htm
This example shows a page full of source code from default.asps.cs. It is possible to look at any default page name that will benefit our trickster extraordinaire!
Direct object references can also pop up in an error code. The hacker can start manipulating entries to see what kinds of exceptions and errors pop up and what they say. It provides more information to search in the URL!
How Can You Prevent Broken Access Control?
Instead of naming your target pages with meaning, use an array of key-value pairs that reference your objects.
Change the default names of your web pages.
Ensure that all pages have an authentication check.
Customize your exceptions and error codes.
Let’s Recap!
Web apps with Broken Access Control do not ensure that every page is locked for authentication.
Direct object references can lead a hacker to understand the patterns and setup of the web applications.
Do not use predicable names or direct references to the database in the URL.
Prevent null byte attacks by protecting your source code.
Use indirect object references with parameters and key-value pairs.
Customize your error codes so they do not reveal database attributes.
