कोर्स का फायदा उठाने के लिए "उत्पत्ति" हेडर को खराब करने से दुर्भावनापूर्ण कोड को रोकने के लिए क्या है?

Question

जिस तरह से मैं इसे समझता हूं, अगर foo.com से किसी पेज पर चलने वाला क्लाइंट-साइड स्क्रिप्ट bar.com से डेटा का अनुरोध करना चाहता है, तो अनुरोध में इसे हेडर को निर्दिष्ट करना होगा Origin: http://foo.com, और बार को जवाब देना होगा Access-Control-Allow-Origin: http://foo.com।

Origin: http://foo.comबार से पृष्ठों का अनुरोध करने के लिए हेडर को खराब करने से साइट roh.com से दुर्भावनापूर्ण कोड को रोकने के लिए क्या है ?

Comments

मेरा मानना ​​है कि मुद्दा यह है कि मूल डोमेन जिस पृष्ठ से (यहां foo.com) परोसा जाता है, उसे Access-Control-Allow-Originहेडर प्रदान करना होगा अन्यथा ब्राउज़र अनुरोध करने की अनुमति नहीं देता है bar.com।

— क्रिस हेस

इस पोस्ट के माध्यम से पढ़ने से मुझे वास्तव में ब्राउज़र, मूल सर्वर और लक्ष्य सर्वर के बीच कोर्स प्रक्रिया की समझ में मदद मिली। html5rocks.com/en/tutorials/cors

— brendonparker

@ChrisHayes यह नहीं है कि कोर कैसे काम करता है। आप इस विषय पर युक्ति , या इस महान MDN विकी पृष्ठ को देखकर थोड़ा और पढ़ सकते हैं ।

— रे Nicholus

@brendonparker हाँ, यह एक बेहतरीन लेख है। यह लेखक SO पर बहुत से प्रश्नों का उत्तर देता है, और enable-cors.org को भी बनाए रखता है ।

— रे निकोलस

@ राएनिचोलस दिलचस्प, मैं स्पष्ट रूप से बंद था। लिंक के लिए धन्यवाद। मेरी टिप्पणी पर वोटों को देखते हुए मैं इस भ्रम के तहत पीड़ित नहीं हूं। मुझे उम्मीद है कि वे दोनों वापस आ जाएंगे और सीखेंगे (और अपने वोटों को हटा देंगे!)।

— क्रिस हेस

Answer 1

ब्राउज़र Originहेडर सेट करने के नियंत्रण में हैं , और उपयोगकर्ता इस मान को ओवरराइड नहीं कर सकते हैं। तो आप Originएक ब्राउज़र से हेडर को स्पूफ नहीं देखेंगे । एक दुर्भावनापूर्ण उपयोगकर्ता एक कर्ल अनुरोध को क्राफ्ट कर सकता है जो मैन्युअल रूप से Originहेडर सेट करता है , लेकिन यह अनुरोध एक ब्राउज़र के बाहर से आएगा, और इसमें ब्राउज़र-विशिष्ट जानकारी (जैसे कि कुकीज़) नहीं हो सकती है।

याद रखें: CORS सुरक्षा नहीं है। अपनी साइट को सुरक्षित करने के लिए CORS पर भरोसा न करें। यदि आप संरक्षित डेटा परोस रहे हैं, तो Originउस डेटा को सुरक्षित करने के लिए हेडर के अलावा कुकीज़ या OAuth टोकन या कुछ और का उपयोग करें । Access-Control-Allow-OriginCORS केवल बातें जो मूल पार मूल अनुरोध करने के लिए अनुमति दी जानी चाहिए में हेडर। कुछ और के लिए उस पर भरोसा मत करो।

Comments

इसके बहुत सारे अर्थ निकलते हैं। यदि ब्राउज़र जावास्क्रिप्ट को मूल हेडर को ओवरराइड करने की अनुमति नहीं देता है, तो कोई समस्या नहीं है। यदि आप ब्राउज़र के बाहर से अनुरोधों को निष्पादित कर रहे हैं, तो आपके पास कुकीज़ नहीं हैं। मुझे लगता है कि मैं उलझन में था क्योंकि सभी डॉक्स में मैं पढ़ रहा था, कहीं भी यह स्पष्ट रूप से नहीं कहा गया था कि ओरिजिन हेडर को ओवरराइड नहीं किया जा सकता है। धन्यवाद!

— जे लामोंट

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

— Mnebuerquo

और बस स्पष्ट करने के लिए, दुर्भावनापूर्ण उपयोगकर्ता बस एक ब्राउज़र उदाहरण को स्पॉन कर सकता है जो उन्हें ओरिजिन हेडर पर मैन्युअल नियंत्रण की अनुमति देने के लिए पैच किया गया था, और फिर एक सामान्य उपयोगकर्ता, कुकीज़, AJAX और सभी को पूरी तरह से प्रतिरूपित करता है।

— जॉर्डन रीगर

"ब्राउज़र्स ओरिजिन हेडर सेट करने के नियंत्रण में हैं, और उपयोगकर्ता इस मान को ओवरराइड नहीं कर सकता है।" मुझे यकीन है कि अनुरोध के ब्राउज़र को छोड़ देने के बाद हेडर को संशोधित करने के लिए Fiddler2 या चार्ल्स जैसे टूल का उपयोग करना बहुत आसान है।

— आसा

दुर्भावनापूर्ण उपयोगकर्ता बस एक ब्राउज़र उदाहरण को स्पॉन कर सकता है जो उन्हें ओरिजिन हेडर पर मैन्युअल नियंत्रण की अनुमति देने के लिए पैच किया गया था यदि आपके पास मशीन तक उस बिंदु तक पहुंच है जहां आप 'बस एक पैच ब्राउज़र उदाहरण को स्पॉन कर सकते हैं' (वास्तव में उतना आसान नहीं लगता है) मेरे लिए), क्यों नहीं सीधे डिस्क से कुकीज़ पढ़ा? वे सादे पाठ में संग्रहीत हैं जो आप जानते हैं। वास्तविक जीवन में, क्रॉस-साइट स्क्रिप्टिंग एक वास्तविक खतरा है, जबकि आपके हमले का परिदृश्य सिर्फ आकस्मिक और अव्यवहारिक है।

— स्टिजिन डे विट

Answer 2

TLDR: मूल स्पूफिंग से दुर्भावनापूर्ण कोड को रोकने के लिए कुछ भी नहीं है। जब ऐसा होता है, तो आपके सर्वर को इसके बारे में कभी पता नहीं चलेगा और अनुरोधों पर कार्य करेगा। कभी-कभी वे अनुरोध महंगे होते हैं। इसलिए किसी भी प्रकार की सुरक्षा के स्थान पर कोर का उपयोग न करें।

---

मैं हाल ही में कोर के साथ खेल रहा हूं, और मैंने खुद से वही सवाल पूछा है। मैंने पाया है कि जब यह एक को देखता है तो ब्राउज़र एक खराब कॉर्स अनुरोध को जानने के लिए पर्याप्त स्मार्ट हो सकता है, लेकिन आपका सर्वर उतना स्मार्ट नहीं है।

पहली चीज़ जो मुझे मिली वह थी कि Originहेडर एक HTTP निषिद्ध हेडर नाम है जिसे प्रोग्रामेटिक रूप से संशोधित नहीं किया जा सकता है। जिसका अर्थ है कि आप Google Chrome के लिए संशोधित हेडर का उपयोग करके इसे लगभग 8 सेकंड में संशोधित कर सकते हैं ।

इसका परीक्षण करने के लिए, मैंने दो क्लाइंट डोमेन और एक सर्वर डोमेन स्थापित किया। मैंने सर्वर पर एक CORS श्वेतसूची को शामिल किया, जिसने क्लाइंट 1 से CORS अनुरोधों की अनुमति दी, लेकिन क्लाइंट 2 से नहीं। मैंने दोनों ग्राहकों का परीक्षण किया, और वास्तव में क्लाइंट 1 के CORS अनुरोध सफल हुए जबकि क्लाइंट 2 विफल रहा।

फिर मैंने Originक्लाइंट 1 के मैच के लिए क्लाइंट 2 के हेडर को स्पूफ किया । सर्वर ने स्पूफ़्ड Originहेडर प्राप्त किया , और सफलतापूर्वक श्वेतसूची जांच पास की (या यदि आप एक ग्लास-आधा-खाली प्रकार का लड़का हैं तो असफल रहे)। उसके बाद, सर्वर ने उन सभी संसाधनों का उपभोग करके सावधानीपूर्वक प्रदर्शन किया जो इसे उपभोग करने के लिए डिज़ाइन किया गया था (डेटाबेस कॉल, महंगे ईमेल भेजना, और भी अधिक महंगे एसएमएस संदेश भेजना आदि)। जब ऐसा किया गया था, तो सर्वर ने ख़ुशी-ख़ुशी Access-Control-Allow-Originहेडर को ब्राउज़र में वापस भेज दिया ।

मैंने जो दस्तावेज़ पढ़ा है, वह बताता है कि Access-Control-Allow-Originप्राप्त Originमूल्य अनुरोध में भेजे गए मूल्य से बिल्कुल मेल खाना चाहिए । उन्होंने मैच किया, इसलिए जब मैंने क्रोम में निम्न संदेश देखा तो मैं आश्चर्यचकित रह गया:

XMLHttpRequest लोड नहीं किया जा सकता है http://server.dev/test। 'एक्सेस-कंट्रोल-अलाउंस-ओरिजिन' हेडर का एक मान http://client1.dev होता है जो आपूर्ति की गई उत्पत्ति के बराबर नहीं होता है। http://client2.dev इसलिए उत्पत्ति की अनुमति नहीं है।

मैंने जो दस्तावेज़ पढ़ा है, वह सटीक नहीं लगता है। Chrome का नेटवर्क टैब स्पष्ट रूप से अनुरोध और प्रतिक्रिया हेडर दोनों को दिखाता है http://client1.dev, लेकिन आप इस त्रुटि में देख सकते हैं कि क्रोम किसी भी तरह से वास्तविक मूल को http://client2.devजानता है और प्रतिक्रिया को सही ढंग से अस्वीकार करता है। जो इस बिंदु पर कोई फर्क नहीं पड़ता क्योंकि सर्वर ने पहले से ही खराब अनुरोध स्वीकार कर लिया था और मेरे पैसे खर्च किए थे।

Comments

@ नोक्टर्नो, उदाहरण के लिए धन्यवाद। मुझे केवल अपना अवलोकन जोड़ने दें। CORS ब्राउज़र सुरक्षा सुविधाओं से संबंधित है। यदि एक सुरक्षित ब्राउज़र को अपनी प्राचीन स्थिति से संशोधित किया जाता है, तो इसकी व्याख्या की जा सकती है क्योंकि ब्राउज़र में संभवतः सुरक्षा सुविधा का अभाव है।

— लुका Lटनिक

शानदार नहीं है। यह पूरी तरह से कोर के बिंदु को याद करता है। यदि आप उपयोगकर्ता की मशीन से उत्पन्न होने वाले अनुरोधों को रोकने की स्थिति में हैं, तो आप बस उनकी कुकीज़ पढ़ सकते हैं, keyloggers, virusses और उन सभी अन्य वास्तविक खतरों को स्थापित कर सकते हैं। कोर एक दुर्भावनापूर्ण स्क्रिप्ट से साइट ए में लॉग इन किए गए ईमानदार उपयोगकर्ताओं की रक्षा करने के लिए है जो किसी तरह साइट बी में इंजेक्ट किया गया है। साइट बी पर स्क्रिप्ट (जो एक फोरम पोस्ट में जावास्क्रिप्ट का स्निपेट हो सकता है जो साइट बी द्वारा सही ढंग से बच नहीं गया था) साइट ए के तहत साइट ए पर कार्रवाई (जैसे सामान आदि को हटाना), साइट ए से सत्र कुकी का उपयोग करना

— स्टिजिन विट विट

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

— १०:५० पर Stijn de Witt

@ नोक्टर्नो हाँ, मैं शायद थोड़ा बहुत कच्चा था, इस बारे में खेद है। आपका मूल बिंदु खड़ा है। समान-उत्पत्ति नीति एक ब्राउज़र सुरक्षा सुविधा है और कुछ डोमेन को श्वेतसूची में करके उस सुरक्षा को कमजोर करने के लिए CORS एक तंत्र है। ओपी को यह समझने की जरूरत है कि ओरिजिन हेडर को खराब करना वास्तव में एक 'हमले' के रूप में व्यवहार्य नहीं है क्योंकि यह आपको कुछ भी नहीं लाता है जो कि उदाहरण के लिए कर्ल के साथ नहीं हो सकता है।

— Stijn de Witt

@ नोक्टर्नो मुझे लगता है कि आपका शुरुआती बयान थोड़ा भ्रामक है। There's nothing stopping malicious code from spoofing the origin-> हाँ वहाँ है, जावास्क्रिप्ट सेट नहीं किया जा सकता है Origin। हां, एक उपयोगकर्ता अपने ब्राउज़र को संशोधित कर सकता है / मूल को बदलने के लिए फ़िडलर का उपयोग कर सकता है, लेकिन ऐसा नहीं है कि कॉर्स के खिलाफ बचाव किया जा रहा है; हमलावर नियंत्रित वेबसाइटें मूल को नहीं बदल सकती हैं, जो कि सभी मायने रखता है।

— RJFalconer

Answer 3

बस एक विनम्र लपेटो:

प्रश्न: क्या समान उत्पत्ति नीति (एसओपी) केवल ब्राउज़रों द्वारा लागू की गई है?
A: हाँ। ब्राउज़र के अंदर आपके द्वारा की जाने वाली सभी कॉल के लिए, ब्राउज़र द्वारा SOP निश्चित रूप से लागू किया जाता है। सर्वर अनुरोध की उत्पत्ति की जांच कर सकता है या नहीं कर सकता है।

प्रश्न: यदि कोई अनुरोध SOP का अनुपालन नहीं करता है, तो क्या ब्राउज़र इसे ब्लॉक करता है?
A: नहीं, यह ब्राउज़र के अधिकार से परे है। ब्राउज़र केवल क्रॉस ओरिजिनल रिक्वेस्ट भेजते हैं और यह देखने के लिए प्रतिक्रिया का इंतजार करते हैं कि क्या कॉल सर्वर द्वारा वैध है Access-Control- * हेडर। यदि सर्वर Access-Control-Allow-Originहेडर वापस नहीं भेजता है , तो कॉलर की उत्पत्ति को वापस नहीं लेता है, या *हेडर में वापस नहीं भेजता है , तो एक ब्राउज़र जो सभी काम करेगा वह कॉल करने वाले को प्रतिक्रिया देने से बच रहा है।

प्रश्न: क्या इसका मतलब है कि मैं खराब नहीं कर सकता Origin?
A: ब्राउज़र में और स्क्रिप्टिंग का उपयोग करके, आप Originइसे ओवरराइड नहीं कर सकते क्योंकि यह ब्राउज़र के नियंत्रण में है। हालाँकि, यदि आप स्वयं को हैक करना चाहते हैं, तो आप ब्राउज़र एक्सटेंशन या आपके मशीन पर इंस्टॉल किए गए अन्य टूल का उपयोग करके अपने ब्राउज़र से आने वाली कॉल से छेड़छाड़ कर सकते हैं। तुम भी जारी कर सकते हैं HTTPका उपयोग कर कॉल curl, Python, C#, आदि और बदल Originचाल सर्वरों के लिए शीर्ष लेख।

Q: इसलिए यदि मैं सर्वर को बदलकर ट्रिक कर सकता हूं Origin, तो क्या इसका मतलब CORSसुरक्षित नहीं है?
A: CORS प्रति se सुरक्षा के बारे में चुप है - यानी प्रमाणीकरण और अनुरोधों का प्राधिकरण। यह अनुरोधों का निरीक्षण करने और उन्हें कुकीज़ या हेडर जैसे किसी भी तंत्र द्वारा काम करने / प्रमाणित करने के लिए सर्वर पर निर्भर है। कहा जाता है कि, यह XSS जैसे हमलों के मामले में हमारी सुरक्षा कर सकता है:

उदाहरण: मान लीजिए कि आपने अपनी वेबसाइट पर लॉग इन किया है और एक दुर्भावनापूर्ण स्क्रिप्ट आपकी शेष राशि की पूछताछ के लिए आपकी बैंक वेबसाइट पर एक अनुरोध भेजने का प्रयास करती है: एक प्रतिबिंबित XSS हमला। आपकी वेबसाइट पर आने वाली साख पर आपकी बैंक वेबसाइट का भरोसा है (इसलिए आपकी वेबसाइट की ओर से) इसलिए अनुरोध को प्रमाणित किया जाता है और HTTPदुर्भावनापूर्ण कोड के लिए एक प्रतिक्रिया जारी की जाती है। यदि आपकी बैंक वेबसाइट अन्य उत्पत्ति के साथ अपने समापन बिंदुओं को साझा करने के बारे में परवाह नहीं करती है, तो इसमें शामिल नहीं हैAccess-Control-Allow-Originप्रतिक्रिया में हेडर। अब, अनुरोध के आने पर, ब्राउज़र को पता चलता है कि अनुरोध एक क्रॉस ऑरिजिंस अनुरोध था, लेकिन प्रतिक्रिया यह नहीं दिखाती है कि सर्वर आपकी वेबसाइट के साथ संसाधन (यहां संतुलन क्वेरी समापन बिंदु) साझा करने के लिए खुश था। तो यह प्रवाह को तोड़ता है, इसलिए लौटा हुआ परिणाम कभी भी दुर्भावनापूर्ण कोड तक नहीं पहुंचेगा।

Comments

अच्छा, स्वीकार किए जाते हैं उत्तर से बेहतर / स्पष्ट IMO

— 3DGrabber