Burp Suite से IDOR Vulnerability की पहचान कैसे करें: एक प्रैक्टिकल Penetration Testing केस स्टडी

साइबर सिक्योरिटी और एथिकल हैकिंग की दुनिया में, वेब एप्लीकेशन पर होने वाले हमलों को रोकना सबसे बड़ी प्राथमिकताओं में से एक है। अक्सर डेवलपर्स ऑथेंटिकेशन (Authentication) यानी लॉगिन सिस्टम को तो मजबूत बना देते हैं, लेकिन ऑथराइजेशन (Authorization) यानी यह जांचना कि किस यूजर को क्या देखने की अनुमति है, इस पर ध्यान देना भूल जाते हैं। इसी लापरवाही के कारण जन्म लेती है एक बेहद खतरनाक कमजोरी, जिसे IDOR (Insecure Direct Object Reference) कहा जाता है।

OWASP (Open Web Application Security Project) की टॉप 10 लिस्ट में यह कमजोरी 'Broken Access Control' के अंतर्गत आती है। इस केस स्टडी में, हम एक काल्पनिक लेकिन बेहद व्यावहारिक उदाहरण (Simulated Lab Environment) के जरिए सीखेंगे कि कैसे एक सिक्योरिटी रिसर्चर या एथिकल हैकर Burp Suite टूल का उपयोग करके इस बग को ढूंढता है और इसे कैसे ठीक किया जाता है।

केस स्टडी का परिदृश्य: 'EduSecure' छात्र पोर्टल

मान लीजिए कि एक कॉलेज का वेब पोर्टल है जिसका नाम 'EduSecure' है। इस पोर्टल पर छात्र अपने मार्क्स, पर्सनल प्रोफाइल और फीस की रसीदें देख सकते हैं।

• यूजर A (रोहन): रोहन का स्टूडेंट आईडी 1005 है।
• यूजर B (अमित): अमित का स्टूडेंट आईडी 1006 है।

हमारा उद्देश्य यह जांचना है कि क्या रोहन (यूजर A) अपने अकाउंट में लॉगिन रहते हुए अमित (यूजर B) की निजी जानकारी देख सकता है। यदि ऐसा संभव है, तो इस वेब एप्लीकेशन में IDOR की गंभीर कमजोरी मौजूद है।

स्टेप-बाय-स्टेप प्रैक्टिकल गाइड: IDOR की पहचान कैसे करें

इस टेस्टिंग को सुरक्षित और कानूनी दायरे में करने के लिए हम अपने लोकल कंप्यूटर पर सेट की गई एक लैब और Burp Suite Community Edition का उपयोग करेंगे।

स्टेप 1: टेस्टिंग लैब सेटअप और प्रॉक्सी कॉन्फ़िगरेशन

सबसे पहले, हम अपने ब्राउज़र के वेब ट्रैफिक को मॉनिटर करने के लिए Burp Suite को कॉन्फ़िगर करते हैं:

• Burp Suite को ओपन करें और Temporary Project शुरू करें।
• 'Proxy' टैब में जाकर 'Intercept' को 'ON' करें।
• Burp Suite के इन-बिल्ट क्रोमियम ब्राउज़र को ओपन करें और उसमें 'EduSecure' के डमी यूआरएल (जैसे http://localhost/edusecure) पर जाएं।

स्टेप 2: लॉगिन और HTTP Request का विश्लेषण

अब हम यूजर A (रोहन) के क्रेडेंशियल्स के साथ लॉगिन करते हैं। लॉगिन सफल होने के बाद, हम 'View Profile' बटन पर क्लिक करते हैं।

जैसे ही हम इस बटन पर क्लिक करते हैं, Burp Suite इस रिक्वेस्ट को बीच में ही रोक लेता है (Intercept कर लेता है)। स्क्रीन पर हमें कुछ इस तरह की HTTP Request दिखाई देती है:

GET /api/v1/view_profile?student_id=1005 HTTP/1.1
Host: localhost
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Cookie: session_id=abc123xyz
Connection: close

विश्लेषण: इस रिक्वेस्ट को ध्यान से देखने पर पता चलता है कि सर्वर यूजर की पहचान के लिए पैरामीटर student_id=1005 का उपयोग कर रहा है।

स्टेप 3: पैरामीटर टैंपरिंग (Parameter Tampering)

यह जांचने के लिए कि क्या वेब एप्लीकेशन केवल आईडी नंबर के आधार पर डेटा दिखा रही है या वह यह भी चेक कर रही है कि यह आईडी लॉगिन किए गए यूजर की ही है, हम रिक्वेस्ट में बदलाव करेंगे:

• Burp Suite में इस रिक्वेस्ट पर राइट-क्लिक करें और इसे 'Repeater' मॉड्यूल में भेजें (शॉर्टकट: Ctrl + R)।
• Repeater टैब में जाएं।
• यहाँ हम student_id=1005 को बदलकर student_id=1006 (अमित की आईडी) कर देते हैं।
• ध्यान दें कि हमने ऑथराइजेशन टोकन (JWT Token) या कुकीज़ में कोई बदलाव नहीं किया है, वे अभी भी रोहन की ही हैं।

स्टेप 4: रिस्पॉन्स का विश्लेषण और बग की पुष्टि

जैसे ही हम 'Send' बटन पर क्लिक करते हैं, हमें दाईं ओर सर्वर का रिस्पॉन्स (Response) दिखाई देता है:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "status": "success",
  "student_id": "1006",
  "name": "Amit Kumar",
  "gpa": "9.2",
  "email": "amit@example.com"
}

परिणाम: सर्वर ने बिना किसी संकोच के रोहन के सेशन टोकन पर अमित का पर्सनल डेटा (नाम, ईमेल और जीपीए) दिखा दिया। यह साबित करता है कि इस पोर्टल पर एक गंभीर IDOR Vulnerability मौजूद है।

इस सिक्योरिटी लूपहोल को कोड लेवल पर कैसे ठीक करें?

सिर्फ कमियों को ढूंढना ही काफी नहीं है, उन्हें ठीक करना एथिकल हैकिंग का सबसे जरूरी हिस्सा है। डेवलपर्स इस गलती को कोड लेवल पर कैसे सुधार सकते हैं, आइए समझते हैं।

गलत कोडिंग का उदाहरण (जिसकी वजह से बग आया):

अक्सर डेवलपर्स डेटाबेस से सीधे डेटा खींचने के लिए यूजर द्वारा भेजी गई आईडी पर भरोसा कर लेते हैं:

# असुरक्षित कोड (Python/Flask Example)
@app.route('/api/v1/view_profile')
def view_profile():
    student_id = request.args.get('student_id')
    # यहाँ कोई चेक नहीं है कि क्या लॉगिन यूजर ही इस आईडी का मालिक है
    user_data = db.query("SELECT * FROM students WHERE id = ?", student_id)
    return jsonify(user_data)

सुरक्षित कोडिंग का उदाहरण (समाधान):

डेवलपर्स को हमेशा सर्वर-साइड सेशन डेटा से लॉगिन यूजर की पहचान की पुष्टि करनी चाहिए, न कि क्लाइंट द्वारा भेजे गए पैरामीटर पर आँख मूंदकर भरोसा करना चाहिए:

# सुरक्षित कोड
@app.route('/api/v1/view_profile')
@token_required # ऑथेंटिकेशन चेक
def view_profile(current_user):
    student_id = request.args.get('student_id')
    
    # ऑथराइजेशन चेक: क्या करंट यूजर ही इस आईडी का हकदार है?
    if current_user.id != int(student_id):
        return jsonify({"error": "Unauthorized Access"}), 403
        
    user_data = db.query("SELECT * FROM students WHERE id = ?", student_id)
    return jsonify(user_data)

निष्कर्ष: हमेशा 'Zero Trust' नीति अपनाएं

IDOR जैसी कमजोरियां यह सिखाती हैं कि वेब डेवलपमेंट में सुरक्षा को कभी भी हल्के में नहीं लिया जाना चाहिए। 'Zero Trust' मॉडल का पालन करते हुए, सर्वर को हमेशा हर उस रिक्वेस्ट को संदेह की नजर से देखना चाहिए जो किसी डेटाबेस ऑब्जेक्ट को सीधे एक्सेस करने की कोशिश करती है। चाहे आप एक डेवलपर हों या साइबर सिक्योरिटी रिसर्चर, हमेशा हर यूजर इनपुट को वैलिडेट और ऑथराइज करना सुरक्षित डिजिटल भविष्य की पहली सीढ़ी है।

FAQ: अक्सर पूछे जाने वाले सवाल

1. क्या IDOR और SQL Injection एक ही हैं?

नहीं, ये दोनों अलग-अलग हैं। SQL Injection में हमलावर डेटाबेस को नुकसान पहुंचाने या अनधिकृत डेटा निकालने के लिए दुर्भावनापूर्ण SQL क्वेरी इनपुट करता है। वहीं, IDOR में हमलावर केवल वैध इनपुट पैरामीटर्स (जैसे आईडी नंबर) को बदलकर दूसरों का डेटा एक्सेस करता है, जिसमें किसी कोड इंजेक्शन की जरूरत नहीं होती।

2. क्या बिना किसी टूल के भी IDOR की टेस्टिंग की जा सकती है?

हाँ, कई मामलों में आप ब्राउज़र के एड्रेस बार में दिखने वाले URL पैरामीटर्स (जैसे ?id=1005) को सीधे बदलकर भी IDOR टेस्ट कर सकते हैं। लेकिन एपीआई (API) और हिडन पैरामीटर्स के लिए Burp Suite जैसे टूल्स का उपयोग करना अधिक प्रभावी होता है।

3. IDOR हमलों से बचने का सबसे आसान तरीका क्या है?

सबसे आसान और सुरक्षित तरीका यह है कि संवेदनशील डेटा दिखाने के लिए डायरेक्ट डेटाबेस आईडी (जैसे 1, 2, 3) का उपयोग करने के बजाय रैंडम और प्रिडिक्ट न किए जा सकने वाले आइडेंटिफायर्स जैसे UUID (Universally Unique Identifier) का उपयोग करें और सर्वर पर कड़ा ऑथराइजेशन चेक लागू करें।