FixVibe
Covered by FixVibehigh

Firebase Sikkerhedsregler: Forhindring af uautoriseret dataeksponering

Firebase Sikkerhedsregler er det primære forsvar for serverløse applikationer, der bruger Firestore og Cloud Storage. Når disse regler er for eftergivende, såsom at tillade global læse- eller skriveadgang i produktionen, kan angribere omgå tilsigtet applikationslogik for at stjæle eller slette følsomme data. Denne forskning udforsker almindelige fejlkonfigurationer, risiciene ved "testtilstand"-standarder og hvordan man implementerer identitetsbaseret adgangskontrol.

CWE-284CWE-863

Firebase Sikkerhedsregler giver en detaljeret, server-tvungen mekanisme til at beskytte data i Firestore, Realtime Database og Cloud Storage [S1]. Fordi Firebase-applikationer ofte interagerer med disse cloud-tjenester direkte fra klientsiden, repræsenterer disse regler den eneste barriere, der forhindrer uautoriseret adgang til backend-dataene [S1].

Indvirkning af tilladelige regler

Fejlkonfigurerede regler kan føre til betydelig dataeksponering [S2]. Hvis regler er indstillet til at være alt for tilladelige - for eksempel ved at bruge standard 'testtilstand'-indstillinger, der tillader global adgang - kan enhver bruger med viden om projekt-id'et læse, ændre eller slette hele databaseindholdet [S2]. Dette omgår alle sikkerhedsforanstaltninger på klientsiden og kan resultere i tab af følsomme brugeroplysninger eller total afbrydelse af tjenesten [S2].

Grundårsag: Utilstrækkelig autorisationslogik

Grundårsagen til disse sårbarheder er typisk manglende implementering af specifikke forhold, der begrænser adgangen baseret på brugeridentitet eller ressourceattributter [S3]. Udviklere lader ofte standardkonfigurationer være aktive i produktionsmiljøer, som ikke validerer request.auth-objektet [S3]. Uden at evaluere request.auth kan systemet ikke skelne mellem en legitim autentificeret bruger og en anonym anmoder [S3].

Teknisk afhjælpning

Sikring af et Firebase-miljø kræver flytning fra åben adgang til en principal-of-mindst-privilege-model.

  • Tving godkendelse: Sørg for, at alle følsomme stier kræver en gyldig brugersession ved at kontrollere, om request.auth-objektet ikke er null [S3].
  • Implementer identitetsbaseret adgang: Konfigurer regler, der sammenligner brugerens UID (request.auth.uid) med et felt i dokumentet eller selve dokument-id'et for at sikre, at brugere kun kan få adgang til deres egne data [S3].
  • Granular Permission Scoping: Undgå globale jokertegn til samlinger. Definer i stedet specifikke regler for hver samling og undersamling for at minimere den potentielle angrebsoverflade [S2].
  • Validering via Emulator Suite: Brug Firebase Emulator Suite til at teste sikkerhedsregler lokalt. Dette giver mulighed for verifikation af adgangskontrollogik mod forskellige brugerpersoner, før de implementeres til et live miljø [S2].

Hvordan FixVibe tester for det

FixVibe inkluderer nu dette som en skrivebeskyttet BaaS-scanning. baas.firebase-rules udtrækker Firebase-konfiguration fra JavaScript-bundter med samme oprindelse, inklusive moderne initializeApp(...)-bundtformer, og kontrollerer derefter Realtime Database, Firestore og Firebase-anmodning om læst-på-opbevaring. For Firestore forsøger den først en rodsamlingsliste; når fortegnelsen er blokeret, undersøger den også almindelige følsomme samlingsnavne såsom users, accounts, customers, orders, ZXCVFIXVIBETOKEN6ZXZVIXX, ZXCVFIXVIBETOKEN6ZXZCVI, ZXCVCKEN6ZXZCV, ZXC7 admin og settings. Den rapporterer kun succesfulde anonyme læsninger eller lister og skriver, sletter eller gemmer ikke kundedokumentindhold.