प्रत्येक pull request किसी एंडपॉइंट को जोड़ने या बदलने से आपके API पर हमले का खतरा बढ़ जाता है। अधिकांश API सुरक्षा उपकरण तब तक इस बात को नहीं पहचान पाते जब तक कि वह एंडपॉइंट सक्रिय न हो जाए और उस पर ट्रैफ़िक आना शुरू न हो जाए। तब तक, समस्या का समाधान कोड समीक्षा में एक पंक्ति का बदलाव मात्र नहीं रह जाता, बल्कि यह एक घटना प्रतिक्रिया वार्ता का विषय बन जाता है।
एपीआई सुरक्षा एक ऐसी प्रक्रिया है जिसमें किसी एप्लिकेशन द्वारा अपने एंडपॉइंट्स को प्रदर्शित करने के तरीके में मौजूद जोखिमों को ढूंढना और उन्हें दूर करना शामिल है: कौन उन्हें कॉल कर सकता है, वे क्या डेटा लौटाते हैं, और क्या वे वही करते हैं जो दस्तावेज़ में बताया गया है।
इस समस्या के लिए बनाए गए अधिकांश टूल API का परीक्षण रनटाइम पर, बाहर से, ठीक उसी तरह करते हैं जैसे कोई हमलावर करता है। यह तरीका कारगर है, लेकिन यह API के डिप्लॉय होने के बाद ही काम करता है। ज़ायजेनी यह पहले वाला तरीका अपनाता है: यह एंडपॉइंट पर एक भी अनुरोध पहुंचने से पहले आपके सोर्स कोड और आपके एपीआई विनिर्देश को पढ़ता है।
एपीआई का परीक्षण करने के चार तरीके, और प्रत्येक तरीका किस प्रश्न का उत्तर देता है
अधिकांश परिपक्व कार्यक्रम इनमें से एक से अधिक का संचालन करते हैं:
- स्थैतिक परीक्षण यह परिनियोजन से पहले स्रोत कोड और एपीआई विनिर्देशों का विश्लेषण करता है। यह इस सवाल का जवाब देता है कि "हमने अभी क्या उजागर किया है?" यह लेख इसी दृष्टिकोण पर केंद्रित है।
- गतिशील परीक्षण (डीएएसटी) यह एक चालू एपीआई पर वास्तविक ट्रैफ़िक भेजता है और देखता है कि वह कैसे प्रतिक्रिया करता है। यह इस सवाल का जवाब देता है कि "वास्तव में अभी क्या पहुंच योग्य और शोषण योग्य है?"
- fuzzing यह क्रैश और एज-केस विफलताओं को उजागर करने के लिए एंडपॉइंट्स पर गलत या अप्रत्याशित इनपुट डालता है। यह इस सवाल का जवाब देता है कि "ऐसे इनपुट के तहत क्या टूटता है जिसकी हमने उम्मीद नहीं की थी?"
- मैनुअल भेदन परीक्षण यह स्वचालित उपकरणों द्वारा अनदेखी की गई तार्किक त्रुटियों को खोजने के लिए मानवीय विवेक का उपयोग करता है। यह इस प्रश्न का उत्तर देता है कि "एक चतुर हमलावर किन चीजों को एक साथ जोड़ सकता है?"
इनमें से कोई भी दूसरे का विकल्प नहीं है। ये जीवनचक्र के विभिन्न चरणों में अलग-अलग सवालों के जवाब देते हैं, और अधिकांश कार्यक्रमों में जो कमी होती है, वह पहले चरण से संबंधित होती है।
अधिकांश एपीआई सुरक्षा उपकरण जोखिम को बहुत देर से क्यों पहचानते हैं?
रनटाइम एपीआई सुरक्षा परीक्षण किसी लाइव एप्लिकेशन पर ट्रैफ़िक भेजता है और देखता है कि वह कैसे प्रतिक्रिया करता है। यह एक वैध और आवश्यक स्तर है। हालांकि, यह एक विलंबित संकेतक भी है: रनटाइम स्कैनर द्वारा किसी एंडपॉइंट के बारे में कुछ भी कहने से पहले, उसका अस्तित्व, तैनाती और पहुंच योग्य होना आवश्यक है। स्कैन चलने में जितना समय लगता है, उतने समय तक जो कुछ भी मिलता है, वह पहले से ही उजागर हो चुका होता है।
इस टाइमिंग प्रॉब्लम के नीचे एक और कमी छिपी है। रनटाइम टूल्स केवल उन्हीं चीजों का परीक्षण कर सकते हैं जिनके अस्तित्व के बारे में उन्हें पता होता है। यदि किसी एंडपॉइंट का कभी दस्तावेज़ीकरण नहीं किया गया हो, या किसी ने नया रूट जारी करते ही ओपनएपीआई स्पेसिफिकेशन पुराना हो गया हो, तो रनटाइम स्कैनर को यह जानने का कोई तरीका नहीं है कि वह एंडपॉइंट मौजूद है। यह मैप का परीक्षण करता है, वास्तविक स्थिति का नहीं।
स्टैटिक एपीआई सुरक्षा परीक्षण परिनियोजन से पहले, एंडपॉइंट को परिभाषित करने वाले स्थान पर जांच को स्थानांतरित करके दोनों कमियों को दूर करता है: आपका कोड और आपकी एपीआई विशिष्टता। pull request जो एक एंडपॉइंट प्रस्तुत करता है वह है pull request जिससे इसका खतरा सामने आता है।
स्टैटिक एपीआई सुरक्षा का असल मतलब क्या है?
Xygeni आपके API इन्वेंटरी को दो स्रोतों से तैयार करता है: आपके एप्लिकेशन का सोर्स कोड और आपके API विनिर्देश, जिसमें OpenAPI और Swagger शामिल हैं।
केवल स्पेसिफिकेशन वाली इन्वेंट्री उन एंडपॉइंट्स को दिखाती है जिन्हें किसी ने डॉक्यूमेंट करना याद रखा। केवल कोड वाली इन्वेंट्री यह दिखाती है कि क्या मौजूद है, लेकिन यह जरूरी नहीं कि यह भी दिखाए कि इसका उपयोग कैसे किया जाना था। दोनों को पढ़ने से आपको पूरी जानकारी मिलती है: वे एंडपॉइंट्स जिन्हें आपकी टीम ने डॉक्यूमेंट किया है, और वे जिन्हें किसी ने डॉक्यूमेंट नहीं किया।
वह इन्वेंट्री ही वह आधार है जिस पर बाकी सब कुछ टिका हुआ है:
- खोजे गए कुल एपीआई और जोखिम में मौजूद संपत्तियों का आकलन एक आधारभूत मानक के आधार पर किया गया।
- HTTP विधि के आधार पर विभाजित एंडपॉइंट
- सेवा के अनुसार वर्गीकृत मुद्दे
- प्रत्येक एंडपॉइंट, जिसमें उसका मेथड, पाथ, सर्विस, मॉड्यूल, प्रमाणीकरण स्थिति और जोखिम स्कोर शामिल है।
आपके इंजीनियरिंग लीडर बिना एक भी टिकट खोले आपके एपीआई सरफेस का स्वरूप देख सकते हैं।
Xygeni द्वारा खोजे गए प्रत्येक एंडपॉइंट को, उसकी विधि, प्रमाणीकरण स्थिति और जोखिम स्कोर के साथ, कोड और विनिर्देश दोनों से मिलाकर निर्मित किया गया था।
Production note किसी भी API सुरक्षा स्क्रीनशॉट से AI ट्राइएज पैनल को क्रॉप करें।
OWASP API सुरक्षा शीर्ष 10 से मैप किया गया
निष्कर्ष उस ढांचे की पुष्टि करते हैं जिसका उपयोग आपकी सुरक्षा टीमें और आपके लेखा परीक्षक पहले से ही कर रहे हैं। Xygeni OWASP API सुरक्षा में जोखिम का पता लगाता है। शीर्ष 10 (2023):
एक श्रेणी जानबूझकर अनुपस्थित रखी गई है। API6, संवेदनशील व्यावसायिक प्रवाहों तक अप्रतिबंधित पहुंच, के लिए यह समझना आवश्यक है कि एक व्यावसायिक प्रक्रिया को क्या अनुमति देनी चाहिए, और कोई भी स्टैटिक एनालाइज़र इसे विश्वसनीय रूप से नहीं पहचान पाता है। इसके विपरीत दावा करने वाला कोई भी विक्रेता आपको केवल खानापूर्ति कर रहा है। यह जानकारी आपके थ्रेट मॉडलिंग और पेनिट्रेशन टेस्टर्स के पास ही रहेगी।
हर निष्कर्ष एक समान नहीं होता: डेटा संवेदनशीलता और हानिकारक संयोजन
निष्कर्षों की एक सपाट सूची अनधिकृत स्वास्थ्य-जांच एंडपॉइंट को ग्राहक रिकॉर्ड लौटाने वाले अनधिकृत एंडपॉइंट के समान मानती है। ये दोनों एक ही समस्या नहीं हैं, और एक प्राथमिकता मॉडल जो उन्हें समान रूप से स्कोर करता है, आपकी टीमों को सूची को अनदेखा करने के लिए प्रशिक्षित करता है।
Xygeni प्रत्येक एंडपॉइंट द्वारा संभाले जाने वाले डेटा को वर्गीकृत करता है, अनुरोध मापदंडों और प्रतिक्रियाओं में PII, PCI और PHI को चिह्नित करता है, और इसे एंडपॉइंट की प्रमाणीकरण स्थिति के साथ जोड़ता है।
यह एक ही एंडपॉइंट पर पहुंचने वाले निष्कर्षों को आपस में जोड़ता है और जब वे एक साथ कई हो जाते हैं तो गंभीरता को बढ़ाता है। किसी प्रतिक्रिया में व्यक्तिगत पहचान योग्य जानकारी (PII) का रिसाव अपने आप में एक गंभीर बात है। प्रमाणीकरण की आवश्यकता न होने वाले एंडपॉइंट पर ऐसा रिसाव गंभीर होता है, और प्लेटफ़ॉर्म इसे मैन्युअल रूप से जांचने के लिए किसी व्यक्ति पर छोड़ने के बजाय उसी तरह स्कोर करता है।
ज़ॉम्बी और अनाथ एंडपॉइंट्स: कोड और स्पेसिफिकेशन के बीच का अंतर
Xygeni आपके कोड और API स्पेसिफिकेशन को साथ-साथ पढ़ता है, इसलिए यह उनमें मौजूद मतभेदों को पहचान लेता है। यह मतभेद तीन विशिष्ट पैटर्न के रूप में सामने आता है:
- अज्ञात एंडपॉइंट्स। वे कोड में मौजूद हैं और उन्हें कभी भी स्पेसिफिकेशन में शामिल नहीं किया गया।
- ज़ोंबी एंडपॉइंट्स। इन्हें अप्रचलित या बंद कर दिया गया है, लेकिन फिर भी इन तक पहुँचा जा सकता है।
- अनाथ एंडपॉइंट्स। वर्तमान टीम में किसी के पास भी ये वस्तुएं नहीं हैं।
इनमें से कोई भी वस्तु केवल विनिर्देशों पर आधारित सूची में नहीं दिखती, क्योंकि विनिर्देशों में ही वे वस्तुएं गायब हैं।
यह ऐसे सबूत हैं जिन पर आप कार्रवाई कर सकते हैं, न कि जांच का आदेश।
प्रत्येक खोज उस सटीक हैंडलर की ओर इशारा करती है जो त्रुटि के लिए ज़िम्मेदार है: फ़ाइल, क्लास, मेथड और वह विशिष्ट पंक्ति जिसने त्रुटि उत्पन्न की, साथ ही त्रुटिपूर्ण कोड भी प्रदर्शित किया जाता है। प्रत्येक खोज में उसकी गंभीरता, OWASP API सुरक्षा शीर्ष 10 श्रेणी, CWE, एंडपॉइंट की प्रमाणीकरण स्थिति और शामिल डेटा का संवेदनशीलता वर्गीकरण भी शामिल होता है।
अगर किसी खोज में सिर्फ एंडपॉइंट का नाम दिया गया हो, तो डेवलपर को कुछ भी ठीक करना शुरू करने से पहले ही पूरे कोड में खोजना पड़ता है। लेकिन अगर खोज में लाइन का नाम दिया गया हो, तो डेवलपर सीधे समाधान तक पहुंच जाता है।
निष्कर्ष JSON, CSV, Markdown और SARIF 2.1.0 फॉर्मेट में निर्यात होते हैं, इसलिए वे t में पहुँच जाते हैं।वे उपकरण जिनका उपयोग आपकी टीमें पहले से ही कर रही हैं।
वह हैंडलर, वह लाइन और वह कोड जिसके कारण यह समस्या उत्पन्न हुई। यह जांच का विषय नहीं है।
यह एक प्लेटफॉर्म पर क्यों उपलब्ध है, दूसरे कंसोल पर क्यों नहीं?
Xygeni API सुरक्षा को साथ-साथ चलाता है SAST, SCA, गुप्त सुरक्षा, IaC और दस्ते एक ही प्लेटफॉर्म के भीतर, सहसंबंधित ASPMइसे एक अलग उपकरण के रूप में भेजने के बजाय, login और इसके स्वयं के लंबित कार्यों का समूह।
यह इसलिए महत्वपूर्ण है क्योंकि स्टैटिक फाइंडिंग्स और रनटाइम फाइंडिंग्स एक ही एंडपॉइंट के बारे में अलग-अलग सवालों के जवाब देती हैं, और ये अलग-अलग की तुलना में एक साथ अधिक उपयोगी होती हैं। स्टैटिक फाइंडिंग्स आपको एंडपॉइंट के लॉन्च होने से पहले ही उसकी जोखिम भरी स्थिति के बारे में बता देती हैं। DAST यह पुष्टि करता है कि एक बार चलने के बाद वास्तव में क्या पहुंच योग्य और शोषण योग्य है।
इसे दो कंसोल में विभाजित करने पर, सहसंबंधित जोखिम दो असंबंधित बैकलॉग में बदल जाता है। कोई भी उनका सामंजस्य नहीं बिठाता, और वह एंडपॉइंट जो न तो दस्तावेजीकृत है और न ही प्रमाणित है, किसी भी कतार में नहीं रहता।
अपनी वास्तविक एपीआई अटैक सतह देखें। एपीआई सुरक्षा एक के रूप में उपलब्ध है Enterprise Xygeni प्लेटफॉर्म के ऐड-ऑन के रूप में, आपके अपने इंफ्रास्ट्रक्चर के भीतर आपके अपने रिपॉजिटरी के खिलाफ एक स्कैन चलाया जाता है।
सामान्य प्रश्न
क्या यह बता सकता है कि कौन से एंडपॉइंट संवेदनशील डेटा को संभालते हैं?
हां। Xygeni एंडपॉइंट पैरामीटर और प्रतिक्रियाओं में PII, PCI और PHI को चिह्नित करता है, और वास्तविक जोखिम के आधार पर निष्कर्षों को रैंक करने के लिए उस वर्गीकरण का उपयोग करता है।
क्या यह हर जगह चल सकता है? pull request?
जी हां। इंक्रीमेंटल स्कैनिंग केवल उन्हीं एंडपॉइंट्स का विश्लेषण करती है जिनमें बदलाव हुआ है, और इससे उत्पन्न मैनिफेस्ट बाद के DAST स्कैन को उन्हीं एंडपॉइंट्स पर केंद्रित कर सकता है, जिससे स्टैटिक और रनटाइम परीक्षण वास्तव में स्थानांतरित हुई चीज़ों के अनुरूप बने रहते हैं।
क्या मेरा कोड मेरे वातावरण से बाहर निकल जाता है?
नहीं। स्कैन आपके अपने इंफ्रास्ट्रक्चर में चलते हैं। केवल परिणाम अपलोड किए जाते हैं, जो ट्रांज़िट और स्टोरेज दोनों में सुरक्षित रहते हैं।
मुझे एपीआई सुरक्षा कैसे मिलेगी?
एपीआई सुरक्षा एक के रूप में उपलब्ध है Enterprise ऐड-ऑन। एक प्रूफ ऑफ कॉन्सेप्ट का अनुरोध करें और आपके साथ मिलकर इसका दायरा तय किया जाएगा।
