Broken Access Control is one the OWASP top 10. Access control can be defined as an application’s ability to give or take away access to certain types of credentials or data based on the authorization of users. Say for example we have a banking application that allows access to alice’s personal banking information and her account is declared with the id=321. And bob has the id=322 and alice can manipulate the id such that is the numeral 1 is replace with 2 and the application improperly applies the necessary controls then alice could view bobs account information. This is a simple use case with wider implications.
The impacts can vary from leaked user data like account info above, horizontal or vertical privilege escalation from a low privilege user to admin, logic flaws to manipulate cart transactions, path traversal and RFI.
IDOR
I would like to go over 3 quick examples. The first being IDOR or Insecure Direct Object Reference. Which I have briefly touched on before on my blog. But in short IDOR is a vulnerability in which a user manipulates code and in return is supplied data from an application directly. In this example we will be using DVWS Node. This application has a note taking functionality that can be manipulated to access notes via the GET request that is called to the API.
We have generated a few notes for our testing purpose. After generating the note and firing up our proxy BurpSuite we captured the requests and started playing around with the application. Notice the Update button, after clicking the button we get an interesting request we can use to manipulate the web application.
We can then manipulate this portion of the get request:
/api/v2/notes/
By adding a 0, 1 or 2 to the end. Which will dump the contents of the notes endpoint of the API.
/api/v2/notes/0 or /api/v2/notes/1
What is super important in this attack is that we are manipulating the id parameter. To glean useful or relevant information about the contents of the notes.
Obviously this is a simple attack, but depending on the context it can be incredibly devastating. Maybe the information accessed is actually critical to the upkeep and maintenance of the company or server.
Vertical Privilege Escalation
In the context of access control vulnerabilities vertical privilege escalation is when a user is allowed some functionality that is not otherwise granted to them. So for example say Alice is a normal everyday user but is able to manipulate a portion of the application request to elevated her privilege to delete or modify another user. This is probably one of the more severe attacks due to the ability to fully compromise an application and wreak havoc.
The PortSwigger website has an amazing series of web application based testing exercises. All focused on the OWASP top 10 and very great for beginners. I will quickly just touch on a small but easy exercise demonstrating the concept of vertical privilege escalation.
In one of the exercises there is a web store with different users and functionalities for each user. The objective is to find the admin panel, browse to the admin panel and then delete the user carlos. So first we need to locate the main page and view the source code. Scrolling through the code we locate a JS script. With our admin panel directory:
/admin-f8pyuv
Taking this and adding to the end of our url we are able to access the admin panel below.
Once in we now have full control of the admin panel and can manipulate aspects of the web application.
Path Traversal
Is a vulnerability in which information or data on an underlying servers directory structure is accessed due to misconfigured permissions. So for example a .php file is called directly from the URL of a server and displayed by the user if permissions are incorrectly set a user can browse the /etc/passwd file.
For this example I am going to use DVWA to show how this vulnerability can occur. Setting the security level to low and browsing to the file inclusion section.
We will manipulate the application in our proxy. By changing the URL path to our .php file from include.php to /etc/passwd
Whatever way you desire to do this you can do it inline in the URL or via a web proxy. I prefer the web proxy since I can use the Repeater tab to change and configure data on the fly.
Digging into the code we can see the code is calling directly to the page and not filtering out user supplied input to the applications underlying server via the PHP get method.
Now that we have broken down some examples of broken access control let’s dive into some steps for remediation.
Mitigations
For remediation of access control issues there are quite a few things you can implement into the architecture of your web application. I will go over a few that are detailed in the OWASP cheat sheet linked below. If you want a full description of how to do check out the links below.
- Role Based Access Control: access decisions in which the roles and responsibilities are defined by the users function.
- Discretionary Access Control: restrictions based on the id of a user or membership within a group/s. So this can be credential separation like a low privilege user and admin need to perform different actions.
- Mandatory Access Control: information is accessed based on the sensitivity, so a need to know basis, admin only has grants access.
- Permission Based Access Control: decision is based on whether or not that user has permission associated with that information or content.
https://owasp.org/www-project-proactive-controls/v3/en/c7-enforce-access-controls
https://cheatsheetseries.owasp.org/cheatsheets/Access_Control_Cheat_Sheet.html