How to Protect Your Business from Data Leaks

author_profile
Tim Szigeti
Friday, Jul 19th, 2024

In this blog, we're going to discuss how you can protect your business from data leaks that can result from insecure application programming interfaces.

Cloud native applications are composed of loosely coupled microservices, which are predominantly intercommunicating via APIs. As such, API exploitation is rapidly becoming a very common threat vector, as seen by the stats in Figure 1, which includes Gartner’s prediction that it will be the #1 attack vector for cloud native applications.

Figure 1
Figure 1: API Attack Prevalence (Sources: Gartner, Salt & Equixly)

A Common Attack Vector on APIs

To better understand the nature of these attacks and how to protect ourselves from them, let’s consider a case study example, one that made the news. This particular example relates to Peloton, but we want to stress that we’re not picking on them, but just using them as an example of a very common attack.

Peloton makes exercise equipment, including stationary bicycles with integrated video screens, so that you can join fitness classes from home. At the time of this incident, they had 3 million subscribers using their APIs, which (at the time) exhibited multiple security vulnerabilities. For example, anyone with Internet access could access significant amounts of personal information of members, including their user IDs, location, age, gender, and even their weight, as shown in Figure 2.

Figure 2
Figure 2: Peloton API Data Exposure
(Source: https://www.pentestpartners.com/security-blog/tour-de-peloton-exposed-user-data/)

So what went wrong? To better understand this, it may be helpful to take a step back and first consider what needs to go right in order for API communications to work securely. To this end, let’s consider the example of making and sharing a dinner reservation. We have a user named Bob who makes a dinner reservation that he wishes to share with Alice for a date. He enters information on when and where, which he is perfectly willing to share with Alice, but there may be information that he would prefer to keep private, such as the credit card information used to secure the reservation.

Figure 3
Figure 3: A Dinner Reservation for Two

So, what are some things that can go wrong? Let’s consider three ways this model can break down.

First, if proper authentication is not in place, then individuals without any credentials could access information within the database. This is called Broken User Authentication, or BUA. These users aren’t challenged for credentials, and, as a result, they can simply begin trolling the API to see what information they can gain access to.

Next, even authenticated users may be restricted as to what they should be able to retrieve. For example, let’s say Alice has an ex-boyfriend, Seamus, who isn’t particularly happy that she’s now dating Bob. What if he were able to log in and retrieve the details of the dinner reservation? Perhaps he would be able to find out the date and time, and possibly even Bob’s credit card information. He could then arrive and cause a scene, and he could potentially even abuse Bob’s credit card information by making fraudulent purchases. For all these reasons, proper Object-Level authentication must also be in place; and if such is missing, then this is called Broken Object-Level Authentication (or BOLA).

Finally, let’s consider one more case: Bob’s ex-girlfriend Angela also wants to cause some problems for the new couple. She’s not going to show up and make a scene, but she’s decided to log in and try to cancel the reservation entirely, so that when Bob and Alice show up, they won’t have a table waiting for them. This is a function that she should not be authorized to do. And if she was able to perform that function, then this would be called Broken Function-Level Authentication (or BFLA).

Figure 4
Figure 4: Examples of Broken User Authentication (BUA), Broken Object-Level Authentication (BOLA) and Broken Function-Level Authentication (BFLA)

So, let’s return to our case-study and analyze what went wrong. First, we see that originally there was no authentication in place, which an example of Broken User Authentication (BUA). Incidentally, this is one of the Open Worldwide Application Security Project (OWASP) Top-10 API Security risks of 2023. While this may seem intuitive and obvious, it’s very common, as can be seen by it being listed as #1 of this Top-10 list.

Another factor was Broken Object Level Authentication (which is #1 on the OWASP Top-10 API Security List): authentication users were able to pull up records that they were not intended to have access to.  Specifically, after the original BUA was reported to Peloton, they silently “fixed” the issue by allowing access to member data “only” to all authenticated users, which is an example of BOLA. This meant, that any given Peloton member could potentially pull up PII of any other Peloton member.

And finally, this was also a case of excessive data exposure, where private data (such as, for example, a member’s age and weight) could be returned via the API, even when these fields may have been designated as private.

We want to stress again that this is not an isolated incident, but rather very common, as has been shown by the earlier stats. As such, how can businesses protect themselves from data leaks via insecure APIs? Panoptica (Cisco Cloud Application Security) makes this quick and easy to do, as shown in this video.

It’s really that easy. So why not take Panoptica for a free test drive and see how it can help secure your cloud native apps? Get started at panoptica.app today!

Popup Image