OWASP API #1: Broken Object Level Authorization
A new section
This is the beginning of a series of stories that aim to share with you, the top cybersecurity attacks during the last couple of years, and more importantly, show you how to proactively prevent them from happening.
OWASP API Top 10
Given we are going through topics discussed in OWASP, lets briefly explain what this is. OWASP stands for ‘Open Web Application Security Project’, and it is a nonprofit foundation that works to improve web application security.
The researches and information shared by this nonprofit organization, are the result of years of study by several cybersecurity professionals, who contribute honorarily just for the sake of helping people be secure while surfing the web.
OWASP maintains a top 10 of the most common vulnerabilities in web applications, each of them having an associated security risk level, ranging from 1 to 3.
API #1: Broken Object Level Authorization
This journey, in which we are going to explain all of the OWASP API Top 10, one by one and on a weekly basis, will begin with ‘Broken Object Level Authorization’.
In each story, we are going to go through ‘Brief explanation’, ‘Is my API vulnerable?’, ‘Attack scenarios’ and ‘How to prevent?’, so by the end you have a comprehensive understanding.
Lets begin :)
Brief explanation
Broken Object Level Authorization, occurs when an application does not properly validate that the user performing the request has the required privileges to access a resource of another user.
Is my API vulnerable?
It is indeed vulnerable in the following cases:
- Your API includes an ID of the resource, either in the URI, the request headers or the body.
/api/restaurant1/financial_info
- Your API does not check permissions for the invoker to access the resource.
- Even worse: the ID has a clear structure that can be enumerated.
/api/123/financial_info
Example attack scenario #1
An e-commerce platform for online stores, provides a listing page with the revenue charts for their hosted shops. Inspecting the browser requests, an attacker can identify the API endpoints used as a data source for those charts and their pattern /shops/{shopName}/revenue_data.json.
Using another API endpoint, the attacker can get the list of all hosted shop names. Creating a simple script to manipulate the names in the list, replacing {shopName} in the URL, the attacker gains access to the sales data of thousands of e-commerce stores.
Example attack scenario #2
While an attacker monitors the network traffic, an HTTP PUT request gets his attention due to the presence of a custom HTTP request header X-User-Id: 54796.
Replacing the ‘X-User-Id’ value with 54795, the attacker receives a successful HTTP response, and is able to modify other users’ account data.
How to prevent?
- Use an authorization mechanism to check if the logged-in user has access to perform the requested action.
- Do not use an ID that has been sent from the client, but instead extract the ID from an auth token.
- Use random and unpredictable values as GUIDs.
Conclusion
This is the start of a weekly series that hopefully will be extremely useful for the community and help eradicate the most common cybersecurity attacks in your applications.
For Broken Object Level Authorization, we have just seen that by using a good authorization mechanism and properly validating the roles of the users performing the requests, we can make the information of our users much more secure.
Thank you for taking the time to read it, and as usual, anyone at Strike will be happy to help you. You can reach out to me here or in LinkedIn!
Cheers from Strike ;)
