Learn & practice AWS Hacking:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Learn & practice GCP Hacking: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
Content Security Policy (CSP) को एक ब्राउज़र तकनीक के रूप में पहचाना जाता है, जिसका मुख्य उद्देश्य **क्रॉस-साइट स्क्रिप्टिंग (XSS)** जैसे हमलों से **सुरक्षा प्रदान करना** है। यह उन पथों और स्रोतों को परिभाषित और विस्तृत करके कार्य करता है जिनसे संसाधनों को ब्राउज़र द्वारा सुरक्षित रूप से लोड किया जा सकता है। ये संसाधन छवियों, फ्रेमों और जावास्क्रिप्ट जैसे विभिन्न तत्वों को शामिल करते हैं। उदाहरण के लिए, एक नीति एक ही डोमेन (स्वयं) से संसाधनों को लोड और निष्पादित करने की अनुमति दे सकती है, जिसमें इनलाइन संसाधन और `eval`, `setTimeout`, या `setInterval` जैसी कार्यों के माध्यम से स्ट्रिंग कोड का निष्पादन शामिल है।
CSP का कार्यान्वयन **प्रतिक्रिया हेडर** के माध्यम से या **HTML पृष्ठ में मेटा तत्वों को शामिल करके** किया जाता है। इस नीति का पालन करते हुए, ब्राउज़र सक्रिय रूप से इन शर्तों को लागू करते हैं और तुरंत किसी भी पहचानी गई उल्लंघनों को अवरुद्ध कर देते हैं।
*`Content-Security-Policy`: CSP को लागू करता है; ब्राउज़र किसी भी उल्लंघन को ब्लॉक करता है।
*`Content-Security-Policy-Report-Only`: मॉनिटरिंग के लिए उपयोग किया जाता है; उल्लंघनों की रिपोर्ट करता है बिना उन्हें ब्लॉक किए। प्री-प्रोडक्शन वातावरण में परीक्षण के लिए आदर्श।
CSP सक्रिय और निष्क्रिय सामग्री को लोड करने के लिए मूल स्थानों को प्रतिबंधित करता है, जैसे इनलाइन जावास्क्रिप्ट निष्पादन और `eval()` के उपयोग को नियंत्रित करता है। एक उदाहरण नीति है:
* **script-src**: JavaScript के लिए विशिष्ट स्रोतों की अनुमति देता है, जिसमें URLs, इनलाइन स्क्रिप्ट और इवेंट हैंडलर्स या XSLT स्टाइलशीट द्वारा ट्रिगर की गई स्क्रिप्ट शामिल हैं।
* **default-src**: जब विशिष्ट फेच निर्देश अनुपस्थित होते हैं, तो संसाधनों को लाने के लिए एक डिफ़ॉल्ट नीति सेट करता है।
* **child-src**: वेब वर्कर्स और एम्बेडेड फ्रेम सामग्री के लिए अनुमत संसाधनों को निर्दिष्ट करता है।
* **connect-src**: उन URLs को प्रतिबंधित करता है जिन्हें fetch, WebSocket, XMLHttpRequest जैसी इंटरफेस का उपयोग करके लोड किया जा सकता है।
* **frame-src**: फ्रेम के लिए URLs को प्रतिबंधित करता है।
* **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>` तत्वों का उपयोग करके लोड करने के लिए अनुमत URLs को निर्दिष्ट करता है।
* **form-action**: फ़ॉर्म सबमिशन के लिए मान्य एंडपॉइंट्स की सूची बनाता है।
* **plugin-types**: उन माइम प्रकारों को प्रतिबंधित करता है जिन्हें एक पृष्ठ सक्रिय कर सकता है।
* **upgrade-insecure-requests**: ब्राउज़रों को HTTP URLs को HTTPS में फिर से लिखने के लिए निर्देशित करता है।
* **report-to**: निर्दिष्ट करता है कि यदि नीति का उल्लंघन होता है तो रिपोर्ट किस समूह को भेजी जाएगी।
* **worker-src**: वर्कर, SharedWorker, या ServiceWorker स्क्रिप्ट के लिए मान्य स्रोतों को निर्दिष्ट करता है।
* **prefetch-src**: उन संसाधनों के लिए मान्य स्रोतों को निर्दिष्ट करता है जिन्हें लाया जाएगा या पहले से लाया जाएगा।
* **navigate-to**: उन URLs को प्रतिबंधित करता है जिन पर कोई दस्तावेज़ किसी भी तरीके से नेविगेट कर सकता है (a, form, window.location, window.open, आदि।)
### Sources
*`*`: सभी URLs की अनुमति देता है सिवाय `data:`, `blob:`, `filesystem:` स्कीम वाले।
*`'self'`: उसी डोमेन से लोड करने की अनुमति देता है।
*`'data'`: डेटा स्कीम के माध्यम से संसाधनों को लोड करने की अनुमति देता है (जैसे, Base64 एन्कोडेड चित्र)।
*`'none'`: किसी भी स्रोत से लोडिंग को ब्लॉक करता है।
*`'unsafe-eval'`: `eval()` और समान विधियों के उपयोग की अनुमति देता है, सुरक्षा कारणों से अनुशंसित नहीं है।
*`'unsafe-hashes'`: विशिष्ट इनलाइन इवेंट हैंडलर्स को सक्षम करता है।
*`'unsafe-inline'`: इनलाइन `<script>` या `<style>` जैसे इनलाइन संसाधनों के उपयोग की अनुमति देता है, सुरक्षा कारणों से अनुशंसित नहीं है।
*`'nonce'`: एक क्रिप्टोग्राफिक नॉनस (एक बार उपयोग किया जाने वाला नंबर) का उपयोग करके विशिष्ट इनलाइन स्क्रिप्ट के लिए एक व्हाइटलिस्ट।
* यदि आपके पास JS सीमित निष्पादन है, तो यह संभव है कि आप पृष्ठ के अंदर एक उपयोग किया गया नॉनस प्राप्त करें `doc.defaultView.top.document.querySelector("[nonce]")` के साथ और फिर इसे एक दुर्भावनापूर्ण स्क्रिप्ट लोड करने के लिए पुन: उपयोग करें (यदि strict-dynamic का उपयोग किया गया है, तो कोई भी अनुमत स्रोत नए स्रोतों को लोड कर सकता है इसलिए इसकी आवश्यकता नहीं है), जैसे कि:
*`'report-sample'`: उल्लंघन रिपोर्ट में उल्लंघन करने वाले कोड का एक नमूना शामिल करता है (डीबगिंग के लिए उपयोगी)।
*`'strict-origin'`: 'self' के समान लेकिन सुनिश्चित करता है कि स्रोतों का प्रोटोकॉल सुरक्षा स्तर दस्तावेज़ से मेल खाता है (केवल सुरक्षित मूल सुरक्षित मूल से संसाधन लोड कर सकते हैं)।
*`'strict-origin-when-cross-origin'`: समान मूल अनुरोध करते समय पूर्ण URLs भेजता है लेकिन केवल तब मूल भेजता है जब अनुरोध क्रॉस-ओरिजिन हो।
*`'unsafe-allow-redirects'`: संसाधनों को लोड करने की अनुमति देता है जो तुरंत किसी अन्य संसाधन पर रीडायरेक्ट करेंगे। सुरक्षा को कमजोर करने के कारण अनुशंसित नहीं है।
यदि आप किसी तरह से एक **अनुमत JS कोड द्वारा DOM में एक नया स्क्रिप्ट टैग बनाया जा सकता है** अपने JS कोड के साथ, क्योंकि एक अनुमत स्क्रिप्ट इसे बना रही है, तो **नया स्क्रिप्ट टैग निष्पादित होने की अनुमति दी जाएगी**।
हालांकि, यह अत्यधिक संभावित है कि सर्वर **अपलोड की गई फ़ाइल को मान्य कर रहा है** और केवल आपको **निर्धारित प्रकार की फ़ाइलें अपलोड करने** की अनुमति देगा।
इसके अलावा, भले ही आप सर्वर द्वारा स्वीकार की गई एक्सटेंशन (जैसे: _script.png_) का उपयोग करके फ़ाइल के अंदर **JS कोड अपलोड** कर सकें, यह पर्याप्त नहीं होगा क्योंकि कुछ सर्वर जैसे अपाचे सर्वर **फाइल के एक्सटेंशन के आधार पर MIME प्रकार का चयन करते हैं** और Chrome जैसे ब्राउज़र **Javascript** कोड को कुछ ऐसा करने से **अस्वीकृत** कर देंगे जो एक छवि होनी चाहिए। "उम्मीद है", वहाँ गलतियाँ हैं। उदाहरण के लिए, एक CTF से मैंने सीखा कि **Apache को _**.wave**_ एक्सटेंशन का पता नहीं है, इसलिए यह इसे **MIME प्रकार जैसे audio/\*** के साथ सर्व नहीं करता है।
यहां से, यदि आप एक XSS और एक फ़ाइल अपलोड पाते हैं, और आप एक **गलत व्याख्यायित एक्सटेंशन** खोजने में सफल होते हैं, तो आप उस एक्सटेंशन के साथ एक फ़ाइल अपलोड करने और स्क्रिप्ट की सामग्री को आज़मा सकते हैं। या, यदि सर्वर अपलोड की गई फ़ाइल के सही प्रारूप की जांच कर रहा है, तो एक पॉलीग्लॉट बनाएं ([कुछ पॉलीग्लॉट उदाहरण यहाँ](https://github.com/Polydet/polyglot-database))।
यदि JS इंजेक्ट करना संभव नहीं है, तो आप उदाहरण के लिए क्रेडेंशियल्स को **फॉर्म एक्शन को इंजेक्ट करके** निकालने की कोशिश कर सकते हैं (और शायद पासवर्ड प्रबंधकों से पासवर्ड को ऑटो-फिल करने की उम्मीद कर सकते हैं)। आप [**इस रिपोर्ट में एक उदाहरण पा सकते हैं**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp)। इसके अलावा, ध्यान दें कि `default-src` फॉर्म क्रियाओं को कवर नहीं करता है।
#### Angular का उपयोग करते हुए Payloads + एक पुस्तकालय जिसमें ऐसे फ़ंक्शन हैं जो `window` ऑब्जेक्ट लौटाते हैं ([इस पोस्ट को देखें](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):
पोस्ट दिखाती है कि आप `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) के अनुसार, आप CSP के भीतर [https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) का दुरुपयोग कर सकते हैं ताकि CSP को बायपास करते हुए मनचाहा JS कोड निष्पादित किया जा सके:
Google Apps Script का दुरुपयोग करना संभव है ताकि script.google.com के अंदर एक पृष्ठ में जानकारी प्राप्त की जा सके। जैसे कि इसे [इस रिपोर्ट में किया गया है](https://embracethered.com/blog/posts/2023/google-bard-data-exfiltration/)।
ऐसे परिदृश्य जहां `script-src` को `self` और एक विशेष डोमेन पर सेट किया गया है जिसे व्हाइटलिस्ट किया गया है, JSONP का उपयोग करके बायपास किया जा सकता है। JSONP एंडपॉइंट असुरक्षित कॉलबैक विधियों की अनुमति देते हैं जो एक हमलावर को XSS करने की अनुमति देते हैं, कार्यशील पेलोड:
यदि **विश्वसनीय एंडपॉइंट में एक ओपन रीडायरेक्ट है**, तो वही भेद्यता उत्पन्न होगी क्योंकि यदि प्रारंभिक एंडपॉइंट विश्वसनीय है, तो रीडायरेक्ट भी विश्वसनीय हैं।
जैसा कि [निम्नलिखित पोस्ट](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses) में वर्णित है, कई थर्ड पार्टी डोमेन हैं, जो CSP में कहीं न कहीं अनुमति दी जा सकती हैं, जिन्हें डेटा को एक्सफिल्ट्रेट करने या जावास्क्रिप्ट कोड निष्पादित करने के लिए दुरुपयोग किया जा सकता है। इनमें से कुछ थर्ड-पार्टी हैं:
यदि आप अपने लक्ष्य के CSP में किसी भी अनुमति प्राप्त डोमेन को पाते हैं, तो संभावना है कि आप थर्ड-पार्टी सेवा पर पंजीकरण करके CSP को बायपास कर सकते हैं और, या तो उस सेवा पर डेटा को एक्सफिल्ट्रेट कर सकते हैं या कोड निष्पादित कर सकते हैं।
आपको डेटा को एक्सफिल्ट्रेट करने में सक्षम होना चाहिए, जैसे कि हमेशा [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" ऐप बनाएं और "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" टैब का चयन करें ताकि "आपकी" वेबसाइट द्वारा भेजे जा रहे इवेंट्स को देखा जा सके।
फिर, पीड़ित पक्ष पर, आप Facebook ट्रैकिंग पिक्सेल को हमलावर के Facebook डेवलपर खाता ऐप-आईडी की ओर इंगित करने और इस तरह का एक कस्टम इवेंट जारी करने के लिए निम्नलिखित कोड निष्पादित करते हैं:
जैसे कि पिछले तालिका में निर्दिष्ट अन्य सात तृतीय-पक्ष डोमेन के लिए, उन्हें दुरुपयोग करने के कई अन्य तरीके हैं। अन्य तृतीय-पक्ष दुरुपयोगों के बारे में अतिरिक्त स्पष्टीकरण के लिए पहले के [ब्लॉग पोस्ट](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>
पथ प्रतिबंधों को बायपास करने के लिए उपरोक्त पुनर्निर्देशन के अलावा, कुछ सर्वरों पर उपयोग की जाने वाली एक और तकनीक है जिसे Relative Path Overwrite (RPO) कहा जाता है।
यह काम करता है क्योंकि ब्राउज़र के लिए, आप `https://example.com/scripts/react/` के अंतर्गत स्थित `..%2fangular%2fangular.js` नामक फ़ाइल को लोड कर रहे हैं, जो CSP के अनुरूप है।
∑, वे इसे डिकोड करेंगे, प्रभावी रूप से `https://example.com/scripts/react/../angular/angular.js` का अनुरोध करेंगे, जो `https://example.com/scripts/angular/angular.js` के बराबर है।
समाधान यह है कि सर्वर-साइड पर `%2f` को `/` के रूप में नहीं माना जाए, जिससे ब्राउज़र और सर्वर के बीच सुसंगत व्याख्या सुनिश्चित हो सके और इस समस्या से बचा जा सके।
यदि **base-uri** निर्देश गायब है तो आप इसका दुरुपयोग कर सकते हैं [**dangling markup injection**](../dangling-markup-html-scriptless-injection/) करने के लिए।
इसके अलावा, यदि **पृष्ठ एक सापेक्ष पथ का उपयोग करके स्क्रिप्ट लोड कर रहा है** (जैसे `<script src="/js/app.js">`) एक **Nonce** का उपयोग करते हुए, आप **base****tag** का दुरुपयोग कर सकते हैं ताकि यह **आपके अपने सर्वर से स्क्रिप्ट लोड करे जिससे XSS प्राप्त हो।**\
यदि कमजोर पृष्ठ **httpS** के साथ लोड होता है, तो बेस में httpS URL का उपयोग करें।
एक विशिष्ट नीति जिसे सामग्री सुरक्षा नीति (CSP) के रूप में जाना जाता है, जावास्क्रिप्ट घटनाओं को प्रतिबंधित कर सकती है। फिर भी, AngularJS एक वैकल्पिक के रूप में कस्टम घटनाएँ पेश करता है। एक घटना के भीतर, AngularJS एक अद्वितीय ऑब्जेक्ट `$event` प्रदान करता है, जो मूल ब्राउज़र घटना ऑब्जेक्ट को संदर्भित करता है। इस `$event` ऑब्जेक्ट का उपयोग CSP को दरकिनार करने के लिए किया जा सकता है। विशेष रूप से, Chrome में, `$event/event` ऑब्जेक्ट में एक `path` विशेषता होती है, जो घटना के निष्पादन श्रृंखला में शामिल ऑब्जेक्टों की एक सरणी रखती है, जिसमें `window` ऑब्जेक्ट हमेशा अंत में स्थित होता है। यह संरचना सैंडबॉक्स बचाव रणनीतियों के लिए महत्वपूर्ण है।
इस सरणी को `orderBy` फ़िल्टर की ओर निर्देशित करके, इसे पुनरावृत्त करना संभव है, अंतिम तत्व ( `window` ऑब्जेक्ट) का उपयोग करके एक वैश्विक फ़ंक्शन जैसे `alert()` को सक्रिय करना। नीचे प्रदर्शित कोड स्निपेट इस प्रक्रिया को स्पष्ट करता है:
यह स्निपेट `ng-focus` निर्देश का उपयोग करके इवेंट को ट्रिगर करने को उजागर करता है, `$event.path|orderBy` का उपयोग करके `path` एरे को संशोधित करता है, और `alert()` फ़ंक्शन को निष्पादित करने के लिए `window` ऑब्जेक्ट का लाभ उठाता है, इस प्रकार `document.cookie` को प्रकट करता है।
एक CSP नीति जो Angular JS एप्लिकेशन में स्क्रिप्ट लोडिंग के लिए डोमेन को व्हाइटलिस्ट करती है, को कॉलबैक फ़ंक्शनों और कुछ कमजोर वर्गों के आह्वान के माध्यम से बायपास किया जा सकता है। इस तकनीक पर अधिक जानकारी इस [git repository](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh\*t,-it's-CSP!%22) पर उपलब्ध विस्तृत गाइड में मिल सकती है।
अन्य JSONP मनमाने निष्पादन एंडपॉइंट्स [**यहां**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) पाए जा सकते हैं (इनमें से कुछ हटा दिए गए या ठीक कर दिए गए हैं)
जब CSP सर्वर-साइड रीडायरेक्शन का सामना करता है तो क्या होता है? यदि रीडायरेक्शन एक अलग मूल की ओर ले जाता है जो अनुमति नहीं है, तो यह अभी भी विफल हो जाएगा।
हालांकि, [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'** की **अनुमति** दे सकते हैं:
आप यहाँ एक उदाहरण पा सकते हैं: [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)
इस बार आप पीड़ित को **XSS** के माध्यम से **आपके नियंत्रण** में एक पृष्ठ **लोड** करने के लिए मजबूर कर सकते हैं `<iframe`। इस बार आप पीड़ित को उस पृष्ठ तक पहुँचने के लिए मजबूर करेंगे जहाँ से आप जानकारी निकालना चाहते हैं (**CSRF**)। आप पृष्ठ की सामग्री तक पहुँच नहीं सकते, लेकिन यदि किसी तरह आप **पृष्ठ को लोड करने में लगने वाले समय को नियंत्रित कर सकते हैं** तो आप आवश्यक जानकारी निकाल सकते हैं।
इस बार एक **झंडा** निकाला जाएगा, जब भी एक **चर सही अनुमानित** किया जाता है SQLi के माध्यम से **प्रतिक्रिया****अधिक समय** लेती है नींद फ़ंक्शन के कारण। फिर, आप झंडा निकालने में सक्षम होंगे:
यह हमला कुछ सामाजिक इंजीनियरिंग को शामिल करेगा जहाँ हमलावर **उपयोगकर्ता को ब्राउज़र के बुकमार्कलेट पर एक लिंक खींचने और छोड़ने के लिए मनाता है**। यह बुकमार्कलेट **दुष्ट जावास्क्रिप्ट** कोड को शामिल करेगा जो खींचने और छोड़ने या क्लिक करने पर वर्तमान वेब विंडो के संदर्भ में निष्पादित होगा, **CSP को बायपास करते हुए और संवेदनशील जानकारी** जैसे कुकीज़ या टोकन चुराने की अनुमति देगा।
[**इस CTF लेख में**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), CSP को एक अनुमत iframe के अंदर एक अधिक प्रतिबंधात्मक CSP को इंजेक्ट करके बायपास किया गया है जो एक विशिष्ट JS फ़ाइल को लोड करने की अनुमति नहीं देता है, जो फिर, **प्रोटोटाइप प्रदूषण** या **DOM क्लॉबरिंग** के माध्यम से **एक अलग स्क्रिप्ट का दुरुपयोग करके एक मनमाना स्क्रिप्ट लोड करने की अनुमति देता है**।
[**इस CTF लेख**](https://github.com/aszx87410/ctf-writeups/issues/48) में, **HTML injection** के माध्यम से **CSP** को और अधिक **सीमित** करना संभव था, जिससे CSTI को रोकने वाला एक स्क्रिप्ट अक्षम हो गया और इसलिए **कमजोरी का लाभ उठाया जा सका।**\
CSP को **HTML मेटा टैग** का उपयोग करके अधिक सीमित किया जा सकता है और इनलाइन स्क्रिप्ट को अक्षम किया जा सकता है **उनके****nonce** को अनुमति देकर और **sha के माध्यम से विशिष्ट इनलाइन स्क्रिप्ट को सक्षम करके**:
यदि आप सर्वर को **`Content-Security-Policy-Report-Only`** हेडर के साथ **आपके द्वारा नियंत्रित मान** के साथ प्रतिक्रिया देने में सफल होते हैं (शायद CRLF के कारण), तो आप इसे अपने सर्वर की ओर इंगित कर सकते हैं और यदि आप **JS सामग्री** को **`<script>`** के साथ लपेटते हैं और क्योंकि CSP द्वारा `unsafe-inline` की अनुमति नहीं है, तो यह **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 के संबंध में iframes को संभालने में विभिन्न व्यवहार होते हैं, जो संवेदनशील जानकारी के संभावित लीक का कारण बन सकते हैं।
एक और तकनीक CSP का स्वयं शोषण करना है ताकि गुप्त सबडोमेन का अनुमान लगाया जा सके। यह विधि एक बाइनरी सर्च एल्गोरिदम पर निर्भर करती है और CSP को विशिष्ट डोमेन को शामिल करने के लिए समायोजित करती है जिन्हें जानबूझकर ब्लॉक किया गया है। उदाहरण के लिए, यदि गुप्त सबडोमेन अज्ञात वर्णों से बना है, तो आप CSP निर्देश को संशोधित करके इन सबडोमेन को ब्लॉक या अनुमति देने के लिए विभिन्न सबडोमेन का क्रमिक परीक्षण कर सकते हैं। यहाँ एक स्निपेट है जो दिखाता है कि CSP को इस विधि को सुविधाजनक बनाने के लिए कैसे सेट किया जा सकता है:
CSP द्वारा अवरुद्ध या अनुमत अनुरोधों की निगरानी करके, कोई भी गुप्त उपडोमेन में संभावित वर्णों को संकीर्ण कर सकता है, अंततः पूर्ण URL का पता लगा सकता है।
दोनों विधियाँ CSP कार्यान्वयन और ब्राउज़रों में व्यवहार के बारीकियों का लाभ उठाती हैं, यह प्रदर्शित करते हुए कि कैसे प्रतीत होता है कि सुरक्षित नीतियाँ अनजाने में संवेदनशील जानकारी लीक कर सकती हैं।
[**इस वीडियो में अंतिम तकनीक**](https://www.youtube.com/watch?v=Sm4G6cAHjWM) के अनुसार, बहुत सारे पैरामीटर (1001 GET पैरामीटर, हालांकि आप इसे POST पैरामीटर और 20 से अधिक फ़ाइलों के साथ भी कर सकते हैं) भेजना। PHP वेब कोड में कोई भी परिभाषित **`header()`** **नहीं भेजा जाएगा** क्योंकि यह त्रुटि उत्पन्न करेगा।
PHP को डिफ़ॉल्ट रूप से **4096** बाइट्स तक प्रतिक्रिया को **बफर** करने के लिए जाना जाता है। इसलिए, यदि PHP एक चेतावनी दिखा रहा है, तो **चेतावनियों के अंदर पर्याप्त डेटा प्रदान करके**, **प्रतिक्रिया****CSP हेडर** से **पहले****भेजी जाएगी**, जिससे हेडर को अनदेखा किया जाएगा।\
फिर, तकनीक मूल रूप से **चेतावनियों के साथ प्रतिक्रिया बफर को भरने** में है ताकि CSP हेडर न भेजा जाए।
[**इस लेख**](https://blog.ssrf.kr/69) से ऐसा लगता है कि एक त्रुटि पृष्ठ (संभावित रूप से CSP के बिना) लोड करके CSP सुरक्षा को बायपास करना संभव था और इसकी सामग्री को फिर से लिखा गया।
SOME एक तकनीक है जो एक XSS (या अत्यधिक सीमित XSS) **एक पृष्ठ के अंत बिंदु में** का दुरुपयोग करती है ताकि **एक ही मूल के अन्य अंत बिंदुओं का दुरुपयोग** किया जा सके। यह एक हमलावर पृष्ठ से कमजोर अंत बिंदु को लोड करके और फिर हमलावर पृष्ठ को उसी मूल में वास्तविक अंत बिंदु पर ताज़ा करके किया जाता है जिसे आप दुरुपयोग करना चाहते हैं। इस तरह **कमजोर अंत बिंदु****`opener`** ऑब्जेक्ट का उपयोग कर सकता है **पेलोड** में **DOM** तक **पहुँचने के लिए****वास्तविक अंत बिंदु का दुरुपयोग** करने के लिए। अधिक जानकारी के लिए देखें:
इसके अलावा, **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 हमले** का दुरुपयोग **कमजोर****callback** अंत बिंदु के माध्यम से कर सकता है जो **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 है जो आपको **बाहरी सर्वरों के साथ बातचीत** करने की अनुमति नहीं देती है, तो कुछ चीजें हैं जो आप हमेशा जानकारी को एक्सफिल्ट्रेट करने के लिए कर सकते हैं।
Learn & practice AWS Hacking:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Learn & practice GCP Hacking: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.