Firebase Անվտանգության կանոնները ապահովում են հատիկավոր, սերվերի կողմից կիրառվող մեխանիզմ՝ պաշտպանելու տվյալները Firestore-ում, Realtime Database-ում և Cloud Storage [S1]-ում: Քանի որ Firebase հավելվածները հաճախ փոխազդում են այս ամպային ծառայությունների հետ անմիջապես հաճախորդի կողմից, այս կանոնները ներկայացնում են միակ խոչընդոտը, որը կանխում է չարտոնված մուտքը դեպի հետնամասի տվյալների [S1]:
Թույլատրելի կանոնների ազդեցությունը
Սխալ կազմաձևված կանոնները կարող են հանգեցնել տվյալների զգալի ազդեցության [S2]: Եթե կանոնները չափազանց թույլատրելի են, օրինակ՝ օգտագործելով լռելյայն «փորձարկման ռեժիմի» կարգավորումները, որոնք թույլ են տալիս գլոբալ հասանելիություն, նախագծի ID-ի իմացությամբ ցանկացած օգտվող կարող է կարդալ, փոփոխել կամ ջնջել տվյալների բազայի ամբողջ բովանդակությունը [S2]: Սա շրջանցում է հաճախորդի կողմից անվտանգության բոլոր միջոցները և կարող է հանգեցնել օգտվողի զգայուն տեղեկատվության կորստի կամ ծառայության ամբողջական խափանման [S2]:
Արմատային պատճառ. Անբավարար թույլտվության տրամաբանություն
Այս խոցելիության հիմնական պատճառը, որպես կանոն, հատուկ պայմանների կիրառման ձախողումն է, որոնք սահմանափակում են հասանելիությունը՝ հիմնված օգտվողի ինքնության կամ ռեսուրսի հատկանիշների վրա՝ [S3]: Մշակողները հաճախ թողնում են լռելյայն կազմաձևերը ակտիվ արտադրական միջավայրերում, որոնք չեն վավերացնում request.auth [S3] օբյեկտը: Առանց request.auth-ի գնահատման՝ համակարգը չի կարող տարբերակել օրինական վավերացված օգտատիրոջ և [S3] անանուն հայցողի միջև:
Տեխնիկական վերականգնում
Firebase միջավայրն ապահովելու համար անհրաժեշտ է բաց մուտքից անցնել նվազագույն արտոնությունների հիմնական մոդելին:
- Իրականացնել նույնականացումը. Համոզվեք, որ բոլոր զգայուն ուղիները պահանջում են վավեր օգտագործողի նստաշրջան՝ ստուգելով, թե արդյոք
request.authօբյեկտը զրոյական չէ [S3]: - Իրականացնել ինքնության վրա հիմնված մուտք. կարգավորեք կանոններ, որոնք համեմատում են օգտվողի UID-ը (
request.auth.uid) փաստաթղթի դաշտի կամ հենց փաստաթղթի ID-ի հետ, որպեսզի համոզվեք, որ օգտվողները կարող են մուտք գործել միայն իրենց սեփական տվյալները [S3]: - Թույլտվության հատիկավոր շրջանակը. Խուսափեք հավաքածուների համար գլոբալ բնագրերից: Փոխարենը, սահմանեք հատուկ կանոններ յուրաքանչյուր հավաքածուի և ենթահավաքածուի համար՝ նվազագույնի հասցնելու հավանական հարձակման մակերեսը [S2]:
- Վավերացում Emulator Suite-ի միջոցով. Օգտագործեք Firebase Emulator Suite-ը՝ տեղական անվտանգության կանոնները ստուգելու համար: Սա թույլ է տալիս ստուգել մուտքի վերահսկման տրամաբանությունը տարբեր օգտատերերի դեմ նախքան [S2] կենդանի միջավայրում տեղակայելը:
Ինչպես է FixVibe-ն փորձարկում դրա համար
FixVibe-ն այժմ ներառում է սա որպես միայն կարդալու BaaS սկանավորում: baas.firebase-rules-ն քաղում է Firebase կոնֆիգուրացիան նույն ծագման JavaScript փաթեթներից, ներառյալ ժամանակակից initializeApp(...) փաթեթների ձևերը, այնուհետև ստուգում է Realtime Database-ը, Firestore-ը և ZXCOKVENFIX-ը BXCV1uthentic-ով: միայն կարդալու հարցումներ. Firestore-ի համար այն նախ փորձում է արմատային հավաքածուի ցուցակը; երբ ցուցակագրումն արգելափակված է, այն նաև ուսումնասիրում է ընդհանուր զգայուն հավաքածուների անունները, ինչպիսիք են users, accounts, customers, orders, users, messages, admin և settings: Այն հաղորդում է միայն հաջողված անանուն ընթերցումների կամ ցանկերի մասին և չի գրում, ջնջում կամ պահում հաճախորդի փաստաթղթերի բովանդակությունը: