Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
This vulnerability type focuses on the fact that sometimes users may be able to edit properties of their own accounts which increase their low privileges to higher ones or where unauthenticated users can make a legitimate request. These vulnerabilities can be easy to miss still but they are somewhat easier to find due to the predictable nature of API endpoints. We can for example try different HTTP methods or simply replacing strings in the URL (such as /employees to /managers)
This issue type exists because in the modern application there is an often complex hierarchy of roles and users. Implementing the correct access control for each type of user is difficult and easy to miss while testing. Often we configure these roles in the application itself or via a secondary application but sometimes the access level can be hard coded as well.
The impact of the vulnerabilities are almost always high since we are talking about having access to functionality the user should not be able to access. This can lead to information leakage, getting free items and even full account takeover of all the accounts if the user can reset passwords of others for example.
From the summary you might have been able to gather this vulnerability can be quite complex and varied. Find out where it is in the OWASP Top 10 ranking now. 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 (for example /books?id=0 might indicate the presence of an endpoint /books/all which may print out books the user should not be able to access.).
Example Attack Scenarios
In our first example we will be looking at a target which contains two types of accounts: Franchise holder and a company looking to exploit the franchise. Both log into the same URL but the Franchise holder type of 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 "exploitant" to "franchise_holder". This allows users to buy a lower priced type of account and change it to a higher priced account type themselves later on.
and by sending this request, the users can upgrade their own accounts to a more expensive account type.
A second example we can add is 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.
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.
will return the same as before, however the following:
exports all the documents.
Preventive measures against Excessive Data Exposure
It's always better to seperate 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.
Besides this 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.
To make things extra secure we can implement a master admin class that implements the main authorization modules as mentioned above. We can use this master admin module to inherent from all other administrative functions to limit the chance of administrative functions being executed by lower privileged users.
Lastly we always need to keep 2 factors in mind:
The users group
The users authorization level
And we have to make sure that with those two factors checked, only administrators can access administrative functions.
To test for this, it is wise to at least partially rely on test automation due to the predictable nature of APIs and how they are structured. A potential test could be to run the OPTIONS method on every API endpoint and to make sure those API endpoints do not allow for any unexpected method. We can also automate the checks of user roles and groups, this requires a proper definition of all the user roles and groups with their access levels.
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 accounts 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.
It is wise to at least partially automate this search but to keep manual testing involved as it's not easy have a robot guess certain URLs. Test automation however can perform directory brute forcing to ensure no API endpoints have been missed that allow for administrative functions. Best way to secure web API - Wallarm.
20+ years IT expertise in system engineering, security analysis, solutions architecture. Proficient in OS (Windows, Linux, Unix), programming (C++, Python, HTML/CSS/JS, Bash), DB (MySQL, Oracle, MongoDB, PostgreSQL). Skilled in scripting (PowerShell, Python), DevOps (microservices, containers, CI/CD), web development (Node.js, React, Angular). Successful track record in managing IT systems.
With over a decade of experience in cybersecurity, well-versed in system engineering, security analysis, and solutions architecture. Ivan possesses a comprehensive understanding of various operating systems, programming languages, and database management. His expertise extends to scripting, DevOps, and web development, making them a versatile and highly skilled individual in the field. Bughunter, working with top tech companies such as Google, Facebook, and Twitter. Blackhat speaker.