اسکنر قوانین Firebase: یافتن قوانین باز Firestore، Realtime Database و Storage

اسکنر چگونه قوانین باز Firebase را پیدا می‌کند

سرویس‌های Firebase اشکال URL شناخته‌شده و قابل پیش‌بینی را در دسترس قرار می‌دهند. یک اسکنر بدون اعتبارنامه می‌تواند هر یک را پروب کند و مشاهده کند آیا خواندن‌های ناشناس موفق می‌شوند یا نه. فحص baas.firebase-rules در FixVibe در سه پروب مستقل اجرا می‌شود — یکی به‌ازای هر سرویس 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 قابل فهرست شدن است. ذخیره‌سازی قابل فهرست شدن یک یافته است حتی وقتی دانلودهای فردی فایل رد شوند — مهاجمان سطل را برای یافتن نام‌های قابل حدس فهرست می‌کنند.

footgun حالت آزمایشی واقعاً چه شکلی است

مستندات quickstart در Firebase یکی از پرکپی‌شده‌ترین بلوک‌های قانون در اینترنت را شامل می‌شود:

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

Firebase قبلاً یک انقضای خودکار ۳۰ روزه روی این قوانین اضافه می‌کرد. این تغییر کرد: امروز قوانین تا زمانی که توسعه‌دهنده آن‌ها را جایگزین نکند، برای همیشه باقی می‌مانند. ابزارهای کدنویسی هوش مصنوعی — که روی سال‌ها مستنداتی که شامل بلوک حالت آزمایشی هستند آموزش دیده‌اند — اغلب آن را verbatim تولید می‌کنند و به توسعه‌دهنده می‌گویند "این قانون امنیت شماست". این‌طور نیست.

گونه‌های دیگری که در تولید ظاهر می‌شوند ولی به همان اندازه بازگذاشته هستند:

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

• یک گونه با timestamp آینده: قانونی که همه چیز را تا یک تاریخ دور در آینده اجازه می‌دهد. عملاً هرگز منقضی نمی‌شود (بلوک هایلایت‌شده بالا را ببینید).
• 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; }. اتصال path-segment {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;
    }
  }
}

قوانین را از طریق Firebase CLI مستقر کنید: 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 خود گوگل از سوءاستفاده جلوگیری می‌کند ولی جایگزین قوانین درست‌محدودشده نیست.

سؤالات متداول

گام‌های بعدی

یک اسکن رایگان 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 را بخوانید.