क्रॉस-डोमेन XMLHttpRequest का उपयोग करने में सुरक्षा जोखिम क्या हैं?

Question

कई जगहों पर मैंने देखा है कि लोगों ने क्रॉस-डोमेन XMLHttpRequest के बारे में बात की है, जो संभव नहीं है, सुरक्षा कारणों के कारण। हालांकि, मुझे कोई पोस्ट नहीं मिला है जो सुरक्षा कारण वास्तव में हैं?

लोगों ने उल्लेख किया है कि JSONP अच्छे विकल्पों में से एक है। एक और विकल्प Origin और Access-Control-Allow-Origin हेडर का उपयोग करना होगा।

हालांकि, मैं सिर्फ यह जानना चाहता हूं कि क्रॉस-डोमेन XMLHttpRequest उपयोग के कारण सुरक्षा समस्याएं कैसे उठाई जा सकती हैं?

Answer 1

मुझे लगता है कि यह एक उदाहरण के आपके प्रश्न का उत्तर देना सबसे अच्छा होगा कि क्यों यह बेहद खराब होगा।

आप मेरी वेबसाइट (example.org) पर जाते हैं। मैं एक स्क्रिप्ट लोड करता हूं जो क्लाइंट-साइड AJAX अनुरोध को facebook.com/messages/from/yourgirlfriend को बनाता है। आप फेसबुक में लॉग इन हुए थे, और आपका ब्राउज़र फेसबुक को बताता है कि मेरा अनुरोध वास्तव में आप है। फेसबुक खुशी से मेरा अनुरोध देता है कि अजीब यौन चीजों के बारे में संदेश जो आप कोशिश करना चाहते हैं। अब मैं तुम्हारे बारे में चीजें जानता हूं, शायद आप मुझे नहीं जानना चाहते थे।

यह निश्चित रूप से एक जंगली अतिसंवेदनशीलता है, और धन्यवाद, वही मूल नीति के लिए धन्यवाद संभव नहीं है।

अब आप सुरक्षित महसूस नहीं करते?

Answer 2

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

जेएसओएनपी इस सुरक्षा उपाय के आसपास सिर्फ एक काम है, जहां आप गंतव्य को कॉलबैक देते हैं और जो भी वे आपको इस कॉलबैक के माध्यम से वापस दे देंगे उन्हें सौंप देते हैं।

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

Answer 3

इन "सुरक्षा कारणों" के बिना पूरे इंटरनेट के रूप में आप जानते हैं कि यह अस्तित्व में नहीं था। असल में मैं एक अंग पर बाहर जाऊंगा और कहूंगा कि कोई नियम नहीं है जो इंटरनेट सुरक्षा के लिए समान मूल नीति से अधिक महत्वपूर्ण है।

कोई भी वेब पेज इन नियमों, Google, वेब मेल खातों, एसओ के बिना प्रमाणीकरण प्राप्त कर सकता है, इनमें से कोई भी अस्तित्व में नहीं हो सकता है। ऐसा लगता है कि आपके पास प्रत्येक डोमेन पर एक्सएसएस था। आप gmail.com के खिलाफ एक एक्सएचआर कर सकते हैं और किसी के ईमेल को पढ़ सकते हैं। सीएसआरएफ टोकन काम नहीं करेंगे क्योंकि आप किसी भी पेज को पढ़ सकते हैं और अनुरोध तैयार कर सकते हैं।

कोई भी समान मूल नीति नहीं है, लेकिन नियम Google Browser Security handbook में स्पष्ट रूप से निर्धारित किए गए हैं। ये बहुत तार्किक हैं, और विभिन्न प्लेटफार्मों के लिए नियम बहुत समान हैं, क्योंकि इस तरह इंटरनेट काम करना चाहिए।

Access-Control-Allow-Origin: * करके आप उस पृष्ठ के लिए वेब ब्राउज़र द्वारा आपको अपने अधिकारों को जब्त कर रहे हैं। इसमें प्रमुख सुरक्षा प्रभाव हैं। आप टोकन का उपयोग कर सीएसआरएफ से अपने आप को बचाने में सक्षम नहीं होंगे। एक capthca इस समस्या को कम कर सकता है, रेफरर की जांच भी मदद कर सकता है (अगर मूल एचटीटीपीएस है तो यह खाली होगा)। आपको CSRF prevention cheat sheet पढ़ना चाहिए।