Translated ['src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting

src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md

@@ -9,7 +9,7 @@
 Google Workspace का डोमेन-वाइड डेलीगेशन एक पहचान वस्तु, या तो एक **बाहरी ऐप** जो Google Workspace मार्केटप्लेस से है या एक आंतरिक **GCP सेवा खाता**, को **उपयोगकर्ताओं की ओर से Workspace में डेटा तक पहुंचने** की अनुमति देता है।
 
 > [!NOTE]
-> इसका मतलब यह है कि **GCP परियोजनाओं** के भीतर **सेवा खाते** एक संगठन के Workspace उपयोगकर्ताओं की **नकल** कर सकते हैं (या यहां तक कि किसी अन्य से भी)।
+> इसका मतलब यह है कि **GCP परियोजनाओं** के अंदर **सेवा खाते** एक संगठन के **Workspace उपयोगकर्ताओं** की नकल कर सकते हैं (या यहां तक कि किसी अलग संगठन के भी)।
 
 इसकी कार्यप्रणाली के बारे में अधिक जानकारी के लिए देखें:
 
@@ -19,14 +19,14 @@ gcp-understanding-domain-wide-delegation.md
 
 ### मौजूदा डेलीगेशन का समझौता
 
-यदि एक हमलावर ने **GCP पर कुछ पहुंच का समझौता किया** और **कंपनी के एक मान्य Workspace उपयोगकर्ता का ईमेल** (अधिमानतः **सुपर एडमिन**) जानता है, तो वह **सभी परियोजनाओं की सूची बना सकता है** जिन तक उसे पहुंच है, **परियोजनाओं के सभी SAs की सूची बना सकता है**, यह जांच सकता है कि उसे **कौन से सेवा खातों तक पहुंच है**, और **हर SA के साथ इन सभी चरणों को दोहरा सकता है** जिसे वह नकल कर सकता है।\
-उसके पास **सभी सेवा खातों की एक सूची** और **Workspace** **ईमेल** की सूची होने पर, हमलावर **प्रत्येक सेवा खाते के साथ उपयोगकर्ता की नकल करने** की कोशिश कर सकता है।
+यदि एक हमलावर ने **GCP पर कुछ पहुंच का समझौता किया** और **कंपनी के एक मान्य Workspace उपयोगकर्ता ईमेल** (अधिमानतः **सुपर एडमिन**) को जानता है, तो वह **सभी परियोजनाओं की सूची बना सकता है** जिन तक उसे पहुंच है, **परियोजनाओं के सभी SAs की सूची बना सकता है**, यह जांच सकता है कि उसे **कौन से सेवा खातों तक पहुंच है**, और **हर SA के साथ इन सभी चरणों को दोहरा सकता है** जिसे वह नकल कर सकता है।\
+एक **सेवा खातों की पूरी सूची** और **Workspace** **ईमेल्स** के साथ, हमलावर **प्रत्येक सेवा खाते के साथ उपयोगकर्ता की नकल करने** की कोशिश कर सकता है।
 
 > [!CAUTION]
-> ध्यान दें कि डोमेन वाइड डेलीगेशन को कॉन्फ़िगर करते समय किसी Workspace उपयोगकर्ता की आवश्यकता नहीं होती है, इसलिए बस जान लें कि **एक मान्य उपयोगकर्ता नकल के लिए पर्याप्त और आवश्यक है**।\
+> ध्यान दें कि डोमेन वाइड डेलीगेशन को कॉन्फ़िगर करते समय किसी Workspace उपयोगकर्ता की आवश्यकता नहीं होती है, इसलिए बस जानें कि **एक मान्य उपयोगकर्ता नकल के लिए पर्याप्त और आवश्यक है**।\
 > हालाँकि, **नकली उपयोगकर्ता के विशेषाधिकारों का उपयोग किया जाएगा**, इसलिए यदि यह सुपर एडमिन है तो आप सब कुछ एक्सेस कर सकेंगे। यदि इसके पास कोई पहुंच नहीं है तो यह बेकार होगा।
 
-#### [GCP जनरेट डेलीगेशन टोकन](https://github.com/carlospolop/gcp_gen_delegation_token)
+#### [GCP Generate Delegation Token](https://github.com/carlospolop/gcp_gen_delegation_token)
 
 यह सरल स्क्रिप्ट **नियुक्त उपयोगकर्ता के रूप में एक OAuth टोकन उत्पन्न करेगी** जिसे आप फिर अन्य Google APIs तक पहुंचने के लिए उपयोग कर सकते हैं, चाहे `gcloud` के साथ हो या बिना:
 ```bash
@@ -41,17 +41,17 @@ python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-ke
 यह एक उपकरण है जो निम्नलिखित चरणों का पालन करके हमले को अंजाम दे सकता है:
 
 1. **GCP प्रोजेक्ट्स की गणना करें** Resource Manager API का उपयोग करके।
-2. प्रत्येक प्रोजेक्ट संसाधन पर इटरेट करें, और **GCP सेवा खाता संसाधनों की गणना करें** जिन तक प्रारंभिक IAM उपयोगकर्ता की पहुंच है _GetIAMPolicy_ का उपयोग करके।
-3. **प्रत्येक सेवा खाता भूमिका पर इटरेट करें**, और लक्षित सेवा खाता संसाधन पर _**serviceAccountKeys.create**_ अनुमति के साथ अंतर्निहित, बुनियादी, और कस्टम भूमिकाएँ खोजें। यह ध्यान रखना चाहिए कि संपादक भूमिका स्वाभाविक रूप से इस अनुमति को रखती है।
-4. प्रत्येक सेवा खाता संसाधन के लिए एक **नया `KEY_ALG_RSA_2048`** निजी कुंजी बनाएं जो IAM नीति में प्रासंगिक अनुमति के साथ पाया गया है।
-5. **प्रत्येक नए सेवा खाते पर इटरेट करें और इसके लिए एक `JWT`** **ऑब्जेक्ट** बनाएं जो SA निजी कुंजी क्रेडेंशियल्स और एक OAuth स्कोप से बना है। एक नया _JWT_ ऑब्जेक्ट बनाने की प्रक्रिया **oauth_scopes.txt** सूची से सभी मौजूदा OAuth स्कोप के संयोजनों पर **इटरेट** करेगी, ताकि सभी प्रतिनिधित्व संभावनाओं को खोजा जा सके। सूची **oauth_scopes.txt** को उन सभी OAuth स्कोप के साथ अपडेट किया गया है जो हमने Workspace पहचानियों का दुरुपयोग करने के लिए प्रासंगिक पाया है।
-6. `_make_authorization_grant_assertion` विधि एक लक्षित कार्यक्षेत्र उपयोगकर्ता, जिसे _subject_ के रूप में संदर्भित किया गया है, को JWTs उत्पन्न करने के लिए घोषित करने की आवश्यकता को प्रकट करती है। जबकि यह एक विशिष्ट उपयोगकर्ता की आवश्यकता प्रतीत हो सकती है, यह समझना महत्वपूर्ण है कि **DWD एक डोमेन के भीतर हर पहचान को प्रभावित करता है**। परिणामस्वरूप, **किसी भी डोमेन उपयोगकर्ता** के लिए JWT बनाना उस डोमेन में सभी पहचानों को प्रभावित करता है, जो हमारे संयोजन गणना जांच के अनुरूप है। सीधे शब्दों में कहें, एक मान्य Workspace उपयोगकर्ता आगे बढ़ने के लिए पर्याप्त है।\
-इस उपयोगकर्ता को DeleFriend के _config.yaml_ फ़ाइल में परिभाषित किया जा सकता है। यदि लक्षित कार्यक्षेत्र उपयोगकर्ता पहले से ज्ञात नहीं है, तो उपकरण GCP प्रोजेक्ट्स पर भूमिकाओं के साथ डोमेन उपयोगकर्ताओं को स्कैन करके मान्य कार्यक्षेत्र उपयोगकर्ताओं की स्वचालित पहचान की सुविधा प्रदान करता है। यह ध्यान रखना महत्वपूर्ण है (फिर से) कि JWTs डोमेन-विशिष्ट होते हैं और हर उपयोगकर्ता के लिए उत्पन्न नहीं होते; इसलिए, स्वचालित प्रक्रिया प्रति डोमेन एक अद्वितीय पहचान को लक्षित करती है।
+2. प्रत्येक प्रोजेक्ट संसाधन पर पुनरावृत्ति करें, और **GCP सेवा खाता संसाधनों की गणना करें** जिन तक प्रारंभिक IAM उपयोगकर्ता की पहुंच है _GetIAMPolicy_ का उपयोग करके।
+3. **प्रत्येक सेवा खाता भूमिका पर पुनरावृत्ति करें**, और लक्षित सेवा खाता संसाधन पर _**serviceAccountKeys.create**_ अनुमति के साथ अंतर्निहित, बुनियादी, और कस्टम भूमिकाएँ खोजें। यह ध्यान रखना चाहिए कि संपादक भूमिका स्वाभाविक रूप से इस अनुमति को रखती है।
+4. प्रत्येक सेवा खाता संसाधन के लिए **नया `KEY_ALG_RSA_2048`** निजी कुंजी बनाएं जो IAM नीति में प्रासंगिक अनुमति के साथ पाया गया है।
+5. **प्रत्येक नए सेवा खाते पर पुनरावृत्ति करें और इसके लिए एक `JWT`** **ऑब्जेक्ट** बनाएं जो SA निजी कुंजी क्रेडेंशियल्स और एक OAuth स्कोप से बना होता है। नए _JWT_ ऑब्जेक्ट को बनाने की प्रक्रिया **oauth_scopes.txt** सूची से सभी मौजूदा OAuth स्कोप के संयोजनों पर पुनरावृत्ति करेगी, ताकि सभी प्रतिनिधित्व संभावनाओं को खोजा जा सके। सूची **oauth_scopes.txt** को उन सभी OAuth स्कोप के साथ अपडेट किया गया है जो हमने Workspace पहचानियों का दुरुपयोग करने के लिए प्रासंगिक पाया है।
+6. `_make_authorization_grant_assertion` विधि एक लक्षित कार्यक्षेत्र उपयोगकर्ता, जिसे _subject_ के रूप में संदर्भित किया गया है, को घोषित करने की आवश्यकता को प्रकट करती है, ताकि DWD के तहत JWT उत्पन्न किए जा सकें। जबकि यह एक विशिष्ट उपयोगकर्ता की आवश्यकता प्रतीत हो सकती है, यह समझना महत्वपूर्ण है कि **DWD एक डोमेन के भीतर हर पहचान को प्रभावित करता है**। परिणामस्वरूप, **किसी भी डोमेन उपयोगकर्ता** के लिए JWT बनाना उस डोमेन में सभी पहचानियों को प्रभावित करता है, जो हमारे संयोजन गणना जांच के अनुरूप है। सीधे शब्दों में कहें, एक मान्य Workspace उपयोगकर्ता आगे बढ़ने के लिए पर्याप्त है।\
+इस उपयोगकर्ता को DeleFriend के _config.yaml_ फ़ाइल में परिभाषित किया जा सकता है। यदि लक्षित कार्यक्षेत्र उपयोगकर्ता पहले से ज्ञात नहीं है, तो उपकरण GCP प्रोजेक्ट्स पर भूमिकाओं के साथ डोमेन उपयोगकर्ताओं को स्कैन करके मान्य कार्यक्षेत्र उपयोगकर्ताओं की स्वचालित पहचान की सुविधा प्रदान करता है। यह फिर से ध्यान देने योग्य है कि JWT डोमेन-विशिष्ट होते हैं और हर उपयोगकर्ता के लिए उत्पन्न नहीं होते; इसलिए, स्वचालित प्रक्रिया प्रति डोमेन एक अद्वितीय पहचान को लक्षित करती है।
 7. **प्रत्येक JWT के लिए एक नया बियरर एक्सेस टोकन की गणना करें और टोकन को tokeninfo API के खिलाफ मान्य करें।**
 
 #### [Gitlab का Python स्क्रिप्ट](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/gcp_misc/-/blob/master/gcp_delegation.py)
 
-Gitlab ने [यह Python स्क्रिप्ट](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp_misc/blob/master/gcp_delegation.py) बनाई है जो दो चीजें कर सकती है - उपयोगकर्ता निर्देशिका को सूचीबद्ध करना और SA क्रेडेंशियल्स और अनुकरण करने के लिए उपयोगकर्ता के साथ एक नया प्रशासनिक खाता बनाना। यहाँ बताया गया है कि आप इसका उपयोग कैसे करेंगे:
+Gitlab ने [यह Python स्क्रिप्ट](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp_misc/blob/master/gcp_delegation.py) बनाई है जो दो चीजें कर सकती है - उपयोगकर्ता निर्देशिका की सूची बनाना और SA क्रेडेंशियल्स और अनुकरण करने के लिए उपयोगकर्ता के साथ एक नया प्रशासनिक खाता बनाना। यहाँ इसका उपयोग कैसे करें:
 ```bash
 # Install requirements
 pip install --upgrade --user oauth2client
@@ -73,32 +73,32 @@ pip install --upgrade --user oauth2client
 --domain target-org.com \
 --account pwned
 ```
-### एक नई प्रतिनिधित्व बनाएँ (Persistence)
+### एक नई प्रतिनिधित्व बनाएँ (स्थायीता)
 
-यह संभव है कि **Domain Wide Delegations की जांच करें** [**https://admin.google.com/u/1/ac/owl/domainwidedelegation**](https://admin.google.com/u/1/ac/owl/domainwidedelegation)**.**
+यह संभव है कि **डोमेन वाइड प्रतिनिधित्व की जांच करें** [**https://admin.google.com/u/1/ac/owl/domainwidedelegation**](https://admin.google.com/u/1/ac/owl/domainwidedelegation)**.**
 
-एक हमलावर जिसके पास **GCP प्रोजेक्ट में सेवा खातों को बनाने की क्षमता** और **GWS के लिए सुपर एडमिन विशेषाधिकार** है, वह एक नई प्रतिनिधित्व बना सकता है जो SAs को कुछ GWS उपयोगकर्ताओं का अनुकरण करने की अनुमति देती है:
+एक हमलावर जिसके पास **GCP प्रोजेक्ट में सेवा खातों को बनाने की क्षमता** और **GWS के लिए सुपर एडमिन विशेषाधिकार** है, वह कुछ GWS उपयोगकर्ताओं का अनुकरण करने के लिए SAs को अनुमति देने वाला एक नया प्रतिनिधित्व बना सकता है:
 
-1. **एक नई सेवा खाता और संबंधित कुंजी जोड़ी उत्पन्न करना:** GCP पर, नई सेवा खाता संसाधनों को या तो इंटरैक्टिव रूप से कंसोल के माध्यम से या सीधे API कॉल और CLI उपकरणों का उपयोग करके प्रोग्रामेटिक रूप से उत्पन्न किया जा सकता है। इसके लिए **भूमिका `iam.serviceAccountAdmin`** या किसी भी कस्टम भूमिका की आवश्यकता होती है जिसमें **`iam.serviceAccounts.create`** **अनुमति** हो। एक बार सेवा खाता बन जाने के बाद, हम एक **संबंधित कुंजी जोड़ी** उत्पन्न करने के लिए आगे बढ़ेंगे (**`iam.serviceAccountKeys.create`** अनुमति)।
-2. **नई प्रतिनिधित्व का निर्माण**: यह समझना महत्वपूर्ण है कि **केवल सुपर एडमिन भूमिका के पास Google Workspace में वैश्विक Domain-Wide प्रतिनिधित्व स्थापित करने की क्षमता है** और Domain-Wide प्रतिनिधित्व **प्रोग्रामेटिक रूप से स्थापित नहीं किया जा सकता,** इसे केवल Google Workspace **कंसोल** के माध्यम से **हाथ से** बनाया और समायोजित किया जा सकता है।
-- नियम का निर्माण **API controls → Manage Domain-Wide delegation in Google Workspace Admin console** पृष्ठ के तहत पाया जा सकता है।
-3. **OAuth स्कोप विशेषाधिकार संलग्न करना**: एक नई प्रतिनिधित्व को कॉन्फ़िगर करते समय, Google केवल 2 पैरामीटर की आवश्यकता होती है, क्लाइंट आईडी, जो **GCP सेवा खाता** संसाधन का **OAuth ID** है, और **OAuth स्कोप** जो परिभाषित करता है कि प्रतिनिधित्व को कौन से API कॉल की आवश्यकता है।
+1. **एक नया सेवा खाता और संबंधित कुंजी जोड़ी उत्पन्न करना:** GCP पर, नए सेवा खाता संसाधनों को या तो कंसोल के माध्यम से इंटरैक्टिव रूप से या सीधे API कॉल और CLI उपकरणों का उपयोग करके प्रोग्रामेटिक रूप से उत्पन्न किया जा सकता है। इसके लिए **भूमिका `iam.serviceAccountAdmin`** या किसी भी कस्टम भूमिका की आवश्यकता होती है जिसमें **`iam.serviceAccounts.create`** **अनुमति** हो। एक बार सेवा खाता बन जाने के बाद, हम एक **संबंधित कुंजी जोड़ी** उत्पन्न करने की प्रक्रिया में आगे बढ़ेंगे (**`iam.serviceAccountKeys.create`** अनुमति)।
+2. **नए प्रतिनिधित्व का निर्माण**: यह समझना महत्वपूर्ण है कि **केवल सुपर एडमिन भूमिका के पास Google Workspace में वैश्विक डोमेन-वाइड प्रतिनिधित्व स्थापित करने की क्षमता है** और डोमेन-वाइड प्रतिनिधित्व **प्रोग्रामेटिक रूप से स्थापित नहीं किया जा सकता,** इसे केवल Google Workspace **कंसोल** के माध्यम से **हाथ से** बनाया और समायोजित किया जा सकता है।
+- नियम का निर्माण **API नियंत्रण → Google Workspace Admin कंसोल में डोमेन-वाइड प्रतिनिधित्व प्रबंधित करें** पृष्ठ के तहत पाया जा सकता है।
+3. **OAuth स्कोप विशेषाधिकार संलग्न करना**: एक नए प्रतिनिधित्व को कॉन्फ़िगर करते समय, Google केवल 2 पैरामीटर की आवश्यकता होती है, क्लाइंट आईडी, जो **GCP सेवा खाता** संसाधन का **OAuth आईडी** है, और **OAuth स्कोप** जो परिभाषित करता है कि प्रतिनिधित्व को कौन से API कॉल की आवश्यकता है।
 - **OAuth स्कोप की पूरी सूची** [**यहाँ**](https://developers.google.com/identity/protocols/oauth2/scopes) पाई जा सकती है, लेकिन यहाँ एक सिफारिश है: `https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid`
 4. **लक्षित पहचान के पक्ष में कार्य करना:** इस बिंदु पर, हमारे पास GWS में एक कार्यशील प्रतिनिधित्व वस्तु है। अब, **GCP सेवा खाता निजी कुंजी का उपयोग करके, हम API कॉल कर सकते हैं** (OAuth स्कोप पैरामीटर में परिभाषित स्कोप में) इसे सक्रिय करने और **Google Workspace में मौजूद किसी भी पहचान के पक्ष में कार्य करने के लिए।** जैसा कि हमने सीखा, सेवा खाता अपनी आवश्यकताओं के अनुसार और REST API अनुप्रयोगों के लिए उसके पास मौजूद अनुमति के अनुसार एक्सेस टोकन उत्पन्न करेगा।
 - इस प्रतिनिधित्व का उपयोग करने के लिए कुछ **उपकरणों** के लिए **पिछले अनुभाग** की जांच करें।
 
 #### क्रॉस-ऑर्गनाइजेशनल प्रतिनिधित्व
 
-OAuth SA ID वैश्विक है और इसका उपयोग **क्रॉस-ऑर्गनाइजेशनल प्रतिनिधित्व** के लिए किया जा सकता है। क्रॉस-वैश्विक प्रतिनिधित्व को रोकने के लिए कोई प्रतिबंध लागू नहीं किया गया है। सरल शब्दों में, **विभिन्न GCP संगठनों के सेवा खातों का उपयोग अन्य Workspace संगठनों पर डोमेन-व्यापी प्रतिनिधित्व कॉन्फ़िगर करने के लिए किया जा सकता है।** इसका परिणाम होगा कि **Workspace के लिए केवल सुपर एडमिन पहुंच की आवश्यकता है**, और न कि उसी GCP खाते तक पहुंच की, क्योंकि प्रतिकूलता अपने व्यक्तिगत रूप से नियंत्रित GCP खाते पर सेवा खातों और निजी कुंजी बना सकता है।
+OAuth SA ID वैश्विक है और इसका उपयोग **क्रॉस-ऑर्गनाइजेशनल प्रतिनिधित्व** के लिए किया जा सकता है। क्रॉस-ग्लोबल प्रतिनिधित्व को रोकने के लिए कोई प्रतिबंध लागू नहीं किया गया है। सरल शब्दों में, **विभिन्न GCP संगठनों के सेवा खातों का उपयोग अन्य Workspace संगठनों पर डोमेन-वाइड प्रतिनिधित्व कॉन्फ़िगर करने के लिए किया जा सकता है।** इसका परिणाम होगा कि **Workspace के लिए केवल सुपर एडमिन पहुंच की आवश्यकता है**, और उसी GCP खाते तक पहुंच की आवश्यकता नहीं है, क्योंकि प्रतिकूल व्यक्ति अपने व्यक्तिगत रूप से नियंत्रित GCP खाते पर सेवा खातों और निजी कुंजी बना सकता है।
 
 ### Workspace को सूचीबद्ध करने के लिए एक प्रोजेक्ट बनाना
 
 **डिफ़ॉल्ट** रूप से Workspace **उपयोगकर्ताओं** को **नए प्रोजेक्ट बनाने** की अनुमति होती है, और जब एक नया प्रोजेक्ट बनाया जाता है तो **निर्माता को उस पर मालिक की भूमिका मिलती है।**
 
-इसलिए, एक उपयोगकर्ता **एक प्रोजेक्ट बना सकता है**, **APIs** को सक्षम कर सकता है ताकि वह अपने नए प्रोजेक्ट में Workspace को सूचीबद्ध कर सके और इसे **सूचीबद्ध** करने की कोशिश कर सके।
+इसलिए, एक उपयोगकर्ता **एक प्रोजेक्ट बना सकता है**, अपने नए प्रोजेक्ट में Workspace को सूचीबद्ध करने के लिए **APIs** को **सक्षम** कर सकता है और इसे **सूचीबद्ध** करने का प्रयास कर सकता है।
 
 > [!CAUTION]
-> एक उपयोगकर्ता के लिए Workspace को सूचीबद्ध करने के लिए, उसे पर्याप्त Workspace अनुमतियाँ भी चाहिए (हर उपयोगकर्ता निर्देशिका को सूचीबद्ध करने में सक्षम नहीं होगा)।
+> एक उपयोगकर्ता के लिए Workspace को सूचीबद्ध करने के लिए, उसे पर्याप्त Workspace अनुमतियों की भी आवश्यकता होती है (हर उपयोगकर्ता निर्देशिका को सूचीबद्ध करने में सक्षम नहीं होगा)।
 ```bash
 # Create project
 gcloud projects create <uniq-projec-name> --name=proj-name
@@ -124,10 +124,10 @@ gcloud beta identity groups preview --customer <org-cust-id>
 
 ### Gcloud क्रेडेंशियल्स का दुरुपयोग
 
-आप लॉगिन के लिए `gcloud` प्रवाह के बारे में और जानकारी पा सकते हैं:
+आप लॉगिन के लिए `gcloud` प्रवाह के बारे में अधिक जानकारी पा सकते हैं:
 
 {{#ref}}
-../gcp-persistence/gcp-non-svc-persistance.md
+../gcp-persistence/gcp-non-svc-persistence.md
 {{#endref}}
 
 जैसा कि वहां समझाया गया है, gcloud स्कोप **`https://www.googleapis.com/auth/drive`** का अनुरोध कर सकता है जो एक उपयोगकर्ता को उपयोगकर्ता के ड्राइव तक पहुंचने की अनुमति देगा।\
@@ -140,7 +140,7 @@ gcloud auth login --enable-gdrive-access
 <figure><img src="../../../images/image (342).png" alt="" width="563"><figcaption></figcaption></figure>
 
 > [!WARNING]
-> इसलिए, अगली बार जब उपयोगकर्ता लॉग इन करेगा, तो वह **ड्राइव तक पहुंच के साथ एक टोकन बनाएगा** जिसका उपयोग हमलावर ड्राइव तक पहुंच प्राप्त करने के लिए कर सकता है। स्पष्ट रूप से, ब्राउज़र यह संकेत देगा कि उत्पन्न टोकन को ड्राइव तक पहुंच प्राप्त होगी, लेकिन चूंकि उपयोगकर्ता स्वयं **`gcloud auth login`** करेगा, इसलिए वह शायद **कुछ भी संदेह नहीं करेगा।**
+> इसलिए, अगली बार जब उपयोगकर्ता लॉग इन करेगा, तो वह **ड्राइव तक पहुंच के साथ एक टोकन बनाएगा** जिसका उपयोग हमलावर ड्राइव तक पहुंच प्राप्त करने के लिए कर सकता है। स्पष्ट रूप से, ब्राउज़र यह संकेत देगा कि उत्पन्न टोकन ड्राइव तक पहुंच रखेगा, लेकिन चूंकि उपयोगकर्ता स्वयं **`gcloud auth login`** करेगा, वह शायद **कुछ भी संदेह नहीं करेगा।**
 >
 > ड्राइव फ़ाइलों की सूची बनाने के लिए: **`curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"`**