एक सत्र के सीएसआरएफ-सुरक्षा टोकन को सुरक्षित कर रहा है?

Django CSRF protection middleware के साथ आता है, जो फ़ॉर्म में उपयोग के लिए एक अद्वितीय प्रति-सत्र टोकन उत्पन्न करता है। यह सही टोकन के लिए आने वाले POST अनुरोधों को स्कैन करता है, और टोकन गुम या अवैध होने पर अनुरोध को अस्वीकार करता है।एक सत्र के सीएसआरएफ-सुरक्षा टोकन को सुरक्षित कर रहा है?

मैं कुछ POST अनुरोधों के लिए AJAX का उपयोग करना चाहता हूं, लेकिन कहा कि अनुरोधों में सीएसआरएफ टोकन availabnle नहीं है। पृष्ठों में <form> तत्वों को हुक करने के लिए कोई नहीं है और मैं टोकन को छिपे हुए मान के रूप में डालने वाले मार्कअप को गड़बड़ नहीं करना चाहूंगा। मुझे यह करने का एक अच्छा तरीका है कि उपयोगकर्ता के टोकन को वापस करने के लिए /get-csrf-token/ जैसे वीव को बेनकाब करना है, शत्रुतापूर्ण साइटों को अनुरोध करने से रोकने के लिए ब्राउज़र के क्रॉस-साइट स्क्रिप्टिंग नियमों पर निर्भर होना।

क्या यह एक अच्छा विचार है? क्या AJAX अनुरोधों को अनुमति देते हुए सीएसआरएफ हमलों के खिलाफ सुरक्षा के बेहतर तरीके हैं?

स्रोत

2008-09-27 John Millikin

यदि आपको पता है कि आपको AJAX अनुरोधों के लिए सीएसआरएफ टोकन की आवश्यकता होगी, तो आप इसे हमेशा HTML में एम्बेड कर सकते हैं; तो आप इसे डोम ट्रैवर्स करके जावास्क्रिप्ट के माध्यम से पा सकते हैं। इस तरह, आपके पास अभी भी टोकन तक पहुंच होगी, लेकिन आप इसे एपीआई के माध्यम से उजागर नहीं कर रहे हैं।

इसे एक और तरीका रखने के लिए: इसे Django के टेम्पलेट्स के माध्यम से करें - यूआरएल प्रेषक के माध्यम से नहीं। यह इस तरह से अधिक सुरक्षित है।

स्रोत

2008-09-28 01:36:36

सीएसआरएफ टोकन हर ऑपरेशन के साथ बदलना चाहिए। क्या आप सुझाव दे रहे हैं कि प्रत्येक ऑपरेशन टोकन अपडेट करें? इसका मतलब यह नहीं है कि उपयोगकर्ता के संचालन को तुल्यकालिक बनना होगा (दूसरा तब तक शुरू नहीं हो सकता जब तक कि पहले वापस नहीं आया और नया सीएसआरएफ टोकन दिया गया हो)। – Mystic

यह सबसे अच्छा जवाब नहीं है। जैसा कि कार्ल मेयर ने अपने जवाब में कहा है: डीजेगो * में टोकन * का उपयोग करके सीएसआरएफ से AJAX अनुरोधों की सुरक्षा करने की कोई आवश्यकता नहीं है, क्योंकि Django पहले से ही AJAX अनुरोधों को एक अलग तरीके से सुरक्षित करता है। यह रहस्यवादी चिंता को भी हटा देता है। – hopla

शायद यह मदद करेगा, भले ही मैंने इस कहानी को AJAX और CSRF के बारे में सॉर्ट नहीं किया है http://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax – amirouche

रद्द करें, मैं गलत था। (टिप्पणियां देखें।) आप अपने JSON को spec का पालन करके यह सुनिश्चित करके शोषण को रोक सकते हैं: हमेशा सुनिश्चित करें कि आप शीर्ष-स्तर ऑब्जेक्ट के रूप में किसी ऑब्जेक्ट को शाब्दिक रूप से वापस कर दें। (मैं गारंटी नहीं दे सकता कि वहां और अधिक शोषण नहीं होंगे। एक ब्राउज़र की कल्पना करें कि उसकी खिड़की में असफल कोड तक पहुंच प्रदान की जा रही है। आतंकवादी घटनाएं!)

आप AJAX रखने के लिए क्रॉस-साइट-स्क्रिप्टिंग नियमों पर भरोसा नहीं कर सकते प्रतिक्रिया निजी। उदाहरण के लिए, यदि आप CSONF टोकन JSON के रूप में वापस करते हैं, तो एक दुर्भावनापूर्ण साइट redefine the String or Array constructor हो सकती है और संसाधन का अनुरोध कर सकती है।

bigmattyh सही है: आपको मार्कअप में कहीं भी टोकन एम्बेड करने की आवश्यकता है। वैकल्पिक रूप से, आप किसी भी POSTs को अस्वीकार कर सकते हैं जो में एक रेफरर है कि मिलान नहीं है। इस तरह, केवल अति उत्साही सॉफ्टवेयर फ़ायरवॉल वाले लोग सीएसआरएफ के लिए कमजोर होंगे।

स्रोत

2008-09-28 17:58:09 phyzome

उह, वह लिंक फिर से। कम से कम लेखक ने अंत में एक नोट जोड़ा है कि वह गलत है। जेएसओएन वास्तव में कन्स्ट्रक्टर को फिर से परिभाषित करने के लिए कमजोर नहीं है, क्योंकि जब आप अनजान JSON को पार्स करने का प्रयास करते हैं तो जावास्क्रिप्ट पार्सर अपवाद उठाएगा। –

अद्यतन: नीचे सत्य था, और यदि सभी ब्राउज़रों और प्लगइन्स को सही ढंग से कार्यान्वित किया गया तो यह सच होना चाहिए। दुर्भाग्यवश, अब हम जानते हैं कि वे नहीं हैं, और ब्राउज़र प्लगइन्स और रीडायरेक्ट के कुछ संयोजन एक हमलावर को क्रॉस-डोमेन अनुरोध पर मनमाने ढंग से शीर्षलेख प्रदान करने की अनुमति दे सकते हैं। दुर्भाग्यवश, इसका मतलब है कि "एक्स-अनुरोधित-साथ: XMLHttpRequest" शीर्षलेख के साथ भी AJAX अनुरोधों को अब CSRF- संरक्षित होना चाहिए। नतीजतन, Django no longer exempts Ajax requests from CSRF protection।

मूल उत्तर

ऐसा नहीं है कि CSRF से AJAX अनुरोध की रक्षा अनावश्यक है, के बाद से ब्राउज़रों क्रॉस साइट AJAX अनुरोध की अनुमति नहीं है उल्लेख के लायक है। वास्तव में, डीजेगो सीएसआरएफ मिडलवेयर अब automatically exempts AJAX requests from CSRF token scanning।

यह केवल तभी वैध है जब आप वास्तव में "XMLHttpRequest" मान (जो Django करता है) के लिए एक्स-अनुरोधित-शीर्षलेख सर्वर-पक्ष की जांच कर रहे हैं, और केवल सीएसआरएफ स्कैनिंग से वास्तविक AJAX अनुरोधों को छोड़ रहे हैं।

स्रोत

2009-02-10 17:55:11

यह सच नहीं है। एक AJAX अनुरोध स्पष्ट रूप से एक सर्वर (आपका) के साथ संचार कर रहा है। एक हमलावर के रूप में, मैं अभी भी कई अलग-अलग तरीकों से और बिना सीएसआरएफ सुरक्षा के एक ही पोस्ट अनुरोध बना सकता हूं, यदि उपयोगकर्ता लॉग इन होता है तो मैं सफल होगा। – Nathan

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

@ करल मेयर: मैं अभी भी असहमत हूं। मैं (उदाहरण के लिए) उपयोगकर्ता को अपने नियंत्रण में एक वेबसाइट पर आकर्षित कर सकता हूं जो सर्वर पर एक पोस्ट को उसी तरह बनाता है जैसे AJAX अनुरोध करता है - आपकी साइट में जावास्क्रिप्ट का कोई इंजेक्शन आवश्यक नहीं है। सामान्य http पोस्ट पर कोई भी डोमेन प्रतिबंध नहीं है - मैं किसी भी डोमेन के साथ किसी भी डोमेन पर पोस्ट कर सकता हूं। कुकीज़ अनुरोध के साथ भेजी जाती हैं - पृष्ठ के साथ नहीं। यह अभी भी एक क्रॉस-साइट-अनुरोध-फोर्जरी की श्रेणी के अंतर्गत आता है। – Nathan

एक सत्र के सीएसआरएफ-सुरक्षा टोकन को सुरक्षित कर रहा है?

उत्तर

संबंधित मुद्दे