Vulnerability as a service

Backend as a Service (BaaS)

I BaaS (Backend as a Service) sono piattaforme che forniscono soluzioni pronte per gestire le funzionalità backend di un’applicazione senza che gli sviluppatori debbano costruire un’infrastruttura server da zero. In altre parole, con i BaaS, gli sviluppatori possono concentrarsi sull’interfaccia utente e la logica dell’app, delegando al servizio il compito di gestire la parte server, come database, autenticazione, storage, notifiche push e altro.

Un esempio pratico di BaaS è Firebase, una piattaforma di Google molto utilizzata per lo sviluppo di applicazioni web e mobile. Con Firebase, gli sviluppatori possono:

Usare Cloud Firestore o Realtime Database per memorizzare e sincronizzare i dati delle app in tempo reale, senza bisogno di configurare server.
Implementare l’autenticazione (login) tramite Google, Facebook, email e altri provider con pochi passaggi.
Utilizzare Firebase Cloud Messaging per inviare notifiche push agli utenti delle app.
Gestire il cloud storage per file come immagini e video.

Automatizzare Senza Riflettere

La comodità di automatizzare numerosi flussi logici non deve indurre gli sviluppatori a trascurare una riflessione critica su ciò che stanno costruendo. Anche se l’esempio può sembrare lontano dalla tecnologia in uso, è fondamentale ricordare il caso dei codici generati da LLM. Recentemente si è parlato molto di una vulnerabilità critica (CVE-2024-45489) scoperta da eva riguardo al web browser Arc.

Una funzionalità peculiare di questo browser consente di salvare degli “arc boosts”, che permettono all’utente di modificare l’aspetto delle varie pagine web attraverso JavaScript e CSS. Questi settaggi sono resi disponibili su tutti i dispositivi dell’utente che utilizzano il browser Arc. Per abilitare questa funzionalità, gli arc boosts devono essere salvati in un layer di persistenza lato backend. Su Arc, questo processo avveniva tramite Firestore, un Database as a Service NoSQL, dove il recupero dei boosts avveniva attraverso chiamate asincrone come questa:

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

Attraverso l’sdk di firebase, in questo esempio esegue la richiesta di lista di tutti i “boosts” del dominio google.com dell’utente di arc attraverso il suo identificativo.

La Vulnerabilità

Il problema sorge nel momento del salvataggio dei boosts, che possono includere codice JavaScript arbitrario. Tuttavia, il creatorID assegnato al momento del salvataggio viene impostato su quello dell’utente autenticato. Se questo valore viene sovrascritto con l’ID di un altro utente, il sistema non esegue un controllo adeguato per verificare che l’ID dell’utente autenticato corrisponda effettivamente al creatorID salvato.

Questa carenza introduce una vulnerabilità di tipo IDOR, permettendo a chiunque conosca l’ID di un altro utente di iniettare codice JavaScript arbitrario senza che l’utente target ne sia consapevole.

Il mancato controllo

Questo caso mi ha particolarmente colpito, anche perché riflette alcuni aspetti su un progetto a cui sto lavorando: una web app che sfrutta un backend as a service. Per i curiosi, sto utilizzando Pocketbase.

L’errore del team di Arc è piuttosto semplice e facilmente evitabile. Ad esempio, su Pocketbase:

Pocketbase example screenshot

Come mostrato nell’immagine, è sufficiente verificare che il parametro user.id che si intende salvare corrisponda all’ID dell’utente autenticato. Se il controllo fallisce, il record non viene salvato.

Dagli errori si impara sempre

Anche se questo errore può sembrare banale, non è mia intenzione screditare le competenze del team di Arc. Da questa vicenda, però, possiamo trarre un’importante lezione sulla sicurezza delle applicazioni che sviluppiamo.

Anche se le vulnerabilità non vengono immediatamente sfruttate da attori malevoli, possono comunque danneggiare gravemente la reputazione di un’azienda. In seguito a questa scoperta, il team di Arc ha deciso di abbandonare Firebase, ma è importante sottolineare che la colpa non era della piattaforma, bensì di una semplice configurazione errata.