One Article Review
| Source |  AlienVault Lab Blog |
|---|---|
| Identifiant | 8318330 |
| Date de publication | 2023-03-14 10:00:00 (vue: 2023-03-14 10:06:55) |
| Titre | Broken Object Level Authorization: API security\'s worst enemy |
| Texte | 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 (OWASP, 2019), 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 (Viriya & Muliono, 2021). 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 d |
| Envoyé | Oui |
| Condensat | https://www bola github object owasp patients science the vulnerability &Muliono “an “attackers “unauthorized https://github 179 2019 2021 2022 5starcooks 8bafter 962 965 Authoriization Broken Viriya able about access accessing according account across action actions actual address addresses adequate adequately adopt affects after against all also altogether any anyone api api2:2019 apis application applications are area article assuming assumption at&t attack attacks attentive authenticating authentication author authorization authorization: authorized automatically bank banking based basics because blokdyk bola bola: breach breaches broken but can capability card case cases central certain check client code codes com/news/courts/2022/07/12/tenet com/owasp/api commerce common compromised computer concerns conduct confronting consequence consequences contained content could credit currently customers’ dallas dallasnews data database” depend describe desire desired develop different disclosure does doing done due easily element eliminate endorse endpoint endpoints enemy ensure ensuring enters entirely entirety essentially establish even every example exciting exists exploit exploitation explore external faces fact fail fallacious find focus following foundational from frontiers full function gain gaining given hacker hackers has have health healthcare home hoping how however humility ids implement implementation inadequate indicates information innovations input inputs insofar insurance intercept interfaces involving its itself july key kind know lack lawsuit lead level likely logged loss magnitude make manipulate manipulating manipulation many marfin may measures mechanism million mobile modern morning most muliono must needs neglect new news not numbers object observe obviously often once one only onto open organization owasp para parties password patients patients/ pattern peeking perform perhaps personal perusing picture place platform positions post potential present prevent preventing prevention priority private problem procedia produce programmers programming project properly protection protections protocol protocols provide provided pursue question rather recent record redirect references regarding request request” requested requests require required requires requisite resources responds responsibility result security security/blob/master/2019/en/SRC/SRC/0xa1 security: sent shops short significant simply since skills social solely solution solve sound specific standpoint stop stories straightforward study successful such system systems take taken takeover” target tenet terms testing texas them themselves then thereby therefore these those though thus too track transmitted unauthorized understood use user user’s users uses various verify very views viriya vulnerabilities vulnerability vulnerable web website well whatsoever whether which who will willing within without worst would |
| Tags | Data Breach Guideline Vulnerability |
| Stories | |
| Notes | ★★★ |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.