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

src/pentesting-web/account-takeover.md

@@ -12,14 +12,14 @@
 2. Unicode का उपयोग करके एक खाता बनाया जाना चाहिए\
 उदाहरण के लिए: `vićtim@gmail.com`
 
-जैसा कि [**इस वार्ता**](https://www.youtube.com/watch?v=CiIyaZ3x49c) में बताया गया है, पिछले हमले को तीसरे पक्ष की पहचान प्रदाताओं का दुरुपयोग करके भी किया जा सकता है:
+जैसा कि [**इस वार्ता में**](https://www.youtube.com/watch?v=CiIyaZ3x49c) समझाया गया है, पिछले हमले को तीसरे पक्ष की पहचान प्रदाताओं का दुरुपयोग करके भी किया जा सकता है:
 
 - पीड़ित के समान ईमेल के साथ तीसरे पक्ष की पहचान में एक खाता बनाएं, जिसमें कुछ 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. पीड़ित का ईमेल प्लेटफ़ॉर्म पर साइन अप करने के लिए उपयोग किया जाना चाहिए, और एक पासवर्ड सेट किया जाना चाहिए (इसकी पुष्टि करने का प्रयास किया जाना चाहिए, हालांकि पीड़ित के ईमेल तक पहुँच न होने पर यह असंभव हो सकता है)।
+1. पीड़ित का ईमेल प्लेटफ़ॉर्म पर साइन अप करने के लिए उपयोग किया जाना चाहिए, और एक पासवर्ड सेट किया जाना चाहिए (इसकी पुष्टि करने का प्रयास किया जाना चाहिए, हालांकि पीड़ित के ईमेल तक पहुंच की कमी इसे असंभव बना सकती है)।
-2. एक को OAuth का उपयोग करके पीड़ित के साइन अप करने और खाते की पुष्टि होने की प्रतीक्षा करनी चाहिए।
+2. एक को ओAuth का उपयोग करके पीड़ित के साइन अप करने और खाते की पुष्टि करने की प्रतीक्षा करनी चाहिए।
-3. आशा है कि नियमित साइन अप की पुष्टि की जाएगी, जिससे पीड़ित के खाते तक पहुँचने की अनुमति मिलेगी।
+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,16 +85,16 @@ oauth-to-account-takeover.md
 
 ## Host Header Injection
 
-1. पासवर्ड रीसेट अनुरोध आरंभ करने के बाद होस्ट हेडर को संशोधित किया जाता है।
+1. पासवर्ड रीसेट अनुरोध प्रारंभ करने के बाद होस्ट हेडर को संशोधित किया जाता है।
 2. `X-Forwarded-For` प्रॉक्सी हेडर को `attacker.com` में बदला जाता है।
-3. होस्ट, रेफरर, और मूल हेडर को एक साथ `attacker.com` में बदल दिया जाता है।
+3. होस्ट, रेफरर, और ओरिजिन हेडर को एक साथ `attacker.com` में बदला जाता है।
-4. पासवर्ड रीसेट शुरू करने के बाद और फिर मेल को फिर से भेजने का विकल्प चुनने के बाद, उपरोक्त तीनों विधियों का उपयोग किया जाता है।
+4. पासवर्ड रीसेट प्रारंभ करने के बाद और फिर मेल को फिर से भेजने का विकल्प चुनने के बाद, उपरोक्त तीनों विधियों का उपयोग किया जाता है।
 
 ## Response Manipulation
 
 1. **कोड मैनिपुलेशन**: स्थिति कोड को `200 OK` में बदला जाता है।
 2. **कोड और बॉडी मैनिपुलेशन**:
-- स्थिति कोड को `200 OK` में बदल दिया जाता है।
+- स्थिति कोड को `200 OK` में बदला जाता है।
 - प्रतिक्रिया बॉडी को `{"success":true}` या एक खाली वस्तु `{}` में संशोधित किया जाता है।
 
 ये मैनिपुलेशन तकनीकें उन परिदृश्यों में प्रभावी हैं जहां डेटा ट्रांसमिशन और रिसीप्ट के लिए JSON का उपयोग किया जाता है।
@@ -112,13 +112,13 @@ oauth-to-account-takeover.md
 यह [**इस रिपोर्ट**](https://dynnyd20.medium.com/one-click-account-take-over-e500929656ea) में भी हुआ।
 
 ### Bypass email verification for Account Takeover
-- हमलावर attacker@test.com के साथ लॉगिन करता है और साइन अप करते समय ईमेल की पुष्टि करता है।
+- हमलावर attacker@test.com के साथ लॉगिन करता है और साइनअप पर ईमेल की पुष्टि करता है।
 - हमलावर पुष्टि किए गए ईमेल को victim@test.com में बदलता है (ईमेल परिवर्तन पर कोई द्वितीयक पुष्टि नहीं)
 - अब वेबसाइट victim@test.com को लॉगिन करने की अनुमति देती है और हमने पीड़ित उपयोगकर्ता की ईमेल सत्यापन को बायपास कर दिया है।
 
 ### 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

theme/ht_searcher.js

@@ -471,16 +471,66 @@ window.search = window.search || {};
         showResults(true);
     }
 
-    var branch = lang === "en" ? "master" : lang
+    (async function loadSearchIndex(lang = window.lang || 'en') {
-    fetch(`https://raw.githubusercontent.com/HackTricks-wiki/hacktricks/refs/heads/${branch}/searchindex.json`)
+        /* ───────── paths ───────── */
-        .then(response => response.json())
+        const branch      = lang === 'en' ? 'master' : lang;
-        .then(json => init(json))        
+        const baseRemote  = `https://raw.githubusercontent.com/HackTricks-wiki/hacktricks/${branch}`;
-        .catch(error => { // Try to load searchindex.js if fetch failed
+        const remoteJson  = `${baseRemote}/searchindex.json`;
-            var script = document.createElement('script');
+        const remoteJs    = `${baseRemote}/searchindex.js`;
-            script.src = `https://raw.githubusercontent.com/HackTricks-wiki/hacktricks/refs/heads/${branch}/searchindex.js`;
+        const localJson   = './searchindex.json';
-            script.onload = () => init(window.search);
+        const localJs     = './searchindex.js';
-            document.head.appendChild(script);
+        const TIMEOUT_MS  = 5_000;
-        });
+        
+        /* ───────── helpers ───────── */
+        const fetchWithTimeout = (url, opt = {}) =>
+            Promise.race([
+            fetch(url, opt),
+            new Promise((_, r) => setTimeout(() => r(new Error('timeout')), TIMEOUT_MS))
+            ]);
+        
+        const loadScript = src =>
+            new Promise((resolve, reject) => {
+            const s = document.createElement('script');
+            s.src      = src;
+            s.onload   = resolve;
+            s.onerror  = reject;
+            document.head.appendChild(s);
+            });
+        
+        /* ───────── 1. remote JSON ───────── */
+        try {
+            const r = await fetchWithTimeout(remoteJson);
+            if (!r.ok) throw new Error(r.status);
+            return init(await r.json());
+        } catch (e) {
+            console.warn('Remote JSON failed →', e);
+        }
+        
+        /* ───────── 2. remote JS ───────── */
+        try {
+            await loadScript(remoteJs);
+            return init(window.search);
+        } catch (e) {
+            console.warn('Remote JS failed →', e);
+        }
+        
+        /* ───────── 3. local JSON ───────── */
+        try {
+            const r = await fetch(localJson);
+            if (!r.ok) throw new Error(r.status);
+            return init(await r.json());
+        } catch (e) {
+            console.warn('Local JSON failed →', e);
+        }
+        
+        /* ───────── 4. local JS ───────── */
+        try {
+            await loadScript(localJs);
+            return init(window.search);
+        } catch (e) {
+            console.error('Local JS failed →', e);
+        }
+    })();
 
     // Exported functions
     search.hasFocus = hasFocus;