This week, we review the API security controls outlined by the FCC to prevent data breaches and examine multiple incidents of API data leaks exposing users’ personal data. We also cover a case of unsafe API consumption in the Docker ecosystem.
Report: FCC weighs in with API security requirements
The U.S. Federal Communications Commission (FCC) has established a list of API security controls as part of a mandatory information security program at Tracfone, a wireless service provider. The company was also fined $16 million in connection with a series of data breaches that exposed its customers’ personal information.
The details of the mandated security program are included in a consent decree issued by the FCC, which specifically emphasizes the paramount importance of API security. Some of the highlights include:
- All input and output data validated and sanitized to prevent injection vulnerabilities
- All output data validated and authorized to avoid excessive data exposures
- All data securely communicated over an encrypted channel (e.g. TLS sessions)
- Numeric identifiers generated to be unpredictable (helps to avoid BOLA exploits)
- Check for the vulnerabilities listed in the OWASP API Security Top 10 List
The list of security controls compiled by the FCC can be a useful reference for other API teams who wish to implement a security program to prevent costly API vulnerabilities.
Vulnerability: Dating Apps highlight risk of client-side data filtering
An article on the Dark Reading website reveals how popular dating apps leak sensitive user information in API response messages, drawing a contrast between the filtered data displayed in the app UI and the unfiltered, more sensitive data returned by the API.
An example given in the report describes a user choosing to display their age in the app, while the API returns the user’s full date of birth to the app. This exposes more information than the user intended if you know where to look (hint: hackers know where to look).
APIs should only return data that is necessary and authorized for a request. Some API developers return data generically and leave it up to the client to determine what data to show or hide based on, for example, the end user’s privacy settings.
This is a mistake because it is often easy for an attacker to bypass a client-side application and access the raw data returned by an API. The golden rule is to never rely on the client to filter sensitive data. Instead, make sure the API only returns necessary and authorized data.
The OWASP documentation on broken object property level authorization recommends a number of API development practices to avoid excessive data exposure:
- When exposing an object using an API endpoint, always make sure that the user should have access to the object’s properties you expose.
- Implement a schema-based response validation mechanism as an extra layer of security. As part of this mechanism, define and enforce data returned by all API methods.
-
Keep returned data structures to the bare minimum, according to the business/functional requirements for the endpoint.
Breach: Life360 API leaks personal data of 400,000 customers
Continuing on the topic of APIs leaking sensitive data, a recent article in CPO Magazine describes how login attempts on the mobile tracking app Life360 returned excessive data in the API response, including the name and mobile phone number of unauthenticated users.
A hacker exploited this vulnerability to compile a list of personal information on more than 400,000 Life360 customers. The method used to exploit the vulnerability appears to follow a similar pattern to other industry cases we have covered recently, such as mass data scraping at Authy and Trello. In each of these incidents a hacker iterates through a list of stolen email addresses, sending each as input to the API one by one. If an account exists for a given email address, the vulnerable API returns personal information about the user.
The article states that the exploit occurred while “attempting” logins. This suggests that the API response containing the sensitive data was actually an error response (e.g. HTTP 401), which should remind API teams to continually test and validate the contents of API success and error responses, since both can be vulnerable to leaking sensitive information.
The article also highlights how the exposed information was not visible to a user through the mobile app’s UI, but could be found behind the scenes in the API response (sound familiar?). The fact that hackers can so easily bypass the app UI and delve into the API traffic, highlights again the importance of testing our APIs directly to ensure that developers apply appropriate constraints to the API response.
Validating users’ personal information at the app UI level is not sufficient, as it can hide the leakage of unauthorized information that occurs from the API.
Vulnerability: Docker AuthZ plugin and unsafe API consumption
According to a report by The Register, a vulnerability in Docker’s AuthZ plugin allows users to bypass authorization using a specially crafted API request with Content-Length set to 0.
The authorization process involves a sequence of API calls between a client, the Docker daemon, and the AuthZ plugin. A client sends an API request to the Docker daemon, which in turn sends an API request to the AuthZ plugin. The AuthZ plugin uses content in the API request body to decide whether a user’s request should be allowed or denied.
The vulnerability occurs when the body of the request to the AuthZ plugin is empty and does not contain any authorization information. In this case, the AuthZ plugin apparently authorized the request from the Docker daemon by default; which is strange behavior for a security control.
I think the AuthZ plugin API was probably implemented to always expect valid authorization content from the Docker daemon. An unsafe assumption if that is the case, since the Docker daemon was vulnerable to a malicious API request from the client, which it then passed on to the AuthZ plugin.
The OWASP guideline for the “unsafe consumption of APIs” vulnerability highlights that this is a common mistake developers make when the input data comes from a well-known source:
“Developers tend to trust data received from third-party APIs more than user input.
This is especially true for APIs offered by well-known companies”
All input data processed by an API, regardless of its source, must be validated before use to ensure it conforms to expectations of functionality and access control. Or, to put it more succinctly, verify don’t trust.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
