nccgroup/crosssitecontenthijackingफ्लैश, पीडीएफ और सिल्वरलाइट का उपयोग करके कंटेंट हाइजैकिंग प्रूफ-ऑफ-कॉन्सेप्ट
AGPL के अंतर्गत जारी (अधिक जानकारी के लिए LICENSE देखें)।
इस परियोजना का उपयोग निम्नलिखित के लिए एक प्रूफ ऑफ कॉन्सेप्ट प्रदान करने के लिए किया जा सकता है:
नोट: .XAP फ़ाइलों का नाम बदलकर किसी अन्य एक्सटेंशन में किया जा सकता है, लेकिन वे अब क्रॉस-डोमेन लोड नहीं हो सकतीं। ऐसा लगता है कि Silverlight प्रदान किए गए URL के आधार पर फ़ाइल एक्सटेंशन का पता लगाता है और यदि वह .XAP नहीं है तो उसे अनदेखा कर देता है। फिर भी इसका शोषण किया जा सकता है यदि कोई वेबसाइट उपयोगकर्ताओं को वास्तविक फ़ाइल नाम के बाद ";" या "/" का उपयोग करके ".XAP" एक्सटेंशन जोड़ने की अनुमति देती है।
असुरक्षित पॉलिसी फ़ाइल का शोषण:
असुरक्षित फ़ाइल अपलोड/डाउनलोड का शोषण:
CVE-2011-2461 का शोषण
असुरक्षित CORS नीति का शोषण:
नोट: .XAP फ़ाइलों का नाम बदलकर किसी अन्य एक्सटेंशन में किया जा सकता है, लेकिन वे अब क्रॉस-डोमेन लोड नहीं हो सकतीं। ऐसा लगता है कि Silverlight प्रदान किए गए URL के आधार पर फ़ाइल एक्सटेंशन का पता लगाता है और यदि वह .XAP नहीं है तो उसे अनदेखा कर देता है। फिर भी इसका शोषण किया जा सकता है यदि कोई वेबसाइट उपयोगकर्ताओं को वास्तविक फ़ाइल नाम के बाद ";" या "/" का उपयोग करके ".XAP" एक्सटेंशन जोड़ने की अनुमति देती है।
नोट: जब Silverlight क्रॉस-डोमेन .XAP फ़ाइल का अनुरोध करता है, तो सामग्री प्रकार होना चाहिए: application/x-silverlight-app।
नोट: PDF फ़ाइलों का उपयोग केवल Adobe Reader व्यूअर में किया जा सकता है (वे Chrome और Firefox के अंतर्निर्मित PDF व्यूअर के साथ काम नहीं करेंगी)
नोट: सार्वजनिक रूप से सुलभ स्थैतिक सामग्री या डेटा को पढ़ना कोई समस्या नहीं माना जा सकता। अपनी एडवाइजरी से गलत-सकारात्मक परिणामों को हटाना महत्वपूर्ण है। ध्यान दें कि "Access-Control-Allow-Origin" हेडर में अकेले एक तारांकन ("*") वर्ण का उपयोग कोई समस्या नहीं है।
उपयोग उदाहरण:
अपलोड करने की अनुमति दी जाने वाली फ़ाइल प्रकार केवल उन्हीं तक सीमित होनी चाहिए जो व्यावसायिक कार्यक्षमता के लिए आवश्यक हैं।
एप्लिकेशन को सर्वर पर अपलोड की गई किसी भी फ़ाइल पर फ़िल्टरिंग और सामग्री जाँच करनी चाहिए। फ़ाइलों को अन्य उपयोगकर्ताओं के लिए उपलब्ध कराने से पहले उनकी पूरी तरह से स्कैनिंग और सत्यापन किया जाना चाहिए। संदेह होने पर, फ़ाइल को हटा दिया जाना चाहिए।
स्थैतिक फ़ाइलों की प्रतिक्रिया में "Content-Disposition: Attachment" और "X-Content-Type-Options: nosniff" हेडर जोड़ने से वेबसाइट Flash या PDF-आधारित क्रॉस-साइट सामग्री-अपहरण हमलों से सुरक्षित रहेगी। यह अनुशंसा की जाती है कि यह अभ्यास उन सभी फ़ाइलों के लिए किया जाए जिन्हें उपयोगकर्ताओं को फ़ाइल डाउनलोड से संबंधित सभी मॉड्यूल में डाउनलोड करने की आवश्यकता होती है। हालाँकि यह विधि Silverlight या समान ऑब्जेक्ट का उपयोग करने वाले हमलों से वेबसाइट को पूरी तरह से सुरक्षित नहीं करती है, फिर भी यह Adobe Flash और PDF ऑब्जेक्ट के उपयोग के जोखिम को कम कर सकती है, विशेष रूप से जब PDF फ़ाइलें अपलोड करने की अनुमति हो।
Flash/PDF (crossdomain.xml) या Silverlight (clientaccesspolicy.xml) क्रॉस-डोमेन पॉलिसी फ़ाइलों को हटा दिया जाना चाहिए यदि वे उपयोग में नहीं हैं और Flash या Silverlight अनुप्रयोगों के लिए वेबसाइट के साथ संवाद करने की कोई व्यावसायिक आवश्यकता नहीं है।
क्रॉस-डोमेन पहुँच को विश्वसनीय और पहुँच की आवश्यकता वाले न्यूनतम डोमेन सेट तक सीमित किया जाना चाहिए। एक एक्सेस पॉलिसी कमजोर या असुरक्षित मानी जाती है जब वाइल्डकार्ड वर्ण का उपयोग किया जाता है, विशेष रूप से "uri" विशेषता के मान में।
Silverlight अनुप्रयोगों के लिए उपयोग की जाने वाली कोई भी "crossdomain.xml" फ़ाइल कमजोर मानी जानी चाहिए क्योंकि यह डोमेन विशेषता में केवल वाइल्डकार्ड ("*") वर्ण स्वीकार कर सकती है।
corssdomain.xml और clientaccesspolicy.xml फ़ाइलों के लिए ब्राउज़र कैशिंग अक्षम की जानी चाहिए। यह वेबसाइट को फ़ाइल को आसानी से अपडेट करने या आवश्यक होने पर वेब सेवाओं तक पहुँच प्रतिबंधित करने में सक्षम बनाता है। एक बार क्लाइंट एक्सेस पॉलिसी फ़ाइल की जाँच हो जाने के बाद, यह ब्राउज़र सत्र के लिए प्रभावी रहती है, इसलिए अंतिम-उपयोगकर्ता पर गैर-कैशिंग का प्रभाव न्यूनतम होता है। इसे लक्षित वेबसाइट की सामग्री और पॉलिसी फ़ाइल(फ़ाइलों) की सुरक्षा और जटिलता के आधार पर कम या सूचनात्मक जोखिम मुद्दे के रूप में उठाया जा सकता है।
CORS हेडर की समीक्षा की जानी चाहिए ताकि वे केवल स्थैतिक या सार्वजनिक रूप से सुलभ डेटा के लिए सक्षम हों। अन्यथा, "Access-Control-Allow-Origin" हेडर में केवल अधिकृत पते होने चाहिए। अन्य CORS हेडर जैसे "Access-Control-Allow-Credentials" का उपयोग केवल तभी किया जाना चाहिए जब उनकी आवश्यकता हो। CORS हेडर के भीतर आइटम जैसे "Access-Control-Allow-Methods" या "Access-Control-Allow-Headers" की समीक्षा की जानी चाहिए और यदि आवश्यक नहीं हैं तो हटा दिए जाने चाहिए।
नोट: "Referer" हेडर का उपयोग समाधान नहीं हो सकता क्योंकि इस हेडर को सेट करना संभव है, उदाहरण के लिए Adobe Reader और PDF का उपयोग करके POST अनुरोध भेजकर ("objects" निर्देशिका में "xfa-manual-ContentHijacking.pdf" फ़ाइल देखें)। अपडेट: "referer" हेडर सेट करने का मुद्दा Adobe द्वारा संबोधित कर दिया गया है, जब तक कि आपको इसके लिए कोई बायपास भी न मिल जाए ;)
नवीनतम अपडेट/सहायता के लिए परियोजना पृष्ठ देखें: https://github.com/nccgroup/CrossSiteContentHijacking
NCC Group से Soroush Dalili (irsdl)
यहाँ तक कि एक JPG फ़ाइल अपलोड करना भी क्रॉस डोमेन डेटा अपहरण (क्लाइंट-साइड हमला) का कारण बन सकता है! https://soroush.secproject.com/blog/2014/05/even-uploading-a-jpg-file-can-lead-to-cross-domain-data-hijacking-client-side-attack/
एकाधिक PDF कमजोरियाँ - टेक्स्ट और चित्र अत्यधिक प्रभावी http://insert-script.blogspot.co.at/2014/12/multiple-pdf-vulnerabilites-text-and.html
Silverlight के साथ HTTP संचार और सुरक्षा http://msdn.microsoft.com/en-gb/library/cc838250(v=vs.95).aspx
Silverlight के लिए क्रॉस डोमेन और क्लाइंट एक्सेस पॉलिसी फ़ाइलों की व्याख्या http://www.devtoolshed.com/explanation-cross-domain-and-client-access-policy-files-silverlight
क्रॉस-डोमेन पॉलिसी फ़ाइल विनिर्देश http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
HTTP स्ट्रीमिंग के लिए crossdomain.xml फ़ाइल सेट करना http://www.adobe.com/devnet/adobe-media-server/articles/cross-domain-xml-for-streaming.html
google.com पर CVE-2011-2461 का शोषण http://blog.mindedsecurity.com/2015/03/exploiting-cve-2011-2461-on-googlecom.html
