Content Security Policy (CSP) Bypass
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Join HackenProof Discord server to communicate with experienced hackers and bug bounty hunters!
Hacking Insights Engage with content that delves into the thrill and challenges of hacking
Real-Time Hack News Keep up-to-date with fast-paced hacking world through real-time news and insights
Latest Announcements Stay informed with the newest bug bounties launching and crucial platform updates
Join us on Discord and start collaborating with top hackers today!
Content Security Policy (CSP) को एक ब्राउज़र तकनीक के रूप में पहचाना जाता है, जिसका मुख्य उद्देश्य क्रॉस-साइट स्क्रिप्टिंग (XSS) जैसे हमलों से सुरक्षा प्रदान करना है। यह उन पथों और स्रोतों को परिभाषित और विस्तृत करके कार्य करता है जिनसे संसाधनों को ब्राउज़र द्वारा सुरक्षित रूप से लोड किया जा सकता है। ये संसाधन छवियों, फ्रेमों और जावास्क्रिप्ट जैसे विभिन्न तत्वों को शामिल करते हैं। उदाहरण के लिए, एक नीति एक ही डोमेन (स्वयं) से संसाधनों को लोड और निष्पादित करने की अनुमति दे सकती है, जिसमें इनलाइन संसाधन और eval, setTimeout, या setInterval जैसी कार्यों के माध्यम से स्ट्रिंग कोड का निष्पादन शामिल है।
CSP का कार्यान्वयन प्रतिक्रिया हेडर के माध्यम से या HTML पृष्ठ में मेटा तत्वों को शामिल करके किया जाता है। इस नीति का पालन करते हुए, ब्राउज़र सक्रिय रूप से इन शर्तों को लागू करते हैं और तुरंत किसी भी पहचानी गई उल्लंघनों को अवरुद्ध कर देते हैं।
Implemented via response header:
मेटा टैग के माध्यम से लागू किया गया:
CSP को इन हेडर्स का उपयोग करके लागू या मॉनिटर किया जा सकता है:
Content-Security-Policy: CSP को लागू करता है; ब्राउज़र किसी भी उल्लंघन को ब्लॉक करता है।
Content-Security-Policy-Report-Only: मॉनिटरिंग के लिए उपयोग किया जाता है; उल्लंघनों की रिपोर्ट करता है बिना उन्हें ब्लॉक किए। प्री-प्रोडक्शन वातावरण में परीक्षण के लिए आदर्श।
CSP सक्रिय और निष्क्रिय सामग्री को लोड करने के लिए मूल स्थानों को प्रतिबंधित करता है, जैसे इनलाइन जावास्क्रिप्ट निष्पादन और eval() के उपयोग को नियंत्रित करता है। एक उदाहरण नीति है:
script-src: जावास्क्रिप्ट के लिए विशिष्ट स्रोतों की अनुमति देता है, जिसमें URL, इनलाइन स्क्रिप्ट और इवेंट हैंडलर्स या XSLT स्टाइलशीट द्वारा ट्रिगर की गई स्क्रिप्ट शामिल हैं।
default-src: जब विशिष्ट फ़ेच निर्देश अनुपस्थित होते हैं, तो संसाधनों को लाने के लिए एक डिफ़ॉल्ट नीति सेट करता है।
child-src: वेब वर्कर्स और एम्बेडेड फ़्रेम सामग्री के लिए अनुमत संसाधनों को निर्दिष्ट करता है।
connect-src: उन URL को प्रतिबंधित करता है जिन्हें fetch, WebSocket, XMLHttpRequest जैसी इंटरफेस का उपयोग करके लोड किया जा सकता है।
frame-src: फ़्रेम के लिए URL को प्रतिबंधित करता है।
frame-ancestors: निर्दिष्ट करता है कि कौन से स्रोत वर्तमान पृष्ठ को एम्बेड कर सकते हैं, जैसे कि <frame>, <iframe>, <object>, <embed>, और <applet> तत्वों पर लागू होता है।
img-src: छवियों के लिए अनुमत स्रोतों को परिभाषित करता है।
font-src: @font-face का उपयोग करके लोड किए गए फ़ॉन्ट के लिए मान्य स्रोतों को निर्दिष्ट करता है।
manifest-src: एप्लिकेशन मैनिफेस्ट फ़ाइलों के लिए अनुमत स्रोतों को परिभाषित करता है।
media-src: मीडिया ऑब्जेक्ट्स को लोड करने के लिए अनुमत स्रोतों को परिभाषित करता है।
object-src: <object>, <embed>, और <applet> तत्वों के लिए अनुमत स्रोतों को परिभाषित करता है।
base-uri: <base> तत्वों का उपयोग करके लोड करने के लिए अनुमत URL को निर्दिष्ट करता है।
form-action: फ़ॉर्म सबमिशन के लिए मान्य एंडपॉइंट्स की सूची बनाता है।
plugin-types: उन माइम प्रकारों को प्रतिबंधित करता है जिन्हें एक पृष्ठ सक्रिय कर सकता है।
upgrade-insecure-requests: ब्राउज़रों को HTTP URL को HTTPS में फिर से लिखने के लिए निर्देशित करता है।
sandbox: <iframe> के सैंडबॉक्स विशेषता के समान प्रतिबंध लागू करता है।
report-to: निर्दिष्ट करता है कि यदि नीति का उल्लंघन होता है तो रिपोर्ट किस समूह को भेजी जाएगी।
worker-src: वर्कर, SharedWorker, या ServiceWorker स्क्रिप्ट के लिए मान्य स्रोतों को निर्दिष्ट करता है।
prefetch-src: उन संसाधनों के लिए मान्य स्रोतों को निर्दिष्ट करता है जिन्हें लाया जाएगा या प्रीफेच किया जाएगा।
navigate-to: उन URL को प्रतिबंधित करता है जिन पर कोई दस्तावेज़ किसी भी तरीके से नेविगेट कर सकता है (a, form, window.location, window.open, आदि।)
*: सभी URL की अनुमति देता है सिवाय data:, blob:, filesystem: स्कीमों के।
'self': समान डोमेन से लोड करने की अनुमति देता है।
'data': डेटा स्कीम के माध्यम से संसाधनों को लोड करने की अनुमति देता है (जैसे, Base64 एन्कोडेड छवियाँ)।
'none': किसी भी स्रोत से लोडिंग को ब्लॉक करता है।
'unsafe-eval': eval() और समान विधियों के उपयोग की अनुमति देता है, सुरक्षा कारणों से अनुशंसित नहीं है।
'unsafe-hashes': विशिष्ट इनलाइन इवेंट हैंडलर्स को सक्षम करता है।
'unsafe-inline': इनलाइन <script> या <style> जैसे इनलाइन संसाधनों के उपयोग की अनुमति देता है, सुरक्षा कारणों से अनुशंसित नहीं है।
'nonce': एक क्रिप्टोग्राफिक नॉनस (एक बार उपयोग किया जाने वाला नंबर) का उपयोग करके विशिष्ट इनलाइन स्क्रिप्ट के लिए एक व्हाइटलिस्ट।
यदि आपके पास JS सीमित निष्पादन है, तो यह संभव है कि आप पृष्ठ के अंदर एक उपयोग किया गया नॉनस प्राप्त करें doc.defaultView.top.document.querySelector("[nonce]") के साथ और फिर इसे एक दुर्भावनापूर्ण स्क्रिप्ट लोड करने के लिए पुन: उपयोग करें (यदि strict-dynamic का उपयोग किया गया है, तो कोई भी अनुमत स्रोत नए स्रोतों को लोड कर सकता है इसलिए इसकी आवश्यकता नहीं है), जैसे कि:
'sha256-<hash>': विशिष्ट sha256 हैश के साथ स्क्रिप्ट को व्हाइटलिस्ट करता है।
'strict-dynamic': यदि इसे नॉनस या हैश द्वारा व्हाइटलिस्ट किया गया है तो किसी भी स्रोत से स्क्रिप्ट लोड करने की अनुमति देता है।
'host': एक विशिष्ट होस्ट निर्दिष्ट करता है, जैसे example.com।
https:: URLs को उन पर प्रतिबंधित करता है जो HTTPS का उपयोग करते हैं।
blob:: Blob URLs (जैसे, JavaScript के माध्यम से बनाए गए Blob URLs) से संसाधनों को लोड करने की अनुमति देता है।
filesystem:: फ़ाइल सिस्टम से संसाधनों को लोड करने की अनुमति देता है।
'report-sample': उल्लंघन रिपोर्ट में उल्लंघन करने वाले कोड का एक नमूना शामिल करता है (डीबगिंग के लिए उपयोगी)।
'strict-origin': 'self' के समान लेकिन सुनिश्चित करता है कि स्रोतों का प्रोटोकॉल सुरक्षा स्तर दस्तावेज़ से मेल खाता है (केवल सुरक्षित मूल सुरक्षित मूल से संसाधन लोड कर सकते हैं)।
'strict-origin-when-cross-origin': समान मूल अनुरोध करते समय पूर्ण URLs भेजता है लेकिन केवल तब ही मूल भेजता है जब अनुरोध क्रॉस-ओरिजिन हो।
'unsafe-allow-redirects': संसाधनों को लोड करने की अनुमति देता है जो तुरंत किसी अन्य संसाधन पर रीडायरेक्ट करेंगे। सुरक्षा को कमजोर करने के कारण अनुशंसित नहीं है।
Working payload: "/><script>alert(1);</script>
यह काम नहीं कर रहा है, अधिक जानकारी के लिए यहाँ देखें.
काम करने वाला पेलोड:
यदि आप किसी तरह से एक अनुमत JS कोड द्वारा DOM में एक नया स्क्रिप्ट टैग बनाया जा सकता है अपने JS कोड के साथ, क्योंकि एक अनुमत स्क्रिप्ट इसे बना रही है, तो नया स्क्रिप्ट टैग निष्पादित होने की अनुमति दी जाएगी।
काम करने वाला पेलोड:
ऐसा लगता है कि यह अब काम नहीं कर रहा है
काम करने वाले पेलोड:
यदि आप एक JS फ़ाइल अपलोड कर सकते हैं तो आप इस CSP को बायपास कर सकते हैं:
कार्यशील पेलोड:
हालांकि, यह अत्यधिक संभावित है कि सर्वर अपलोड की गई फ़ाइल को मान्य कर रहा है और केवल आपको निर्धारित प्रकार की फ़ाइलें अपलोड करने की अनुमति देगा।
इसके अलावा, भले ही आप सर्वर द्वारा स्वीकार की गई एक्सटेंशन (जैसे: script.png) का उपयोग करके फ़ाइल के अंदर JS कोड अपलोड कर सकें, यह पर्याप्त नहीं होगा क्योंकि कुछ सर्वर जैसे अपाचे सर्वर फाइल के एक्सटेंशन के आधार पर MIME प्रकार का चयन करते हैं और ब्राउज़र जैसे Chrome Javascript कोड को कुछ ऐसा करने के लिए अस्वीकृत कर देंगे जो एक छवि होनी चाहिए। "उम्मीद है", वहाँ गलतियाँ हैं। उदाहरण के लिए, एक CTF से मैंने सीखा कि Apache को _.wave**_ एक्सटेंशन का पता नहीं है, इसलिए यह इसे MIME प्रकार जैसे audio/* के साथ सर्व नहीं करता है।
यहां से, यदि आप एक XSS और एक फ़ाइल अपलोड पाते हैं, और आप एक गलत व्याख्या की गई एक्सटेंशन खोजने में सफल होते हैं, तो आप उस एक्सटेंशन के साथ एक फ़ाइल अपलोड करने और स्क्रिप्ट की सामग्री को आज़मा सकते हैं। या, यदि सर्वर अपलोड की गई फ़ाइल के सही प्रारूप की जांच कर रहा है, तो एक पॉलीग्लॉट बनाएं (कुछ पॉलीग्लॉट उदाहरण यहाँ)।
यदि JS इंजेक्ट करना संभव नहीं है, तो आप उदाहरण के लिए क्रेडेंशियल्स को फॉर्म एक्शन इंजेक्ट करके निकालने की कोशिश कर सकते हैं (और शायद पासवर्ड प्रबंधकों से पासवर्ड स्वचालित रूप से भरने की उम्मीद कर सकते हैं)। आप इस रिपोर्ट में एक उदाहरण पा सकते हैं। इसके अलावा, ध्यान दें कि default-src फॉर्म क्रियाओं को कवर नहीं करता है।
कुछ निम्नलिखित पेलोड के लिए unsafe-eval की आवश्यकता नहीं है।
एक कमजोर संस्करण का एंगुलर लोड करें और मनमाना JS निष्पादित करें:
window ऑब्जेक्ट लौटाती हैं (इस पोस्ट को देखें):पोस्ट दिखाती है कि आप cdn.cloudflare.com (या किसी अन्य अनुमत JS लाइब्रेरी रिपॉजिटरी) से सभी लाइब्रेरीज़ को लोड कर सकते हैं, प्रत्येक लाइब्रेरी से सभी जोड़ी गई फ़ंक्शंस को निष्पादित कर सकते हैं, और यह जांच सकते हैं कि कौन से फ़ंक्शंस कौन सी लाइब्रेरीज़ से window ऑब्जेक्ट लौटाते हैं।
Angular XSS एक क्लास नाम से:
इस CTF लेख के अनुसार, आप CSP के अंदर https://www.google.com/recaptcha/ का दुरुपयोग कर सकते हैं ताकि CSP को बायपास करते हुए मनचाहा JS कोड निष्पादित किया जा सके:
अधिक इस लेख से पेलोड:
निम्नलिखित URL example.com पर रीडायरेक्ट करता है (यहां से यहां):
Abusing *.google.com/script.google.com
Google Apps Script का दुरुपयोग करके script.google.com के अंदर एक पृष्ठ में जानकारी प्राप्त करना संभव है। जैसे कि इसे इस रिपोर्ट में किया गया है।
ऐसे परिदृश्य जहाँ script-src को self और एक विशेष डोमेन पर सेट किया गया है जिसे व्हाइटलिस्ट किया गया है, JSONP का उपयोग करके बायपास किया जा सकता है। JSONP एंडपॉइंट असुरक्षित कॉलबैक विधियों की अनुमति देते हैं जो एक हमलावर को XSS करने की अनुमति देते हैं, कार्यशील पेलोड:
JSONBee विभिन्न वेबसाइटों के CSP बायपास के लिए उपयोग करने के लिए तैयार JSONP एंडपॉइंट्स शामिल करता है।
यदि विश्वसनीय एंडपॉइंट में एक ओपन रीडायरेक्ट है, तो वही भेद्यता उत्पन्न होगी क्योंकि यदि प्रारंभिक एंडपॉइंट विश्वसनीय है, तो रीडायरेक्ट भी विश्वसनीय हैं।
जैसा कि निम्नलिखित पोस्ट में वर्णित है, कई थर्ड पार्टी डोमेन हैं, जो CSP में कहीं न कहीं अनुमति दी जा सकती हैं, जिन्हें डेटा को एक्सफिल्ट्रेट करने या जावास्क्रिप्ट कोड निष्पादित करने के लिए दुरुपयोग किया जा सकता है। इनमें से कुछ थर्ड-पार्टी हैं:
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 पाते हैं:
या
आपको डेटा को एक्सफिल्ट्रेट करने में सक्षम होना चाहिए, जैसे कि हमेशा Google Analytics/Google Tag Manager के साथ किया गया है। इस मामले में, आप इन सामान्य चरणों का पालन करते हैं:
यहाँ एक Facebook Developer खाता बनाएं।
एक नया "Facebook Login" ऐप बनाएं और "Website" चुनें।
"Settings -> Basic" पर जाएं और अपना "App ID" प्राप्त करें।
लक्षित साइट पर, जिससे आप डेटा एक्सफिल्ट्रेट करना चाहते हैं, आप "customEvent" और डेटा पेलोड के माध्यम से Facebook SDK गैजेट "fbq" का सीधे उपयोग करके डेटा एक्सफिल्ट्रेट कर सकते हैं।
अपने ऐप "Event Manager" पर जाएं और उस एप्लिकेशन का चयन करें जिसे आपने बनाया है (ध्यान दें कि इवेंट मैनेजर एक URL में पाया जा सकता है जो इस तरह का है: https://www.facebook.com/events_manager2/list/pixel/[app-id]/test_events)
"Test Events" टैब का चयन करें ताकि "आपकी" वेबसाइट द्वारा भेजे जा रहे इवेंट्स को देखा जा सके।
फिर, पीड़ित पक्ष पर, आप Facebook ट्रैकिंग पिक्सेल को हमलावर के Facebook डेवलपर खाता ऐप-आईडी की ओर इंगित करने और इस तरह का एक कस्टम इवेंट जारी करने के लिए निम्नलिखित कोड निष्पादित करते हैं:
जैसे कि पिछले तालिका में निर्दिष्ट अन्य सात तृतीय-पक्ष डोमेन के लिए, उन्हें दुरुपयोग करने के कई अन्य तरीके हैं। अन्य तृतीय-पक्ष दुरुपयोगों के बारे में अतिरिक्त स्पष्टीकरण के लिए पहले के ब्लॉग पोस्ट को देखें।
पथ प्रतिबंधों को बायपास करने के लिए उपरोक्त पुनर्निर्देशन के अलावा, एक और तकनीक है जिसे Relative Path Overwrite (RPO) कहा जाता है, जिसे कुछ सर्वरों पर उपयोग किया जा सकता है।
उदाहरण के लिए, यदि CSP पथ https://example.com/scripts/react/ की अनुमति देता है, तो इसे निम्नलिखित तरीके से बायपास किया जा सकता है:
The browser will ultimately load 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
यदि base-uri निर्देश गायब है तो आप इसका दुरुपयोग कर सकते हैं dangling markup injection करने के लिए।
इसके अलावा, यदि पृष्ठ एक सापेक्ष पथ का उपयोग करके स्क्रिप्ट लोड कर रहा है (जैसे <script src="/js/app.js">) एक Nonce का उपयोग करते हुए, आप base tag का दुरुपयोग कर सकते हैं ताकि यह आपके अपने सर्वर से स्क्रिप्ट लोड करे जिससे XSS प्राप्त हो।
यदि कमजोर पृष्ठ httpS के साथ लोड होता है, तो बेस में httpS URL का उपयोग करें।
एक विशेष नीति जिसे सामग्री सुरक्षा नीति (CSP) के रूप में जाना जाता है, जावास्क्रिप्ट घटनाओं को प्रतिबंधित कर सकती है। फिर भी, AngularJS एक वैकल्पिक के रूप में कस्टम घटनाएँ पेश करता है। एक घटना के भीतर, AngularJS एक अद्वितीय ऑब्जेक्ट $event प्रदान करता है, जो मूल ब्राउज़र घटना ऑब्जेक्ट को संदर्भित करता है। इस $event ऑब्जेक्ट का उपयोग CSP को दरकिनार करने के लिए किया जा सकता है। विशेष रूप से, Chrome में, $event/event ऑब्जेक्ट में एक path विशेषता होती है, जो घटना के निष्पादन श्रृंखला में शामिल ऑब्जेक्टों की एक सरणी रखती है, जिसमें window ऑब्जेक्ट हमेशा अंत में स्थित होता है। यह संरचना सैंडबॉक्स से बचने की रणनीतियों के लिए महत्वपूर्ण है।
इस सरणी को orderBy फ़िल्टर की ओर निर्देशित करके, इसे पुनरावृत्त करना संभव है, अंतिम तत्व ( window ऑब्जेक्ट) का उपयोग करके एक वैश्विक फ़ंक्शन जैसे alert() को सक्रिय करना। नीचे प्रदर्शित कोड स्निपेट इस प्रक्रिया को स्पष्ट करता है:
यह स्निप्पेट ng-focus निर्देश का उपयोग करके इवेंट को ट्रिगर करने को उजागर करता है, $event.path|orderBy का उपयोग करके path एरे को संशोधित करता है, और alert() फ़ंक्शन को निष्पादित करने के लिए window ऑब्जेक्ट का लाभ उठाता है, इस प्रकार document.cookie को प्रकट करता है।
अन्य Angular बायपास खोजें https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
एक CSP नीति जो Angular JS एप्लिकेशन में स्क्रिप्ट लोडिंग के लिए डोमेन को व्हाइटलिस्ट करती है, को कॉलबैक फ़ंक्शनों और कुछ कमजोर वर्गों के आह्वान के माध्यम से बायपास किया जा सकता है। इस तकनीक पर अधिक जानकारी इस git repository पर उपलब्ध विस्तृत गाइड में मिल सकती है।
कार्यशील पेलोड:
अन्य JSONP मनमाने निष्पादन एंडपॉइंट्स यहाँ पाए जा सकते हैं (इनमें से कुछ हटा दिए गए या ठीक कर दिए गए हैं)
जब CSP सर्वर-साइड रीडायरेक्शन का सामना करता है तो क्या होता है? यदि रीडायरेक्शन एक अलग मूल की ओर ले जाता है जो अनुमति नहीं है, तो यह अभी भी विफल हो जाएगा।
हालांकि, CSP स्पेक 4.2.2.3. पाथ्स और रीडायरेक्ट्स में वर्णन के अनुसार, यदि रीडायरेक्शन एक अलग पथ की ओर ले जाता है, तो यह मूल प्रतिबंधों को बायपास कर सकता है।
यहाँ एक उदाहरण है:
यदि 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 नियमों में कोई ऐसे डोमेन न हों जिन्हें शोषित किया जा सके।
'unsafe-inline' का मतलब है कि आप कोड के अंदर कोई भी स्क्रिप्ट चला सकते हैं (XSS कोड चला सकता है) और img-src * का मतलब है कि आप वेबपेज पर किसी भी संसाधन से कोई भी छवि उपयोग कर सकते हैं।
आप इस CSP को छवियों के माध्यम से डेटा निकालकर बायपास कर सकते हैं (इस अवसर पर XSS एक CSRF का दुरुपयोग करता है जहां एक पृष्ठ जो बॉट द्वारा सुलभ है, एक SQLi है, और एक छवि के माध्यम से ध्वज निकालता है):
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 द्वारा सीमित नहीं है:
अनुसंधान: https://portswigger.net/research/bypassing-csp-with-policy-injection
यदि एक पैरामीटर जो आपने भेजा है, नीति के घोषणा के अंदर पेस्ट किया जा रहा है, तो आप नीति को इस तरह से बदल सकते हैं कि यह बेकार हो जाए। आप इन बायपास में से किसी के साथ स्क्रिप्ट '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 में यह बहुत सरल है। यदि आप CSP में बस यह जोड़ सकते हैं: ;_ Edge पूरी नीति को छोड़ देगा।
उदाहरण: http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;_&y=%3Cscript%3Ealert(1)%3C/script%3E
निर्देश 'unsafe-inline' की कमी पर ध्यान दें।
इस बार आप पीड़ित को XSS के माध्यम से आपके नियंत्रण में एक पृष्ठ लोड करने के लिए मजबूर कर सकते हैं <iframe के साथ। इस बार आप पीड़ित को उस पृष्ठ तक पहुँचने के लिए मजबूर करने जा रहे हैं जहाँ से आप जानकारी निकालना चाहते हैं (CSRF)। आप पृष्ठ की सामग्री तक पहुँच नहीं सकते, लेकिन यदि किसी तरह आप पृष्ठ को लोड करने में लगने वाले समय को नियंत्रित कर सकते हैं तो आप आवश्यक जानकारी निकाल सकते हैं।
इस बार एक झंडा निकाला जाएगा, जब भी एक चर सही अनुमानित किया जाता है SQLi के माध्यम से, प्रतिक्रिया अधिक समय लेती है नींद फ़ंक्शन के कारण। फिर, आप झंडा निकालने में सक्षम होंगे:
यह हमला कुछ सामाजिक इंजीनियरिंग को शामिल करेगा जहाँ हमलावर उपयोगकर्ता को ब्राउज़र के बुकमार्कलेट पर एक लिंक खींचने और छोड़ने के लिए मनाता है। यह बुकमार्कलेट दुष्ट जावास्क्रिप्ट कोड को शामिल करेगा जो खींचने और छोड़ने या क्लिक करने पर वर्तमान वेब विंडो के संदर्भ में निष्पादित होगा, CSP को बायपास करते हुए और संवेदनशील जानकारी जैसे कुकीज़ या टोकन चुराने की अनुमति देगा।
अधिक जानकारी के लिए यहाँ मूल रिपोर्ट देखें।
इस CTF लेखन में, CSP को एक अनुमत iframe के अंदर एक अधिक प्रतिबंधात्मक CSP को इंजेक्ट करके बायपास किया गया है जो एक विशिष्ट JS फ़ाइल को लोड करने की अनुमति नहीं देता है, जो फिर, प्रोटोटाइप प्रदूषण या DOM क्लॉबरिंग के माध्यम से एक अलग स्क्रिप्ट का दुरुपयोग करके एक मनमाना स्क्रिप्ट लोड करने की अनुमति देता है।
आप csp विशेषता के साथ एक iframe के CSP को प्रतिबंधित कर सकते हैं:
इस CTF लेख में, HTML इंजेक्शन के माध्यम से CSP को और अधिक सीमित करना संभव था, जिससे CSTI को रोकने वाला एक स्क्रिप्ट अक्षम हो गया और इसलिए कमजोरी का लाभ उठाया जा सका। CSP को HTML मेटा टैग का उपयोग करके अधिक सीमित किया जा सकता है और इनलाइन स्क्रिप्ट को अक्षम किया जा सकता है उनके nonce को अनुमति देकर और sha के माध्यम से विशिष्ट इनलाइन स्क्रिप्ट को सक्षम करके:
यदि आप सर्वर को Content-Security-Policy-Report-Only हेडर के साथ आपके द्वारा नियंत्रित मान के साथ प्रतिक्रिया देने में सक्षम हैं (शायद CRLF के कारण), तो आप इसे अपने सर्वर की ओर इंगित कर सकते हैं और यदि आप JS सामग्री को <script> के साथ लपेटते हैं और क्योंकि CSP द्वारा unsafe-inline की अनुमति नहीं है, तो यह CSP त्रुटि को प्रेरित करेगा और स्क्रिप्ट का एक भाग (संवेदनशील जानकारी वाला) Content-Security-Policy-Report-Only से सर्वर पर भेजा जाएगा।
उदाहरण के लिए इस CTF लेख को देखें.
एक iframe बनाया जाता है जो एक URL (हम इसे https://example.redirect.com कहते हैं) की ओर इशारा करता है जिसे CSP द्वारा अनुमति दी गई है।
यह URL फिर एक गुप्त URL (जैसे, https://usersecret.example2.com) की ओर रीडायरेक्ट करता है जो CSP द्वारा अनुमति नहीं दी गई है।
securitypolicyviolation इवेंट को सुनकर, कोई blockedURI प्रॉपर्टी को कैप्चर कर सकता है। यह प्रॉपर्टी ब्लॉक किए गए URI के डोमेन को प्रकट करती है, जिससे प्रारंभिक URL द्वारा रीडायरेक्ट किए गए गुप्त डोमेन का लीक होना होता है।
यह ध्यान देने योग्य है कि Chrome और Firefox जैसे ब्राउज़रों में CSP के संबंध में iframes को संभालने में विभिन्न व्यवहार होते हैं, जो संवेदनशील जानकारी के संभावित लीक का कारण बन सकते हैं।
एक और तकनीक CSP का लाभ उठाकर गुप्त सबडोमेन का अनुमान लगाने में शामिल है। यह विधि एक बाइनरी सर्च एल्गोरिदम पर निर्भर करती है और CSP को विशिष्ट डोमेन को शामिल करने के लिए समायोजित करती है जो जानबूझकर ब्लॉक किए गए हैं। उदाहरण के लिए, यदि गुप्त सबडोमेन अज्ञात वर्णों से बना है, तो आप CSP निर्देश को संशोधित करके इन सबडोमेनों को ब्लॉक या अनुमति देने के लिए विभिन्न सबडोमेनों का क्रमिक परीक्षण कर सकते हैं। यहाँ एक स्निपेट है जो दिखाता है कि CSP को इस विधि को सुविधाजनक बनाने के लिए कैसे सेट किया जा सकता है:
CSP द्वारा अवरुद्ध या अनुमत अनुरोधों की निगरानी करके, कोई भी गुप्त उपडोमेन में संभावित वर्णों को संकीर्ण कर सकता है, अंततः पूर्ण URL का पता लगा सकता है।
दोनों विधियाँ CSP कार्यान्वयन और ब्राउज़रों में व्यवहार के बारीकियों का लाभ उठाती हैं, यह प्रदर्शित करते हुए कि कैसे प्रतीत होता है कि सुरक्षित नीतियाँ अनजाने में संवेदनशील जानकारी लीक कर सकती हैं।
यहाँ से ट्रिक।
अनुभवी हैकरों और बग बाउंटी शिकारियों के साथ संवाद करने के लिए HackenProof Discord सर्वर में शामिल हों!
हैकिंग अंतर्दृष्टि हैकिंग के रोमांच और चुनौतियों में गहराई से जाने वाली सामग्री के साथ संलग्न हों
वास्तविक समय हैक समाचार वास्तविक समय समाचार और अंतर्दृष्टियों के माध्यम से तेज़-तर्रार हैकिंग दुनिया के साथ अद्यतित रहें
नवीनतम घोषणाएँ नवीनतम बग बाउंटी लॉन्च और महत्वपूर्ण प्लेटफ़ॉर्म अपडेट के साथ सूचित रहें
आज ही Discord पर हमसे जुड़ें और शीर्ष हैकरों के साथ सहयोग करना शुरू करें!
इस वीडियो में अंतिम तकनीक के अनुसार, बहुत सारे पैरामीटर (1001 GET पैरामीटर, हालाँकि आप इसे POST पैरामीटर और 20 से अधिक फ़ाइलों के साथ भी कर सकते हैं) भेजने पर। PHP वेब कोड में कोई भी परिभाषित header() नहीं भेजा जाएगा क्योंकि यह त्रुटि उत्पन्न करेगा।
PHP को डिफ़ॉल्ट रूप से 4096 बाइट्स तक प्रतिक्रिया को बफर करने के लिए जाना जाता है। इसलिए, यदि PHP एक चेतावनी दिखा रहा है, तो चेतावनियों के अंदर पर्याप्त डेटा प्रदान करके, प्रतिक्रिया CSP हेडर से पहले भेजी जाएगी, जिससे हेडर को अनदेखा किया जाएगा। फिर, तकनीक मूल रूप से चेतावनियों के साथ प्रतिक्रिया बफर को भरने में है ताकि CSP हेडर न भेजा जाए।
इस लेख से विचार।
इस लेख से ऐसा लगता है कि एक त्रुटि पृष्ठ (संभावित रूप से CSP के बिना) लोड करके और इसकी सामग्री को फिर से लिखकर CSP सुरक्षा को बायपास करना संभव था।
SOME एक तकनीक है जो एक XSS (या अत्यधिक सीमित XSS) एक पृष्ठ के एंडपॉइंट में का दुरुपयोग करती है ताकि एक ही मूल के अन्य एंडपॉइंट्स का दुरुपयोग किया जा सके। यह एक हमलावर पृष्ठ से कमजोर एंडपॉइंट को लोड करके और फिर हमलावर पृष्ठ को उसी मूल के वास्तविक एंडपॉइंट पर रिफ्रेश करके किया जाता है जिसे आप दुरुपयोग करना चाहते हैं। इस तरह कमजोर एंडपॉइंट opener ऑब्जेक्ट का उपयोग कर सकता है पेलोड में DOM तक पहुँचने के लिए वास्तविक एंडपॉइंट का दुरुपयोग करने के लिए। अधिक जानकारी के लिए देखें:
इसके अलावा, wordpress में /wp-json/wp/v2/users/1?_jsonp=data पर एक JSONP एंडपॉइंट है जो आउटपुट में भेजे गए डेटा को प्रतिबिंबित करेगा (केवल अक्षरों, संख्याओं और बिंदुओं की सीमा के साथ)।
एक हमलावर उस एंडपॉइंट का दुरुपयोग करके WordPress के खिलाफ एक SOME हमले को जनरेट कर सकता है और इसे <script src=/wp-json/wp/v2/users/1?_jsonp=some_attack></script> के अंदर एंबेड कर सकता है, ध्यान दें कि यह स्क्रिप्ट लोड होगी क्योंकि इसे 'self' द्वारा अनुमति दी गई है। इसके अलावा, और क्योंकि WordPress स्थापित है, एक हमलावर SOME हमले का दुरुपयोग कमजोर कॉलबैक एंडपॉइंट के माध्यम से कर सकता है जो CSP को बायपास करता है ताकि एक उपयोगकर्ता को अधिक विशेषाधिकार दिए जा सकें, एक नया प्लगइन स्थापित किया जा सके...
इस हमले को कैसे करना है, इसके बारे में अधिक जानकारी के लिए देखें https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/
यदि एक सख्त CSP है जो आपको बाहरी सर्वरों के साथ इंटरैक्ट करने की अनुमति नहीं देती है, तो कुछ चीजें हैं जो आप हमेशा जानकारी को एक्सफिल्ट्रेट करने के लिए कर सकते हैं।
आप बस स्थान को अपडेट कर सकते हैं ताकि हमलावर के सर्वर पर गुप्त जानकारी भेजी जा सके:
आप एक मेटा टैग इंजेक्ट करके रीडायरेक्ट कर सकते हैं (यह केवल एक रीडायरेक्ट है, यह सामग्री लीक नहीं करेगा)
पृष्ठों को तेजी से लोड करने के लिए, ब्राउज़र होस्टनाम को आईपी पते में पूर्व-समाधान करने और उन्हें बाद में उपयोग के लिए कैश करने जा रहे हैं।
आप एक ब्राउज़र को एक होस्टनाम को पूर्व-समाधान करने के लिए संकेत दे सकते हैं: <link rel="dns-prefetch" href="something.com">
आप इस व्यवहार का दुरुपयोग करके DNS अनुरोधों के माध्यम से संवेदनशील जानकारी को निकाल सकते हैं:
एक और तरीका:
इससे बचने के लिए सर्वर HTTP हेडर भेज सकता है:
स्पष्ट रूप से, यह तकनीक हेडलेस ब्राउज़रों (बॉट्स) में काम नहीं करती है।
कई पृष्ठों पर आप पढ़ सकते हैं कि WebRTC CSP की connect-src नीति की जांच नहीं करता है।
वास्तव में, आप DNS अनुरोध का उपयोग करके जानकारी लीक कर सकते हैं। इस कोड को देखें:
एक और विकल्प:
https://csper.io/docs/generating-content-security-policy
Join HackenProof Discord server to communicate with experienced hackers and bug bounty hunters!
Hacking Insights हैकिंग की रोमांचक और चुनौतियों में गहराई से जाने वाली सामग्री के साथ जुड़ें
Real-Time Hack News तेज-तर्रार हैकिंग दुनिया के साथ वास्तविक समय की समाचार और अंतर्दृष्टि के माध्यम से अद्यतित रहें
Latest Announcements नवीनतम बग बाउंटी लॉन्च और महत्वपूर्ण प्लेटफ़ॉर्म अपडेट के साथ सूचित रहें
Join us on Discord and start collaborating with top hackers today!
```html ```
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
