[ This article was originally published here ]
The content of this publication is the sole responsibility of the author. AT&T does not adopt or endorse any of the opinions, 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 facing modern application programming interfaces (APIs). It can be exciting to look for innovations in the API area, but while doing so, developers need to make sure they are adequately aware of security concerns and develop protocols that can address those concerns. This article will describe the BOLA issue and its consequences, and then present potential actions that can be taken to resolve the issue.
The problem
OWASP (2019) states 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” ( paragraph 1). For example, a hacker can access information about how various stores make requests to an e-commerce platform. The hacker can then see that there is a certain pattern in the codes for these requests. If the hacker can gain access to the codes and has the authorization to tamper with them, then he could set a different endpoint in the code and thus redirect all data back to himself.
Exploitation of BOLA vulnerabilities is very common because, without implementation of an authorization protocol, APIs have essentially no protection against hackers. To attack this type of API, the hacker only needs the ability to access request code systems and intercept data by manipulating the codes, which can be done quite easily by anyone with the necessary skills and resources (). APIs that do not have security measures in place simply hope that no one knows how to perform such an attack or has the desire to do so. However, once a voluntary hacker enters the scene, the APIs would have no real protections to prevent the hacker from gaining access to the system and all of the data contained within and transmitted through it.
The consequences
BOLA attacks have significant consequences in terms of data security: “Unauthorized access may result in disclosure of data to unauthorized parties, loss of data, or manipulation of data. Unauthorized access can also lead to total account takeover” (OWASP, 2019, para. 3). In short, BOLA attacks produce data leaks. Stories about data breaches are very common in the news, with a very recent one involving a health care organization in Texas (Marfin, 2022). While not all data breaches are the result of BOLA attacks, many of them are, since 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, the data breach could lead to hackers gaining access to patients’ private health insurance. If the target is a bank, it is likely that hackers will be able to access customers’ social security numbers. If the target is an e-commerce website, data related to customer credit card numbers and addresses would be compromised. In all cases, the central consequence of a BOLA attack is that hackers can access personal information due to a lack of adequate security measures within the APIs in question.
The solution
The solution for BOLA is for programmers to implement authorization protocols to access any data or code within an API. As OWASP (2019) indicates, the prevention of BOLA will require the implementation of “an authorization mechanism to verify if the logged in user has access to perform the action requested in the registry in each function that uses client input to access a record in the database” (para. 9).
The BOLA vulnerability essentially has to do with APIs and the assumption that if a user has access to the information required to make a request, then they should automatically be authorized to make that request. This assumption is obviously wrong, as hackers can gain access to the information and then use it to manipulate the API even without actual authorization to do so.
Therefore, preventing the BOLA vulnerability requires a system that not only responds to user input, but can also verify if the user is authorized to perform the desired actions (Blokdyk, 2022). For example, the system may require an external password that a hacker could not find simply by examining data and information within the API itself.
The solution to BALL, then, is simple. APIs currently focus on object IDs to authenticate requests, which is totally inadequate from a data security standpoint. To prevent BOLA, APIs need to keep track of the users themselves and focus on ensuring that users are properly authorized to make requests, perform actions, and provide input within the system. The BOLA vulnerability is based entirely on the fact that programmers often do not implement such a protocol. Such an implementation would remove the vulnerability in its entirety to the extent that hackers will not be able to access or tamper with the target APIs.
Perhaps BOLA is thus a case study in humility. As developers explore new frontiers of modern APIs, they also need to make sure they don’t neglect the basics. Implementing user authorization protocols to prevent the BOLA vulnerability should be understood as a fundamental element of any robust API, and doing so will address a key OWASP priority.
References
Blokdyk, G. (2022). Authentication and authorization of users. 5STARKitchens.
Marfin, C. (2022, July 12). Tenet Healthcare is facing a lawsuit after a data breach affects 1.2 million patients. Dallas Morning News.
Open the Web Application Security Project. (2019). API2: 2019 broken object level authorization. GitHub. authorization-level-object.md
Viriya, A. and Muliono, Y. (2021). Take a look and test the broken object-level authorization vulnerability in e-commerce and e-banking mobile applications. Proceeds Computer Science, 179, 962-965.
Advertisement
