Firebase-sääntöskanneri: löydä avoimet Firestore-, Realtime Database- ja Storage-säännöt

Miten skanneri löytää avoimet Firebase-säännöt

Firebase-palvelut paljastavat tunnettuja, ennustettavia URL-muotoja. Skanneri ilman tunnistautumistietoja voi tutkia jokaista ja havainnoida, onnistuvatko anonyymit luvut. FixVibe-tarkistus baas.firebase-rules ajetaan kolmena riippumattomana tutkimuksena — yksi Firebase-palvelua kohti:

• <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. Skanneri tutkii https://[project-id]-default-rtdb.firebaseio.com/.json:n. Jos juuri on anonyymisti luettavissa, vastaus on koko tietokantapuu JSONina. Konservatiivisempi testi kysyy .json?shallow=true:n, joka palauttaa vain ylätason avaimet — kummassakin tapauksessa löydös.
• Cloud Storage. Skanneri kysyy https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o:n. Jos vastaus listaa tiedostonimiä ilman autentikointia, bucket on anonyymisti listattavissa. Listattava storage on löydös, vaikka yksittäisten tiedostojen lataukset kielletäänkin — hyökkääjät enumeroivat bucketin löytääkseen arvattavia tiedostonimiä.

Miltä test-mode-jalkaan-ammunta todellisuudessa näyttää

Firebasen pikastarttiopas sisältää yhden internetin eniten kopioiduista sääntölohkoista:

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

Firebase lisäsi ennen automaattisen 30 päivän vanhentumisajan näille säännöille. Se muuttui: nykyään säännöt säilyvät ikuisesti, ellei kehittäjä korvaa niitä. AI-koodaustyökalut — koulutettuina vuosien dokumentaatiolla, joka sisältää test-mode-lohkon — päästävät sen usein sanasta sanaan ja kertovat kehittäjälle "tämä on tietoturvasääntösi". Se ei ole.

Muita variantteja, jotka ilmenevät tuotannossa mutta ovat yhtä sallivia:

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

• Tulevaisuuden aikaleimavariantti: sääntö, joka sallii kaiken kauas tulevaisuuteen sijoittuvaan päivämäärään asti. Ei tehokkaasti vanhene koskaan (katso korostettu lohko yllä).
• allow read: if true; allow write: if request.auth != null; — julkiset luvut, kuka tahansa autentikoitu käyttäjä voi kirjoittaa.
• allow read, write: if request.auth != null; — kuka tahansa kirjautunut käyttäjä voi lukea tai kirjoittaa minkä tahansa dokumentin, mukaan lukien toisten käyttäjien dataa.

Mitä tehdä, kun skanneri löytää avoimen säännön

Avoimet Firebase-säännöt ovat ajonaikainen hätätilanne. Korjaus on samanmuotoinen kaikissa kolmessa palvelussa: rajaa jokainen sääntö request.auth.uid:lla eksplisiittistä omistaja-kenttää vastaan. Jokaisella palvelulla on oma sääntösyntaksinsa:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }. Polkusegmentin sidonta {userId} tulee ainoaksi dokumentiksi, johon käyttäjä voi koskea.

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; } } }. Konventio: tallenna tiedostot polun users/[uid]/[filename] alle ja anna polun pakottaa omistajuus.

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

Julkaise säännöt Firebase CLI:n kautta: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Verifioi uudet säännöt tuotannossa ajamalla FixVibe-skannaus uudelleen — baas.firebase-rules-löydöksen tulisi kadota.

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

Miten tämä vertautuu Firebasen sisäänrakennettuihin työkaluihin

Firebase Console näyttää nykyiset säännöt mutta ei tarkasta niitä ajonaikaista käyttäytymistä vastaan. Firebase Rules -simulaattorin avulla voit testata sääntölogiikkaa synteettisiä pyyntöjä vastaan — hyödyllistä mutta paikallista. Kumpikaan työkalu ei kerro, mitä tuotantosääntösi todellisuudessa palauttavat anonyymille hyökkääjälle julkisessa internetissä. Ulkoinen skanneri kuten FixVibe (tai Burp Suite manuaalisella konfiguroinnilla) on ainoa, joka tutkii samasta kulmasta kuin hyökkääjä. Googlen oma App Check lieventää väärinkäyttöä mutta ei korvaa oikein rajattuja sääntöjä.

Usein kysytyt kysymykset

Seuraavat askeleet

Aja ilmainen FixVibe-skannaus tuotanto-URL:ääsi vastaan — baas.firebase-rules-tarkistus tulee jokaisessa suunnitelmassa ja lippuu avoimet säännöt Firestoressa, Realtime Databasessa ja Cloud Storagessa. Syvempää selvitystä allow read, write: if true-kuviosta erityisesti varten katso Firebase allow read, write: if true selitettynä. Kokonaisnäkymää varten Supabasen, Firebasen, Clerkin ja Auth0:n yli lue BaaS-virhekonfiguraatioskanneri.