Сканер правіл Firebase: знайдзіце адкрытыя правілы Firestore, Realtime Database і Storage

Як сканер знаходзіць адкрытыя правілы Firebase

Сэрвісы Firebase раскрываюць добра вядомыя, прадказальныя формы URL. Сканер без уліковых дадзеных можа зандаваць кожны і назіраць, ці ўдаюцца ананімныя чытанні. Праверка FixVibe baas.firebase-rules запускаецца ў трох незалежных зондах — па адным на кожны сэрвіс Firebase:

• <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. Сканер зандуе https://[project-id]-default-rtdb.firebaseio.com/.json. Калі корань чытаецца ананімна, адказ — гэта ўсё дрэва базы дадзеных у JSON. Больш кансерватыўны тэст запытвае .json?shallow=true, які вяртае толькі ключы верхняга ўзроўню — знаходка ў любым выпадку.
• Cloud Storage. Сканер запытвае https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o. Калі адказ пералічвае імёны файлаў без аўтэнтыфікацыі, сховішча anon-пералічальнае. Пералічальнае сховішча — гэта знаходка, нават калі ўзятыя загрузкі асобных файлаў адхіляюцца — зламыснікі пералічваюць сховішча, каб знайсці ўгадваемыя імёны файлаў.

Як выглядае гэты падвох тэставага рэжыму

Дакументацыя хуткага старту Firebase змяшчае адзін з найбольш капіруемых блокаў правіл у інтэрнэце:

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

Раней Firebase дадаваў аўтаматычны 30-дзённы тэрмін дзеяння на гэтыя правілы. Гэта змянілася: сёння правілы захоўваюцца назаўжды, калі распрацоўшчык іх не заменіць. ШІ-інструменты кадавання — навучаныя на гадах дакументацыі, якая ўключае блок тэставага рэжыму — часта выпускаюць яго даслоўна і кажуць распрацоўшчыку "гэта ваша правіла бяспекі". Гэта не так.

Іншыя варыянты, якія з'яўляюцца ў прадакшэне, але аднолькава дазвольныя:

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

• Варыянт з будучай часавай меткай: правіла, якое дазваляе ўсё да даты ў далёкай будучыні. Ніколі эфектыўна не сканчае дзеянне (гл. падсветлены блок вышэй).
• allow read: if true; allow write: if request.auth != null; — публічныя чытанні, любы аўтэнтыфікаваны карыстальнік можа пісаць.
• allow read, write: if request.auth != null; — любы карыстальнік, які ўвайшоў, можа чытаць або пісаць любы дакумент, у тым ліку дадзеныя іншых карыстальнікаў.

Што рабіць, калі сканер знаходзіць адкрытае правіла

Адкрытыя правілы Firebase — гэта надзвычайная сітуацыя ў часе выканання. Выпраўленне мае тую ж форму ва ўсіх трох сэрвісах: абмяжуйце кожнае правіла request.auth.uid супраць відавочнага поля ўладальніка. Кожны сэрвіс мае свой сінтаксіс правіл:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }. Прывязка сегмента шляху {userId} становіцца адзіным дакументам, да якога карыстальнік можа дакранацца.

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; } } }. Канвенцыя: захоўвайце файлы пад users/[uid]/[filename] і дазвольце шляху забяспечваць валоданне.

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

Разгарніце правілы праз CLI Firebase: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Пацвердзіце, што новыя правілы знаходзяцца ў прадакшэне, паўторна запусціўшы сканаванне FixVibe — знаходка baas.firebase-rules павінна знікнуць.

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

Як гэта параўноўваецца з убудаванымі інструментамі Firebase

Кансоль Firebase паказвае вам бягучыя правілы, але не правярае іх супраць паводзін у часе выканання. Сімулятар правіл Firebase дазваляе вам тэставаць логіку правіл супраць сінтэтычных запытаў — карысна, але лакальна. Ніводны інструмент не паведамляе вам, што вашы прадукцыйныя правілы насамрэч вяртаюць ананімнаму зламысніку ў публічным інтэрнэце. Знешні сканер, такі як FixVibe (або Burp Suite з ручной канфігурацыяй), — гэта адзінае, што зандуе пад тым самым вуглом, што і зламыснік. Уласны App Check ад Google змякчае злоўжыванне, але не замяняе правільна абмежаваныя правілы.

Часта задаваныя пытанні

Наступныя крокі

Запусціце бясплатнае сканаванне FixVibe супраць вашага прадукцыйнага URL — праверка baas.firebase-rules пастаўляецца на кожным тарыфе і пазначае адкрытыя правілы ў Firestore, Realtime Database і Cloud Storage. Для больш глыбокага тлумачэння канкрэтна пра шаблон allow read, write: if true гл. Firebase allow read, write: if true растлумачана. Для агульнага агляду па Supabase, Firebase, Clerk і Auth0 прачытайце Сканер няправільных налад BaaS.