Blog
Software engineer
← Blog

Vulnerability as a Service

Marco Montorsi

Automated services, if misused, can lead to vulnerabilities

Security

Backend as a Service (BaaS)

Backend as a Service (BaaS) platforms provide ready-made solutions for managing the backend functionalities of an application, freeing developers from the need to build a server infrastructure from scratch. Essentially, BaaS allows developers to focus on the user interface and application logic, while delegating the management of server components—such as databases, authentication, storage, push notifications, and more—to the service.

A well-known example of BaaS is Firebase, Google's platform widely used for web and mobile application development. With Firebase, developers can:

  • Use Cloud Firestore or Realtime Database to store and sync app data in real-time without server configuration.
  • Implement authentication (login) via Google, Facebook, email, and other providers with minimal effort.
  • Use Firebase Cloud Messaging to send push notifications to app users.
  • Manage cloud storage for files like images and videos.

Automating Without Thinking

The convenience of automating many logical flows should not lead developers to overlook a critical assessment of what they are building. Even if the example seems distant from the technology in use, the risk of vulnerabilities is always present, as highlighted by the recent case involving code generated by LLMs.

Recently, a critical vulnerability (CVE-2024-45489) was discovered in the Arc web browser, as reported by eva. Arc offers a unique feature that allows users to save "arc boosts", which enable them to modify the appearance of various web pages through JavaScript and CSS. These settings are synced across all devices that use the Arc browser. To enable this feature, arc boosts are saved in a persistence layer on the backend.

In Arc, this process was handled via Firestore, a NoSQL Database as a Service. The retrieval of boosts was performed through asynchronous calls like this one:

firebase
  .collection("boosts")
  .where("creatorID", "==", "UvMIUnuxJ2h0E47fmZPpHLisHn12")
  .where("hostPattern", "==", "www.google.com");

In this example, the Firebase SDK requests a list of all boosts for the domain google.com created by the user identified by the creatorID.

The Vulnerability

The issue arises when saving the boosts, as they can contain arbitrary JavaScript code. However, during the save process, the creatorID is set to that of the authenticated user. If this value is overwritten with another user's ID, Arc’s team failed to implement a simple check: the saved creatorID should match the authenticated user's ID.

This oversight exposes a vulnerability known as IDOR, which allows, once the target user’s ID is known, the injection of any JavaScript without the user's knowledge.

The Missing Check

This case particularly caught my attention, as it reflects some aspects of a project I’m working on—a web app that utilizes a backend as a service. For those curious, I’m using Pocketbase.

The error made by the Arc team is quite simple, as shown in this Pocketbase example:

As seen in the rules, it's enough to check that the user.id parameter being saved matches the authenticated user's ID. If not, the record is not saved.

Learning from Mistakes

Even though this might seem like a simple mistake, it’s not my intention to discredit the skills of the Arc team. Instead, this serves as a valuable lesson on the importance of security in the applications we develop.

Even if such vulnerabilities are not immediately exploited by malicious users, they can still severely damage a company's reputation. Following this incident, the Arc team announced they will move away from Firebase. However, it’s crucial to highlight that the issue wasn’t Firebase itself, but rather a simple misconfiguration.

In today’s fast-paced market, innovation is key, and the speed at which new features are introduced can sometimes lead to oversight. However, it’s essential to learn from these mistakes to avoid repeating them in the future.

← All articles