<summary><strong>जानें AWS हैकिंग को शून्य से हीरो तक</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong> के साथ!</strong></summary>
* यदि आप अपनी **कंपनी का विज्ञापन HackTricks में देखना चाहते हैं** या **HackTricks को PDF में डाउनलोड करना चाहते हैं** तो [**सब्सक्रिप्शन प्लान्स देखें**](https://github.com/sponsors/carlospolop)!
सामग्री सुरक्षा नीति (CSP) को ब्राउज़र प्रौद्योगिकी के रूप में मान्यता प्राप्त है, जिसका मुख्य उद्देश्य **क्रॉस-साइट स्क्रिप्टिंग (XSS) जैसे हमलों से बचाव** है। यह इसलिए काम करता है क्योंकि यह ब्राउज़र द्वारा सुरक्षित रूप से लोड किए जा सकने वाले संसाधनों के लिए मार्ग और स्रोतों को परिभाषित और विस्तारित करके कार्य करता है। इन संसाधनों में छवियाँ, फ्रेम्स, और जावास्क्रिप्ट जैसे तत्व शामिल हैं। उदाहरण के लिए, एक नीति स्वयं डोमेन (सेल्फ) से संसाधनों को लोड और क्रियान्वित करने की अनुमति देने की सक्षम हो सकती है, इनलाइन संसाधनों और `eval`, `setTimeout`, या `setInterval` जैसे फ़ंक्शन के माध्यम से स्ट्रिंग कोड के क्रियान्वयन की अनुमति देने की सहायता कर सकती है।
CSP का कार्यान्वयन **प्रतिक्रिया हेडर** के माध्यम से या **HTML पेज में मेटा तत्वों को शामिल करके** किया जाता है। इस नीति के अनुसार, ब्राउज़र सक्रिय रूप से इन निर्धारणों का पालन करता है और किसी भी पारदर्शित उल्लंघन को तुरंत रोक देता है।
*`Content-Security-Policy`: CSP को प्रवर्तित करता है; ब्राउज़र किसी भी उल्लंघन को रोकता है।
*`Content-Security-Policy-Report-Only`: मॉनिटरिंग के लिए उपयोग किया जाता है; उल्लंघन की रिपोर्ट बनाता है बिना उन्हें रोकने के। प्री-प्रोडक्शन वातावरण में टेस्टिंग के लिए आदर्श है।
CSP निर्धारित करता है कि सक्रिय और निष्क्रिय सामग्री लोड करने के लिए मूल स्थानों की प्रतिबंधित करने से, इनलाइन जावास्क्रिप्ट निष्पादन और `eval()` का उपयोग जैसे पहलुओं को नियंत्रित करता है। एक उदाहरण नीति है:
* **script-src**: जावास्क्रिप्ट के लिए विशिष्ट स्रोतों को अनुमति देता है, जैसे URL, इनलाइन स्क्रिप्ट, और ईवेंट हैंडलर या XSLT स्टाइलशीट द्वारा ट्रिगर किए गए स्क्रिप्ट।
* **frame-ancestors**: मौजूदा पेज को एम्बेड कर सकने वाले स्रोतों को निर्दिष्ट करता है, `<frame>`, `<iframe>`, `<object>`, `<embed>`, और `<applet>` जैसे तत्वों के लिए लागू होता है।
* **img-src**: छवियों के लिए अनुमति देने वाले स्रोतों को परिभाषित करता है।
* **font-src**: `@font-face` का उपयोग करके लोड किए जाने वाले फॉन्ट के लिए मान्य स्रोतों को निर्दिष्ट करता है।
*`'unsafe-inline'`: इनलाइन `<script>` या `<style>` जैसे इनलाइन संसाधनों का उपयोग करने की अनुमति देता है, सुरक्षा कारणों से सिफारिश नहीं की जाती है।
*`'nonce'`: एक क्रिप्टोग्राफिक नॉन्स (एक बार उपयोग किया गया संख्या) का उपयोग करके विशिष्ट इनलाइन स्क्रिप्ट के लिए एक सफेद सूची है। यदि आपके पास JS सीमित निष्पादन है तो पृष्ठ में उपयुक्त नॉन्स को पुनः प्रयोग करना संभव है `doc.defaultView.top.document.querySelector("[nonce]")` और फिर इसे दुरुपयोग करने के लिए एक दुर्भाग्यपूर्ण स्क्रिप्ट लोड करने के लिए। (यदि स्ट्रिक्ट-डायनामिक का उपयोग किया जाता है, तो किसी भी अनुमत स्रोत नए स्रोतों को लोड कर सकता है, इसलिए यह आवश्यक नहीं है)। जैसे कि:
<details>
<summary>नॉन्स का पुनः प्रयोग करके स्क्रिप्ट लोड करें</summary>
```html
<!-- From https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/ -->
*`'sha256-<hash>'`: विशिष्ट sha256 हैश के साथ स्क्रिप्ट को सफेद सूचीबद्ध करता है।
*`'strict-dynamic'`: किसी भी स्रोत द्वारा सफेद सूचीबद्ध किया गया हो तो किसी भी स्रोत से स्क्रिप्ट लोड करने की अनुमति देता है।
*`'host'`: एक विशिष्ट होस्ट को निर्दिष्ट करता है, जैसे `example.com`।
*`https:`: URL को उनके HTTPS का उपयोग करने वाले तक ही सीमित करता है।
*`blob:`: Blob URLs से संसाधनों को लोड करने की अनुमति देता है (जैसे, JavaScript के माध्यम से बनाए गए Blob URLs)।
*`filesystem:`: फ़ाइल सिस्टम से संसाधनों को लोड करने की अनुमति देता है।
*`'report-sample'`: उल्लंघन रिपोर्ट में उल्लंघक कोड का एक नमूना शामिल करता है (डीबगिंग के लिए उपयोगी)।
*`'strict-origin'`: 'self' के समान है लेकिन स्रोतों का प्रोटोकॉल सुरक्षा स्तर दस्तावेज से मेल खाता है (केवल सुरक्षित मूल स्रोत सुरक्षित मूल स्रोतों से संसाधनों को लोड कर सकते हैं)।
*`'strict-origin-when-cross-origin'`: समान मूल स्रोत अनुरोध करते समय पूर्ण URL भेजता है लेकिन अनुरोध क्रॉस-मूल होने पर केवल मूल को भेजता है।
*`'unsafe-allow-redirects'`: संसाधनों को लोड करने की अनुमति देता है जो तुरंत दूसरे संसाधन पर पुन:निर्देशित हो जाएगा। सुरक्षा को कमजोर करने के लिए सिफारिश नहीं की जाती।
यदि आप किसी प्रकार से **अनुमत JS कोड नए स्क्रिप्ट टैग** को DOM में अपने JS कोड के साथ बना सकते हैं, क्योंकि एक अनुमत स्क्रिप्ट इसे बना रहा है, तो **नया स्क्रिप्ट टैग को निषेधित किया जाने दिया जाएगा**।
इसके अतिरिक्त, यदि आप सर्वर द्वारा स्वीकृत एक्सटेंशन का उपयोग करके एक फ़ाइल में **जेएस कोड अपलोड कर सकते हैं** (जैसे: _script.png_) तो भी यह काफी नहीं होगा क्योंकि कुछ सर्वर जैसे अपाचे सर्वर **फ़ाइल के MIME प्रकार का चयन एक्सटेंशन पर आधारित करते हैं** और Chrome जैसे ब्राउज़र **उस चीज़ को जिसे एक छवि होना चाहिए में जावास्क्रिप्ट को निषेधित करेगा**। "आशा है", यहाँ गलतियाँ हैं। उदाहरण के लिए, एक सीटीएफ से मुझे पता चला कि **अपाचे को पता नहीं है**_**.wave**_ एक्सटेंशन, इसलिए यह ऑडियो/\* जैसे MIME प्रकार के साथ सर्विस नहीं करता।
यहाँ से, यदि आप एक XSS और एक फ़ाइल अपलोड पाते हैं, और आप एक **गलत अनुवादित एक्सटेंशन** पाते हैं, तो आप उस एक्सटेंशन के साथ एक फ़ाइल और स्क्रिप्ट की सामग्री का प्रयास कर सकते हैं। या, यदि सर्वर अपलोड की गई फ़ाइल का सही प्रारूप जांच रहा है, तो एक पॉलीग्लॉट बनाएं ([यहाँ कुछ पॉलीग्लॉट उदाहरण हैं](https://github.com/Polydet/polyglot-database))।
इस पोस्ट में दिखाया गया है कि आप **cdn.cloudflare.com** से सभी **पुस्तकालय** को **लोड** कर सकते हैं (या किसी अन्य अनुमत JS पुस्तकालय रेपो से), प्रत्येक पुस्तकालय से जोड़ी गई सभी फ़ंक्शन को क्रियान्वित कर सकते हैं, और जांच सकते हैं **कौन से पुस्तकालयों से कौन से फ़ंक्शन `window` ऑब्ज
[**इस 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) के अनुसार आप [https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) का दुरुपयोग कर सकते हैं एक CSP के अंदर अनियमित JS कोड को बाहर करते हुए:
ऐसे परिदृश्य जहाँ `script-src` को `self` और एक विशेष डोमेन जो whitelist किया गया है सेट किया गया है, उन्हें JSONP का उपयोग करके बाईपास किया जा सकता है। JSONP endpoints असुरक्षित कॉलबैक मेथड को संभावित करते हैं जिससे हमलावार XSS कार्रवाई कर सकते हैं, काम करने वाला payload:
यदि **विश्वसनीय एंडपॉइंट में ओपन रीडायरेक्ट होता है**, तो एक ही सुरक्षा दोष होगा क्योंकि यदि प्रारंभिक एंडपॉइंट विश्वसनीय है, तो रीडायरेक्ट्स भी विश्वसनीय होते हैं।
[निम्नलिखित पोस्ट](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses) में वर्णित के अनुसार, कई तीसरे पक्ष डोमेन, जो कहीं-न-कहीं CSP में अनुमति हो सकते हैं, उनका दुरुपयोग किया जा सकता है या तो डेटा को बाहर ले जाने के लिए या जावास्क्रिप्ट को क्रियान्वित करने के लिए। कुछ तीसरे पक्ष इस प्रकार हैं:
यदि आपके लक्ष्य के CSP में किसी भी अनुमत डोमेन को पाते हैं, तो संभावना है कि आप तीसरे पक्ष सेवा पर पंजीकरण करके CSP को बाईपास कर सकते हैं, या तो उस सेवा को डेटा को बाहर ले जाने के लिए या कोड को क्रियान्वित करने के लिए।
In some scenarios, you may encounter a website that has a strict Content Security Policy (CSP) in place, which restricts the sources from which certain types of content can be loaded. However, there are ways to bypass CSP protections and execute malicious code on the target website.
4.**Trusted Types Bypass**: If the website uses Trusted Types to restrict the use of certain functions, you can find ways to bypass these restrictions.
Understanding how to bypass CSP protections is crucial for a penetration tester to identify and exploit security vulnerabilities in web applications. By utilizing various techniques, you can bypass CSP restrictions and execute malicious code, highlighting the importance of implementing strong security measures to protect against such attacks.
आपको डेटा को बाहर निकालने में सक्षम होना चाहिए, जैसे कि [Google Analytics](https://www.humansecurity.com/tech-engineering-blog/exfiltrating-users-private-data-using-google-analytics-to-bypass-csp)/[Google Tag Manager](https://blog.deteact.com/csp-bypass/) के साथ हमेशा किया गया है। इस मामले में, आप निम्नलिखित सामान्य चरणों का पालन करते हैं:
2. एक नया "Facebook Login" ऐप बनाएं और "वेबसाइट" का चयन करें।
3. "सेटिंग्स -> मूल" पर जाएं और अपना "ऐप आईडी" प्राप्त करें।
4. उस लक्षित साइट में जहां से आप डेटा बाहर निकालना चाहते हैं, आप "fbq" उपकरण का सीधा उपयोग करके "कस्टम इवेंट" और डेटा पेलोड के माध्यम से डेटा बाहर निकाल सकते हैं।
5. अपने ऐप "इवेंट मैनेजर" पर जाएं और आपने बनाया ऐप्लिकेशन चुनें (नोट करें कि इवेंट मैनेजर इस प्रकार के यूआरएल में पाया जा सकता है: https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events)
6. "टेस्ट इवेंट्स" टैब का चयन करें ताकि "आपकी" वेबसाइट द्वारा भेजे जा रहे इवेंट्स देख सकें।
फिर, पीड़ित पक्ष पर, आप निम्नलिखित कोड को निष्पादित करें ताकि आप Facebook ट्रैकिंग पिक्सल को आक्रमक के Facebook डेवलपर खाते ऐप-आईडी पर पॉइंट करने और इस प्रकार का कस्टम इवेंट जारी करें:
### Bypass के माध्यम से RPO (सापेक्ष पथ ओवरराइट) <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>
पिछले तालिका में उल्लिखित अन्य सात थर्ड-पार्टी डोमेन के लिए, आप उनका दुरुपयोग करने के कई अन्य तरीके का उपयोग कर सकते हैं। अन्य थर्ड-पार्टी दुरुपयोग के बारे में अतिरिक्त व्याख्यान के लिए पिछले [ब्लॉग पोस्ट](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses) का संदर्भ दें।
उपरोक्त पथ प्रतिबंधों को अनदेखा करने के लिए उल्लिखित पुनर्निर्देशन के अतिरिक्त, कुछ सर्वरों पर एक और तकनीक नामक सापेक्ष पथ ओवरराइट (RPO) है जिसका उपयोग किया जा सकता है।
यह काम करता है क्योंकि ब्राउज़र के लिए आप `https://example.com/scripts/react/` के नीचे स्थित `..%2fangular%2fangular.js` नामक फ़ाइल लोड कर रहे हैं, जो सीएसपी के अनुसार है।
इसके बाद, वे इसे डिकोड करेंगे, जिससे `https://example.com/scripts/react/../angular/angular.js` का अनुरोध किया जाएगा, जो `https://example.com/scripts/angular/angular.js` के समान है।
समाधान यह है कि सर्वर-साइड पर `%2f` को `/` के रूप में न देखें, ताकि ब्राउज़र और सर्वर के बीच संगत व्याख्या सुनिश्चित करने के लिए इस समस्या से बचा जा सके।
यदि **base-uri** निर्देशिका गायब है तो आप इसे दुरुपयोग करने के लिए उपयोग कर सकते हैं ताकि एक [**डैंगलिंग मार्कअप इंजेक्शन**](../dangling-markup-html-scriptless-injection/) किया जा सके।
इसके अतिरिक्त, यदि पृष्ठ एक **अवस्थित पथ** का उपयोग करके स्क्रिप्ट लोड कर रहा है (जैसे `<script src="/js/app.js">`) एक **Nonce** का उपयोग करके, तो आप **बेस टैग** का दुरुपयोग कर सकते हैं ताकि यह **आपके अपने सर्वर से स्क्रिप्ट लोड** करें और एक XSS प्राप्त करें।\
एक विशिष्ट नीति जिसे सामग्री सुरक्षा नीति (CSP) कहा जाता है, जावास्क्रिप्ट घटनाओं को प्रतिबंधित कर सकती है। फिर भी, AngularJS एक वैकल्पिक रूप में कस्टम घटनाएँ पेश करता है। एक घटना के भीतर, AngularJS एक अद्वितीय ऑब्जेक्ट `$event` प्रदान करता है, जो मूल ब्राउज़र घटना ऑब्ज
यह स्निपेट `ng-focus` निर्देशिका का उपयोग हासिल करता है घटना को ट्रिगर करने के लिए, `$event.path|orderBy` का उपयोग करता है `path` एरे को संशोधित करने के लिए, और `alert()` फ़ंक्शन को निष्पादित करने के लिए `window` ऑब्जेक्ट का उपयोग करता है, जिससे `document.cookie` प्रकट होता है।
अन्य JSONP अनिवार्य क्रियान्वयन अंत्यस्थ बिंदु [**यहाँ**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) में पाए जा सकते हैं (कुछ उन्हें हटा दिया गया था या सुधार दिया गया था)
हालांकि, [CSP स्पेक 4.2.2.3. पथ और पुनर्निर्देश](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects) में वर्णन के अनुसार, यदि पुनर्निर्देशन एक विभिन्न पथ पर ले जाता है, तो यह मूल प्रतिबंधों को बाईपास कर सकता है।
यदि CSP को `https://www.google.com/a/b/c/d` पर सेट किया गया है, क्योंकि पथ को मान्य माना जाता है, इसलिए `/test` और `/a/test` स्क्रिप्ट दोनों CSP द्वारा अवरोधित किए जाएंगे।
हालांकि, अंतिम `http://localhost:5555/301`**सर्वर-द्वारा `https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//` पर पुनर्निर्देशित किया जाएगा**। क्योंकि यह एक पुनर्निर्देशन है, **पथ को ध्यान में नहीं रखा जाता है**, और **स्क्रिप्ट लोड किया जा सकता है**, इसलिए पथ प्रतिबंध को उलटा कर दिया जा सकता है।
इसलिए, सबसे अच्छा समाधान यह है कि सुनिश्चित किया जाए कि वेबसाइट में कोई खुला पुनर्निर्देशन संवर्गनी न हो और कोई डोमेन न हो जिसे CSP नियमों में शोषित किया जा सके।
`'unsafe-inline'` का मतलब है कि आप कोड के अंदर कोई भी स्क्रिप्ट निष्पादित कर सकते हैं (XSS कोड को निष्पादित कर सकता है) और `img-src *` का मतलब है कि आप वेबपेज में किसी भी स्रोत से किसी भी छवि का उपयोग कर सकते हैं।
आप इस CSP को छदने के लिए छवियों के माध्यम से डेटा को बाहर निकाल सकते हैं (इस अवसर में XSS एक CSRF का दुरुपयोग करता है जहां बॉट द्वारा पहुंची जा सकने वाली पृष्ठ में एक SQLi होती है, और एक छवि के माध्यम से ध्वज को निकालता है):
आप इस कॉन्फ़िगरेशन का दुरुपयोग करके **एक छवि के अंदर डाले गए जावास्क्रिप्ट को लोड** कर सकते हैं। यदि उदाहरण के लिए, पृष्ठ ट्विटर से छवियां लोड करने की अनुमति देता है। तो आप **एक विशेष छवि** तैयार कर सकते हैं, इसे ट्विटर पर अपलोड कर सकते हैं और "**unsafe-inline**" का दुरुपयोग करके एक JS कोड (एक नियमित XSS के रूप में) को **चलाने** के लिए उसे **कर सकते हैं**: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
यदि आप द्वारा भेजे गए **पैरामीटर** को नीति के **घोषणा** के **अंदर पेस्ट** किया जा रहा है, तो आप **नीति** को किसी भी तरह से **बदल** सकते हैं जिससे यह **अनर्थक** हो जाए। आप इनमें से किसी भी बायपास के साथ स्क्रिप्ट 'unsafe-inline' को **अनुमति** दे सकते हैं:
आप यहाँ एक उदाहरण पा सकते हैं: [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)
नोटिस करें कि निर्देशिका `'unsafe-inline'` की कमी है।\
इस बार आप पीड़ित को एक `<iframe` के माध्यम से **XSS** के जरिए **आपके नियंत्रण में** एक पृष्ठ **लोड** करने के लिए कर सकते हैं। इस बार आप पीड़ित से जिस पृष्ठ को एक्सट्रैक्ट करना चाहते हैं (**CSRF**) उस पृष्ठ तक पहुंचने के लिए करेंगे। आप पृष्ठ की सामग्री तक पहुंच नहीं सकते, लेकिन अगर किसी प्रकार से आप **पृष्ठ को लोड होने में समय को नियंत्रित कर सकते हैं** तो आप आवश्यक जानकारी निकाल सकते हैं।
इस बार एक **ध्वज** निकाला जाएगा, जब किसी **व्यंजन को सही ढंग से अनुमानित** किया जाता है तो **प्रतिक्रिया** में **अधिक समय** लगता है नींद कार्य के कारण। फिर, आप ध्वज निकाल सकेंगे:
इस हमले में कुछ सामाजिक इंजीनियरिंग शामिल होगी जहां हमलावर **उपयोगकर्ता को यह धोखा देता है कि वह ब्राउज़र के बुकमार्कलेट पर एक लिंक को खींचकर छोड़े**। यह बुकमार्कलेट **हानिकारक जावास्क्रिप्ट** को शामिल करेगा जो जब खींचा और छोड़ा जाए या क्लिक किया जाए, तो वर्तमान वेब विंडो के संदर्भ में क्रियान्वित होगा, **CSP को छलकर गुजरता है और कुकीज़ या टोकन जैसी संवेदनशील जानकारी चुरा सकता है**।
[**इस CTF व्रिटअप में**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), CSP को एक अनुमत आईफ्रेम के अंदर एक और संकीर्ण CSP डालकर बाईपास किया गया है जो एक विशिष्ट JS फ़ाइल को लोड करने की अनुमति नहीं देता था, जिसके बाद, **प्रोटोटाइप पोल्लूशन** या **डोम क्लॉबरिंग** के माध्यम से एक विभिन्न स्क्रिप्ट का दुरुपयोग करने की अनुमति देता था जिससे किसी भी विचारशील स्क्रिप्ट को लोड करने की अनुमति मिलती थी।
[**इस CTF व्रिटअप में**](https://github.com/aszx87410/ctf-writeups/issues/48), **HTML इन्जेक्शन** के माध्यम से **CSP** को और अधिक **प्रतिबंधित** किया जा सकता था ताकि CSTI को रोकने वाला एक स्क्रिप्ट निषेधित हो और इसलिए **सुरक्षा दोष उत्पन्न हो सकता था.**\
CSP को और अधिक प्रतिबंधक बनाया जा सकता है **HTML मेटा टैग्स** का उपयोग करके और इनलाइन स्क्रिप्ट्स को निषेधित किया जा सकता है **उनके एंट्री को हटाकर** जिससे उनके **नॉन्स** को अनुमति दी जा सकती है और **विशिष्ट इनलाइन स्क्रिप्ट को शा के माध्यम से सक्षम किया जा सकता है:**
यदि आप सर्वर को **`Content-Security-Policy-Report-Only`** हेडर के साथ प्रतिक्रिया करने के लिए प्रबंधित कर सकते हैं जिसका **मान आपके द्वारा नियंत्रित होता है** (शायद CRLF के कारण), तो आप इसे अपने सर्वर की ओर देखा सकते हैं और यदि आप **`<script>`** के साथ उस **JS सामग्री** को **लपेटते** हैं जिसे आप निकालना चाहते हैं और क्योंकि संभावना है कि `unsafe-inline` को CSP द्वारा अनुमति नहीं है, तो यह एक CSP त्रुटि को **ट्रिगर** करेगा और स्क्रिप्ट का हिस्सा (संवेदनशील जानकारी वाला) `Content-Security-Policy-Report-Only` से सर्वर को भेज दिया जाएगा।
* एक `iframe` बनाया जाता है जो एक URL की ओर पोइंट करता है (हम इसे `https://example.redirect.com` नाम देते हैं) जो CSP द्वारा अनुमति दी गई है।
* इस URL फिर एक गुप्त URL (उदाहरण के लिए, `https://usersecret.example2.com`) पर रीडायरेक्ट होता है जो CSP द्वारा **अनुमति नहीं** दी गई है।
*`securitypolicyviolation` इवेंट को सुनकर, `blockedURI` प्रॉपर्टी को कैप्चर किया जा सकता है। यह प्रॉपर्टी ब्लॉक हुए URI के डोमेन को प्रकट करती है, जिससे प्रारंभिक URL ने रीडायरेक्ट किया।
यह दिलचस्प है कि Chrome और Firefox जैसे ब्राउज़र्स में आईफ्रेम को CSP के संबंध में अलग-अलग व्यवहार होता है, जिससे अपरिभाषित व्यवहार के कारण संवेदनशील जानकारी का लीक हो सकता है।
एक और तकनीक में CSP का उपयोग करके गुप्त सबडोमेन का अंदाज लगाना शामिल है। यह विधि एक बाइनरी खोज एल्गोरिदम पर निर्भर करती है और विशेष डोमेन्स को ब्लॉक करने या अनुमति देने के लिए CSP को समायोजित करने पर। उदाहरण के लिए, यदि गुप्त सबडोमेन अज्ञात वर्णों से बना है, तो आप CSP निर्देशिका को संशोधित करके इन सबडोमेन्स को ब्लॉक या अनुमति देने के लिए विभिन्न सबडोमेन्स का परीक्षण कर सकते हैं। यहां एक स्निपेट दिखाया गया है जो इस विधि को सुविधाजनक बनाने के लिए CSP को कैसे सेट किया जा सकता है:
CSP द्वारा अनुमति दी या अवरुद्ध की गई अनुरोधों का मॉनिटरिंग करके, व्यक्ति गोपनीय सबडोमेन में संभावित वर्णों को संक्षेपित कर सकता है, अंततः पूर्ण URL का पता लगा सकता है।
दोनों तकनीकों में CSP के कार्यान्वयन और ब्राउज़र में व्यवहार का शोध किया जाता है, जिससे प्रतीत होता है कि दिखाई देने वाली सुरक्षित नीतियाँ अनजाने में संवेदनशील जानकारी छिपा सकती है।
PHP को डिफ़ॉल्ट रूप से 4096 बाइट तक की प्रतिक्रिया को बफर करने के लिए जाना जाता है। इसलिए, यदि PHP एक चेतावनी दिखा रहा है, तो चेतावनियों में पर्याप्त डेटा प्रदान करके, प्रतिक्रिया **CSP हेडर** से **पहले****भेजी** जाएगी, जिससे हेडर को नजरअंदाज किया जाएगा।\
फिर, तकनीक बुनियादी रूप से **चेतावनियों के साथ प्रतिक्रिया बफर भरने** में है ताकि CSP हेडर न भेजा जाए।
[**इस व्रिटअप से**](https://blog.ssrf.kr/69) ऐसा लगता है कि एक सीएसपी सुरक्षा को छलने के लिए एक त्रुटि पृष्ठ (संभावित रूप से बिना सीएसपी के) लोड करके और उसकी सामग्री को पुनः लिखकर यह संभव था।
कुछ एक तकनीक है जो एक पृष्ठ के एंडपॉइंट में XSS (या अत्यंत सीमित XSS) का दुरुपयोग करती है **एक ही मूल से अन्य एंडपॉइंट का दुरुपयोग करने के लिए**। यह एक हमलावर पृष्ठ से विकल्पित एंडपॉइंट को लोड करके किया जाता है और फिर हमलावर पृष्ठ को वास्तविक एंडपॉइंट में रिफ्रेश किया जाता है जिसे आप दुरुपयोग करना चाहते हैं। इस तरह **विकल्पित एंडपॉइंट** प्रयोग कर सकता है **`opener`** ऑब्ज
यदि आपको वेबसाइट के किसी भी भाग को अनुमति नहीं दी गई Content Security Policy (CSP) से गुजरने के लिए, तो आप एक और तरीके का उपयोग कर सकते हैं। इस तरीके में, आप एक अलग डोमेन पर अपने अवैध स्क्रिप्ट को होस्ट कर सकते हैं और फिर उसे अपनी वेबसाइट में एम्बेड कर सकते हैं। इससे वेबसाइट के अनुशासन को उल्टा किया जा सकता है और अनुमति नहीं दी गई स्रोतों को एक्सेस किया जा सकता है।
<summary><strong>जानें AWS हैकिंग को शून्य से हीरो तक</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong> के साथ!</strong></summary>
* यदि आप अपनी कंपनी को **HackTricks में विज्ञापित करना** या **HackTricks को PDF में डाउनलोड करना** चाहते हैं तो [**सब्सक्रिप्शन प्लान्स**](https://github.com/sponsors/carlospolop) देखें!
* [**आधिकारिक PEASS & HackTricks स्वैग**](https://peass.creator-spring.com) प्राप्त करें
* हमारे विशेष [**NFTs**](https://opensea.io/collection/the-peass-family) संग्रह [**The PEASS Family**](https://opensea.io/collection/the-peass-family) खोजें
* **शामिल हों** 💬 [**Discord समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) या हमें **ट्विटर** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)** पर फॉलो** करें।
* **HackTricks** और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github रेपो में PR जमा करके अपने हैकिंग ट्रिक्स साझा करें।