API Security: Broken Function Level Authorization

From the summary you might have been able to gather this vulnerability can be quite complex and varied. Humans are predictable in nature and they tend to follow several patterns when it comes to hosting endpoints, for example, it usually occurs that higher privilege endpoints are hosted on the same relative path, which makes it easier for the users to guess these endpoints but that alone does not make the vulnerability though. We have to be able to access endpoints as lower privileged users as well of course. This access can occur by executing the provided HTTP method (for example POST) but it can also occur on other methods that the developers left enabled (un)intentionally (for example DELETE). These issues are often made worse by how predictable the endpoints are.

Example:-

For example /books?id=0 might indicate the presence of an endpoint /books/all may print out books the user should not be able to access.

Let's say there is one application that contains three types of accounts for the users let's say silver, gold, and diamond. All the users log into the same URL but the diamond account is much more expensive. However, by going to the account settings and saving, we notice a hidden parameter "Account type" and we change it from "silver" to “diamond”. This allows users to buy a lower-priced type of account and change it to higher priced account type themselves later on.

POST /api/saveSettings
 
[
  {
    "Name": "123", 
    "...": "AAAAA...AAAA"
		"AccountType":"silver"
  }
]
 
We change this body to 
 
POST /api/saveSettings
 
[
  {
    "Name": "123", 
    "...": "AAAAA...AAAA"
		"AccountType":"diamond"
  }
]
and by sending this request, the users can upgrade their own accounts to a more expensive account type.        

We can take one more example where users try to view documents however they can only view their own. By exporting their own documents though, the user is presented a URL /api/documents/export. This URL does return the proper documents and only the only belonging to the user but by simply guessing, the user discovers a URL that returns all the books on /api/documents/export/all.

GET /api/documents
 
Will return the following response
 
[
  {
    "id": "1", 
    "content": "AAAAA...AAAA"
		"creationDate":"10-10-10"
  },
  {
    "id": "4", 
    "content": "AAAAA...AAAA"
		"creationDate":"10-10-10"
  }
]
 
Since this user can only see their own documents, they can only see those 2, however if they export the documents, the user notices they can change the path and export all the documents.
 
GET /api/documents/export/
 
will return the same as before, however the following:
 
GET /api/documents/export/all
 
exports all the documents.        

Preventive Measures:-

• It's always better to separate the authentication and authorization module from the main code and make it easy to implement where needed.
• By default all access should be denied to make it safer, we can also work on blocking the traffic we do not want but this would make it easier to miss certain paths of attack.
• We should conduct regular and thorough testing and analysis of the authorization module while we keep the logic of the application and the different user levels in mind.
• We can implement a master admin class that implements the main authorization modules as mentioned above. We can use this master admin module to inherit from all other administrative functions to limit the chance of administrative functions being executed by lower privilege users.
• We always need to keep 2 factors in mind:

1. The user's group
2. The user's authorization level

• All parameters returned by the API should be indexed on a regular basis and tested to ensure we can edit properties we are not supposed to as a user which could elevate the account's privilege level.

There are three main ways to abuse this vulnerability, being by manipulating the URL or by manipulating certain parameters, and even by manipulating the HTTP method. The consequences of this vulnerability are almost always severe and lead to vertical privilege escalation on the API level. With all these factors in mind, we should pay close attention to not let any of these issues slip through the net and land in production.