वेब सुरक्षा के बुनियादी तत्व: SSRF, CSRF और CORS की व्याख्या

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

आज, हम तीन महत्वपूर्ण अवधारणाओं में गहराई से उतर रहे हैं जिन्हें हर वेब डेवलपर को मास्टर करना चाहिए: SSRF, CSRF, और CORS। हालांकि ये सुनने में वर्णमाला के सूप की तरह लग सकते हैं, वे वेब एप्लिकेशन सुरक्षा की अग्रिम पंक्तियों का प्रतिनिधित्व करते हैं।

1. SSRF (सर्वर-साइड रिक्वेस्ट फोर्जरी)

SSRF एक भेद्यता (vulnerability) है जहां एक हमलावर सर्वर-साइड एप्लिकेशन को हमलावर की पसंद के किसी भी डोमेन पर HTTP अनुरोध करने के लिए मजबूर कर सकता है।

यह कैसे काम करता है

एक वेब एप्लिकेशन की कल्पना करें जो इनपुट के रूप में एक URL लेता है (उदाहरण के लिए, प्रोफ़ाइल चित्र लाने या लिंक का पूर्वावलोकन करने के लिए) और फिर सर्वर से उस URL पर अनुरोध करता है। यदि एप्लिकेशन इस URL को ठीक से मान्य (validate) नहीं करता है, तो एक हमलावर आंतरिक IP पता या लूपबैक पता (127.0.0.1) प्रदान कर सकता है।

सर्वर, एक प्रॉक्सी के रूप में कार्य करते हुए, आंतरिक सेवाओं से संवेदनशील डेटा प्राप्त कर सकता है जो सार्वजनिक इंटरनेट पर उजागर नहीं होते हैं, जैसे:

• क्लाउड मेटाडेटा: IAM क्रेडेंशियल प्राप्त करने के लिए AWS/GCP पर 169.254.169.254 तक पहुँचना।
• आंतरिक एडमिन पैनल: जेनकिंस या कुबेरनेट्स डैशबोर्ड जैसे आंतरिक उपकरणों तक पहुँचना।
• पोर्ट स्कैनिंग: आंतरिक नेटवर्क पर चल रही अन्य सेवाओं की खोज करना।

रोकथाम

• अनुमति सूची (Allowlisting): केवल विश्वसनीय डोमेन की पूर्व-निर्धारित सूची के अनुरोधों की अनुमति दें।
• इनपुट सत्यापन: सुनिश्चित करें कि URL अनुमत प्रोटोकॉल (जैसे केवल https://) का उपयोग करता है और आंतरिक IP श्रेणियों की ओर इशारा नहीं करता है।
• नेटवर्क पृथक्करण (Segregation): सुनिश्चित करें कि वेब सर्वर की आंतरिक संसाधनों तक सीमित पहुंच है।

2. CSRF (क्रॉस-साइट रिक्वेस्ट फोर्जरी)

CSRF एक हमला है जो किसी पीड़ित के ब्राउज़र को किसी अन्य वेबसाइट पर अवांछित कार्रवाई करने के लिए प्रेरित करता है जहां पीड़ित वर्तमान में प्रमाणित (authenticated) है।

यह कैसे काम करता है

यह हमला इस तथ्य का फायदा उठाता है कि ब्राउज़र स्वचालित रूप से किसी डोमेन के प्रत्येक अनुरोध के साथ परिवेशी क्रेडेंशियल—जैसे सत्र कुकीज़ (session cookies)—शामिल करते हैं।

1. एक उपयोगकर्ता bank.com में लॉग इन करता है।
2. उपयोगकर्ता दूसरे टैब में एक दुर्भावनापूर्ण साइट evil.com पर जाता है।
3. evil.com में एक छिपा हुआ फॉर्म होता है जो bank.com/transfer?amount=1000&to=attacker पर एक POST अनुरोध सबमिट करता है।
4. ब्राउज़र उपयोगकर्ता की bank.com सत्र कुकी के साथ अनुरोध भेजता है।
5. bank.com एक वैध सत्र देखता है और स्थानांतरण की प्रक्रिया करता है।

रोकथाम

• एंटी-CSRF टोकन: प्रत्येक स्थिति-परिवर्तनकारी (state-changing) अनुरोध में एक अद्वितीय, गुप्त और अप्रत्याशित टोकन शामिल करें। सर्वर प्रसंस्करण से पहले इस टोकन की पुष्टि करता है।
• SameSite कुकीज़: कुकीज़ पर SameSite विशेषता को Strict या Lax पर सेट करें ताकि उन्हें क्रॉस-साइट अनुरोधों पर भेजे जाने से रोका जा सके।
• कस्टम हेडर: AJAX अनुरोधों के लिए, एक कस्टम हेडर (जैसे X-Requested-With) की आवश्यकता होती है जिसे मानक HTML फॉर्म द्वारा सेट नहीं किया जा सकता है।

3. CORS (क्रॉस-ओरिजिन रिसोर्स शेयरिंग)

SSRF और CSRF के विपरीत, CORS अपने आप में कोई भेद्यता नहीं है, बल्कि एक सुरक्षा तंत्र है। यह सर्वरों के लिए ब्राउज़र को यह बताने का एक तरीका है: “इस विशिष्ट बाहरी ओरिजिन के लिए मेरे संसाधनों तक पहुँचना ठीक है।”

यह क्यों मौजूद है

डिफ़ॉल्ट रूप से, ब्राउज़र समान-ओरिजिन नीति (SOP) लागू करते हैं, जो एक साइट पर स्क्रिप्ट को दूसरी साइट से डेटा पढ़ने से रोकता है। यह evil.com को आपके gmail.com पर ईमेल पढ़ने से रोकता है।

CORS सर्वरों को इस नीति को सुरक्षित रूप से ढीला करने की अनुमति देता है। जब एक वेब ऐप क्रॉस-ओरिजिन अनुरोध करता है, तो ब्राउज़र एक Origin हेडर भेजता है। सर्वर Access-Control-Allow-Origin के साथ प्रतिक्रिया करता है।

सामान्य गलत विन्यास (Misconfigurations)

• वाइल्डकार्ड ओरिजिन (*): सभी ओरिजिन की अनुमति देना। हालांकि सार्वजनिक API के लिए ठीक है, लेकिन अगर Access-Control-Allow-Credentials: true के साथ जोड़ा जाए तो यह खतरनाक है।
• ओरिजिन को प्रतिबिंबित करना: सत्यापन के बिना Origin हेडर के आधार पर गतिशील रूप से अनुमत ओरिजिन सेट करना। यह प्रभावी रूप से SOP को पूरी तरह से बायपास कर देता है।

सर्वोत्तम अभ्यास

• विशिष्ट बनें: केवल उन विशिष्ट डोमेन की अनुमति दें जिन्हें पहुंच की आवश्यकता है।
• यदि संभव हो तो क्रेडेंशियल से बचें: यदि आपके API को कुकीज़ या प्राधिकरण हेडर की आवश्यकता नहीं है, तो उन्हें अनुमति न दें।
• सुरक्षा मिडलवेयर का उपयोग करें: हेडर को मैन्युअल रूप से प्रबंधित करने के बजाय CORS कॉन्फ़िगरेशन को संभालने के लिए अच्छी तरह से परीक्षण की गई लाइब्रेरी का उपयोग करें।

सारांश तुलना

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

सुरक्षित रहें, और हैप्पी कोडिंग!