Exploitation of Excessive Data Exposure is simple, and is usually performed by sniffing the traffic to analyze the API responses, looking for sensitive data exposure that should not be returned to the user.
APIs rely on clients to perform the data filtering. Since APIs are used as data sources, sometimes developers try to implement them in a generic way without thinking about the sensitivity of the exposed data. Traditional security scanning and runtime detection tools will sometimes alert on this type of vulnerability, but they can’t differentiate between legitimate data returned from the API and sensitive data that should not be returned. This requires a deep understanding of the application design and API context.
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.
In the example, the client-side code running in the user’s web browser is submitting a POST request 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 2019 a security researcher found that by passing a phone number in an API request the Bounceshare application would return an access token and RiderId associated with the account for that phone number. An attacker could automate this process by using a phone number dump found online and a script allowing them to gain unauthorized access to multiple user accounts. Once logged in to a target user’s Bounceshare account the attacker would have access to sensitive information such as their driver’s license, email address, and photos. If the target user had linked their Paytm account for payments, the attacker could also see the user's balance and book rides from the target user's account.
Traditional security controls like WAFs and API gateways have no context to identify sensitive data being sent over an API and therefore do not understand the exposure risk of the data being sent. Typically, they 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.
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. These solutions must also have the ability to baseline and track API access per endpoint and per user in order to identify excessive consumption of sensitive data. These solutions must also provide API context and a range of response actions so that not every transmission of sensitive data results in an alert or blocked request.
Salt Security's Michelle McLean speaks with the team at Xolv about how Xolv has deployed Salt to protect the APIs at the heart of its healthcare applications.
As part of our continuing mission here at Salt to educate the broader industry, our technical evangelist, Michael Isbitski, provides a comprehensive overview of the challenges and best practices in API security.