Firebase rules szkenner: nyitott Firestore-, Realtime Database- és Storage-szabályok megtalálása

Hogyan találja meg a szkenner a nyitott Firebase-szabályokat

A Firebase-szolgáltatások jól ismert, kiszámítható URL-formákat exponálnak. Egy credentialek nélküli szkenner mindegyiket szondázhatja, és megfigyelheti, hogy az anonim olvasások sikerülnek-e. A FixVibe baas.firebase-rules ellenőrzése három független szondázásban fut — egyenként Firebase-szolgáltatásonként:

• <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. A szkenner a https://[project-id]-default-rtdb.firebaseio.com/.json-t szondázza. Ha a root anonim módon olvasható, a válasz az egész adatbázisfa JSON-ként. Egy konzervatívabb teszt a .json?shallow=true-t kérdezi le, ami csak a felső szintű kulcsokat adja vissza — mindkét esetben találat.
• Cloud Storage. A szkenner a https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o-t kérdezi le. Ha a válasz fájlneveket listáz hitelesítés nélkül, a bucket anonim módon listázható. A listázható storage találat akkor is, ha az egyedi fájl-letöltéseket megtagadja — a támadók a bucketet enumerálva kitalálható fájlneveket keresnek.

Hogy néz ki valójában a test-mode footgun

A Firebase quickstart dokumentációja az internet egyik legtöbbet másolt szabályblokkját tartalmazza:

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

A Firebase korábban automatikus 30 napos lejáratot adott ezekhez a szabályokhoz. Ez megváltozott: ma a szabályok örökre fennmaradnak, hacsak a fejlesztő nem cseréli le őket. Az MI-kódoló eszközök — éveken át tanítva a test-mode blokkot tartalmazó dokumentációkon — gyakran szó szerint kiadják, és azt mondják a fejlesztőnek, hogy „ez a biztonsági szabályod". Nem az.

Más változatok, amelyek megjelennek a produkcióban, de ugyanolyan megengedők:

// 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;

• Egy jövőbeli időbélyeg-változat: egy szabály, ami mindent megenged egy távoli jövőbeli dátumig. Soha nem jár le hatékonyan (lásd a kiemelt blokkot fent).
• allow read: if true; allow write: if request.auth != null; — nyilvános olvasások, bármely hitelesített felhasználó tud írni.
• allow read, write: if request.auth != null; — bármely bejelentkezett felhasználó tud bármely dokumentumot olvasni vagy írni, beleértve más felhasználók adatait is.

Mit tegyél, ha a szkenner nyitott szabályt talál

A nyitott Firebase-szabályok futási idejű vészhelyzetet jelentenek. A fix ugyanaz a forma mind a három szolgáltatáson: szűkíts minden szabályt request.auth.uid-re egy explicit tulajdonos-mező ellen. Mindegyik szolgáltatásnak saját szabály-szintaxisa van:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }. Az útvonal-szegmens kötés {userId} lesz az egyetlen dokumentum, amelyhez a felhasználó hozzányúlhat.

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; } } }. Konvenció: tárold a fájlokat users/[uid]/[filename] alatt, és hagyd, hogy az útvonal érvényesítse a tulajdonjogot.

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

Deployold a szabályokat a Firebase CLI-vel: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Ellenőrizd, hogy az új szabályok élesben vannak, úgy hogy újra futtatod a FixVibe-szkennelést — a baas.firebase-rules találatnak el kell tűnnie.

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

Hogyan hasonlítható ez a Firebase beépített eszközeihez

A Firebase Console megmutatja az aktuális szabályokat, de nem auditálja őket a futási viselkedéssel szemben. A Firebase Rules szimulátor lehetővé teszi a szabálylogika tesztelését szintetikus kérések ellen — hasznos, de lokális. Egyik eszköz sem mondja meg, mit ad ténylegesen vissza a produkciós szabályrendszered egy anonim támadónak a nyilvános interneten. Egy külső szkenner, mint a FixVibe (vagy a Burp Suite manuális konfigurációval) az egyetlen, ami ugyanabból a szögből szondáz, ahonnan egy támadó tenné. A Google saját App Check-je csillapítja a visszaélést, de nem helyettesíti a helyesen szűkített szabályokat.

Gyakori kérdések

Következő lépések

Futtass egy ingyenes FixVibe-szkennelést az éles URL-edre — a baas.firebase-rules ellenőrzés minden csomagban benne van, és jelzi a nyitott szabályokat a Firestore-on, a Realtime Database-en és a Cloud Storage-en. Konkrétan az allow read, write: if true mintáról mélyebb magyarázatért lásd Firebase allow read, write: if true magyarázat. A Supabase, Firebase, Clerk és Auth0 átfogó áttekintéséért olvasd el a BaaS hibás konfiguráció szkenner cikket.