सीएसआरएफ ब्राउज़र सुरक्षा समस्या नहीं है?

Question

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

क्या ऐसे व्यवहार को अस्वीकार कर ब्राउज़र में सीएसआरएफ आसानी से रोकथाम योग्य नहीं है?

जहां तक ​​मुझे पता है, इस तरह की सुरक्षा जांच वेब ब्राउज़र में लागू नहीं की गई है, लेकिन मुझे समझ में नहीं आता क्यों। क्या मुझे कुछ गलत मिला?

CSRF के बारे में:

• On wikipedia
• On coding horror

संपादित करें: मुझे लगता है कि कुकीज़ उपरोक्त मामले में http पोस्ट पर नहीं भेजा जाना चाहिए। वह ब्राउज़र व्यवहार है जो मुझे आश्चर्यचकित करता है।

Answer 1

ब्राउजर कुकीज़ क्यों नहीं भेजेगा?

साइट ए (http://www.sitea.com) उपयोगकर्ता के लिए एक कुकी सेट करता है।

उपयोगकर्ता साइट बी (http://www.siteb.com) पर नेविगेट करता है। साइट बी साइट ए के साथ एकीकरण सुविधाएँ - साइट ए पर कुछ करने के लिए यहां क्लिक करें! उपयोगकर्ता "यहां" क्लिक करते हैं।

जहां तक ​​ब्राउज़र कह सकता है, उपयोगकर्ता साइट ए के लिए अनुरोध करने का सचेत निर्णय ले रहा है, इसलिए यह साइट ए के किसी भी अनुरोध को संभालने के समान तरीके से संभालता है, और इसमें साइट ए कुकीज़ भेजना शामिल है संपादित साइट ए

---

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

या आप कह रहे हैं यदि आप "जीमेल" के लिए याहू खोज, और फिर लिंक है कि आप http://mail.google.com पर ले जाता है पर क्लिक करें, आप लॉग इन नहीं किया जाना चाहिए, भले ही आप आप में लॉग इन रखने के लिए जीमेल बताया , क्योंकि आपने किसी अन्य साइट से लिंक पर क्लिक किया है?

Answer 2

ऐसा नहीं है कि ब्राउज़र बाहरी डोमेन पर या कुकी से कुकी भेज रहा है, यह तथ्य है कि आप प्रमाणीकृत हैं और साइट अनुरोध के स्रोत को मान्य नहीं कर रही है, इसलिए यह इस तरह से व्यवहार करती है जैसे कि अनुरोध साइट से आया था।

जहां तक ​​एक ब्राउज़र को यह अस्वीकार करना चाहिए कि ... ऐसी कई स्थितियों के बारे में क्या है जहां क्रॉस-साइट अनुरोध वांछनीय हैं?

संपादित करें: स्पष्ट होने के लिए, आपकी कुकी डोमेन पर नहीं भेजी जाती है।

Answer 3

मुझे नहीं पता कि एक्सएसआरएफ हमले के बिंदु से ब्राउज़र उस ब्राउज़र में ऐसा कर सकता है क्योंकि ब्राउजर को उस एप्लिकेशन में किसी अन्य बिंदु पर निर्देशित करना है जो कुछ खराब करेगा। दुर्भाग्यवश, ब्राउज़र को पता नहीं है कि भेजने के लिए निर्देशित किया जा रहा अनुरोध दुर्भावनापूर्ण है या नहीं।

<img src="http://domain.com/do_something_bad" /> 

यह ब्राउज़र है कि कुछ बुरा हो रहा है स्पष्ट नहीं है: उदाहरण के लिए, XSRF की क्लासिक उदाहरण दिया। आखिरकार, यह और उसके बीच के अंतर को कैसे जानना है:

<img src="http://domain.com/show_picture_if_authenticated" /> 

Answer 4

पुराने पुराने प्रोटोकॉल में बहुत से सुरक्षा छेद हैं - हाल ही में खोजे गए DNS vulnerabilities पर वापस सोचें। मूल रूप से किसी भी नेटवर्क सुरक्षा की तरह, यह अंत-बिंदुओं की ज़िम्मेदारी है; हाँ, यह बेकार है कि हमें इसे स्वयं ठीक करना है, लेकिन ब्राउज़र स्तर पर ठीक करना बहुत कठिन है। कुछ स्पष्ट हैं (< img src = "logoff.php" > बहुत खराब लग रहा है, है ना?), लेकिन हमेशा किनारे के मामले होंगे। (शायद यह एक PHP फ़ाइल में एक जीडी स्क्रिप्ट है।) AJAX प्रश्नों के बारे में क्या? और इतने पर ...

Answer 5

किसी साइट के लिए कुकीज़ किसी अन्य साइट पर कभी नहीं भेजी जाती है। वास्तव में, एक सफल सीएसआरएफ हमले को लागू करने के लिए, हमलावर को इन कुकीज़ तक पहुंच की आवश्यकता नहीं है।

असल में, एक हमलावर उपयोगकर्ता को ट्रिक्स करता है, जो पहले से ही लक्षित वेबसाइट पर लॉग इन होता है, एक लिंक पर क्लिक करने या उस छवि को लोड करने में जो उस उपयोगकर्ता के क्रेडेंशियल्स के साथ लक्षित साइट पर कुछ करेगा।

आईई, उपयोगकर्ता कार्रवाई कर रहा है, और हमलावर ने उपयोगकर्ता को ऐसा करने में धोखा दिया है।

Answer 6

कुछ लोगों ने कहा है कि उन्हें नहीं लगता कि ब्राउज़र बहुत कुछ कर सकता है।

देखें इस:

http://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html

यह एक नया HTTP शीर्षक के लिए एक प्रस्ताव मदद करने के लिए CSRF हमलों को कम करने के एक सिंहावलोकन है।

प्रस्तावित हैडर नाम "उत्पत्ति" है और यह मूल रूप से "संदर्भ" शीर्षलेख शून्य पथ आदि है