CSRF क्या है? हम CSRF को कैसे रोक सकते हैं?

डिजिटल युग में, इंटरनेट हमारे दैनिक जीवन के ताने-बाने में बुना हुआ है। हमने कई गतिविधियों को ऑनलाइन स्थानांतरित कर दिया है, जैसे कि खरीदारी से लेकर विभिन्न प्लेटफॉर्म पर सोशलाइजिंग और बैंकिंग लेनदेन करना। जैसे-जैसे वित्तीय लेनदेन अधिक व्यापक होते जा रहे हैं, नेटवर्क सुरक्षा के प्रभाव भी अधिक स्पष्ट होते जा रहे हैं। इंटरनेट पर सबसे आम साइबर खतरों में से एक CSRF (क्रॉस-साइट रिक्वेस्ट फोर्जरी) है, और इसके बारीकियों को समझना आवश्यक है।

CSRF क्या है?

CSRF हमले लक्षित वेबसाइट के अनुरोध सत्यापन तंत्र में कमजोरियों का फायदा उठाते हैं। कुछ स्थितियों में, उपयोगकर्ता लक्षित वेबसाइट पर लॉग इन होने के दौरान अनजाने में दुर्भावनापूर्ण अनुरोध निष्पादित करते हैं। हमलावर आमतौर पर लक्षित वेबसाइट के डोमेन से मिलते-जुलते पते का उपयोग करते हैं, जिससे उपयोगकर्ताओं को क्लिक करने के लिए प्रलोभित किया जाता है। वे छवि लोड या छिपे हुए फॉर्म के रूप में दुर्भावनापूर्ण कोड को छिपाकर, लक्षित वेबसाइट को अनुरोध भेजते हैं और गुप्त अनधिकृत कार्यों को निष्पादित करते हैं। उद्देश्य जैसे कि उपयोगकर्ता पासवर्ड बदलना या अनधिकृत बैंक ट्रांसफर शुरू करना, उपयोगकर्ताओं के लिए महत्वपूर्ण नुकसान का कारण बन सकते हैं।

वास्तविक जीवन का उदाहरण

कल्पना कीजिए कि एक वेबसाइट e-bank.com है जो इलेक्ट्रॉनिक बैंकिंग सेवाएं प्रदान करती है, जिसमें ट्रांसफर अनुरोध जमा करने के लिए /transfer नामक एक पेज है। जब उपयोगकर्ता e-bank.com/transfer पेज पर पहुंचते हैं, तो उन्हें उपयोगकर्ता द्वारा दर्ज किए गए विवरणों को प्रदर्शित करने वाला एक फॉर्म दिखाई देता है। फॉर्म पूरा करने और सबमिट करने पर, HTTP POST अनुरोध पेज के पते पर भेजा जाता है, जिसमें उपयोगकर्ता द्वारा दर्ज किए गए प्राप्तकर्ता और राशि जैसे पैरामीटर होते हैं।

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

यदि उपयोगकर्ता e-bank.com पर पंजीकृत या लॉग इन नहीं है, तो ट्रांसफर अनुरोध निष्पादित नहीं किया जा सकता है। हालांकि, यदि उपयोगकर्ता ने हाल ही में सेवा का उपयोग किया है और लॉगिन स्थिति बनी हुई है, तो ट्रांसफर अनुरोध सफलतापूर्वक निष्पादित हो सकता है।

यह CSRF हमलों को समझाता है—सिद्धांत में सरल लेकिन भारी संभावित नुकसान के साथ। सौभाग्य से, ऐसे हमलों को रोकने के लिए कई परिपक्व तरीके हैं। आइए उन्हें नीचे देखें।

हम CSRF को कैसे रोक सकते हैं?

इस समस्या का समाधान सक्रिय और निष्क्रिय उपायों से किया जा सकता है।

HTTP मेथड प्रतिबंध और Referer प्रतिबंध

डेवलपर्स के रूप में, हम सेवा के भीतर संवेदनशील पतों पर सख्त प्रतिबंध लगा सकते हैं, जैसे:

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

• इसके अलावा, हम HTTP अनुरोध हेडर में Referer फ़ील्ड (Referer) पर प्रतिबंध लगा सकते हैं, केवल ज्ञात वैध पतों से अनुमति देते हैं और दुर्भावनापूर्ण अनुरोधों को ब्लॉक करते हैं।

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

CSRF टोकन

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

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

यह एक सक्रिय सुरक्षात्मक उपाय है, जिसमें कुछ प्रयास की आवश्यकता होती है लेकिन मजबूत सुरक्षा प्रदान करता है।

क्रॉस-ओरिजिन सुरक्षा

हम अक्सर CORS (क्रॉस-ओरिजिन रिसोर्स शेयरिंग) नामक एक तकनीक का सामना करते हैं, जो एक विनिर्देश है जो बताता है कि ब्राउज़र क्रॉस-ओरिजिन अनुरोधों की अनुमति देता है या नहीं। आधुनिक ब्राउज़र इस विनिर्देश का समर्थन करते हैं। जब किसी मौजूदा पेज पर Fetch/XHR अनुरोध शुरू किया जाता है, तो ब्राउज़र HTTP OPTIONS अनुरोध भेजता है ताकि यह जांच सके कि लक्षित सेवा वर्तमान स्रोत पते से अनुरोधों की अनुमति देती है या नहीं। सर्वर एक प्रतिक्रिया-हेडर्स सूची प्रदान करेगा, जो अनुमत स्रोतों, अनुरोध विधियों और हेडर्स को निर्दिष्ट करता है। ब्राउज़र इन संकेतों का पालन करता है, जिससे क्लाइंट साइड पर निषिद्ध अनुरोधों को रोका जाता है।

यह एक और सक्रिय सुरक्षात्मक उपाय है, जिसे सर्वर साइड पर कॉन्फ़िगर किया जा सकता है, लेकिन ध्यान दें कि हालांकि सामान्य उपयोगकर्ताओं के लिए इस सुविधा को अक्षम करना संभावना नहीं है, यह क्लाइंट साइड पर संभव है।

तृतीय-पक्ष कुकीज़ को ब्लॉक करना

हमारे द्वारा विकसित सेवाएं कभी-कभी उपयोगकर्ता सत्र ID को कुकीज़ में संग्रहीत करती हैं ताकि लॉगिन स्थिति बनाए रखा जा सके। कुकीज़ SameSite सेटिंग्स का समर्थन करती हैं, जो ब्राउज़र को क्रॉस-ओरिजिन साइट्स पर कुकीज़ भेजने से रोकती हैं। CSRF हमलों का प्रयास करने पर लक्षित साइट पर प्रमाणीकरण स्थिति नहीं होती है।

इसके अलावा, HTTP कुकी तंत्र के दुरुपयोग के कारण, ब्राउज़र डेवलपर्स ने तृतीय-पक्ष कुकीज़ (कुकी काउंटडाउन) को धीरे-धीरे प्रतिबंधित और ब्लॉक करने का निर्णय लिया है। जब डोमेन A पर एक पेज डोमेन B को कॉल करने का प्रयास करता है, तो भले ही यह CORS नियम जांच पास कर ले, ब्राउज़र उस क्रॉस-ओरिजिन साइट पर कुकीज़ नहीं भेजेगा।

सारांश

API गेटवे के रूप में, Apache APISIX और API7 Enterprise दोनों CSRF टोकन और CORS—पहले उल्लेखित दो सुरक्षात्मक उपायों—का समर्थन करते हैं ताकि CSRF हमलों को रोका जा सके।

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