Google Firebase, geliştiricilerin interaktif web ve mobil uygulamalar sorunsuz bir şekilde oluşturmalarını sağlayan birkaç yerleşik bileşen ve hizmet sunan popüler bir arka uç uygulama geliştirme platformudur. Ancak herhangi bir geliştirme platformunda ve çerçevede olduğu gibi, güvenlik her zaman zor olduğunu kanıtlar. Firebase Firestore’u kullanan Çay Arkadaş uygulamasını içeren son veri ihlali olayı, güvenliğin kavramanın zorlaştığını kanıtlıyor.
Bu makalede, Google Firebase Firestore veya depolama alanını aktif olarak kullanan hedeflerdeki en yaygın güvenlik yanlış yapılandırmalarını ele alacağız.
Hadi dalalım!
Google Firebase, Google’ın sahip olduğu, Hizmet Olarak Arka Uç (BAAS) işlevselliği sağlayan kapsamlı bir uygulama geliştirme platformudur. Geliştiricilerin sunucu altyapılarını yönetmeden etkileşimli web ve mobil uygulamalar oluşturmalarını sağlar. Hizmetler arasında kimlik doğrulama, depolama analizi ve uygulama barındırma bulunur.
Bu makale boyunca ana odağımızı iki hizmete koyacağız:
-
Firebase Firestore: Uygulama verilerini istemciler arasında gerçek zamanlı olarak saklamak ve senkronize etmek için NoSQL belge veritabanı.
-
Firebase Depolama: Görüntüler, videolar ve dosyalar gibi kullanıcı tarafından oluşturulan içeriği depolamak ve sunmak için bir bulut depolama hizmeti.
Her iki hizmet de daha derin dalış yapmak istediğimiz yerleşik güvenlik erişim kontrol kuralları sağlar.
Firebase Güvenlik Kuralları
Firebase Güvenlik Kuralları, Firebase kaynaklarınıza ve hangi koşullar altında kimin erişebileceğini tanımlayan bir bildirici yapılandırma dilidir. Firebase hizmetleri için birincil güvenlik mekanizması olarak hareket ederler, esasen verilerinize erişime izin vermeden veya reddetmeden önce her isteği değerlendiren bir sunucu tarafı güvenlik duvarı olarak işlev görür.
Örneğin, Firebase Firestore’da, güvenlik kuralları hangi kullanıcıların NoSQL veritabanınızda belgeleri ve koleksiyonları okuyabileceğini, yazabileceğini, güncelleyebileceğini veya silebileceğini belirler. Firebase depolama için, güvenlik kuralları benzer bir koruyucu işleve hizmet eder, ancak veritabanı işlemlerinden ziyade dosya işlemlerine odaklanır. Depolama kovalarınızdaki dosyaları kimin yükleyebileceğini, indirebileceğini, değiştirebileceğini veya silebileceğini kontrol ederler.
Bu sunucu tarafı uygulama çok önemlidir, çünkü yalnızca istemci tarafı doğrulamasına veya API seviyesindeki kontrollere güvenmek temelde güvensizdir. Saldırganlar uygulamanızı tamamen atlayabilir ve istekleri doğrudan Firebase’in dinlenme API’lerine gönderebilir veya arka uç hizmetlerinizle etkileşim kurmak için Firebase SDK’larını kullanabilir.
Benzer bir etkinlik birkaç hafta önce çay flört uygulaması ile oldu. Firebase’i teknoloji yığınlarında aktif olarak kullanan hedefleri nasıl tespit edeceğinizi öğrenelim, çünkü bu her zaman basit bir süreç değildir.
Hedefinize bağlı tüm Firebase projelerini düzgün bir şekilde tanımlamak için birden fazla keşif yöntemini birleştirmemiz gerekecek. Bazı geliştiriciler, Firebase REST API’sına doğrudan istemci tarafından bağlantıları başlatmaktan kaçınmak için ters bir proxy kullanır.
HTTP isteklerini incelemek
Hedefinizdeki ateş tabanına parmak izi için en basit yaklaşım, giden HTTP isteklerini incelemektir. Bazı durumlarda, istemci tarafı ile Firebase’in REST API’sı arasında bir sunucu dağıtmadan Firebase Hizmetlerinden yararlanan hedeflerle karşılaşacaksınız.
Bu durumda, ağ sekmenizi geliştirici araçları veya seçtiğiniz proxy önleme alacınız altında açabilir ve *.firebaseio.com ve .firebaseapp.com adresine HTTP isteklerini inceleyebilirsiniz. Bu yöntem aynı zamanda erişim kontrolleri için testlere devam ettiğimizde önemli bir adım olan olası dinlenme API uç noktalarını numaralandırmamıza izin verecektir.
JavaScript dosyalarını incelemek
JavaScript dosyaları genellikle proje kimliği, veritabanı URL’si dahil olmak üzere Firebase yapılandırma verileri içerir ( *.firebaseio.comdepolama kovası (işaret ediyor firebasestorage.app), vb. Bu veriler, eksik erişim kontrollerini test etmek için Firebase’s Rest API ile iletişim kurmak istediğimizde çok önemlidir.
Firebase proje yapılandırmasına sahip bir JavaScript dosyası örneği
Okuma İpucu: JavaScript dosyaları böcek ödül avcıları için bir altın madeni! Daha fazla güvenlik açığı bulmak için JavaScript dosyalarını nasıl düzgün bir şekilde analiz edeceğiniz ve test edeceğiniz hakkında daha fazla bilgi edinin.
Google ve Github Dorking
Firebase Firestore ve Depolama, her türlü veri manipülasyon işlemini gerçekleştirmek için iletişim kurabileceğiniz bir REST API’sını sağlar. Bunlar daha sonraki sırada barındırılır firebaseio.com Ve firebasestorage.app alan adları.
Basit bir Google veya GitHub kod aramasıyla, hedefimizin test edebileceğimiz herhangi bir etkin Firebase projesi olup olmadığını kolayca kontrol edebiliriz:
site:.firebaseio.com "" Veya:
(site:.firebasestorage.app OR site:.appspot.com) "" Şimdi Firebase hizmetlerini aktif olarak kullanan hedefleri nasıl başarılı bir şekilde bulacağımızı ve tanımlayacağınızı öğrendik. Eksik erişim kontrolleri ve diğer güvenlik yanlış yapılandırmalarını nasıl test edeceğine daha derin dalış yapmaya devam edelim.
Bu makalede daha önce belgelediğimiz gibi, Firebase Firestore (NoSQL veritabanı) ve depolama, uygun erişim kontrollerini doğrulamak için Firebase güvenlik kurallarına güvenmektedir. Geliştiricilerin, JavaScript’e benzer bir programlama dilinde, belirli Firebase kaynaklarına erişebilen ve hangi koşullar altında tanımlamasına izin verirler. Bunlar eksik veya uygunsuz bir şekilde yapılandırıldığında, muhtemelen istediğimizden daha fazla veri okumamıza, oluşturmamıza veya silmemize izin verebilir.
Eksik erişim kontrolleri için test yaparken, testlerinizi doğrudan Firebase’in REST API’sına karşı gerçekleştirmeniz gerektiğini belirtmek gerekir. Ek olarak, Firebase kurallarının uygulama şekli nedeniyle (Varsayılan Redd), kimlik bilgileri olan ve kimlik bilgileri olmayan erişim kontrollerini test etmeliyiz. Pratik olarak, bu, anonim bir navigatör (kimlik bilgileri olmadan) ve kimlik doğrulamalı (girişli) bir kullanıcı olarak erişimi test etmemiz gerektiği anlamına gelir.
Firebase güvenlik kuralları ayrıntılı olduğundan ve geliştiricilerin kaynak başına güvenlik koşullarını belirtmelerine izin verdiğinden (dosya, veritabanı, veritabanı toplama, vb.) Tüm uç noktaları ayrı ayrı test ettiğimizden emin olmalıyız.
Eksik okuma erişim kontrolleri için test
Aşırı hizmetli bir Firebase güvenlik kuralının temel bir örneğiyle başlayalım. Sorunu aşağıdaki kuralda bulabilir misiniz?
Yanlış yapılandırılmış bir Firebase Firestore Güvenlik Kuralı Tanımı örneği
Yukarıdaki kod snippet’inde, tüm erişimin varsayılan olarak kısıtlandığını görebiliriz. Ancak, /contact-form-data Endpoint yeterince korunmaz ve herkesin hassas iletişim bilgileri içeren iletişim formu sorularını okumasına izin verir.
Bu basit genel gider, geliştiricinin sayfa ziyaretçilerinin bir iletişim sorgusu formu göndermeleri için oluşturulduğunu, okuduğunu, güncellemesini ve silme erişimini düşündüğü bir mantık hatasından kaynaklanmaktadır.
Uygulamada, aşağıdaki uç noktalardan birini ziyaret edebilir ve tüm verileri okuyabiliriz:
https://firestore.googleapis.com/v1/projects//databases/(default)/documents/contact-form-data Yanlış yapılandırılmış bir Firebase Firestore örneği örneği
Eksik Oluştur ve Yazma Erişim Denetimleri için Test
Firebase Firestore ve Depolama 4 Veri Manipülasyon İşlemlerini Destekleyin: CBirleştirmek READ, UPdate (yaz) ve Delete. Hedefimizi ‘Oluştur’ yöntemi için eksik erişim kontrollerine karşı test etmek istediğimizi varsayalım.
Bir örneğe bir göz atalım:
Yanlış yapılandırılmış bir Firebase Firestore Güvenlik Kuralı Tanımı örneği
Yukarıdaki Firebase kuralları yapılandırmasında 3 sorun bulabiliriz:
-
Son nokta
/admin-mgmt/productsYalnızca kimlik doğrulama kontrolleri gerçekleştirir (yetkilendirme doğrulaması yok) -
Son nokta
/admin-mgmt/discount-codesKullanıcı rolü ise okumaya, oluşturmaya ve erişimi silinadminveyamaintainerkimlik doğrulama nesnesinde. -
Son nokta
/users/profileeklenmeden önce herhangi bir veri doğrulaması gerçekleştirmez, (kimlik doğrulamalı bir kullanıcı olarak) tercih edilen bir kullanıcı rolü atamamıza veya eklememize izin verir.
İlk kusur, doğrulanmış herhangi bir kullanıcı olarak yeni ürünler oluşturmamızı sağlar. Aşağıdaki HTTP isteğini çoğaltmak, esasen hedefimizin web mağazasının ön planında görülebilecek yeni bir ürün oluşturacaktır.
POST /v1/projects//databases/(default)/documents/admin-mgmt/products HTTP/2
Host: firestore.googleapis.com
Content-Type: application/json
Authorization: Bearer USER_ID
Content-Length: 336
{
"fields": {
"name": {
"stringValue": "New Product"
},
"price": {
"doubleValue": 9999.99
},
"description": {
"stringValue": "This product was created by an unauthorized user"
},
"category": {
"stringValue": "intigriti"
},
"inStock": {
"booleanValue": true
}
}
} Ayrıca, Firebase Güvenlik Kuralları yapılandırmasından, uç nokta /kullanıcı /profilin herhangi bir veri doğrulaması gerçekleştirmediğine neden olabiliriz. Bu muhtemelen geliştiricilerin, taleplerimizi doğrudan Firbase REST API’sına göndererek tüm doğrulamadan kolayca kaçabileceğimiz için, tüm veri doğrulamasını gerçekleştiren bir API yerinde olduğu anlamına gelir.
İle kombinasyon halinde /admin-mgmt/discount-codesaslında ödeme sayfasında çalışacak indirim kodlarımızı ekleyebiliriz.
İstek 1: Profilimizi gerekli kullanıcı rollerini içerecek şekilde güncellemek
PATCH /v1/projects//databases/(default)/documents/users/profile/ HTTP/2
Host: firestore.googleapis.com
Content-Type: application/json
Authorization: Bearer
Content-Length: 308
{
"fields": {
"name": {
"stringValue": "Intigriti Example"
},
"email": {
"stringValue": "[email protected]"
},
"roles": {
"arrayValue": {
"values": [
{"stringValue": "admin"},
{"stringValue": "maintainer"}
]
}
}
}
} İstek 2: Yeni indirim kodları ekleme
POST /v1/projects//databases/(default)/documents/admin-mgmt/discount-codes HTTP/2
Host: firestore.googleapis.com
Content-Type: application/json
Authorization: Bearer
Content-Length: 308
{
"fields": {
"code": {
"stringValue": "INTIGRITI1337"
},
"discount": {
"doubleValue": 1337.0
},
"expiryDate": {
"timestampValue": "2025-12-31T23:59:59Z"
},
"usageLimit": {
"integerValue": 1
},
"isActive": {
"booleanValue": true
}
}
} Eksik Sil erişim kontrolleri için test
Başka bir örneği ele alalım. Kullanıcıların profil resmini kolayca eklemelerine ve kaldırmalarına yardımcı olmak için aşağıdaki Firebase güvenlik kuralları uygulanır.
Yanlış yapılandırılmış bir Firebase Firestore Güvenlik Kuralı Tanımı örneği
Bu yapılandırmada, sahiplik doğrulamasının kusurlu olduğunu ve metadata.userId Dosya yüklemesi sırasında kaynağı da silebilir. Bu durumda, bir geliştiricinin oluşturma ve yazma erişimine uygun giriş doğrulaması getirmesi gerekecektir.
Her iki Firebase hizmetinde ormanlar arası kaynak paylaşımı desteklenmektedir. Firebase Firestore, herhangi bir kaynağın istendiği gibi REST API’sına bağlanmasına izin verir. Ancak, Firebase Storage, geliştiricilerin özel bir yapılandırma dosyasında bildirmesi gereken bir dizi kuralla çalışır.
Bu kurallar aşırı derecede izin verildiğinde, örneğin, geliştirme sırasında, herhangi bir istenmeyen kökenin depolama kovasına istekte bulunmasına izin verilecektir. Bu, daha yüksek şiddetli sorunlara daha fazla silahlanabilecek potansiyel güvenlik kusurlarını tanıtabilir.
Firebase Depolama alanında aşırı tutarsız bir CORS politikası örneği
Okuma İpucu: Modern uygulamalarda CORS yanlış yapılandırmalarını nasıl silahlandıracağınızı öğrenin.
Muhtemelen aktif olarak Firebase Firestore/Depolama, hatta yanlış yapılandırılmış bir hedef kullanan bir hedefle karşılaştınız ve bunları daha önce görmezden gelirseniz, bu makalenin bu iki hizmette bulunan en yaygın güvenlik yanlış yapılandırmalarına biraz ışık tutmasını umuyoruz.
Bu nedenle, Firebase Firestore/Depolama’daki güvenlik yanlış yapılandırmaları hakkında yeni bir şey öğrendiniz… Şu anda, becerilerinizi test etme zamanı! Savunmasız laboratuvarlarda pratik yaparak başlayabilir veya … Intigriti’deki 70+ genel hata ödül programlarımıza göz atabilirsiniz ve belki de bir sonraki gönderiminizde bir ödül kazanırsınız!
Bugün Intigriti’de hacklemeye başlayın