Firebase უსაფრთხოების წესები უზრუნველყოფს გრანულურ, სერვერზე დანერგილ მექანიზმს, რათა დაიცვან მონაცემები Firestore-ში, რეალურ დროში მონაცემთა ბაზაში და Cloud Storage [S1]. იმის გამო, რომ Firebase აპლიკაციები ხშირად ურთიერთქმედებენ ამ ღრუბლოვან სერვისებთან უშუალოდ კლიენტის მხრიდან, ეს წესები წარმოადგენს ერთადერთ ბარიერს, რომელიც ხელს უშლის არაავტორიზებული წვდომის უკანონო მონაცემებზე [S1].
ნებადართული წესების გავლენა
არასწორად კონფიგურირებულმა წესებმა შეიძლება გამოიწვიოს მონაცემთა მნიშვნელოვანი ექსპოზიცია [S2]. თუ წესები დაყენებულია ზედმეტად დასაშვებად - მაგალითად, ნაგულისხმევი "ტესტის რეჟიმის" პარამეტრების გამოყენებით, რომლებიც გლობალურ წვდომას იძლევა - ნებისმიერ მომხმარებელს, რომელმაც იცის პროექტის ID, შეუძლია წაიკითხოს, შეცვალოს ან წაშალოს მონაცემთა ბაზის მთლიანი შინაარსი [S2]. ეს გვერდს უვლის კლიენტის მხრიდან უსაფრთხოების ყველა ზომას და შეიძლება გამოიწვიოს მომხმარებლის სენსიტიური ინფორმაციის დაკარგვა ან სერვისის სრული შეფერხება [S2].
ძირეული მიზეზი: არასაკმარისი ავტორიზაციის ლოგიკა
ამ დაუცველობის ძირითადი მიზეზი, როგორც წესი, არის კონკრეტული პირობების შეუსრულებლობა, რომლებიც ზღუდავს წვდომას მომხმარებლის ვინაობის ან რესურსის ატრიბუტების [S3] საფუძველზე. დეველოპერები ხშირად ტოვებენ ნაგულისხმევ კონფიგურაციებს აქტიურ საწარმოო გარემოში, რომლებიც არ ადასტურებენ request.auth ობიექტს [S3]. request.auth შეფასების გარეშე სისტემა ვერ განასხვავებს ლეგიტიმურ ავტორიზებულ მომხმარებელსა და ანონიმურ მთხოვნელს [S3].
ტექნიკური გამოსწორება
Firebase გარემოს დაცვა მოითხოვს ღია წვდომიდან უმცირეს პრივილეგიის ძირითად მოდელზე გადასვლას.
- Authentication-ის აღსრულება: დარწმუნდით, რომ ყველა მგრძნობიარე გზა მოითხოვს მომხმარებლის მოქმედ სესიას, შემოწმებით, არის თუ არა
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-თან ერთად მხოლოდ წაკითხვადი მოთხოვნები. Firestore-ისთვის ის ჯერ ცდის root კოლექციის ჩამონათვალს; როდესაც ჩამონათვალი დაბლოკილია, ის ასევე იკვლევს საერთო მგრძნობიარე კოლექციების სახელებს, როგორიცაა users, accounts, customers, orders, users, messages, admin და settings. ის იტყობინება მხოლოდ წარმატებულ ანონიმურ წაკითხვებს ან განცხადებებს და არ წერს, წაშლის ან ინახავს მომხმარებლის დოკუმენტის შინაარსს.