वेब सर्वर एक ही मूल नीति को कैसे लागू करते हैं?

Question

मैं RESTful API को विकसित करने में गहराई से गोता लगा रहा हूं और इसे प्राप्त करने के लिए अब तक कुछ अलग रूपरेखाओं के साथ काम किया है। बेशक मैं एक ही मूल नीति में चला गया हूं, और अब मैं सोच रहा हूं कि वेब सर्वर (वेब ​​ब्राउज़र के बजाय) इसे कैसे लागू करते हैं। जो मैं समझता हूं, कुछ ब्राउज़र के अंत में होता है (उदाहरण के लिए, एक सर्वर से प्राप्त एक्सेस-कंट्रोल-अनुमति-मूल हेडर का सम्मान करते हुए)। लेकिन सर्वर का क्या?

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

या क्या क्रॉस-ऑरिजिन पॉलिसी केवल क्लाइंट एंड पर लागू होती है?

Comments

वास्तव में एक अच्छा सवाल

— बेनी

Answer 1

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

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

समान-मूल नीति का आविष्कार किया गया था क्योंकि यह एक वेबसाइट के कोड को किसी अन्य साइट पर क्रेडेंशियल-प्रतिबंधित सामग्री तक पहुंचने से रोकता है । Ajax अनुरोध डिफ़ॉल्ट रूप से लक्षित साइट द्वारा दिए गए किसी भी सामान्य कुकीज़ के साथ भेजे जाते हैं। उदाहरण के लिए, मान लें कि मैं गलती से लोड करता हूं http://evil.com/, जिसके लिए एक अनुरोध भेजा जाता है http://mail.google.com/। यदि SOP नहीं था, और मुझे Gmail में साइन इन किया गया था, तो स्क्रिप्ट evil.comमेरे इनबॉक्स को देख सकती थी । यदि साइट मेरी कुकीज़ के बिना evil.comलोड करना चाहती है mail.google.com, तो यह सिर्फ एक प्रॉक्सी सर्वर का उपयोग कर सकती है; की सार्वजनिक सामग्री mail.google.comएक गुप्त नहीं हैं (लेकिन की सामग्री को mail.google.comजब मेरे कुकीज़ के साथ पहुँचा रहे हैं एक गुप्त)।

Answer 2

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

 Access-Control-Allow-Origin: www.example.com

ब्राउज़र को www.example.com से क्रॉस-ऑरिजिन अनुरोध करने की अनुमति देगा।

 Access-Control-Allow-Origin: *

ब्राउज़र को उस संसाधन के सभी क्रॉस-ऑरिजिन अनुरोधों की अनुमति देने के लिए कहता है।

Answer 3

वेब सर्वर आमतौर पर RefererHTTP हेडर में (बदनाम गलत ढंग से) लाइन की जाँच करके इस तरह के हमलों को रोकते हैं, यह सुनिश्चित करने के लिए कि उनकी साइट पर एक पेज से एक अनुरोध आ रहा है। एक दुर्भावनापूर्ण ग्राहक के खिलाफ पहरा देने का कोई अच्छा तरीका नहीं है, लेकिन यह नहीं है कि कैसे XSRF हमले काम करते हैं।

ग्राहक दुर्भावनापूर्ण नहीं है; यह आम तौर पर एक साधारण उपयोगकर्ता है जो एक दुर्भावनापूर्ण तृतीय-पक्ष द्वारा एक दस्तावेज़ खोलने में धोखा दिया गया है जो क्लाइंट के संग्रहीत कुकीज़ का उपयोग करके चुपचाप HTTP अनुरोध करता है। इसलिए यदि सर्वर इस Refererबात से सत्यापित कर सकता है कि HTTP अनुरोध gmail.com से आ रहा है, न कि MyAwesomeWebsite.com, तो यह हमले को बंद कर सकता है।

Comments

क्या होगा यदि रेफरल लाइन दुर्भावनापूर्ण रूप से जाली है?

— बेनी

@ बेनी: यह अत्यधिक संभावना नहीं है। Refererलाइन उपयोगकर्ता के वेब ब्राउज़र द्वारा उत्पन्न होता है, और उपयोगकर्ता शिकार यहाँ, नहीं हमलावर है। उसके पास कोई कारण नहीं है Referer, और हमलावर के पास ऐसा करने का अवसर नहीं है।

— मेसन व्हीलर

Answer 4

वेब सर्वर एक ही मूल नीति को कैसे लागू करते हैं?

संक्षेप में, वे नहीं करते हैं, जैसा कि अप्सिलर्स और डिर्क ने बताया है।
एक महत्वपूर्ण कारण यह है कि एसीएओ हेडर सर्वरों को खुद को प्रचंड डीडीओएस से बचाता है, - वितरित डेनियल ऑफ सर्विस- हमलों ।

कौन:

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

किस तरह:

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

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

भविष्य:

उस बिंदु पर, वेब-ब्राउज़र निर्माता की दिशा:

• डिफ़ॉल्ट प्लगइन हटाने , एक पूरी तरह से सैंडबॉक्स वाले वातावरण की ओर एक कदम के रूप में और
• जावास्क्रिप्ट को बंद करने के लिए उपयोगकर्ता-विकल्प को हटाना

टीएसएल 2/3, मजबूत सत्र-आईडी, टैन, दो कारक प्रमाणीकरण आदि के संयोजन का उपयोग करके सुरक्षा प्रतिबंधों को शालीनता से स्थापित किया जा सकता है।

'Google' के पास DDOS के बारे में दिखाने और कहने के लिए यह है

अंत में, कोई भी किसी भी वेब सामग्री को प्रॉक्सी करने के लिए स्वतंत्र है और समीपस्थ क्रॉस-साइट सामग्री तक पहुँचने के लिए एक वांछित ACAO हैडर जोड़ सकता है। इसी तरह, यह प्रॉक्सी तब डीडीओएस हमले के लिए खुला है, क्योंकि एसीएओ सेटिंग इसे अनुमति देता है। मैं वास्तव में एक एकल, मुफ्त सार्वजनिक सेवा की पेशकश के बारे में नहीं जानता। अगर मैं गलत हूं कृपया मुझे सही।

Answer 5

जैसा कि दूसरों ने कहा, यह क्लाइंट के ऊपर है। लेकिन सर्वर को XSS से निपटने की आवश्यकता हो सकती है, जो SOP को बायपास करता है।

अपना सर्वर छोड़ दें उपयोगकर्ता उपयोगकर्ताओं को सामग्री अपलोड करने की अनुमति देता है, जो तब प्रदर्शित होता है जब अन्य उपयोगकर्ता आपकी साइट ब्राउज़ करते हैं। यह पृष्ठ एक अच्छा उदाहरण है - मैंने अभी सामग्री अपलोड की है, और यह आपके लिए प्रदर्शित है।
यदि मेरी सामग्री में <script>टैग शामिल है , और सर्वर इसे HTML में कॉपी करता है, तो यह मेरे द्वारा अपलोड की गई स्क्रिप्ट चलेगा।
चूंकि स्क्रिप्ट आपकी फ़ाइल से HTML में मिली थी, इसलिए इसमें आपकी साइट की स्क्रिप्ट की सभी अनुमतियां हैं। उदाहरण के लिए, यह इस उत्तर को बढ़ा सकता है। और यही कारण है कि इस उत्तर में बहुत सारे उत्थान हैं।

एक अच्छा वेब सर्वर (जैसे, अफसोस, एक StackExchange का उपयोग करता है), ऐसा नहीं होने देंगे। यह <script>टैग को हटा सकता है , या इसे बच सकता है, इसलिए यह देखा जाएगा, लेकिन निष्पादित नहीं किया जाएगा (चेतावनी - यह उत्तर XSS को रोकने के लिए एक विश्वसनीय नुस्खा से बहुत दूर है)।

तो यह ग्राहक पक्ष है जो एसओपी को लागू करता है, लेकिन कुछ मामलों में सर्वर को इसे दरकिनार करने से रोकने के लिए काम करना चाहिए।