API Security Need to Know: Excessive Data Exposure

In today’s online world, privacy is more than concealing what you’re up to. Privacy begins with an expectation, that is maintained in an ongoing manner. When you use an application that sets a privacy expectation with words like “secure”, the maintenance falls to the provider of the application.

Clubhouse App Security Flaws: Excessive Data Exposure Explained

Recently Stanford’s Internet Observatory took a look at ClubHouse, a viral application that launched globally but had a huge impact on Chinese-speaking audiences because users could speak a secure message to one or more other users. The question came up, is this application actually secure and are these conversations subject to scrutiny from the Chinese Authorities?

Knowing there was an expectation of privacy, Stanford’s team downloaded the app, installed it on their phone, installed a cert from BURP and did the first thing everyone does in this situation. They tried to use it like a normal user. Based on the content about the evaluation it didn’t take them very long, nor did it take much doing, to start finding flaws.

Application security teams often rank flaws by criticality or severity but more often than not, they are ranked as being on or off of one of the OWASP Top 10 lists (Web Application or API Security). Using a Top 10 ranking means severity has been built in based on position, if the app had a #1 flaw for authorization it would be the worst flaw and should be addressed right away. Ranked #3 in the OWASP API Security Top 10 is Excessive Data Exposure – which can be triggered by many things – error messages that show too much information or even displaying obfuscated information.

The analysis of the ClubHouse app showed that it doesn’t display the data that the Stanford Team found, it filters it away. So your conversations are private, right? Not necessarily. Just because you cannot see it, does not mean it’s not there. Often these pieces of sensitive data are contained in a large JSON object that shows in plain-text some of this data. Once the data is available to the attacker they will utilize it in some way to exploit the next steps.

In the case of the Clubhouse app, an API call was made resulting in the token exchange routed through the app vendor servers to establish a connection between users. The information is then sent unencrypted, containing metadata about the channel, such as whether a user has requested to join a chatroom, the user’s Clubhouse id number, and whether they have muted themselves. This is where the application developers introduced an Excessive Data Exposure Threat, #3 on the OWASP API Top 10 list.

The Stanford team showed that having the keys and the data including information that could lead to the identities of others that had conversations could be possible. If the Chinese authorities were so inclined, it would be possible to figure out who is using the app, and what they are discussing. This extends to having all conversations monitored by another government and creates a general concern that the application be better secured on the back end.

How Developers Can Prevent Excessive Data Exposure in APIs

Excessive data exposure is usually not intentional – developers did what they thought was requested by the requirements document. In some cases, the result of excessive data exposure is it gives a user a greater understanding of the application and how it functions. That same information can be used for malicious purposes by threat actors. Recommendations are that the development and business teams collaborate to make sure all parties understand what is being transferred in a request/response series to make sure that the minimum amount of metadata is transferred to lessen the possibility that it can lead to an attack.

Download the interactive e-book to learn how Cequence API helps developers and security teams detect and prevent API coding errors that introduce OWASP API Top 10 threats.