Broken Access Control (BAC)
These are some of my notes about Broken Access Control. These notes will (maybe) be updated with more info as I learn new things.
A few months ago I started learning about hacking and more precisely web hacking. Here I will try to explain, as clearly as I currently can, what is a Broken Access Control, how to find, and maybe, just maybe, some examples of exercises I’ve done.
So, without further due, let’s begin…
Because we can’t start testing without understanding the basics, I will first start by explaining what is a BAC and the different types of BAC.
Broken Access Control is when there are a group of restrictions about what a user, be it unauthenticated or authenticated, can or cannot do/access. This can be, for example, an unauthenticated user that can’t access certain information on a website or an authenticated user that can’t access an admin panel.
In a web application this control is dependent on three factors:
- Authentication: This is what identifies the user and confirms that he is who he says he is (I know, a bit confusing but bear with me).
- Session Management: This identifies that the subsequent HTTP requests are made by the same user.
- Access Control: This determines what action can the user make on the website.
As the name of this web vulnerability says, it is focused on Access Control and, I kid you not, there are also three types of Access Control:
- Vertical Access Control (VAC): These are the mechanisms that restrict access to sensitive functionalities that normal users can’t do. One example is that a normal user can’t delete other users’ accounts but an admin can.
- Horizontal Access Control (HAC): These are mechanisms that restrict the access to resources to users that have been guaranteed specific access to that resource. An easy example is that a user can’t access the account details of another user.
- Context-Dependent Access Control (CDAC): These are mechanisms that restrict access to resources and functionalities based on the actual state of the application. This can be confusing but the following example can easily clarify. A shopping application can’t permit a user to change the cart after buying the products.
This takes the theory out of the way, but there are still some tips that should be said before moving to the practical part.
First and foremost, as it was explained, these are functionalities that protect the access to info/actions from unauthorized accounts, so the first step to find BAC is to create two (or more) different accounts, and try to access information about one account from the other or try to make and admin action from a normal user account.
There are some parameters/keywords that should immediately trigger some sense that they should be tested. These can be numeric values such as id, account, order, user… Some functions such as change email/password, change user role… And even the access to documents, emails, profiles, groups…
The last tip I have is to make an MFLAC (Missing Function Level Access Control) matrix like the following. This will help you have a clear view of the functionalities found on the website, and who should have access to them.
Having said all this, let’s go for the meat and potatoes, the practical examples.
There are an almost infinite number of attacks and techniques, and I can’t (for the love of God) put them all here. So here are some examples of different flaws in multiple types of Access Control.
- Unprotected Functionality
Sometimes web developers find it easier to hide links to “protected” functionalities instead of protecting them. For the common user, this is enough, but we know that just because we can’t find something, doesn’t mean it isn’t there. In this example, we are unauthenticated but bypass the need to authenticate by going directly to the URL that has sensitive info. http://example.com/app/admin_getAppInfo
And because this info should only be accessed by admin, this is a case of a VAC.
2. Parameter-based Access Control Methods (Vertical)
An application may determine the access rights of a user at login and store this information somewhere (hidden fields, cookie, parameter…). This method of protection doesn’t work because the attacker can find how this information is stored and change it to have more rights. This can be as easy as changing a value on a role parameter, or changing a cookie to say “admin=true”.
3. URL-based Access Control Circumvented
In this example, the website has an admin panel that is accessible to unauthenticated users but there is a front-end protection that blocks external access. Another thing to note is that the back-end is built on a framework that supports the HTTP header X-Original-URL.
This header allows the user to access one URL but has the web application return a different URL. This allows the attacker to bypass the front-end restrictions.
Get /admin HTTP/1.1 — 403 Forbidden
The original request to admin is forbidden because we are an unauthenticated user.
GET /
X-Original-URL: /adminThis is not blocked and the response has the contents of /admin. With this, we can make a call that causes a privileged action.
GET /?username-carlos HTTP/I.I
X-Original—URL: /admin/delete4. Parameter-based Access Control Methods (Horizontal)
This first example is the most simple one of a HAC where there are no defenses against a user simply calling the account info of another user. Here we have access to the following bit of SQL code:
pstmt.setString(1, request.getParameter("acct")); ResultSet results = pstmt.executeQuery( );
An attacker can modify the “acct” parameter on the browser to send any value he wants. This value should be verified before returning the info, if it isn’t we have a HAC. An example of an URL that explores this vulnerability is https://example.com/app/accountInfo?acct=notmyaccount
5. Insecure Direct Object Reference
There is a special case of BAC called IDOR, or Insecure Direct Object Reference. An IDOR is when we have a BAC with a numeric value, for example, an URL that has id=1, a cookie with a user_id, or a request to do an action to a specific user.
In this example, the website saves logs directly on the file system of the server and we can view them using static URLs.
GET /download-transcript/2.txt
As you know already, we try to obtain a different log than the one we have access to by changing the number.
Get /download-transcript/1.txt
You: Ok so my password is kip$23jf&k8. Is that right?
In this example, the log actually contained a password that can lead to a compromised account.
There is so much more to the word of Broken Access Control than what I said in this blog post. Some references I used for my studies and this post are:
