[ This article was originally published here ]
The content of this post is solely the responsibility of the author. AT&T does not adopt or endorse any of the views, positions, or information provided by the author in this article.
According to the Open Web Application Security Project (), broken object-level authorization (BOLA) is the most significant vulnerability confronting modern application programming interfaces (APIs). It can be exciting to pursue innovations in the API area, but while doing so, programmers must ensure that they are adequately attentive to security concerns and that they develop protocols that can address such concerns. This article will describe the problem of BOLA and its consequences, and then it will present potential actions that can be taken to solve the problem.
The problem
OWASP (2019) indicates the following regarding BOLA: “Attackers can exploit API endpoints that are vulnerable to broken object-level authorization by manipulating the ID of an object that is sent within the request” (para. 1). For example, a hacker may access information regarding how various shops make requests to an e-commerce platform. The hacker may then observe that a certain pattern exists in the codes for these requests. If the hacker can gain access to the codes and has the authorization to manipulate them, then they could establish a different endpoint in the code and thereby redirect all the data to themselves.
The exploitation of BOLA vulnerabilities is very common because, without the implementation of an authorization protocol, APIs essentially have no protection whatsoever against hackers. To attack this kind of APIs, the hacker only needs the capability to access request code systems and intercept data by manipulating the codes, which can be done rather easily by anyone who has the requisite skills and resources (). APIs that do not have security measures in place are thus simply hoping that no one will know how to conduct such an attack or have the desire to do so. Once a willing hacker enters the picture, however, the APIs would have no actual protections to stop the hacker from gaining access to the system and all the data contained within it and transmitted across it.
The consequences
BOLA attacks have significant consequences in terms of data security: “Unauthorized access can result in data disclosure to unauthorized parties, data loss, or data manipulation. Unauthorized access can also lead to full account takeover” (OWASP, 2019, para. 3). In short, BOLA attacks produce data breaches. Stories about data breaches are all too common in the news, with a very recent one involving a healthcare organization in Texas (Marfin, 2022). While not all data breaches are the result of BOLA attacks, many of them are, given that BOLA is a very common vulnerability in APIs. The specific consequences of a successful BOLA attack, as well as the magnitude of those consequences, would depend on the target of the attack.
For example, if the target is a healthcare organization, then the data breach could lead to hackers gaining access to patients’ private health insurance. If the target is a bank, then the hackers would likely be able to access customers’ social security numbers. If the target is an e-commerce website, then data regarding customers’ credit card numbers and home addresses would be compromised. In all cases, the central consequence of a BOLA attack is that hackers can gain access to personal information due to a lack of adequate security measures within the APIs in question.
The solution
The solution to BOLA is for programmers to implement authorization protocols for accessing any data or codes within an API. As OWASP (2019) indicates, prevention of BOLA will require the implementation of “an authorization mechanism to check if the logged-in user has access to perform the requested action on the record in every function that uses input from the client to access a record in the database” (para. 9).
BOLA vulnerability essentially has to do with APIs and assuming that if a user has access to the information required to make a request, then they must automatically be authorized to make that request. This assumption is obviously fallacious since hackers can gain access to the information and then use it to manipulate the API even though they have no actual authorization to do so.
Therefore, preventing BOLA vulnerability requires a system that not only responds to the user’s inputs but is also able to verify whether the user is authorized to perform the desired actions (Blokdyk, 2022). For example, the system may require an external password that a hacker would not be able to find simply by perusing data and information within the API itself.
The solution to BOLA, then, is straightforward one. APIs currently focus on object IDs for authenticating requests, which is altogether inadequate from a data security standpoint. To prevent BOLA, APIs must track the users themselves and focus on ensuring that users are properly authorized to make requests, take actions, and provide inputs within the system. The BOLA vulnerability is based entirely on the fact that programmers often fail to implement such a protocol. Such implementation would eliminate the entirety of the vulnerability insofar as hackers will then not be able to access and manipulate target APIs.
Perhaps BOLA is thus a case study in humility. As programmers explore new frontiers of modern APIs, they must also ensure that they do not neglect the basics. The implementation of user authorization protocols to prevent BOLA vulnerability must be understood as a foundational element for any sound API, and doing so will address a key OWASP priority.
References
Blokdyk, G. (2022). User authentication and authorization. 5STARCooks.
Marfin, C. (2022, July 12). Tenet Healthcare faces lawsuit after data breach affects 1.2 million patients. Dallas Morning News.
Open Web Application Security Project. (2019). API2:2019 broken object level authorization. GitHub. object-level-authorization.md
Viriya, A., & Muliono, Y. (2021). Peeking and testing broken object level authorization vulnerability onto e-commerce and e-banking mobile applications. Procedia Computer Science, 179, 962-965.
Ad