Broken Object Level Authorization in the Wild: An Empirical Taxonomy from 100+ Bug Bounty Disclosures
यह शोध पत्र 107 वर्गीकृत बग बाउंटी रिपोर्टों का एक बड़े पैमाने पर अनुभवजन्य विश्लेषण प्रस्तुत करता है, जो यह प्रकट करता है कि एक्शन-लेवल ऑब्जेक्ट BOLA एक प्रमुख लेकिन कम प्रतिनिधित्व वाला भेद्यता परिवार है और यह प्रदर्शित करता है कि प्लेटफॉर्म टैग्स पर निर्भरता ब्रोकन ऑब्जेक्ट लेवल ऑथोराइजेशन की व्यापकता को काफी अधिक बढ़ाकर दिखाती है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक विशाल, हाई-टेक अपार्टमेंट कॉम्प्लेक्स में घूम रहे हैं। आपके पास एक की-कार्ड है जो आपको इमारत में प्रवेश करने देता है (प्रमाणीकरण/authentication), लेकिन असली सुरक्षा इस बात की होनी चाहिए कि आप किस विशिष्ट अपार्टमेंट में जाने के लिए अधिकृत हैं।
ब्रोकन ऑब्जेक्ट लेवल ऑथोराइजेशन (BOLA) तब होता है जब बिल्डिंग का सुरक्षा गार्ड यह जांचना भूल जाता है कि आपका की-कार्ड उस विशिष्ट अपार्टमेंट नंबर से मेल खाता है या नहीं जिसे आप खोलने की कोशिश कर रहे हैं। हो सकता है कि आप एक वैध निवासी हों, लेकिन आप अपार्टमेंट 402 खोलने की कोशिश करते हैं, और गार्ड बस कहता है, "ज़रूर, जाइए," बिना यह जांचे कि क्या 402 आपका है।
यह शोध पत्र एक बग बाउंटी प्रोग्राम (जहाँ हैकर्स को कमियां खोजने के लिए पैसे दिए जाते हैं) से 107 वास्तविक जीवन की सुरक्षा रिपोर्टों की एक व्यापक जांच है। शोधकर्ता "सैद्धांतिक" सुरक्षा सलाह से आगे बढ़कर यह देखना चाहते थे कि वास्तविक दुनिया में वास्तव में क्या हो रहा है।
यहाँ उनके निष्कर्षों का विवरण दिया गया है, सरल उपमाओं (analogies) का उपयोग करते हुए:
1. "लेबल नॉइज़" की समस्या (नकली अलार्म)
शोधकर्ताओं ने HackerOne पर "IDOR" (इस प्रकार के बग का एक सामान्य नाम) के रूप में टैग की गई 200 रिपोर्टों को देखा।
- निष्कर्ष: उनमें से केवल 42% ही वास्तव में असली मामले थे।
- उपमा: कल्पना कीजिए कि एक फायर अलार्म सिस्टम 200 बार बजता है। शोधकर्ताओं ने पाया कि 39% बार, कोई आग नहीं लगी थी—बल्कि यह सिर्फ टोस्ट जलने, गर्म शावर या एक खराब सेंसर की वजह से था।
- सीख: सिर्फ इसलिए कि किसी सिस्टम को "IDOR" के रूप में टैग किया गया है, इसका मतलब यह नहीं है कि उसमें वह विशिष्ट, खतरनाक "ब्रोकन ऑब्जेक्ट" भेद्यता (vulnerability) है। सुरक्षा टीमें अक्सर टैग पर बहुत अधिक भरोसा करके जोखिम का अतिरंजित आकलन करती हैं।
2. दो मुख्य विलेन (वर्गीकरण/Taxonomy)
शोधकर्ताओं ने वास्तविक बग्स को छह श्रेणियों में बांटा। इनमें से दो स्पष्ट विजेता थे, जो लगभग 80% मामलों के लिए जिम्मेदार थे:
विलेन A: "डायरेक्ट ऑब्जेक्ट रेफरेंस" (फोनबुक ट्रिक)
- यह क्या है: आप एक URL देखते हैं जैसे
website.com/invoice/101। आप नंबर बदलकर102कर देते हैं, और अचानक आप किसी और का इनवॉइस देख लेते हैं। - उपमा: यह मेलबॉक्स की एक कतार के पास जाने जैसा है। आप जानते हैं कि आपका बॉक्स #101 है। आप #102 आज़माते हैं, और लॉक टूटा हुआ है, इसलिए आप उसे खोलकर अपने पड़ोसी की डाक पढ़ लेते हैं।
- आवृत्ति (Frequency): यह 37% मामलों में हुआ।
- यह क्या है: आप एक URL देखते हैं जैसे
विलेन B: "एक्शन-लेवल ऑब्जेक्ट" (वैंडल/तोड़फोड़ करने वाला)
- यह क्या है: यह एक बड़ा आश्चर्य है। यह केवल किसी दूसरे का डेटा पढ़ना नहीं है; यह उसे बदलना या मिटाना है।
- उपमा: आप अपने पड़ोसी के मेलबॉक्स के पास जाते हैं (जिसे आपको छूने की अनुमति नहीं है), और केवल उनकी डाक पढ़ने के बजाय, आप मेलबॉक्स को दीवार से उखाड़ देते हैं, उनके ईमेल डिलीट कर देते हैं, या उनके पैसे ट्रांसफर कर देते हैं।
- आवृत्ति: यह 42% मामलों में हुआ।
- यह क्यों मायने रखता है: अधिकांश सुरक्षा गाइड केवल डेटा "पढ़ने" पर ध्यान केंद्रित करती हैं। यह पेपर कहता है, "हे, बुरे लोग केवल जासूसी करने से ज़्यादा, डेटा को नष्ट करने और बदलने में वास्तव में अधिक सक्रिय हैं।"
3. अन्य चालाक विलेन्स
शेष 20% बग अधिक जटिल थे:
- टेनेंट आइसोलेशन (Tenant Isolation): आप एक साझा कार्यालय भवन में हैं। आप किसी दूसरी कंपनी के कार्यालय कक्ष का दरवाजा खोलने की कोशिश करते हैं, और लॉक विफल हो जाता है।
- वर्कफ़्लो-कॉन्टेक्स्ट (Workflow-Context): आपको कंपनी से निकाल दिया गया था, लेकिन सिस्टम अभी भी आपको उस प्रोजेक्ट की "आर्काइव्ड" फाइलों तक पहुँचने देता है जिस पर आप काम करते थे, क्योंकि सिस्टम ने आपकी स्थिति (status) को अपडेट करना भूल गया।
- चेन्ड डिस्क्लोजर (Chained Disclosure): आप ID का अनुमान नहीं लगा सकते, लेकिन आप ऐप के दूसरे हिस्से (जैसे रसीद) में IDs की एक सूची पाते हैं और अन्य खातों में घुसने के लिए उस सूची का उपयोग करते हैं।
- ऑब्जेक्ट रीबाइंडिंग (Object Rebinding): आप एक छिपे हुए फ़ील्ड (जैसे दस्तावेज़ पर "मालिक" का नाम बदलना) को बदलकर सिस्टम को यह विश्वास दिला देते हैं कि वह ऑब्जेक्ट आपका है।
4. "वर्टिकल" सरप्राइज (लिफ्ट की सवारी)
आमतौर पर, हम इन हमलों को "होरिजोंटल" (उपयोगकर्ता A द्वारा उपयोगकर्ता B से चोरी करना) के रूप में देखते हैं।
- निष्कर्ष: 12% समय, एक सामान्य उपयोगकर्ता ने एडमिनिस्ट्रेटर (Administrator) की चीजों तक पहुँच प्राप्त की या उन्हें डिलीट कर दिया।
- उपमा: एक अपार्टमेंट कॉम्प्लेक्स का एक सामान्य किरायेदार बिल्डिंग मैनेजर के निजी कार्यालय में घुस जाता है और मास्टर चाबियों को डिलीट कर देता है।
- सीख: यह एक बहुत बड़ा जोखिम है जिसे अधिकांश सुरक्षा चेकलिस्ट अनदेखा कर देती है क्योंकि वे मान लेती हैं कि "एडमिन सुरक्षित हैं।"
5. "मैजिक" IDs काम नहीं करते
डेवलपर्स अक्सर सोचते हैं, "यदि हम साधारण नंबर जैसे 1, 2, 3 का उपयोग नहीं करते हैं, बल्कि लंबे, रैंडम कोड (UUIDs) या एन्कोडेड स्ट्रिंग्स का उपयोग करते हैं, तो हम सुरक्षित हैं।"
- निष्कर्ष: सफल हमलों में से 39% ने इन "जटिल" IDs का उपयोग किया।
- उपमा: बुरे लोगों ने मेलबॉक्स पर लिखे "गुप्त कोड" को डिकोड करने का तरीका ढूंढ लिया, महसूस किया कि यह केवल एक छिपा हुआ नंबर है, और फिर अगले मेलबॉक्स तक पहुँचने के लिए बस उस नंबर को आगे बढ़ा दिया।
- सीख: ID को छिपाना समस्या को ठीक नहीं करता है। सर्वर को अभी भी यह जांचना होगा कि क्या आप उस डेटा के मालिक हैं, चाहे ID कैसी भी दिखे।
6. "GraphQL" का लूपहोल
पेपर में पाया गया कि कई आधुनिक ऐप्स GraphQL नामक सिस्टम का उपयोग करते हैं। ये सिस्टम "ग्लोबल ID" (जैसे gid://hackerone/Report/123) का उपयोग करते हैं।
- निष्कर्ष: हमलावरों ने पाया कि यदि वे इन IDs को डिकोड करते हैं, तो वे इसके नीचे छिपे क्रमिक (sequential) नंबरों को प्रकट करते हैं, जिससे अगले ID का अनुमान लगाना आसान हो जाता है।
- सीख: सिर्फ इसलिए कि एक ID अक्षरों की एक जटिल स्ट्रिंग दिखती है, इसका मतलब यह नहीं है कि वह रैंडम है।
आम आदमी के लिए सारांश
यह पेपर हमें बताता है कि:
- टैग पर भरोसा न करें: सिर्फ इसलिए कि किसी सिस्टम को एक विशिष्ट बग के रूप में चिह्नित किया गया है, इसका मतलब यह नहीं है कि वह वास्तव में उसी तरह से टूटा हुआ है।
- बुरे लोग विनाशकारी होते हैं: वे केवल डेटा चुरा नहीं रहे हैं; वे हमारी सोच से कहीं अधिक डेटा को डिलीट और बदल रहे हैं।
- गुप्त कोड पर्याप्त नहीं हैं: यदि सर्वर यह जांच नहीं करता है कि डेटा का मालिक कौन है, तो जटिल ID का उपयोग करना हैकर्स को रोकने के लिए काफी नहीं है।
- सामान्य उपयोगकर्ता एडमिन को नुकसान पहुँचा सकते हैं: एक सामान्य उपयोगकर्ता खाता कभी-कभी एडमिन की चीजों में घुसपैठ कर सकता है या उन्हें नुकसान पहुँचा सकता है।
पेपर निष्कर्ष निकालता है कि सुरक्षा परीक्षण को बदलना होगा। हमें केवल यह जांचना बंद करना होगा कि क्या आप किसी और का डेटा पढ़ सकते हैं और यह जांचना शुरू करना होगा कि क्या आप उसे डिलीट या बदल सकते हैं, और हमें यह भी टेस्ट करना होगा कि क्या सामान्य उपयोगकर्ता अनजाने में (या जानबूझकर) एडमिन के काम को बिगाड़ सकते हैं।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।