एंटी-सीएसआरएफ टोकन और जावास्क्रिप्ट

Question

मैं सीएसआरएफ से एक एप्लिकेशन (PHP और जेएस के बहुत सारे) की रक्षा करने की कोशिश कर रहा हूं।

मैं टोकन का उपयोग करना चाहता हूं।

AJAX के साथ बहुत से ऑपरेशन किए जाते हैं, इसलिए मुझे जावास्क्रिप्ट में टोकन पास करना होगा। यदि मैं प्रति सत्र 1 टोकन जेनरेट करना चाहता हूं या प्रति पृष्ठ लोड करना चाहता हूं तो यह आसान है - मैं नया टोकन जेनरेट करता हूं, इसे कहीं डीओएम में डालता हूं और फिर इसे जावास्क्रिप्ट से ढूंढता हूं और प्रसंस्करण पक्ष को भेजता हूं।

लेकिन अगर मैं हर ऑपरेशन के लिए नया टोकन उपयोग करना चाहता हूं तो क्या होगा? मैं टोकन को पुन: उत्पन्न करने के लिए अजाक्स कॉल करने के बारे में सोच रहा था और फिर परिणाम को प्रसंस्करण पृष्ठ पर पास कर रहा था।

क्या इससे सुरक्षा जोखिम बढ़ता है? मैं उपयोगकर्ता को स्क्रिप्ट के साथ पेज पर लुभाने के बारे में सोच रहा था जो टोकन के लिए पूछेगा और उसके बाद अनुरोध करने के लिए इसका उपयोग करेगा लेकिन फिर डोमेन को पार कर जाएगा जावास्क्रिप्ट को प्रतिबंधित किया गया है। क्या यह फ़्लैश के साथ किया जा सकता है?

शायद सीएसआरएफ से AJAX कॉल की सुरक्षा के लिए एक और तरीका?

धन्यवाद!

Answer 1

कई तकनीकें हैं, जो एक साथ उपयोग की जाने पर पर्याप्त सीएसआरएफ सुरक्षा प्रदान करती हैं।

अद्वितीय टोकन

एक एकल, सत्र-विशिष्ट टोकन सबसे अनुप्रयोगों के लिए काफी अच्छा है। बस सुनिश्चित करें कि आपकी साइट में कोई एक्सएसएस भेद्यता नहीं है, अन्यथा आपके द्वारा नियोजित किसी भी प्रकार की टोकन तकनीक बर्बाद है।

टोकन को पुन: उत्पन्न करने के लिए AJAX कॉल एक बुरा विचार है। गार्ड की रक्षा कौन करेगा? अगर एजेक्स कॉल स्वयं सीएसआरएफ के लिए कमजोर है, तो इस तरह के उद्देश्य को हराया जाता है। AJAX के साथ एकाधिक टोकन सामान्य बुरे विचार में हैं। यह आपको अपने अनुरोधों को क्रमबद्ध करने के लिए मजबूर करता है यानी एक समय में केवल एक AJAX अनुरोध की अनुमति है। यदि आप उस सीमा के साथ रहने के इच्छुक हैं, तो आप पहले अनुरोध के जवाब में दूसरे AJAX कॉल के लिए शायद पिगबैक टोकन कर सकते हैं।

व्यक्तिगत रूप से, मुझे लगता है कि महत्वपूर्ण लेनदेन के लिए उपयोगकर्ता को फिर से प्रमाणीकृत करना बेहतर है, और सत्र-विशिष्ट टोकन के साथ शेष लेन-देन की रक्षा करना बेहतर है।

कस्टम HTTP शीर्षक

आप अपने अनुरोध से प्रत्येक के लिए एक कस्टम HTTP शीर्षक जोड़ सकते हैं, और सर्वर साइड पर अपनी उपस्थिति की जाँच करें। वास्तविक कुंजी/मान को गुप्त होने की आवश्यकता नहीं है, सर्वर को यह सुनिश्चित करने की आवश्यकता है कि यह आने वाले अनुरोध में मौजूद है।

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

जांच की जा रही संदर्भ

संदर्भ शीर्ष के लिए जांच की जा रही भी नए ब्राउज़रों में CSRF की रक्षा के लिए अच्छा है। इस हेडर को धोखा देना संभव नहीं है, हालांकि फ्लैश के पुराने संस्करणों में यह संभव था। इसलिए, जबकि यह मूर्खतापूर्ण नहीं है, यह अभी भी कुछ सुरक्षा जोड़ता है।

कैप्चा

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

सारांश

1. एक सत्र आधारित टोकन का प्रयोग करें, लेकिन उच्च मूल्य लेनदेन
2. के लिए पुन: प्रमाणीकृत एक कस्टम HTTP शीर्षक जोड़ें, और भी रेफरर लिए जाँच करें। दोनों अपने आप से मूर्ख नहीं हैं, लेकिन