Skener Firebase pravila: pronađite otvorena Firestore, Realtime Database i Storage pravila

Kako skener pronalazi otvorena Firebase pravila

Firebase servisi izlažu poznate, predvidljive URL oblike. Skener bez vjerodajnica može ispitati svaki i promatrati uspijevaju li anonimna čitanja. FixVibe-ova provjera baas.firebase-rules radi u tri neovisne probe — jedna po Firebase servisu:

• <strong>Firestore.</strong> The scanner extracts the project ID from the deployed app's bundle (it's in <code>firebase.initializeApp({ projectId: ... })</code>), then issues <code>GET https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents/[collection]:listDocuments</code> against common collection names. A <code>200 OK</code> with documents in the response means <code>allow read</code> is permissive.
• Realtime Database. Skener ispituje https://[project-id]-default-rtdb.firebaseio.com/.json. Ako je korijen anonimno čitljiv, odgovor je cijelo stablo baze kao JSON. Konzervativniji test upituje .json?shallow=true, što vraća samo ključeve na najvišoj razini — i jedno i drugo je nalaz.
• Cloud Storage. Skener upituje https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o. Ako odgovor popisuje imena datoteka bez autentifikacije, bucket je anon-listable. Listable storage je nalaz čak i kada su preuzimanja pojedinačnih datoteka zabranjena — napadači nabrajaju bucket da pronađu nazive koji se mogu pogoditi.

Kako footgun test-modea zaista izgleda

Firebase quickstart dokumentacija uključuje jedan od najkopiranijih blokova pravila na internetu:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

Firebase je nekada dodavao automatski 30-dnevni istek na ova pravila. To se promijenilo: danas pravila ostaju zauvijek osim ako ih developer ne zamijeni. AI alati za kodiranje — trenirani na godinama dokumentacije koja uključuje test-mode blok — često ih emitiraju doslovno i govore developeru "ovo je vaše sigurnosno pravilo". To nije.

Druge varijante koje se pojavljuju u produkciji, ali su jednako permisivne:

// future-date variant — equivalent to "if true"
allow read, write: if request.time < timestamp.date(2099, 1, 1);

// authenticated-user variant — any signed-in user reads and writes anything
allow read: if true;
allow write: if request.auth != null;

// any-auth variant — any signed-in user owns every document
allow read, write: if request.auth != null;

• Varijanta s budućim timestampom: pravilo koje dopušta sve do datuma daleko u budućnosti. Nikad efektivno ne istječe (vidi istaknuti blok iznad).
• allow read: if true; allow write: if request.auth != null; — javna čitanja, svaki autenticirani korisnik može pisati.
• allow read, write: if request.auth != null; — svaki prijavljeni korisnik može čitati ili pisati bilo koji dokument, uključujući podatke drugih korisnika.

Što učiniti kada skener pronađe otvoreno pravilo

Otvorena Firebase pravila su runtime hitnost. Popravak je istog oblika u sva tri servisa: ograničite svako pravilo na request.auth.uid u odnosu na eksplicitno polje vlasnika. Svaki servis ima svoju sintaksu pravila:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }. Vezivanje segmenta putanje {userId} postaje jedini dokument koji korisnik može dotaknuti.

match /users/{userId} {
  allow read, write: if request.auth != null
                     && request.auth.uid == userId;
}

Realtime Database

<code>{ "rules": { "users": { "$uid": { ".read": "$uid === auth.uid", ".write": "$uid === auth.uid" } } } }</code>. The <code>$uid</code> wildcard captures the path segment for comparison.

{
  "rules": {
    "users": {
      "$uid": {
        ".read":  "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    }
  }
}

Cloud Storage

service firebase.storage { match /b/{bucket}/o { match /users/{userId}/{allPaths=**} { allow read, write: if request.auth.uid == userId; } } }. Konvencija: pohranjujte datoteke pod users/[uid]/[filename] i neka putanja primjenjuje vlasništvo.

service firebase.storage {
  match /b/{bucket}/o {
    match /users/{userId}/{allPaths=**} {
      allow read, write: if request.auth.uid == userId;
    }
  }
}

Deployajte pravila preko Firebase CLI: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Provjerite jesu li nova pravila u produkciji ponovnim pokretanjem FixVibe skena — nalaz baas.firebase-rules trebao bi nestati.

firebase deploy --only firestore:rules
firebase deploy --only database
firebase deploy --only storage

Kako se ovo uspoređuje s Firebase-ovim ugrađenim alatima

Firebase konzola vam pokazuje trenutna pravila, ali ih ne auditira u odnosu na runtime ponašanje. Simulator Firebase pravila omogućuje testiranje logike pravila u odnosu na sintetičke zahtjeve — korisno, ali lokalno. Nijedan alat vam ne govori što vaša produkcijska pravila zapravo vraćaju anonimnom napadaču na javnom internetu. Vanjski skener poput FixVibe-a (ili Burp Suite uz ručnu konfiguraciju) jedina je stvar koja ispituje iz istog kuta iz kojeg bi napadač. Google-ov vlastiti App Check ublažava zlouporabu, ali ne zamjenjuje ispravno ograničena pravila.

Često postavljana pitanja

Sljedeći koraci

Pokrenite besplatan FixVibe sken prema svom produkcijskom URL-u — provjera baas.firebase-rules isporučuje se u svakom paketu i označava otvorena pravila u Firestoreu, Realtime Databaseu i Cloud Storageu. Za detaljnije objašnjenje obrasca allow read, write: if true specifično, pogledajte Firebase allow read, write: if true objašnjeno. Za pogled iz ptičje perspektive na Supabase, Firebase, Clerk i Auth0, pročitajte Skener BaaS pogrešnih konfiguracija.