preventing CSRF के बारे में काफी कुछ लिखा गया है।सीएसआरएफ सुरक्षा
लेकिन मुझे बस यह नहीं मिला: मैं लक्ष्य पृष्ठ फ़ॉर्म में सीएसआरएफ टोकन का विश्लेषण क्यों नहीं कर सकता और इसे अपने फोर्ज अनुरोध के साथ सबमिट नहीं कर सकता?
क्योंकि सीएसआरएफ टोकन का मूल्य पहले से ज्ञात नहीं है।
यदि आप लक्ष्य पृष्ठ (एक्सएसएस) में स्क्रिप्ट कोड इंजेक्ट करने में सक्षम हैं तो हाँ, आप ऐसा कर सकते हैं जिससे सीएसआरएफ रोकथाम बेकार हो।
सीएसआरएफ टोकन को अंतिम पृष्ठ प्राप्त करने वाले पृष्ठ में संग्रहीत किया जाना चाहिए (या वह इसे भी नहीं जानता)।
असल में, सुरक्षा आकलन में, एक्सएसएस ने आमतौर पर अपने नुकसान की संभावना के लिए मूल्यांकन नहीं किया बल्कि इस तरह के हमलों में इसका उपयोग करने के लिए मूल्यांकन किया।
प्रत्येक उपयोगकर्ता के लिए सीएसआरएफ टोकन हर बार और प्रत्येक अनुरोध के लिए एक पूरी तरह से अलग टोकन होना चाहिए, इसलिए इसे किसी हमलावर से कभी अनुमानित नहीं किया जा सकता है।
PHP, .net और जावास्क्रिप्ट के लिए OWASP CSRFGuard Project में एक नज़र डालें - यदि आप जावा और जेएसएफ 2.x के साथ काम कर रहे हैं तो यह पहले ही सीएसआरएफ के खिलाफ सहेज रहा है (जब तक आप पोस्ट का उपयोग करते हैं और प्राप्त नहीं करते - इसके लिए आपके पास होगा जेएसएफ 2.2 के लिए प्रतीक्षा करने के लिए) अन्यथा यदि आप जेएसएफ के बिना काम करते हैं तो ओडब्ल्यूएएसपी ईएसएपीआई से HTTPUtillities Interface भी बहुत उपयोगी हो सकता है!
सीएसआरएफ हमले अंधे हैं। वे सत्र सवारी करते हैं और हमलावर का कोई प्रत्यक्ष नियंत्रण नहीं होता है जब तक कि वह एक एक्सएसएस भेद्यता के माध्यम से टोकन निकालने नहीं कर सकता। आम तौर पर एक सत्र चौड़ा टोकन का उपयोग किया जा सकता है। प्रति अनुरोध घूर्णन टोकन एक ओवरकिल हो सकता है और झूठे अलार्म का कारण बन सकता है। मैं मास्टर सत्र टोकन के साथ प्रति संसाधन टोकन का उपयोग करना पसंद करता हूं।