API3:2023 Broken Object Property Level Authorization
The Broken Object Property Level Authorization category combines attacks that happen by gaining unauthorized access to sensitive information by way of Excessive Data Exposure (previously listed as number 3 in the 2019 OWASP API Security Top 10) or Mass Assignment (previously in sixth place).
Both techniques are based on API endpoint manipulation to gain access to sensitive data.
This new category deals with object properties level authorization as opposed to object level authorization (number 1 on the list since 2019).
The main reason for introducing this new threat on the list is that, even if an API can enforce sufficient object-level authorization security measures, this might still not be enough to protect it. More specific authorization that covers the objects and their characteristics is often required. The varying access levels within an API object must also be taken into account, as an API object often has both a public property and a private one.
.jpg)
Learn how to reduce the business risk of API attacks and maximize the value of digital innovation.
Download NowPotential Impact of Broken Object Property Level Authorization
APIs often send more information than is needed in an API response and leave it up to the client application to filter the data and render a view for the user. An attacker can sniff the traffic sent to the client to gain access to potentially sensitive data that can include information such as account numbers, email addresses, phone numbers, and access tokens.
Additionally, an attacker exploiting this type of vulnerability can update object properties that they should not have access to allowing them to escalate privileges, tamper with data, and bypass security mechanisms.
What Does a Broken Object Property Level Authorization Attack Look Like?
In the example above, the client-side code running in the user’s web browser is submitting a POSTrequest to a backend API to retrieve stored payment information. In this case, the API is retrieving stored credit card information, specifically primary account number (PAN) and card verification value (CVV) code. Within the world of credit card handling and payment processing, this type of data is deemed to be sensitive as part of PCI-DSS and must be protected appropriately. The scope of what is necessary for protection varies depending on exposure of the cardholder data environment, or where the data is stored, processed, or transmitted.
This sensitive data sharing may be intentional as part of the design or necessary for functionality. As a result, organizations augment with additional security controls such as stronger authentication or encrypted transport to ensure the data is sufficiently protected. In the example, you can see additional HTTP security headers to help protect the data, such as x-frame-options for mitigating cross-frame scripting attacks and x-xss-protection for mitigating cross-site scripting attacks. Some organizations may also mask data being returned to a client to avoid cases where someone intercepts traffic or views data outside of the intended client application. Relying on the client-side code to filter or obscure such sensitive data is typically not appropriate since attackers regularly bypass client-side web application and mobile application code and call APIs directly.
In the second example above, the attacker has changed the API call to update their account, escalate their role and privileges to an “admin” role, and bypass single-sign on (SSO). If successful, the attacker can then perform actions within the application as an administrator.
Real-World Example: Twitter users see their data compromised
According to a statement released by Twitter in August 2022, a broken object properly level authorization vulnerability was initially spotted by their bug bounty program in January 2022. As a result of the flaw, if someone submitted an email address or phone number to Twitter’s systems, they would be informed of what Twitter account the submitted email addresses or phone number was associated with, if any. The issue was investigated and fixed by Twitter at the time with no evidence to suggest it had been exploited in the wild. However, in July 2022, it came to light that a bad actor had taken advantage of the issue before it was addressed by the company and was now offering to sell the data they compiled.
This very public incident brought to light the risk that this type of security vulnerability can pose, even for a well-established brand with vast resources and supposedly robust security programs.
Why Existing Tools Fail to Protect You Against Broken Object Property Level Authorization Vulnerabilities
Traditional security controls like WAFs and API gateways have no context over API activity and business logic and therefore fail to identify sensitive data being sent over an API or understand the exposure risk of the data being sent. They also can’t know if the API caller in the example above should be able to send a request using the PUT method with additional parameters, failing to differentiate between a legitimate call and malicious activity. To these traditional controls, this API call looks normal. At best, a WAF or API gateway may be able to offer basic message filtering mechanisms to block this type of request wholesale. However, additional parameters may be necessary for other users and other use cases. It would also require detailed knowledge upfront from development teams on the design and intended use of the API so that operational teams can implement even basic message filters.
Typically, API gateways and WAFs will employ basic pattern matching and message filtering to identify sensitive data types, also referred to as regular expression (regex) patterns. While these types of filters can catch well-defined sensitive data types such as PANs or social security numbers (SSNs), they do not understand API context and business logic flows. They will flag any data that matches the pattern, regardless of whether it is necessary to block the request, encrypt payloads or obscure data. API gateways are often used to mediate API calls that contain sensitive data, and this may be necessary as part of an overarching enterprise architecture, application design or systems integration. Blocking or masking sensitive data wholesale often breaks functionality as a result leaving security teams reluctant to aggressively use these capabilities in proxies in favor of relying on the API/application layer to control exposure.
How to Protect Your APIs Against Broken Object Property Level Vulnerability
An API security solution must be able to identify and report on the large variety of sensitive data types that can be sent in API requests and responses, as well as any anomalous activity where attackers send manipulated API requests with unauthorized parameters.
These solutions must also be able to baseline and track API access per endpoint and per user in order to identify excessive consumption of sensitive data and spot those instances when additional parameters are passed in API calls that fall outside of typical behavior. API Security solutions should also be able to identify attackers as they probe the API during their reconnaissance phase to gain an understanding of the API structure and business logic.
To learn more about how Salt can help defend your organization from API risks, you can connect with a rep or schedule a personalized demo.
