एक सर्वर साइड प्रॉक्सी लिखने की सादगी को देखते हुए जो डोमेन पर डेटा लाता है, मुझे लगता है कि शुरुआती इरादा क्लाइंट पक्ष AJAX को डोमेन पर कॉल करने से रोकने में क्या था। मैं अटकलों के लिए नहीं पूछ रहा हूं, मैं डेवलपर्स के लिए हल्की असुविधा पैदा करने के अलावा, भाषा डिजाइनरों (या उनके करीब के लोगों) से दस्तावेज की तलाश कर रहा हूं, जो उन्होंने सोचा था कि वे क्या कर रहे थे।AJAX क्रॉस-डोमेन सुरक्षा के पीछे तर्क क्या है?
TIA
यह एक ब्राउज़र को रिवर्स प्रॉक्सी के रूप में कार्य करने से रोकने के लिए है। मान लीजिए कि आप अपने कार्यालय में किसी पीसी से http://www.evil.com ब्राउज़ कर रहे हैं, और मान लीजिए कि उस कार्यालय में http://intranet.company.com पर संवेदनशील जानकारी वाला इंट्रानेट मौजूद है जो केवल स्थानीय नेटवर्क से ही पहुंच योग्य है। यदि क्रॉस डोमेन नीति मौजूद नहीं है, तो www.evil.com आपके ब्राउज़र का उपयोग रिवर्स प्रॉक्सी के रूप में करते हुए http://intranet.company.com पर AJAX अनुरोध कर सकता है, और उस जानकारी को www.evil.com पर अन्य अजाक्स अनुरोध के साथ भेज सकता है।
मुझे लगता है कि प्रतिबंध के कारणों में से एक यह है।
हां यह है:) ... मेरे उत्तर से बहुत अधिक स्पष्ट है, मैंने – fguillen
खो दिया है जो लगता है कि * बेहद दूर है। आपके इंट्रानेट में एजेक्स उत्तरदाताओं को होना होगा जो बुराई को जानना होगा कि कॉल कैसे करें! यदि यह वास्तव में चिंता का विषय है, तो इंट्रानेट कोई भी CGI नहीं चला सकता है, है ना? –
जैसा कि @ ग्रेब्रियलजर्जेंस ने कहा था, बिना किसी _cross डोमेन नीति_ आपके इंट्रानेट में कोई यूआरआई (केवल सीजीआई नहीं, मुझे नहीं पता कि AJAX उत्तरदाता क्या है) समझौता किया गया है। हमलावर कॉल करने के लिए विशिष्ट यूआरआई को जान सकता है या सिर्फ बलपूर्वक प्रयास कर सकता है, इससे कोई फर्क नहीं पड़ता, यह वास्तविक सुरक्षा समस्या है। – fguillen
इस सीमा के लिए सबसे महत्वपूर्ण कारण एक सुरक्षा चिंता का विषय है: JSON अनुरोध करना ब्राउज़र की सेवा और किसी अन्य डोमेन में अनुरोध के साथ कुकीज़ या सुरक्षा क्रेडेंशियल को स्वीकार करना चाहिए? यह सर्वर-साइड प्रॉक्सी के साथ कोई चिंता नहीं है, क्योंकि इसकी क्लाइंट पर्यावरण तक सीधी पहुंच नहीं है। a proposal for safe sanitized JSON-specific request methods था, लेकिन इसे अभी तक कहीं भी लागू नहीं किया गया था।
यदि आप myblog.com के लेखक हैं और आप facebook.com पर XHR बनाते हैं, तो क्या अनुरोध आपके फेसबुक कुकी प्रमाण-पत्र भेजना चाहिए? नहीं, इसका मतलब यह होगा कि आप अपने ब्लॉग से उपयोगकर्ताओं की निजी फेसबुक जानकारी का अनुरोध कर सकते हैं।
यदि आप ऐसा करने के लिए प्रॉक्सी सेवा बनाते हैं, तो आपकी प्रॉक्सी फेसबुक कुकीज़ तक नहीं पहुंच सकती है।
आप सवाल भी पूछ सकते हैं कि JSONP ठीक क्यों है। इसका कारण यह है कि आप एक स्क्रिप्ट लोड कर रहे हैं जिसे आपने नहीं लिखा था, इसलिए जब तक कि फेसबुक की स्क्रिप्ट आपको अपने जेएस कोड से जानकारी भेजने का फैसला नहीं करती है, तब तक आपको इसकी पहुंच नहीं होगी
शायद मैं एक्सएचआर से परिचित नहीं हूं जैसा कि मुझे होना चाहिए ... क्या एक्सएचआर के हिस्से को कुकीज़ खींचने और जांचने की निहित क्षमता है? मैंने सोचा कि कुकीज एक अलग तंत्र थे, और एक्सएचआर विशेष रूप से (और विशेष रूप से) HTTP अनुरोधों के लिए डेटा ट्रांसफर तंत्र था। –
एक्सएचआर एक HTTP अनुरोध है। यह हमेशा उस डोमेन के लिए कुकीज़ भेजता है, जिसे आप कनेक्ट कर रहे हैं, जैसे कि जब आप किसी HTML पृष्ठ या उस डोमेन की छवि का अनुरोध करते हैं, तो अपने हेडर बाहर निकलते हैं यदि आप अपने पृष्ठ पर XHR बनाते हैं, या किसी छवि, स्क्रिप्ट का अनुरोध करते हैं , या यहां तक कि किसी अन्य सर्वर से एक आईफ्रेम –
प्रत्यक्ष पहुंच और एक के बीच का अंतर प्रॉक्सी कुकीज़ और अन्य सुरक्षा प्रासंगिक पहचान/सत्यापन जानकारी है जो पूरी तरह से एक मूल तक सीमित है।
उन लोगों के साथ, आपका ब्राउज़र संवेदनशील डेटा तक पहुंच सकता है। आपकी प्रॉक्सी नहीं होगी, क्योंकि यह उपयोगकर्ता के लॉगिन डेटा को नहीं जानता है।
इसलिए, प्रॉक्सी केवल सार्वजनिक डेटा पर लागू होती है; जैसा कि CORS है।
मुझे पता है तुम विशेषज्ञों का जवाब के लिए पूछ रहे हैं, मैं तो बस एक नौसिखिया हूँ, और यह क्यों सर्वर साइड प्रॉक्सी एक उचित अंतिम समाधान नहीं है करने के लिए मेरी राय है:
document.domain को संशोधित करें।और सबसे मेरे लिए महत्वपूर्ण:
लेकिन, अपने प्रश्न को फिर से पढ़ने के बाद, मुझे लगता है कि मैंने अभी भी इसका जवाब नहीं दिया है, इसलिए यह AJAX सुरक्षा क्यों?, फिर मुझे लगता है, जवाब है:
चूंकि आप किसी वेब पृष्ठ पर जाएं अपने कार्यालय के इंट्रानेट में किसी भी कंप्यूटर या सर्वर के लिए अपने डेस्कटॉप से कॉल बनाने के लिए सक्षम होने के लिए नहीं करना चाहती
, यह एक पूर्ण लाल हेरिंग है। यदि आपका इंट्रानेट सीजीआई अनुरोधों को लेने और संसाधित करने के लिए स्थापित किया गया है, तो वह पृष्ठ उन लोगों का लाभ लेने की संभावना है। यह बस वास्तविक दुनिया की चिंता नहीं है! –
http://msdn.microsoft.com/en-us/library/cc709423(v=vs.85).aspx – user1096188
http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_XMLHttpRequest पढ़ने के लायक पूरी किताब। – jasssonpet
@jasssonpet बहुत बढ़िया लिंक, इसे बुकमार्क किया गया! –