2009-11-26 13 views
18

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

लेकिन क्या दुर्भावनापूर्ण स्क्रिप्ट पहले के आदेश एक छिपा इनपुट क्षेत्र में antiforgery टोकन युक्त पेज डाउनलोड करने के लिए में (Ajax से) कुछ सरल GET अनुरोध करता जाएगा, यह अर्क, और इसका इस्तेमाल एक वैध POST बनाने के लिए तो क्या होगा?

क्या यह संभव है, या क्या मुझे कुछ याद आ रहा है?

उत्तर

12

हां, यह सब आपको करने की ज़रूरत है।

जब तक आप प्रत्येक संरक्षित पृष्ठ पर कोई नया टोकन बनाएं, <%= Html.AntiForgeryToken() %> और हमेशा यह सुनिश्चित यह किसी भी संरक्षित कार्रवाई में चेक किया गया है के साथ, [ValidateAntiForgeryToken]

का उपयोग कर इस सिंक्रनाइज़र टोकन पैटर्न के रूप में OWASP पर CSRF Prevention Cheat Sheet में चर्चा को लागू करता है ।

स्वीकार्य अनुरोध करने में एक स्क्रिप्ट सफल होने के लिए, इसे पहले फॉर्म प्राप्त करना होगा और टोकन को पढ़ना होगा और फिर टोकन पोस्ट करना होगा। Same Origin Policy इसे ब्राउज़र में अनुमति देने से रोक देगा। एक साइट कैनोट एक AJAX शैली http अनुरोध किसी अन्य साइट पर बनाते हैं; केवल खुद के लिए। अगर किसी कारण से मूल उत्पत्ति का उल्लंघन किया जा सकता है, तो आप कमजोर हो जाएंगे।

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

फ्लैश और सिल्वरलाइट के लिए बाहर देखने के लिए एक और चीज है। इन दोनों तकनीकों में एक ही मूल नीति की सदस्यता नहीं है और इसके बजाय दूरस्थ संसाधनों तक पहुंच प्रतिबंधित करने के लिए क्रॉस डोमेन नीति फ़ाइलों का उपयोग करें। फ्लैश/सिल्वरलाइट स्क्रिप्ट केवल आपकी साइट पर संसाधनों तक पहुंच सकता है यदि आप अपनी साइट पर एक क्रॉस डोमेन नीति xml फ़ाइल प्रकाशित करते हैं। यदि आप इस फ़ाइल को प्रकाशित करते हैं, तो केवल विश्वसनीय तृतीय-पक्ष सर्वरों की श्वेतसूची की अनुमति दें और कभी भी अनुमति न दें *।

और पढ़ें के बारे में भी CSRF at OWASP देखें: XSS Prevention Cheat Sheet

+1

तो टोकन को सत्यापित करने के अलावा किसी को crossdomain.xml के साथ सावधान रहना होगा, है ना? अगर मैं सही ढंग से समझता हूं, अप्रतिबंधित क्रॉस डोमेन अनुरोधों के लिए वेब एप्लिकेशन का खुलासा करता हूं (crossdomain.xml में डोमेन = "*" से डोमेन-अनुरोध-शीर्षलेखों को अनुमति देता है) एंटीफोर्गेरीटोकेंस के उद्देश्य को हरा देता है, और साइट सीएसआरएफ को कमजोर बनाता है? – PanJanek

+0

हां। अच्छा बिंदु यदि आप अपने सर्वर पर crossdomain.xml नीति फ़ाइल प्रकाशित करते हैं तो आप रिमोट फ्लैश मूवी में एक्शनस्क्रिप्ट के माध्यम से किए गए सीएसआरएफ हमलों के लिए स्वयं को फिर से खोल सकते हैं। यदि आप इस फ़ाइल को प्रकाशित करते हैं तो केवल श्वेतसूची पर भरोसेमंद तृतीय पक्षों और कभी नहीं *। मैं इसे उत्तर में – Cheekysoft

+1

"जोड़ सकता हूं" एक साइट कैनोट किसी अन्य साइट पर AJAX शैली http अनुरोध करता है; केवल अपने आप के लिए " Google Analytics कैसे काम करता है? मुझे लगता है कि समान-उत्पत्ति-नीति को किसी अन्य साइट की कुकीज़ को पढ़ने/संशोधित करने में असमर्थता के साथ करना है। –

3

लेकिन क्या होगा अगर दुर्भावनापूर्ण स्क्रिप्ट आदेश छिपी हुई इनपुट फ़ील्ड में antiforgery टोकन युक्त पेज डाउनलोड करने के लिए में पहली कुछ सरल GET अनुरोध (AJAX) के द्वारा कर देगा, यह अर्क , और वैध पोस्ट करने के लिए इसका इस्तेमाल करें?

हाँ, यह सच है, लेकिन, यदि यह ब्राउज़र में समाप्त नहीं हो रहा है तो यह एक सीएसआरएफ हमला नहीं है।

यदि यह ब्राउज़र को समाप्त करता है (उदाहरण के लिए सर्वर साइड कोड में HTTP अनुरोध के माध्यम से स्क्रैपिंग) तो स्क्रैप कोड को सीएसआरएफ टोकन प्राप्त होगा। हालांकि आपके वैध, प्रमाणित उपयोगकर्ताओं को उनकी मशीन पर एक अलग टोकन दिया जाएगा। चूंकि टोकन कि स्क्रैपर लिफ्ट आपके उपयोगकर्ताओं को जारी किए गए एक से अलग है तो POST विफल हो जाएगा।

यदि आप गैर-ब्राउज़र स्क्रिप्ट पोस्ट करना बंद करना चाहते हैं तो आपको इसे मानव मानने के लिए एक और दृष्टिकोण लेने की आवश्यकता है।

+0

AJAX के साथ GET अनुरोध करके, मेरा मतलब था कि जीईटी को किसी पृष्ठ पर एम्बेड किए गए दुर्भावनापूर्ण स्क्रिप्ट द्वारा निष्पादित किया जाता है जिसे किसी ऐसे ब्राउज़र द्वारा खोले जाने वाले उपयोगकर्ता द्वारा खोला जाता है, जिसे किसी ऐसे पृष्ठ को खोलने के लिए धोखा दिया गया था। इस प्रकार स्क्रिप्ट उपयोगकर्ता के संदर्भ में निष्पादित होगी। तो यह अभी भी सीएसआरएफ है, मुझे लगता है। – PanJanek

+0

आह मैं देखता हूं। वैसे तो यह वही मूल नीति के कारण काम नहीं करेगा, जब तक कि वे कुछ ट्रिक्स नहीं कर रहे हैं, इस मामले में कुकी किसी भी तरह से बहती नहीं है, इसलिए टोकन अलग होगा – blowdart

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