Introduction

API1:2019 Broken Object Level Authorization

What is Broken Object Level Authorisation?

Broken Object Level Authorisation all starts with an object. Objects should be looked at in the context of "Object-Oriented Programming", what I mean by that is objects are the things you think about first in designing a program and they are also the units of code that are eventually derived from the process. This can be anything, ranging from an account to an invoice to a credit note and everything in between. Usually, these objects are marked with an identifier because we need to address these objects directly and this is where issues can arise because we need to always check if the user is allowed to access that object. This might seem simple at first but I can assure you it's not, more about that later in the "testing" section of this article.

A broken Object issue occurs when the server does not properly check if the currently logged-in user or if a logged-out user can read, update or delete an object to which they do not have the rights.

Two main types of Broken Object Level Authorization

There are two types of broken authorization on objects, these can occur because either a userID is passed on to the server or an object, we will look into both.

Based on user ID

Sometimes a userID is passed on to the server, this can happen when we request all the resources for a certain user for example:

<https://google.com/get_users_search_history?userID=1234>

If we replace the userID with someone else's userID, we should not be able to get the search history of other users but when a Broken Object Level Authorization issue arises, we can view the search history of other users.

This issue is simple to solve as a developer. We simply need to check if the currently logged-in user is allowed to access those objects. In this example, we need to check if the userID from the GET parameter is the same as the userID of the object's owner.

Psuedo code:

if($_GET['userID'] === object.ownerID){
	ShowData()
}else{
	echo "You are not allowed to view this data"
	wait(5s)
	Redirect(Homepage)
}

This is the safest way to handle the exception, DO NOT USE THE FOLLOWING CODE AS IT IS NOT SAFE:

if(!$_GET['userID'] === object.ownerID){
	echo "You are not allowed to view this data"
	wait(5s)
	Redirect(Homepage)
}
	ShowData()

The data does not get rendered because of the redirect but a simple push of the back button can still enable the data to be displayed

Based on object ID

This vulnerability type can also exist because objectID's are passed to the server when the server does not properly check if the user is authorized for that object. This can happen very easily for example when a developer needs to secure some resources and some not. They might forget to secure one of the objects which should be secured.

Example of an attack

Whatever type we are dealing with, some properties are the same across both.

These issues can arise more easily in two situations but of course, they can arise any time that a developer forgets to add authorization. We will zoom into two examples:

• When functionality is being developed and needs a change or addition after a long time. Often sufficient documentation does not exist and by the time development begins, the developers might have forgotten part of the functionality. If this happens, it's easy to forget initial authorization requirements and they might get overwritten or simply removed.

  • For example, if you build a function to add products but users should only be able to edit their own products. We have 3 calls we can make to a product:
    • GET product.php?id=12 for getting the details
    • POST product.php?id=12 for updating a product's details
    • DELETE product.php?id=12 to delete a product
    • OPTIONS
  • These calls are secure and users can only execute them for their own objects
  • After a year we want to add an option to import products via CSV
    • POST /import.php? with a CSV body containing id,name and price: {1,"test",12}
  • The problem is that the developers forgot to check if the user is allowed to write to that product with id=1 and the attacker can overwrite product details of products that do not belong to them

  POST updateProduct.php?productID?id=1
  
  if($_GET['productID'].owner === object.ownerID){
  	UpdateData()
  }else{
  	echo "You are not allowed to view this data"
  	wait(5s)
  	Redirect(Homepage)
  }
  
  POST /import.php? 
  
  StartUpdateData()
  

  In this pseudocode example we can see the described vulnerability in action