Burp Suite से API Security Audit: E-Commerce App में IDOR Vulnerability ढूंढने और फिक्स करने की केस स्टडी

भूमिका: API सुरक्षा और IDOR की गंभीरता

आधुनिक वेब और मोबाइल एप्लिकेशन्स मुख्य रूप से REST APIs पर निर्भर करते हैं। जब आप किसी ऐप में अपनी प्रोफ़ाइल देखते हैं, तो बैकएंड सर्वर से डेटा प्राप्त करने के लिए बैकग्राउंड में API रिक्वेस्ट भेजी जाती है। यदि इन API की सुरक्षा सही ढंग से न की जाए, तो वे गंभीर साइबर हमलों का शिकार हो सकती हैं।

OWASP (Open Web Application Security Project) Top 10 की सूची में 'Broken Access Control' को सबसे बड़ा सुरक्षा जोखिम माना गया है। इसी का एक प्रमुख हिस्सा है IDOR (Insecure Direct Object Reference)। इस केस स्टडी में, हम एक काल्पनिक ई-कॉमर्स प्लेटफ़ॉर्म 'ShopEasy' का व्यावहारिक उदाहरण देखेंगे। हम समझेंगे कि कैसे एक साइबर सुरक्षा ऑडिटर ने Burp Suite टूल का उपयोग करके API में छिपी IDOR वल्नरेबिलिटी की पहचान की और डेवलपर्स ने इसे कैसे पैच किया।

परिदृश्य (Scenario Background): ShopEasy API की संरचना

ShopEasy एक उभरता हुआ ई-कॉमर्स प्लेटफ़ॉर्म है। इसका एंड्रॉइड ऐप और वेब पोर्टल Node.js बैकएंड पर काम करता है। जब कोई ग्राहक अपने अकाउंट में लॉगिन करता है, तो सर्वर उसे एक JWT (JSON Web Token) प्रदान करता है।

ग्राहक जब ऐप के 'My Profile' सेक्शन में जाता है, तो ऐप बैकएंड सर्वर को एक HTTP GET रिक्वेस्ट भेजता है:

GET /api/v1/users/profile?user_id=8492

यहां user_id=8492 उस यूज़र का यूनिक डेटाबेस आईडी है। सर्वर इस रिक्वेस्ट को प्रोसेस करता है और यूज़र का नाम, ईमेल, फ़ोन नंबर और डिलीवरी एड्रेस वापस भेजता है।

स्टेप 1: Burp Suite Proxy से नेटवर्क ट्रैफ़िक को इंटरसेप्ट करना

सुरक्षा परीक्षण (Penetration Testing) शुरू करने के लिए, ऑडिटर को ऐप और सर्वर के बीच होने वाले डेटा ट्रांसफर को देखना और रोकना होता है। इसके लिए Burp Suite के HTTP Proxy का उपयोग किया गया।

प्रक्रिया step-by-step:

• प्रॉक्सि सेटअप: ऑडिटर ने अपने टेस्टिंग डिवाइस का नेटवर्क प्रॉक्सी Burp Suite के IP और पोर्ट (127.0.0.1:8080) पर कॉन्फ़िगर किया।
• इंटरसेप्ट ऑन करना: Burp Suite में 'Intercept is ON' फ़ीचर को सक्रिय किया गया।
• अकाउंट में लॉगिन: ऑडिटर ने टेस्ट अकाउंट (User ID: 8492) से ऐप में लॉगिन किया और 'My Profile' पर क्लिक किया।

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

GET /api/v1/users/profile?user_id=8492 HTTP/1.1
Host: api.shopeasy.com
Authorization: Bearer eyJhbGciOi... (JWT Token)
User-Agent: ShopEasyAndroid/2.1

स्टेप 2: Burp Repeater से IDOR वल्नरेबिलिटी का परीक्षण

अब ऑडिटर का लक्ष्य यह जांचना था कि क्या सर्वर केवल JWT टोकन की वैधता देख रहा है, या यह भी जांच रहा है कि टोकन भेजने वाला व्यक्ति वास्तव में user_id=8492 का मालिक है या नहीं।

मैन्युअल मैनिपुलेशन और रिस्पॉन्स एनालिसिस:

1. ऑडिटर ने रिक्वेस्ट पर राइट-क्लिक किया और उसे Burp Repeater टूल में भेजा। Repeater टूल से हम पैरामीटर्स को बार-बार बदलकर सर्वर के रिस्पॉन्स की जांच कर सकते हैं।
2. ऑडिटर ने URL में मौजूद user_id=8492 को बदलकर user_id=8493 (किसी दूसरे ग्राहक की ID) कर दिया।
3. 'Authorization' हेडर में वही पहला वाला JWT टोकन रहने दिया गया और 'Send' बटन पर क्लिक किया गया।

परिणाम (The Flaw Discovered):

सर्वर को इस रिक्वेस्ट को रिजेक्ट करना चाहिए था और 403 Forbidden एरर कोड देना चाहिए था। लेकिन इसके बजाय, सर्वर ने 200 OK रिस्पॉन्स लौटाया!

रिस्पॉन्स की बॉडी में किसी अनजान ग्राहक (User 8493) का पूरा पर्सनल डेटा (नाम, प्राइवेट ईमेल आईडी, घर का पता और प्राइमरी फ़ोन नंबर) स्पष्ट रूप से दिख रहा था। यह एक क्लासिक IDOR (Insecure Direct Object Reference) Vulnerability का उदाहरण था।

स्टेप 3: रूट कॉज़ एनालिसिस और व्यावसायिक जोखिम (Business Impact)

इस सुरक्षा चूक का विश्लेषण करने पर दो मुख्य बातें सामने आईं:

1. रूट कॉज़ (Root Cause)

डेवलपर्स ने ऑथेंटिकेशन (Authentication) तो लागू किया था—यानी केवल वही लोग रिक्वेस्ट भेज सकते थे जिनके पास वैलिड JWT टोकन था। लेकिन उन्होंने **ऑथराइजेशन (Authorization)** लागू नहीं किया था। सर्वर ने कभी यह चेक ही नहीं किया कि रिक्वेस्ट भेजने वाले का टोकन और रिक्वेस्ट में माँगी गई user_id आपस में मेल खाते हैं या नहीं।

2. बिज़नेस इम्पैक्ट (Business Impact)

यदि कोई हैकर इस खामी का फायदा उठाता, तो वह एक साधारण पायथन (Python) स्क्रिप्ट लिखकर user_id=1 से लेकर user_id=1000000 तक ऑटोमेटेड रिक्वेस्ट भेज सकता था। इससे कुछ ही मिनटों में ShopEasy के लाखों ग्राहकों का संवेदनशील डेटा लीक हो सकता था, जिससे कंपनी पर भारी कानूनी जुर्माना लग सकता था और उसकी साख खराब हो सकती थी।

स्टेप 4: वल्नरेबिलिटी को फिक्स (Remediation) करने का व्यावहारिक समाधान

सुरक्षा रिपोर्ट मिलने के बाद, विकास टीम (Development Team) ने इस समस्या को हल करने के लिए दो-स्तरीय सुरक्षा उपाय लागू किए:

1. क्लाइंट-सप्लाई की गई ID पर निर्भरता हटाना

टीम ने API के डिज़ाइन को बदला। अब यूज़र प्रोफ़ाइल फ़ेच करने के लिए URL में `user_id` पैरामीटर भेजने की आवश्यकता खत्म कर दी गई। एंडपॉइंट को बदलकर `GET /api/v1/users/me` कर दिया गया।

2. सर्वर-साइड टोकन वैलीडेशन लागू करना

बैकएंड कोड में परिवर्तन किया गया ताकि सर्वर आने वाली रिक्वेस्ट के JWT टोकन को डिकोड करे और उसमें से सुरक्षात्मक रूप से यूज़र की पहचान (User Identity) निकाले।

सुधारे गए बैकएंड लॉजिक का एक उदाहरण:

// पैच करने से पहले का कोड (सुरक्षित नहीं)
app.get('/api/v1/users/profile', async (req, res) => {
  const userId = req.query.user_id; // क्लाइंट के इनपुट पर सीधा भरोसा किया गया
  const user = await User.findById(userId);
  res.json(user);
});

// पैच करने के बाद का सुरक्षित कोड
app.get('/api/v1/users/me', authenticateToken, async (req, res) => {
  const userId = req.user.id; // सीधे वैलिडेटेड JWT टोकन से ID निकाली गई
  const user = await User.findById(userId);
  res.json(user);
});

इस बदलाव के बाद, यदि कोई यूज़र किसी दूसरे का डेटा एक्सेस करने का प्रयास भी करता है, तो बैकएंड केवल उसी यूज़र का डेटा लौटाएगा जिसका JWT टोकन रिक्वेस्ट में मौजूद है।

डेवलपर्स और पेन-टेस्टर्स के लिए मुख्य सुरक्षा सुझाव

• नेवर ट्रस्ट क्लाइंट इनपुट: क्लाइंट-साइड से आने वाले किसी भी पैरामीटर (जैसे IDs, Role Names, Price) पर बिना सर्वर-साइड वैलिडेशन के भरोसा न करें।
• इनडायरेक्ट ऑब्जेक्ट रेफरेंस का उपयोग करें: डायरेक्ट डेटाबेस ID (जैसे 101, 102) को URL में एक्सपोज़ करने के बजाय GUIDs या हेश्ड रांडोम स्ट्रिंग्स का उपयोग करें।
• सेंट्रलाइज्ड ऑथराइजेशन चेक्स: प्रत्येक सेंसिटिव एंडपॉइंट पर मिडिलवेयर के ज़रिए यह जांचें कि क्या रिक्वेस्ट करने वाले यूज़र के पास उस ऑब्जेक्ट को देखने या बदलने का अधिकार (Privilege) है।
• ऑटोमेटेड और मैन्युअल टेस्टिंग: SAST/DAST टूल्स के अलावा Burp Suite जैसे टूल्स से मैन्युअल बिज़नेस लॉजिक और ऑथराइजेशन टेस्टिंग अवश्य करें।

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

Q1: IDOR वल्नरेबिलिटी क्या होती है?

IDOR (Insecure Direct Object Reference) एक ऐसी सुरक्षा कमी है, जो तब होती है जब कोई एप्लिकेशन क्लाइंट-साइड से दिए गए इनपुट के आधार पर डेटाबेस ऑब्जेक्ट (जैसे फ़ाइल, अकाउंट या रिकॉर्ड) का एक्सेस बिना सही ऑथराइजेशन चेक्स के दे देता है।

Q2: क्या Burp Suite Community (Free) एडिशन से IDOR टेस्ट किया जा सकता है?

हाँ, Burp Suite का फ्री कम्युनिटी एडिशन में HTTP Proxy और Repeater जैसे फीचर्स शामिल होते हैं, जो मैन्युअल रूप से IDOR और API वल्नरेबिलिटी जांचने के लिए पूरी तरह से पर्याप्त हैं।

Q3: क्या IDOR केवल GET रिक्वेस्ट में ही होता है?

नहीं, IDOR POST, PUT, या DELETE जैसी किसी भी HTTP रिक्वेस्ट में हो सकता है। उदाहरण के लिए, DELETE /api/v1/orders/55 जैसी रिक्वेस्ट में ऑर्डर ID बदलकर किसी अन्य का ऑर्डर डिलीट किया जा सकता है।

Q4: एथिकल हैकिंग में API टेस्टिंग शुरू करने के लिए क्या सीखना जरूरी है?

API टेस्टिंग सीखने के लिए आपको HTTP/HTTPS प्रोटोकॉल, HTTP हेडर, स्टेटस कोड, JSON डेटा फॉर्मेट, REST API डिज़ाइन और Burp Suite या Postman जैसे टूल्स का उपयोग आना आवश्यक है।