<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)!
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारा विशेष [**NFTs**](https://opensea.io/collection/the-peass-family) संग्रह
* **शामिल हों** 💬 [**Discord समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) या **मेरा** ट्विटर पर **फॉलो** करें 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **हैकिंग ट्रिक्स साझा करें** द्वारा PRs सबमिट करके [**HackTricks**](https://github.com/carlospolop/hacktricks) और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos में।
सामग्री सुरक्षा नीति (CSP) को ब्राउज़र प्रौद्योगिकी के रूप में मान्यता प्राप्त है, जिसका मुख्य उद्देश्य **क्रॉस-साइट स्क्रिप्टिंग (XSS) जैसे हमलों से बचाव** है। यह ब्राउज़र द्वारा सुरक्षित रूप से लोड किए जा सकने वाले संसाधनों के मार्ग और स्रोतों को परिभाषित और विस्तारित करके काम करता है। इन संसाधनों में छवियाँ, फ्रेम्स, और जावास्क्रिप्ट जैसे तत्व शामिल होते हैं। उदाहरण के लिए, एक नीति स्वयं डोमेन (सेल्फ) से संसाधनों को लोड और क्रियान्वित करने की अनुमति देने की सक्षम हो सकती है, जिसमें इनलाइन संसाधनों और `eval`, `setTimeout`, या `setInterval` जैसे फ़ंक्शन के माध्यम से स्ट्रिंग कोड का क्रियान्वयन शामिल हो सकता है।
CSP का कार्यान्वयन **प्रतिक्रिया हेडर** के माध्यम से या **HTML पेज में मेटा तत्वों को शामिल करके** किया जाता है। इस नीति के अनुसार, ब्राउज़र सक्रिय रूप से इन निर्धारित शर्तों का पालन करते हैं और किसी भी पारदर्शित उल्लंघन को तुरंत रोक देते हैं।
*`Content-Security-Policy`: CSP को प्रवर्तित करता है; ब्राउज़र किसी भी उल्लंघन को रोकता है।
*`Content-Security-Policy-Report-Only`: मॉनिटरिंग के लिए उपयोग किया जाता है; उल्लंघन की रिपोर्ट बनाता है बिना उन्हें रोकने के। प्री-प्रोडक्शन वातावरण में टेस्टिंग के लिए आदर्श है।
CSP निर्माणात्मक और निष्क्रिय सामग्री को लोड करने के लिए मूल स्रोतों को प्रतिबंधित करता है, इनलाइन जावास्क्रिप्ट निष्पादन और `eval()` का उपयोग जैसे पहलुओं को नियंत्रित करता है। एक उदाहरण नीति है:
* **script-src**: जावास्क्रिप्ट के लिए विशिष्ट स्रोतों को अनुमति देता है, जैसे URL, इनलाइन स्क्रिप्ट, और इवेंट हैंडलर या XSLT स्टाइलशीट द्वारा ट्रिगर किए गए स्क्रिप्ट।
* **default-src**: विशिष्ट फेच निर्देशिकाओं के अभाव में संसाधनों को लाने के लिए एक डिफ़ॉल्ट नीति सेट करता है।
* **child-src**: वेब वर्कर्स और एम्बेडेड फ्रेम सामग्री के लिए अनुमति देने वाले स्रोतों को निर्दिष्ट करता है।
* **connect-src**: fetch, WebSocket, XMLHttpRequest जैसे इंटरफेस का उपयोग करके लोड किए जा सकने वाले URL को प्रतिबंधित करता है।
* **frame-src**: फ्रेम के लिए URL को प्रतिबंधित करता है।
* **frame-ancestors**: वर्तमान पृष्ठ को एम्बेड करने के लिए कौन स्रोत उपयोग कर सकते हैं, `<frame>`, `<iframe>`, `<object>`, `<embed>`, और `<applet>` जैसे तत्वों के लिए लागू है।
* **img-src**: छवियों के लिए अनुमति देने वाले स्रोतों को परिभाषित करता है।
* **font-src**: `@font-face` का उपयोग करके लोड किए जाने वाले फ़ॉन्ट के लिए मान्य स्रोतों को निर्दिष्ट करता है।
* **manifest-src**: एप्लिकेशन मैनिफ़ेस्ट फ़ाइलों के अनुमत स्रोतों को परिभाषित करता है।
* **media-src**: मीडिया ऑब्जेक्ट्स को लोड करने के लिए अनुमति देने वाले स्रोतों को परिभाषित करता है।
* **object-src**: `<object>`, `<embed>`, और `<applet>` तत्वों के लिए अनुमति देने वाले स्रोतों को परिभाषित करता है।
* **base-uri**: `<base>` तत्वों का उपयोग करके लोड करने के लिए अनुमति देने वाले URL को निर्दिष्ट करता है।
* **form-action**: फॉर्म सबमिशन के लिए मान्य एंडपॉइंट्स की सूची देता है।
* **plugin-types**: पृष्ठ द्वारा आमंत्रित किए जाने वाले माइम प्रकारों को प्रतिबंधित करता है।
* **upgrade-insecure-requests**: ब्राउज़र को HTTP URL को HTTPS में रीव्राइट करने के लिए निर्देशित करता है।
* **sandbox**: `<iframe>` के सैंडबॉक्स विशेषता के समान प्रतिबंध लागू करता है।
* **report-to**: यदि नीति का उल्लंघन होता है तो रिपोर्ट भेजा जाएगा उस समूह को निर्दिष्ट करता है।
* **worker-src**: Worker, SharedWorker, या ServiceWorker स्क्रिप्ट के लिए मान्य स्रोतों को निर्दिष्ट करता है।
* **prefetch-src**: उन स्रोतों के लिए मान्य स्रोतों को निर्दिष्ट करता है जो लोड या पूर्वाभिलेखित किए जाएंगे।
* **navigate-to**: किसी भी तरीके से एक दस्तावेज़ जिसे नेविगेट किया जा सकता है के लिए URL को प्रतिबंधित करता है (a, form, window.location, window.open, आदि)।
### स्रोत
*`*`: `data:`, `blob:`, `filesystem:` योजनाओं वाले URL को छोड़कर सभी URL की अनुमति देता है।
*`'self'`: एक ही डोमेन से लोड करने की अनुमति देता है।
*`'data'`: डेटा योजना के माध्यम से संसाधनों को लोड करने की अनुमति देता है (उदाहरण के लिए, बेस64 एन्कोडेड छवियाँ)।
*`'none'`: किसी भी स्रोत से लोड करने की अनुमति नहीं देता है।
*`'unsafe-eval'`: `eval()` और समान विधियों का उपयोग करने की अनुमति देता है, सुरक्षा कारणों से सिफारिश नहीं की जाती है।
*`'unsafe-hashes'`: विशिष्ट इनलाइन इवेंट हैंडलर्स को सक्षम करता है।
*`'unsafe-inline'`: इनलाइन `<script>` या `<style>` जैसे इनलाइन संसाधनों का उपयोग करने की अनुमति देता है, सुरक्षा कारणों से सिफारिश नहीं की जाती है।
*`'nonce'`: एक क्रिप्टोग्राफिक नॉन्स (एक बार उपयोग किया गया संख्या) का उपयोग करके विशिष्ट इनलाइन स्क्रिप्ट के लिए एक सफेद सूची।
*`'sha256-<hash>'`: विशिष्ट sha256 हैश के साथ स्क्रिप्ट को सफेद सूची में रखता है।
*`'strict-dynamic'`: यदि एक नॉन्स या हैश द्वारा सफेद सूची में शामिल किया गया है तो किसी भी स्रोत से स्क्रिप्ट लोड करने की अनुमति देता है।
*`'host'`: `example.com` जैसा विशिष्ट होस्ट निर्दिष्ट करता है।
*`https:`: HTTPS का उपयोग करने वाले उन URL को प्रतिबंधित करता है।
*`blob:`: ब्लॉब URL से संसाधनों को लोड करने की अनुमति देता है (उदाहरण के लिए, जावास्क्रिप्ट के माध्यम से बनाए गए ब्लॉब URL)।
*`filesystem:`: फ़ाइल सिस्टम से संसाधनों को लोड करने की अनुमति देता है।
*`'report-sample'`: उल्लंघन रिपोर्ट में उल्लंघन कोड का एक नमूना शामिल करता है (डीबगिंग के लिए उपयोगी)।
*`'strict-origin'`: 'self' के समान है लेकिन स्रोतों का प्रोटोकॉल सुरक्षा स्तर दस्तावेज़ से मेल खाता है (केवल सुरक्षित मूल स्रोत सुरक्षित मूल स्रोतों से संसाधनों को लोड कर सकते हैं)।
*`'strict-origin-when-cross-origin'`: समान मूल स्रोत अनुरोध करते समय पूर्ण URL भेजता है, लेकिन अनुरोध क्रॉस-मूल होने पर केवल मूल को भेजता है।
*`'unsafe-allow-redirects'`: संसाधनों को लोड करने की अनुमति देता है जो तुरंत दूसरे संसाधन पर पुनर्निर्देशित होंगे। सुरक्षा कमजोर करने के लिए सिफारिश नहीं की जाती है।
यदि आप किसी प्रकार से **अनुमत JS कोड नए स्क्रिप्ट टैग** को DOM में अपने JS कोड के साथ बना सकते हैं, क्योंकि एक अनुमत स्क्रिप्ट इसे बना रहा है, तो **नया स्क्रिप्ट टैग को निषेधित किया जाने दिया जाएगा**।
इसके अतिरिक्त, यदि आप एक फ़ाइल में **JS कोड अपलोड** कर सकते हैं जिसमें सर्वर द्वारा स्वीकृत एक्सटेंशन का उपयोग किया जाता है (जैसे: _script.png_) तो यह काफी नहीं होगा क्योंकि कुछ सर्वर जैसे अपाचे सर्वर **एक्सटेंशन पर आधारित फ़ाइल के MIME प्रकार का चयन करते हैं** और Chrome जैसे ब्राउज़र **उसमें जावास्क्रिप्ट को निषेधित करेगा** जो कुछ एक छवि होना चाहिए। "आशा है", यहाँ गलतियाँ हैं। उदाहरण के लिए, एक CTF से मुझे पता चला कि **अपाचे को पता नहीं है** कि _**.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 कोड को चलाने के लिए CSP को छलकरते हुए:
ऐसे परिदृश्य जहाँ `script-src` को `self` और एक विशेष डोमेन जो whitelist किया गया है पर सेट किया गया है, JSONP का उपयोग करके बाईपास किया जा सकता है। JSONP endpoints असुरक्षित कॉलबैक मेथड को संभावित करते हैं जिससे हमलावार XSS कार्रवाई कर सकते हैं, कार्यक्षम पेलोड:
यदि **विश्वसनीय एंडपॉइंट में ओपन रीडायरेक्ट होता है**, तो एक ही सुरक्षा दोष होगा क्योंकि यदि प्रारंभिक एंडपॉइंट विश्वसनीय है, तो रीडायरेक्ट्स भी विश्वसनीय होते हैं।
[निम्नलिखित पोस्ट](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses) में वर्णित के अनुसार, कई तृतीय पक्ष डोमेन, जो किसी स्थान पर CSP में अनुमति हो सकते हैं, उनका दुरुपयोग डेटा को बाहर ले जाने या JavaScript को क्रियान्वित करने के लिए किया जा सकता है। कुछ तृतीय-पक्ष हैं:
यदि आपके लक्ष्य के CSP में किसी भी अनुमत डोमेन को पाते हैं, तो संभावना है कि आप तृतीय-पक्ष सेवा पर पंजीकरण करके CSP को बाईपास कर सकते हैं, या तो उस सेवा को डेटा को बाहर ले जाने के लिए या कोड को क्रियान्वित करने के लिए।
In this section, we will discuss various techniques to bypass Content Security Policy (CSP) implemented on a web application.
### What is CSP?
Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, such as Cross Site Scripting (XSS) and data injection attacks. CSP is implemented by using an HTTP header to restrict the types of content that can be loaded on a web page.
### Bypassing CSP
There are several ways to bypass CSP, including:
1.**Inline Scripts**: Executing code directly within HTML attributes or tags.
2.**External Scripts**: Loading scripts from whitelisted domains.
3.**Unsafe Inline**: Using `'unsafe-inline'` keyword to allow inline scripts.
4.**Unsafe Eval**: Using `'unsafe-eval'` keyword to allow `eval()` function.
5.**Data Protocol**: Using the `data:` protocol to execute scripts.
6.**Nonce-Based CSP Bypass**: Generating and including a nonce value in the CSP header.
### Conclusion
By understanding how CSP works and the various bypass techniques available, you can effectively test the security of web applications and help developers improve their CSP configurations.
आपको डेटा को बाहर ले जाने की क्षमता होनी चाहिए, जिसे [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/) के साथ हमेशा किया गया है। इस मामले में, आप निम्नलिखित सामान्य चरणों का पालन करते हैं:
1. एक नया "Facebook Login" ऐप बनाएं और "वेबसाइट" का चयन करें।
1. "सेटिंग्स -> मूल" पर जाएं और अपना "ऐप आईडी" प्राप्त करें।
1. उस लक्ष्य साइट पर जहां से आप डेटा बाहर ले जाना चाहते हैं, आप डेटा को सीधे "फेसबुक एसडीके" गैजेट "fbq" का उपयोग करके "कस्टम इवेंट" और डेटा पेलोड के माध्यम से बाहर ले सकते हैं।
1. अपने ऐप "इवेंट मैनेजर" पर जाएं और आपने बनाया ऐप्लिकेशन चुनें (नोट करें कि इवेंट मैनेजर इस प्रकार के यूआरएल में पाया जा सकता है: https://www.facebook.com/events_manager2/list/pixel/[app-id]/test_events)
1. "टेस्ट इवेंट्स" टैब का चयन करें ताकि "आपकी" वेबसाइट द्वारा भेजे जा रहे इवेंट्स देख सकें।
फिर, पीड़ित पक्ष पर, आप निम्नलिखित कोड को निष्पादित करते हैं ताकि आप अटैकर के फेसबुक डेवलपर खाते के एप्लिकेशन आईडी पर फेसबुक ट्रैकिंग पिक्सल को प्रारंभ करें और एक कस्टम इवेंट जारी करें:
### पिछले तालिका में उल्लिखित अन्य सात थर्ड-पार्टी डोमेनों के लिए, आप उनका दुरुपयोग करने के कई और तरीके हैं। अन्य थर्ड-पार्टी दुरुपयोगों के बारे में अतिरिक्त व्याख्यान के लिए पिछले [ब्लॉग पोस्ट](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses) का संदर्भ दें।
### RPO (Relative Path Overwrite) के माध्यम से बायपास <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>
यह काम करता है क्योंकि ब्राउज़र के लिए आप `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/) कर सकते हैं।
इसके अतिरिक्त, यदि पृष्ठ एक उपयुक्त **Nonce** का उपयोग करके एक संबंधित पथ का स्क्रिप्ट लोड कर रहा है (जैसे `<script src="/js/app.js">`), तो आप **बेस टैग** का दुरुपयोग करके इसे **अपनी सर्वर से स्क्रिप्ट लोड** करने के लिए कर सकते हैं जिससे एक XSS प्राप्त हो।\
यदि संकटपूर्ण पृष्ठ **httpS** के साथ लोड हो रहा है, तो बेस में httpS url का उपयोग करें।
एक विशेष नीति जिसे सामग्री सुरक्षा नीति (CSP) के रूप में जाना जाता है, जावास्क्रिप्ट इवेंट्स को प्रतिबंधित कर सकती है। फिर भी, AngularJS एक वैकल्पिक रूप में कस्टम इवेंट्स को पेश करता है। एक इवेंट के भीतर, AngularJS एक अद्वितीय ऑब्ज
यह स्निपेट `ng-focus` निर्देशिका का उपयोग हासिल करता है घटना को ट्रिगर करने के लिए, `$event.path|orderBy` का उपयोग करता है `path` एरे को संशोधित करने के लिए, और `विंडो` ऑब्जेक्ट का लाभ उठाता है `alert()` फ़ंक्शन को क्रियान्वित करने के लिए, इसके फलस्वरूप `document.cookie` को प्रकट करता है।
हालांकि, [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 के रूप में) को **चलाने** के लिए उसे **कर सकते हैं** छवि, से **JS** निकालें और **इसे****चलाएं**: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
यदि आप द्वारा भेजे गए **पैरामीटर** को **नीति** के **घोषणा** के **अंदर पेस्ट** किया जा रहा है, तो आप **नीति** को उस प्रकार से **बदल** सकते हैं जिससे वह **अनर्थक** हो जाए। आप इनमें से किसी भी बाइपास के साथ स्क्रिप्ट 'unsafe-inline' को **अनुमति** दे सकते हैं:
क्योंकि यह निर्देशिका **मौजूदा 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)
नोटिस करें निर्देशिका `'unsafe-inline'` की कमी को।\
इस बार आप पीड़ित को एक पृष्ठ **अपने नियंत्रण में****XSS** के माध्यम से लोड करने के लिए कर सकते हैं `<iframe`। इस बार आप पीड़ित से जिस पृष्ठ को आप जानकारी निकालना चाहते हैं (**CSRF**) उस पृष्ठ तक पहुंचने के लिए करेंगे। आप पृष्ठ की सामग्री तक पहुंच नहीं सकते, लेकिन अगर किसी प्रकार से आप **पृष्ठ को लोड होने में समय को नियंत्रित कर सकते हैं** तो आप आवश्यक जानकारी निकाल सकते हैं।
इस बार एक **ध्वज** निकाला जाएगा, जब किसी **वर्ण को सही ढंग से अनुमानित** किया जाता है तो **प्रतिक्रिया** में **अधिक समय** लेता है नींद कार्य के कारण। फिर, आप ध्वज निकाल सकेंगे:
```html
<!--code from https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle -->
इस हमले में कुछ सामाजिक इंजीनियरिंग शामिल होगी जहां हमलावर **उपयोगकर्ता को यह धोखा देता है कि वह ब्राउज़र के बुकमार्कलेट पर एक लिंक को खींचकर छोड़े**। यह बुकमार्कलेट **हानिकारक जावास्क्रिप्ट** कोड शामिल करेगा जो जब खींचकर छोड़ा या क्लिक किया जाएगा, तो वर्तमान वेब विंडो के संदर्भ में क्रियान्वित होगा, **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 के कार्यान्वयन और ब्राउज़र में व्यवहार का शोध किया जाता है, जिससे ऐसी दिखाई देने वाली सुरक्षित नीतियाँ अनजाने में संवेदनशील जानकारी छिपा सकती है।
यहाँ से ट्रिक देखें [**यहाँ**](https://ctftime.org/writeup/29310)।
PHP को डिफ़ॉल्ट रूप से 4096 बाइट तक की प्रतिक्रिया को बफर करने के लिए जाना जाता है। इसलिए, अगर PHP एक चेतावनी दिखा रहा है, तो **चेतावनियों में पर्याप्त डेटा प्रदान करके**, **प्रतिक्रिया** को **CSP हेडर** से **पहले****भेज दिया जाएगा**, जिससे हेडर को नजरअंदाज किया जाएगा।\
फिर, तकनीक बुनियादी रूप से **चेतावनियों से प्रतिक्रिया बफर भरने** में है ताकि CSP हेडर न भेजा जाए।
[**इस व्रिटअप से**](https://blog.ssrf.kr/69) लगता है कि एक CSP सुरक्षा को छलने की संभावना थी जिसमें एक त्रुटि पृष्ठ (संभावित रूप से CSP के बिना) लोड करके और उसकी सामग्री को पुनरलेखन करके।
SOME एक तकनीक है जो एक पृष्ठ के एंडपॉइंट में XSS (या अत्यधिक सीमित XSS) का दुरुपयोग करती है **एक हमला करने के लिए****उसी मूल स्रोत के अन्य एंडपॉइंट्स का दुरुपयोग करने के लिए.** यह एक हमला करने के लिए किया जाता है जिसमें हमलावर पृष्ठ को एक हमलावर पृष्ठ से विकल्पित एंडपॉइंट लोड करता है और फिर हमलावर पृष्ठ को उसी मूल स्रोत में वास्तविक एंडपॉइंट पर ताजगी देता है जिसे आप दुरुपयोग करना चाहते हैं. इस तरह **विकल्पित एंडपॉइंट** प्रयोग कर सकता है **`opener`** ऑब्ज
In some scenarios, the target website may allow loading scripts from a CDN that is not included in the CSP directive. By hosting a malicious script on an untrusted CDN and including it in the target website, it may be possible to bypass the CSP restrictions.
### Proof of Concept
1. Host a malicious script on an untrusted CDN.
2. Include the script in the target website using a `<script>` tag.
3. Access the target website and observe if the script executes despite CSP restrictions.
### Impact
Successful exploitation of this vulnerability could allow an attacker to execute arbitrary scripts on the target website, bypassing CSP protections.
### Recommendation
Ensure that all CDNs and external sources used in the website are trusted and included in the CSP directive to prevent such bypasses.
<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) देखें!
