मुझे हाल ही में क्रॉस-सबडोमेन अजाक्स कॉल करने में सक्षम होने के लिए सेट Access-Control-Allow-Originकरना पड़ा *।
अब मैं मदद नहीं कर सकता लेकिन मुझे लगता है कि मैं अपने पर्यावरण को सुरक्षा जोखिमों में डाल रहा हूं।
अगर मैं इसे गलत कर रहा हूं तो कृपया मेरी मदद करें।
जवाबों:
के साथ जवाब देकर Access-Control-Allow-Origin: *, अनुरोधित संसाधन हर मूल के साथ साझा करने की अनुमति देता है। इसका मूल रूप से मतलब यह है कि कोई भी साइट आपकी साइट पर एक एक्सएचआर अनुरोध भेज सकती है और सर्वर की प्रतिक्रिया तक पहुंच सकती है जो अगर आपने इस कॉर्स प्रतिक्रिया को लागू नहीं किया था, तो ऐसा नहीं होगा।
तो कोई भी साइट अपने आगंतुकों की ओर से आपकी साइट पर अनुरोध कर सकती है और उसकी प्रतिक्रिया को संसाधित कर सकती है। यदि आपके पास प्रमाणीकरण या प्राधिकरण योजना जैसी कोई चीज़ लागू है, जो कि ब्राउज़र (कुकीज़, कुकी-आधारित सत्र, आदि) द्वारा स्वचालित रूप से प्रदान की जाने वाली चीज़ पर आधारित है, तो तृतीय पक्ष साइटों द्वारा ट्रिगर किए गए अनुरोध उनका भी उपयोग करेंगे।
यह वास्तव में सुरक्षा जोखिम पैदा करता है, खासकर यदि आप संसाधन को केवल चयनित संसाधनों के लिए ही नहीं, बल्कि प्रत्येक संसाधन के लिए साझा करने की अनुमति देते हैं। इस संदर्भ में आपके पास एक नज़र होनी चाहिए कि कॉर्स को सक्षम करना कब सुरक्षित है? ।
Access-Control-Allow-Origin: *हैं? कोई नोगिन आदि नहीं होंगे, वे सभी के लिए सार्वजनिक हैं?
Access-Control-Allow-Origin: *किसी भी संसाधन को जोड़ने के लिए पूरी तरह से सुरक्षित है, जब तक कि संसाधन में मानक क्रेडेंशियल (कुकीज़, मूल स्थिति, टीएलएस ग्राहक प्रमाणपत्र) के अलावा किसी अन्य द्वारा संरक्षित निजी डेटा शामिल नहीं है।
कल्पना कीजिए https://example.com/users-private-data, जो राज्य में उपयोगकर्ता के लॉग के आधार पर निजी डेटा को उजागर कर सकता है। यह राज्य एक सत्र कुकी का उपयोग करता है। यह सुरक्षित जोड़ने के लिए Access-Control-Allow-Origin: *इस संसाधन के लिए, के रूप में इस शीर्ष लेख केवल जवाबी कार्रवाई के लिए उपयोग की अनुमति देता है, तो अनुरोध कुकी के बिना किया जाता है, और कुकीज़ निजी डेटा प्राप्त करने के लिए आवश्यक हैं। नतीजतन, कोई भी निजी डेटा लीक नहीं हुआ है।
कल्पना कीजिए https://intranet.example.com/company-private-data, जो निजी कंपनी के डेटा को उजागर करता है, लेकिन यह केवल तभी तक पहुँचा जा सकता है जब आप कंपनी के वाईफाई नेटवर्क पर हों। यह सुरक्षित नहीं जोड़ने के लिए Access-Control-Allow-Origin: *, इस संसाधन के रूप में यह मानक साख के अलावा कुछ का उपयोग कर संरक्षित है। अन्यथा, एक बुरी स्क्रिप्ट आपको इंट्रानेट के लिए एक सुरंग के रूप में उपयोग कर सकती है।
कल्पना करें कि एक गुप्त विंडो में संसाधन तक पहुँचने पर उपयोगकर्ता क्या देखेगा। यदि आप इस सामग्री (ब्राउज़र द्वारा प्राप्त स्रोत कोड सहित) को देखकर सभी से खुश हैं, तो इसे जोड़ना सुरक्षित है Access-Control-Allow-Origin: *।
Access-Control-Allow-Origin: *केवल कुकीज़ के बिना अनुरोध की अनुमति देता है । मैंने उत्तर को थोड़ा स्पष्ट करने के लिए संपादित किया है।
AFAIK, Access-Control-Allow-Origin केवल एक http हैडर है जो सर्वर से ब्राउज़र में भेजा जाता है। इसे एक विशिष्ट पते पर सीमित करना (या इसे अक्षम करना) आपकी साइट को सुरक्षित नहीं बनाता है, उदाहरण के लिए, रोबोट। यदि रोबोट चाहते हैं, तो वे हेडर को अनदेखा कर सकते हैं। नियमित ब्राउज़र वहाँ (एक्सप्लोरर, क्रोम, आदि) डिफ़ॉल्ट रूप से हेडर का सम्मान करते हैं। लेकिन पोस्टमैन की तरह एक आवेदन बस इसे अनदेखा करता है।
सर्वर का अंत वास्तव में यह जांच नहीं करता है कि प्रतिक्रिया के वापस आने पर 'मूल' क्या है। यह सिर्फ http हैडर जोड़ता है। यह ब्राउज़र (क्लाइंट एंड) है जिसने अनुरोध भेजा है जो एक्सेस-कंट्रोल हेडर को पढ़ने और उस पर कार्य करने का निर्णय लेता है। ध्यान दें कि XHR के मामले में यह पहले हेडर के लिए पूछने के लिए एक विशेष 'विकल्प' अनुरोध का उपयोग कर सकता है।
तो, रचनात्मक स्क्रिप्टिंग क्षमताओं वाला कोई भी आसानी से पूरे हेडर को अनदेखा कर सकता है, जो भी इसमें सेट है।
Access-Control-Allow-Origin की स्थापना के संभावित सुरक्षा मुद्दे भी देखें ।
अब वास्तव में प्रश्न का उत्तर देना है
मैं मदद नहीं कर सकता लेकिन मुझे लगता है कि मैं अपने पर्यावरण को सुरक्षा जोखिमों में डाल रहा हूं।
यदि कोई आप पर हमला करना चाहता है, तो वे आसानी से एक्सेस-कंट्रोल-अनुमति-उत्पत्ति को बायपास कर सकते हैं। लेकिन '*' को सक्षम करने से आप हमलावर को कुछ और 'अटैक वैक्टर' देते हैं, जैसे कि नियमित रूप से वेबब्रोजर्स का उपयोग करके, जो कि HTTP हेडर का सम्मान करते हैं।
Access-Control-Allow-Origin *एक दुर्भावनापूर्ण वेबसाइट पर सेटिंग करना जो स्क्रिप्ट को पासवर्ड चुराने के लिए होस्ट करता है, दृढ़ता से हतोत्साहित किया जाता है :-)
192.168.1.1) के लिए HTTP अनुरोध कर सकती है और हमलों की अनुमति देने के लिए अपने राउटर को फिर से कॉन्फ़िगर कर सकती है। यहां तक कि यह आपके राउटर को सीधे DDoS नोड के रूप में उपयोग कर सकता है। (अधिकांश राउटर में परीक्षण पृष्ठ होते हैं जो पिंग या सरल HTTP सर्वर चेक के लिए अनुमति देते हैं। इनका दुरुपयोग किया जा सकता है।)
यहां 2 उदाहरण टिप्पणी के रूप में पोस्ट किए गए हैं, जब एक वाइल्डकार्ड वास्तव में समस्याग्रस्त है:
मान लीजिए मैं अपने बैंक की वेबसाइट पर लॉग इन करता हूं। यदि मैं दूसरे पृष्ठ पर जाता हूं और फिर अपने बैंक में वापस जाता हूं, तो मैं कुकी के कारण अभी भी लॉग इन हूं। इंटरनेट पर अन्य उपयोगकर्ता मेरे बैंक में उसी URL को हिट कर सकते हैं जैसा कि मैं करता हूं, फिर भी वे कुकी के बिना मेरे खाते तक नहीं पहुंच पाएंगे। यदि क्रॉस-उत्पत्ति अनुरोधों की अनुमति है, तो एक दुर्भावनापूर्ण वेबसाइट उपयोगकर्ता को प्रभावी ढंग से लागू कर सकती है।
- ब्रैड
मान लीजिए कि आपके पास एक कॉमन होम राउटर है, जैसे कि Linksys WRT54g या कुछ और। मान लीजिए कि राउटर क्रॉस-ऑरिजनल रिक्वेस्ट को अनुमति देता है। मेरे वेब पेज की एक स्क्रिप्ट, सामान्य राउटर आईपी एड्रेस (जैसे 192.168.1.1) से HTTP अनुरोध कर सकती है और हमलों की अनुमति देने के लिए अपने राउटर को फिर से कॉन्फ़िगर कर सकती है। यह आपके राउटर को सीधे DDoS नोड के रूप में भी उपयोग कर सकता है। (अधिकांश राउटर में परीक्षण पृष्ठ होते हैं जो पिंग या सरल HTTP सर्वर चेक की अनुमति देते हैं। इनका दुरुपयोग किया जा सकता है।)
- ब्रैड
मुझे लगता है कि इन टिप्पणियों के उत्तर होने चाहिए थे, क्योंकि वे समस्या को वास्तविक जीवन के उदाहरण के साथ समझाते हैं।
परिदृश्य में जहां सर्वर हेडर को नीचे सेट करके पूरी तरह से कोर को निष्क्रिय करने का प्रयास करता है।
प्रवेश-नियंत्रण-अनुमति-उत्पत्ति: * (उस ब्राउज़र को बताता है जो सर्वर किसी भी ORIGIN से क्रॉस साइट अनुरोध स्वीकार करता है)
Access-Control-Allow-Credentials: true (ब्राउज़र बताता है कि क्रॉस साइट अनुरोध कुकीज़ भेज सकते हैं)
ब्राउज़रों में एक विफल सुरक्षित क्रियान्वयन होता है जिसके परिणामस्वरूप नीचे त्रुटि होगी
"Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’"इसलिए अधिकांश परिदृश्यों में 'एक्सेस-कंट्रोल-अलाउंस-ओरिजिन' को स्थापित करने *में समस्या नहीं होगी। हालाँकि, हमलों के खिलाफ सुरक्षित करने के लिए, सर्वर अनुमत उत्पत्ति की सूची को बनाए रख सकता है और जब भी सर्वर को एक क्रॉस मूल अनुरोध प्राप्त होता है, तो यह अनुमति दी गई मूल की सूची के खिलाफ ORIGIN शीर्षलेख को मान्य कर सकता है और फिर एक्सेस-कंट्रोल-अनुमति-उत्पत्ति में उसी को वापस गूंज सकता है। हैडर।
चूंकि ORIGIN हेडर को ब्राउज़र पर चलने वाली जावास्क्रिप्ट द्वारा नहीं बदला जा सकता है, दुर्भावनापूर्ण साइट इसे स्पूफ नहीं कर पाएगी।