APISIX कैसे OWASP टॉप 10 API सुरक्षा खतरों से बचाता है

आज के परस्पर जुड़े डिजिटल परिदृश्य में API के बढ़ते उपयोग और निर्भरता के साथ, उन पर लक्षित सुरक्षा खतरे भी वर्षों में बढ़े हैं। 2023 में, ओपन वेब एप्लिकेशन सुरक्षा प्रोजेक्ट (OWASP) ने API सुरक्षा के लिए नए शीर्ष 10 खतरों की पहचान की। इस ब्लॉग पोस्ट में, हम प्रत्येक खतरे का पता लगाएंगे और उदाहरणों के साथ सीखेंगे कि APISIX उनसे कैसे सुरक्षा प्रदान कर सकता है।

OWASP एक वैश्विक स्तर पर मान्यता प्राप्त समुदाय है जो नियमित रूप से साइबर सुरक्षा से संबंधित शोध प्रकाशित करता है।

यहां OWASP द्वारा उल्लिखित सुरक्षा जोखिमों की सूची दी गई है:

1. टूटी हुई ऑब्जेक्ट स्तरीय प्राधिकरण
2. टूटी हुई प्रमाणीकरण
3. टूटी हुई ऑब्जेक्ट संपत्ति स्तरीय प्राधिकरण
4. असीमित संसाधन खपत
5. टूटी हुई फ़ंक्शन स्तरीय प्राधिकरण
6. संवेदनशील व्यावसायिक प्रवाह तक असीमित पहुंच
7. सर्वर-साइड अनुरोध जालसाजी
8. सुरक्षा गलत कॉन्फ़िगरेशन
9. अनुचित इन्वेंटरी प्रबंधन
10. API का असुरक्षित उपभोग

1. टूटी हुई ऑब्जेक्ट स्तरीय प्राधिकरण

खतरा: API अक्सर ऐसे एंडपॉइंट्स को एक्सपोज़ करते हैं जो ऑब्जेक्ट पहचानकर्ताओं को संभालते हैं, जिससे ऑब्जेक्ट स्तरीय पहुंच नियंत्रण समस्याएं हो सकती हैं। हमलावर इन कमजोरियों का फायदा उठाकर डेटा तक अनधिकृत पहुंच प्राप्त कर सकते हैं।

उदाहरण: एक स्वास्थ्य संस्थान एक ऑनलाइन मरीज पोर्टल प्रदान करता है। पोर्टल के डिज़ाइन में एक खामी के कारण, एक बार जब एक मरीज प्रमाणित हो जाता है, तो वह URL या अनुरोध पैरामीटर्स को संशोधित करके एक अलग मरीज ID से जुड़े मेडिकल रिकॉर्ड तक पहुंच सकता है। उदाहरण के लिए, एक मरीज स्टीव मरीज पोर्टल में लॉग इन करके अपने मेडिकल रिकॉर्ड देखता है। उसके रिकॉर्ड URL https://healthportal.com/patient/123 के माध्यम से एक्सेस किए जा सकते हैं। जिज्ञासावश, स्टीव URL को https://healthportal.com/patient/124 में बदलता है और पाता है कि वह अब एक अन्य मरीज के मेडिकल रिकॉर्ड देख सकता है। यह एक महत्वपूर्ण गोपनीयता उल्लंघन को उजागर करता है और हेल्थ इंश्योरेंस पोर्टेबिलिटी और अकाउंटेबिलिटी एक्ट (HIPAA) जैसे नियमों का उल्लंघन करता है।

सिफारिश: उपयोगकर्ता नीतियों और पदानुक्रम पर आधारित एक उचित प्राधिकरण तंत्र लागू करें। APISIX गेटवे प्लगइन्स की मदद से OAuth2 या JWT-आधारित प्राधिकरण प्रवाह का समर्थन करता है। आप प्रत्येक अनुरोध पर टोकन को सत्यापित करने के लिए OAuth2 नीति का उपयोग कर सकते हैं।

Open Policy Agent (OPA) के साथ एकीकृत करके APISIX की रोल-आधारित पहुंच नियंत्रण (RBAC) प्रणाली के माध्यम से सूक्ष्म पहुंच नियंत्रण का उपयोग करें। APISIX में विशिष्ट रोल और अनुमतियां सेट करके और इन रोल को विशिष्ट उपयोगकर्ताओं या टोकन से जोड़कर, आप यह सुनिश्चित कर सकते हैं कि संवेदनशील एंडपॉइंट्स के लिए अनुरोधों को उचित रूप से प्राधिकृत किया जाता है।

2. टूटी हुई प्रमाणीकरण

खतरा: गलत तरीके से लागू प्रमाणीकरण तंत्र हमलावरों को प्रमाणीकरण टोकन को समझौता करने की अनुमति दे सकते हैं या सिर्फ एक हमलावर लॉगिन एंडपॉइंट्स को ब्रूट-फोर्स कर सकता है क्योंकि कोई दर सीमा नहीं है।

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

सिफारिश: सबसे पहले, API के लिए सभी संभावित प्रमाणीकरण प्रवाह को समझें, और प्रमाणीकरण में पहिया का पुन: आविष्कार न करें! APISIX मानक OpenID Connect (OIDC) प्राधिकरण प्रवाह का समर्थन करता है। पूर्वानुमानित सत्र टोकन के बजाय, APISIX Keycloak जैसे बाहरी पहचान प्रदाताओं या सत्र प्रबंधन सिस्टम के साथ प्लगइन्स का उपयोग करके एकीकृत कर सकता है ताकि यह सुनिश्चित किया जा सके कि सत्र टोकन यादृच्छिक, एन्क्रिप्टेड और सीमित जीवनकाल वाले हैं।

उपयोगकर्ता खातों पर ब्रूट फोर्स हमलों को रोकने के लिए, APISIX का दर सीमित करना प्लगइन का उपयोग किया जा सकता है। यह सुनिश्चित करता है कि यदि कम समय में कई असफल लॉगिन प्रयास होते हैं, तो IP या उपयोगकर्ता को अस्थायी रूप से ब्लॉक कर दिया जाता है। डेटा गोपनीयता और अखंडता सुनिश्चित करने के लिए, APISIX SSL/TLS एन्क्रिप्शन का समर्थन करता है। यह सुनिश्चित करता है कि उपयोगकर्ता क्रेडेंशियल्स और अन्य संवेदनशील डेटा ट्रांसमिशन के दौरान एन्क्रिप्टेड होते हैं।

3. टूटी हुई ऑब्जेक्ट संपत्ति स्तरीय प्राधिकरण

खतरा: यह खतरा ऑब्जेक्ट संपत्ति स्तर पर प्राधिकरण सत्यापन की कमी या अनुचित सत्यापन के कारण उत्पन्न होता है, जिससे अनधिकृत जानकारी का प्रकटीकरण या हेरफेर हो सकता है।

उदाहरण: एक ऑनलाइन शॉपिंग प्लेटफॉर्म का API पंजीकृत उपयोगकर्ताओं को अपने प्रोफाइल विवरण जैसे नाम, ईमेल, शिपिंग पता और भुगतान विवरण को अपडेट करने की अनुमति देता है। इसके अलावा, प्रत्येक उपयोगकर्ता प्रोफाइल में एक संपत्ति userType होती है, जो regular या admin हो सकती है। API के डिज़ाइन में एक समस्या के कारण, उपयोगकर्ता अपने प्रोफाइल अपडेट अनुरोधों में userType संपत्ति को भी संशोधित कर सकते हैं। मान लीजिए कि एलिस, एक नियमित उपयोगकर्ता, अपने ब्राउज़र के डेवलपर टूल्स का उपयोग करके API अनुरोधों का निरीक्षण करते समय इस खामी का पता लगाती है। वह देखती है कि जब वह अपने प्रोफाइल को अपडेट करती है, तो सर्वर को एक JSON पेलोड भेजा जाता है। एलिस userType मान को admin में संशोधित करती है और अनुरोध भेजती है। उसके आश्चर्य के लिए, उसका प्रोफाइल अपडेट हो जाता है और अब उसे प्लेटफॉर्म पर प्रशासनिक विशेषाधिकार प्राप्त होते हैं, जिससे वह संवेदनशील डेटा तक पहुंच सकती है, उत्पाद सूची को संशोधित कर सकती है और यहां तक कि अन्य उपयोगकर्ताओं के ऑर्डर इतिहास देख सकती है।

सिफारिश: यह सुनिश्चित करें कि एक्सपोज़ की गई ऑब्जेक्ट संपत्तियां उपयोगकर्ता के लिए सुलभ हों और व्यावसायिक आवश्यकताओं के आधार पर लौटाए गए डेटा संरचनाओं को न्यूनतम रखें। इसे प्राप्त करने के लिए, आप APISIX का अनुरोध-सत्यापन प्लगइन का उपयोग कर सकते हैं जो आने वाले अनुरोधों को पूर्वनिर्धारित स्कीमा के खिलाफ सत्यापित कर सकता है। या APISIX की RBAC प्रणाली का उपयोग करके नियमित उपयोगकर्ताओं और प्रशासकों के लिए रोल सेट करें। क्लाइंट को एक्सपोज़ किए गए अनावश्यक डेटा को हटाने के लिए, APISIX एक प्रतिक्रिया-पुनर्लेखन प्लगइन प्रदान करता है जो API प्रतिक्रिया को तुरंत संशोधित कर सकता है।

4. असीमित संसाधन खपत

खतरा: हमलावर API का उपयोग करके अत्यधिक संसाधनों का उपभोग कर सकते हैं, जिससे डिनायल ऑफ सर्विस हमले या परिचालन लागत में वृद्धि हो सकती है।

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

सिफारिश:

• सभी आने वाले पैरामीटर्स और पेलोड के लिए अधिकतम डेटा आकार को परिभाषित और लागू करें। क्लाइंट-नियंत्रण प्लगइन का उपयोग करके अनुरोध बॉडी का अधिकतम आकार सेट करें ताकि उपयोगकर्ता अत्यधिक बड़ी फ़ाइलें अपलोड न कर सकें। या अनुरोध-सत्यापन प्लगइन का उपयोग करके क्वेरी स्ट्रिंग्स को सत्यापित करें, विशेष रूप से उन्हें जो लौटाए गए रिकॉर्ड की संख्या को नियंत्रित करते हैं। एक बॉट, स्क्रिप्ट या उपयोगकर्ता एजेंट को अवांछित डेटा भेजने से रोकने के लिए, आप ua-restriction प्लगइन का लाभ उठा सकते हैं।
• व्यावसायिक आवश्यकताओं के आधार पर दर सीमित करना लागू करें। APISIX limit-req, limit-conn, और limit-count प्लगइन्स प्रदान करता है जो किसी व्यक्तिगत उपयोगकर्ता या IP पते द्वारा अनुरोध करने की दर को सीमित कर सकते हैं। यह सुनिश्चित करता है कि उपयोगकर्ता सिस्टम को बड़ी संख्या में तेजी से अनुरोधों से भर नहीं सकते।

5. टूटी हुई फ़ंक्शन स्तरीय प्राधिकरण

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

उदाहरण: एक ऑनलाइन लर्निंग प्लेटफॉर्म छात्रों को विभिन्न पाठ्यक्रम प्रदान करता है। प्लेटफॉर्म के डिज़ाइन में समस्याओं के कारण, छात्र URL या API एंडपॉइंट्स को हेरफेर करके इंस्ट्रक्टर-केवल कार्यक्षमताओं तक पहुंच सकते हैं। उदाहरण के लिए, एक छात्र यह पता लगा सकता है कि URL को /student/dashboard से /instructor/dashboard में बदलकर, वह इंस्ट्रक्टर के डैशबोर्ड तक पहुंच सकता है, जिससे वह पाठ्यक्रम सामग्री को संशोधित कर सकता है, असाइनमेंट ग्रेड कर सकता है या यहां तक कि पाठ्यक्रम जोड़/हटा सकता है।

सिफारिश:

• डिफ़ॉल्ट रूप से सभी पहुंच को अस्वीकार करें और विशिष्ट रोल के लिए स्पष्ट अनुमति की आवश्यकता हो। APISIX के साथ, आप उपभोक्ता या उपभोक्ता समूह बना सकते हैं ताकि उपयोगकर्ताओं के लिए अलग-अलग पहुंच नियंत्रण दिया जा सके। फिर, JWT प्रमाणीकरण प्लगइन को JWT टोकन में रोल जानकारी शामिल करने के लिए कॉन्फ़िगर किया जा सकता है। जब एक उपयोगकर्ता लॉग इन करता है, तो उन्हें प्राप्त होने वाला JWT टोकन उनके रोल (student या instructor) को शामिल करेगा। APISIX तब विशिष्ट कार्यक्षमताओं तक पहुंच प्रदान करने से पहले JWT टोकन से उपयोगकर्ता के रोल को सत्यापित कर सकता है।
• सुनिश्चित करें कि प्रशासनिक नियंत्रक एक ऐसे नियंत्रक से विरासत में मिलते हैं जो उपयोगकर्ता रोल के आधार पर प्राधिकरण जांच लागू करता है। यदि आप API7 एंटरप्राइज़ का उपयोग करते हैं, तो यह प्रशासकों को विशिष्ट उपयोगकर्ताओं/समूहों के लिए API पहुंच को सीमित करने की अनुमति देता है और आप प्रति अनुरोध और प्रति उपयोगकर्ता आधार पर पहुंच सेट कर सकते हैं।

6. संवेदनशील व्यावसायिक प्रवाह तक असीमित पहुंच

खतरा: संवेदनशील व्यावसायिक प्रवाह को जोखिम मूल्यांकन के बिना एक्सपोज़ किया जाता है कि यदि इस कार्यक्षमता का स्वचालित और अत्यधिक तरीके से उपयोग किया जाता है तो व्यवसाय को कैसे नुकसान हो सकता है।

उदाहरण: प्रॉक्सी और स्वचालित स्क्रिप्ट्स (बॉट्स) के संयोजन का उपयोग करके, हमलावर कई वास्तविक उपयोगकर्ताओं को खरीदारी करने का अनुकरण करता है। स्क्रिप्ट तेजी से उत्पाद को कार्ट में जोड़ती है और चेकआउट प्रक्रिया को पूरा करती है, जिससे वास्तविक ग्राहकों के पास खरीदारी करने का मौका आने से पहले स्टॉक खत्म हो जाता है। हमलावर फिर इन उत्पादों को अन्य प्लेटफॉर्म पर उच्च कीमत पर बेचता है। विक्रेता प्लेटफॉर्म संभावित राजस्व खो देता है क्योंकि वे उत्पादों को वास्तविक ग्राहकों को इच्छित कीमत पर नहीं बेच सकते।

सिफारिश:

• अप्रत्याशित क्लाइंट डिवाइसों को सेवा से इनकार करने के लिए डिवाइस फिंगरप्रिंटिंग लागू करें। APISIX को Auth0, Authgear जैसे पहचान और पहुंच प्रबंधन प्लेटफॉर्म के साथ एकीकृत किया जा सकता है ताकि डिवाइस पर बायोमेट्रिक लॉगिन सुविधाओं सहित विभिन्न प्रमाणीकरण तंत्र सक्षम किए जा सकें।
• कैप्चा या उन्नत बायोमेट्रिक समाधान जैसे मानव पहचान तंत्र का उपयोग करें। ऊपर के समान।
• गैर-मानव पैटर्न का पता लगाने के लिए उपयोगकर्ता प्रवाह का विश्लेषण करें। आप API7 एंटरप्राइज़ का उपयोग करके अनुरोध से जुड़े गैर-मानव पैटर्न, जैसे विभिन्न लॉगिन स्थानों के बीच उच्च गति या बॉट्स का पता लगाने पर अतिरिक्त प्रमाणीकरण कारक लागू कर सकते हैं।
• ज्ञात दुर्भावनापूर्ण स्रोतों के IP पतों को ब्लॉक करें। APISIX में एक ip-restriction प्लगइन है जो एक या कई IP पतों से पहुंच को ब्लॉक कर सकता है।

7. सर्वर साइड अनुरोध जालसाजी (SSRF)

खतरा: SSRF हमले हमलावर को सर्वर के आंतरिक संसाधनों के लिए अनुरोध करने की अनुमति देते हैं, जिससे आंतरिक नेटवर्क, फ़ाइल सिस्टम या यहां तक कि कमांड निष्पादित करने तक पहुंच प्राप्त हो सकती है। यह तब होता है जब एक API एंडपॉइंट URL या उसके एक हिस्से को इनपुट के रूप में स्वीकार करता है और उसे उचित सत्यापन के बिना फ़ेच करता है।

उदाहरण: एक API एंडपॉइंट इंटरनेट से एक छवि फ़ेच करने के लिए एक URL स्वीकार करता है। एक दुर्भावनापूर्ण उपयोगकर्ता http://169.254.169.254/latest/meta-data/ (क्लाउड वातावरण में एक सामान्य मेटाडेटा एंडपॉइंट) जैसा URL सबमिट करता है। सेवा URL को फ़ेच करती है, यह सोचकर कि यह एक छवि है, लेकिन इसके बजाय IAM रोल, गुप्त कुंजी या अन्य आंतरिक कॉन्फ़िगरेशन विवरण जैसे संवेदनशील डेटा प्राप्त करती है। हमलावर फिर इस जानकारी का उपयोग विशेषाधिकार वृद्धि या डेटा उल्लंघन जैसे आगे के हमलों के लिए करता है।

सिफारिश:

• इनपुट सत्यापन - हमेशा इनपुट को सत्यापित और सैनिटाइज़ करें। अविश्वसनीय स्रोतों से पूर्ण URL स्वीकार करने से बचें। APISIX के साथ, आप आंतरिक संसाधनों पर ब्लॉकिंग नियम लागू करने के लिए uri-blocker प्लगइन सेट कर सकते हैं।
• व्हाइटलिस्टिंग - केवल ज्ञात और विश्वसनीय डोमेन या IPs के लिए कनेक्शन की अनुमति दें। आप APISIX के ip-restriction प्लगइन का उपयोग कर सकते हैं या स्वीकार्य डोमेन या URL पैटर्न की व्हाइटलिस्ट के लिए referer-restriction सक्षम कर सकते हैं। व्हाइटलिस्ट से मेल न खाने वाला कोई भी URL अस्वीकार कर दिया जाता है।
• नेटवर्क विभाजन - सुनिश्चित करें कि आपके सर्वर विभाजित हैं और संवेदनशील आंतरिक संसाधन सीधे एक्सेस करने योग्य नहीं हैं।

8. सुरक्षा गलत कॉन्फ़िगरेशन

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

उदाहरण: एक सरल उदाहरण यह हो सकता है कि एक API अनजाने में एक .git डायरेक्टरी को एक्सपोज़ कर दे, जिससे स्रोत कोड और कमिट इतिहास प्रकट हो जाए। एक अन्य उदाहरण, एक दुर्भावनापूर्ण उपयोगकर्ता, आपके प्लेटफॉर्म का उपयोग करते समय, एक त्रुटि संदेश का सामना करता है। एक सामान्य त्रुटि संदेश के बजाय, वह एक विस्तृत स्टैक ट्रेस देखता है जो डेटाबेस संरचना, सॉफ्टवेयर संस्करण और फ़ाइल पथ