Правилата за сигурност на Firebase осигуряват подробен, наложен от сървъра механизъм за защита на данни във Firestore, база данни в реално време и облачно съхранение [S1]. Тъй като приложенията на Firebase често взаимодействат с тези облачни услуги директно от страна на клиента, тези правила представляват единствената бариера, предотвратяваща неоторизиран достъп до бекенд данните [S1].
Въздействие на разрешителните правила
Неправилно конфигурираните правила могат да доведат до значително излагане на данни [S2]. Ако правилата са настроени да бъдат прекалено разрешителни – например, като се използват настройките по подразбиране за „тестов режим“, които позволяват глобален достъп – всеки потребител с познания за идентификатора на проекта може да чете, променя или изтрива цялото съдържание на базата данни [S2]. Това заобикаля всички мерки за сигурност от страна на клиента и може да доведе до загуба на чувствителна потребителска информация или пълно прекъсване на услугата [S2].
Основна причина: Недостатъчна логика за оторизация
Основната причина за тези уязвимости обикновено е неуспехът да се приложат специфични условия, които ограничават достъпа въз основа на потребителска самоличност или ресурсни атрибути [S3]. Разработчиците често оставят активни конфигурации по подразбиране в производствени среди, които не валидират request.auth обект [S3]. Без оценка на request.auth, системата не може да направи разлика между легитимен удостоверен потребител и анонимен заявител [S3].
Техническо отстраняване
Осигуряването на Firebase среда изисква преминаване от отворен достъп към модел на принципал с най-малко привилегии.
- Прилагане на удостоверяване: Уверете се, че всички чувствителни пътища изискват валидна потребителска сесия, като проверите дали обектът
request.authне е null [S3]. - Прилагане на достъп, базиран на идентичност: Конфигурирайте правила, които сравняват UID на потребителя (
request.auth.uid) с поле в документа или самия идентификатор на документа, за да гарантирате, че потребителите могат да имат достъп само до собствените си данни [S3]. - Грануално определяне на обхвата на разрешенията: Избягвайте глобалните заместващи знаци за колекции. Вместо това, дефинирайте конкретни правила за всяка колекция и подколекция, за да минимизирате потенциалната повърхност за атака [S2].
- Проверка чрез Emulator Suite: Използвайте Firebase Emulator Suite, за да тествате правилата за сигурност локално. Това позволява проверка на логиката за контрол на достъпа срещу различни потребителски персони преди внедряване в среда на живо [S2].
Как FixVibe го тества
FixVibe вече включва това като BaaS сканиране само за четене. baas.firebase-rules извлича Firebase конфигурация от JavaScript пакети със същия произход, включително модерни форми на пакети initializeApp(...), след което проверява базата данни в реално време, Firestore и Firebase Storage с неавтентифицирани заявки само за четене. За Firestore първо се опитва списък на коренната колекция; когато списъкът е блокиран, той също така проверява общи чувствителни имена на колекции като users, accounts, customers, orders, payments, messages, admin и settings. Той отчита само успешни анонимни четения или списъци и не записва, изтрива или съхранява съдържание на клиентски документи.