Translated ['src/pentesting-web/account-takeover.md'] to hi

src/pentesting-web/account-takeover.md

@@ -17,9 +17,9 @@
 - पीड़ित के समान ईमेल के साथ तीसरे पक्ष की पहचान में एक खाता बनाएं, जिसमें कुछ unicode वर्ण हो (`vićtim@company.com`)।
 - तीसरे पक्ष के प्रदाता को ईमेल की पुष्टि नहीं करनी चाहिए
 - यदि पहचान प्रदाता ईमेल की पुष्टि करता है, तो आप डोमेन भाग पर हमला कर सकते हैं जैसे: `victim@ćompany.com` और उस डोमेन को पंजीकृत कर सकते हैं और आशा करते हैं कि पहचान प्रदाता डोमेन का ascii संस्करण उत्पन्न करे जबकि पीड़ित प्लेटफ़ॉर्म डोमेन नाम को सामान्य करता है।
-- इस पहचान प्रदाता के माध्यम से पीड़ित प्लेटफ़ॉर्म में लॉगिन करें, जिसे unicode वर्ण को सामान्य करना चाहिए और आपको पीड़ित खाते तक पहुंचने की अनुमति देनी चाहिए।
+- इस पहचान प्रदाता के माध्यम से पीड़ित प्लेटफ़ॉर्म में लॉगिन करें, जिसे unicode वर्ण को सामान्य करना चाहिए और आपको पीड़ित खाते तक पहुँचने की अनुमति देनी चाहिए।
 
-अधिक जानकारी के लिए, Unicode Normalization पर दस्तावेज़ देखें:
+अधिक विवरण के लिए, Unicode Normalization पर दस्तावेज़ देखें:
 
 {{#ref}}
 unicode-injection/unicode-normalization.md
@@ -31,13 +31,13 @@ unicode-injection/unicode-normalization.md
 
 ## **Pre Account Takeover**
 
-1. पीड़ित का ईमेल प्लेटफ़ॉर्म पर साइन अप करने के लिए उपयोग किया जाना चाहिए, और एक पासवर्ड सेट किया जाना चाहिए (इसकी पुष्टि करने का प्रयास किया जाना चाहिए, हालांकि पीड़ित के ईमेल तक पहुंच की कमी इसे असंभव बना सकती है)।
-2. एक को ओAuth का उपयोग करके पीड़ित के साइन अप करने और खाते की पुष्टि करने की प्रतीक्षा करनी चाहिए।
-3. आशा है कि नियमित साइन अप की पुष्टि की जाएगी, जिससे पीड़ित के खाते तक पहुंच प्राप्त होगी।
+1. पीड़ित का ईमेल प्लेटफ़ॉर्म पर साइन अप करने के लिए उपयोग किया जाना चाहिए, और एक पासवर्ड सेट किया जाना चाहिए (इसकी पुष्टि करने का प्रयास किया जाना चाहिए, हालांकि पीड़ित के ईमेल तक पहुँच न होने पर यह असंभव हो सकता है)।
+2. एक को OAuth का उपयोग करके पीड़ित के साइन अप करने और खाते की पुष्टि होने की प्रतीक्षा करनी चाहिए।
+3. आशा है कि नियमित साइन अप की पुष्टि की जाएगी, जिससे पीड़ित के खाते तक पहुँचने की अनुमति मिलेगी।
 
 ## **CORS Misconfiguration to Account Takeover**
 
-यदि पृष्ठ में **CORS misconfigurations** हैं, तो आप **उपयोगकर्ता से संवेदनशील जानकारी चुराने** में सक्षम हो सकते हैं ताकि **उसका खाता ले लिया जा सके** या उसे उसी उद्देश्य के लिए प्रमाणीकरण जानकारी बदलने के लिए मजबूर किया जा सके:
+यदि पृष्ठ में **CORS misconfigurations** हैं, तो आप **उपयोगकर्ता से संवेदनशील जानकारी चुराने** में सक्षम हो सकते हैं ताकि **उसका खाता ले सकें** या उसे उसी उद्देश्य के लिए प्रमाणीकरण जानकारी बदलने के लिए मजबूर कर सकें:
 
 {{#ref}}
 cors-bypass.md
@@ -53,7 +53,7 @@ csrf-cross-site-request-forgery.md
 
 ## **XSS to Account Takeover**
 
-यदि आप एप्लिकेशन में XSS पाते हैं, तो आप कुकीज़, स्थानीय भंडारण, या वेब पृष्ठ से जानकारी चुराने में सक्षम हो सकते हैं जो आपको खाता ले जाने की अनुमति दे सकती है:
+यदि आप एप्लिकेशन में XSS पाते हैं, तो आप कुकीज़, स्थानीय भंडारण, या वेब पृष्ठ से जानकारी चुराने में सक्षम हो सकते हैं जो आपको खाता लेने की अनुमति दे सकती है:
 
 {{#ref}}
 xss-cross-site-scripting/
@@ -61,7 +61,7 @@ xss-cross-site-scripting/
 
 ## **Same Origin + Cookies**
 
-यदि आप सीमित XSS या एक उपडोमेन पर कब्जा पाते हैं, तो आप कुकीज़ के साथ खेल सकते हैं (उदाहरण के लिए, उन्हें स्थिर करना) ताकि पीड़ित खाते को समझौता करने का प्रयास किया जा सके:
+यदि आप सीमित XSS या एक उपडोमेन पर कब्जा पाते हैं, तो आप कुकीज़ के साथ खेल सकते हैं (उदाहरण के लिए, उन्हें स्थिर करना) ताकि पीड़ित के खाते को समझौता करने का प्रयास कर सकें:
 
 {{#ref}}
 hacking-with-cookies/
@@ -75,7 +75,7 @@ reset-password.md
 
 ## **Response Manipulation**
 
-यदि प्रमाणीकरण प्रतिक्रिया को **सरल बूलियन में घटाया जा सकता है, तो बस false को true में बदलने का प्रयास करें** और देखें कि क्या आपको कोई पहुंच मिलती है।
+यदि प्रमाणीकरण प्रतिक्रिया को **सरल बूलियन में घटाया जा सकता है, तो बस false को true में बदलने का प्रयास करें** और देखें कि क्या आपको कोई पहुँच मिलती है।
 
 ## OAuth to Account takeover
 
@@ -85,19 +85,19 @@ oauth-to-account-takeover.md
 
 ## Host Header Injection
 
-1. पासवर्ड रीसेट अनुरोध प्रारंभ करने के बाद होस्ट हेडर को संशोधित किया जाता है।
+1. पासवर्ड रीसेट अनुरोध आरंभ करने के बाद होस्ट हेडर को संशोधित किया जाता है।
 2. `X-Forwarded-For` प्रॉक्सी हेडर को `attacker.com` में बदला जाता है।
 3. होस्ट, रेफरर, और मूल हेडर को एक साथ `attacker.com` में बदल दिया जाता है।
-4. पासवर्ड रीसेट प्रारंभ करने के बाद और फिर मेल को फिर से भेजने का विकल्प चुनने के बाद, उपरोक्त तीनों विधियों का उपयोग किया जाता है।
+4. पासवर्ड रीसेट शुरू करने के बाद और फिर मेल को फिर से भेजने का विकल्प चुनने के बाद, उपरोक्त तीनों विधियों का उपयोग किया जाता है।
 
 ## Response Manipulation
 
 1. **कोड मैनिपुलेशन**: स्थिति कोड को `200 OK` में बदला जाता है।
 2. **कोड और बॉडी मैनिपुलेशन**:
-- स्थिति कोड को `200 OK` में बदला जाता है।
+- स्थिति कोड को `200 OK` में बदल दिया जाता है।
 - प्रतिक्रिया बॉडी को `{"success":true}` या एक खाली वस्तु `{}` में संशोधित किया जाता है।
 
-ये मैनिपुलेशन तकनीकें उन परिदृश्यों में प्रभावी होती हैं जहां डेटा ट्रांसमिशन और रिसीप्ट के लिए JSON का उपयोग किया जाता है।
+ये मैनिपुलेशन तकनीकें उन परिदृश्यों में प्रभावी हैं जहां डेटा ट्रांसमिशन और रिसीप्ट के लिए JSON का उपयोग किया जाता है।
 
 ## Change email of current session
 
@@ -118,7 +118,7 @@ oauth-to-account-takeover.md
 
 ### Old Cookies
 
-जैसा कि [**इस पोस्ट**](https://medium.com/@niraj1mahajan/uncovering-the-hidden-vulnerability-how-i-found-an-authentication-bypass-on-shopifys-exchange-cc2729ea31a9) में बताया गया है, एक खाते में लॉगिन करना, एक प्रमाणित उपयोगकर्ता के रूप में कुकीज़ को सहेजना, लॉगआउट करना, और फिर फिर से लॉगिन करना संभव था।\
+[**इस पोस्ट**](https://medium.com/@niraj1mahajan/uncovering-the-hidden-vulnerability-how-i-found-an-authentication-bypass-on-shopifys-exchange-cc2729ea31a9) में बताया गया है कि एक खाते में लॉगिन करना, कुकीज़ को एक प्रमाणित उपयोगकर्ता के रूप में सहेजना, लॉगआउट करना, और फिर फिर से लॉगिन करना संभव था।\
 नए लॉगिन के साथ, हालांकि विभिन्न कुकीज़ उत्पन्न हो सकती हैं, पुरानी कुकीज़ फिर से काम करने लगीं।
 
 ## References