प्रत्येक pull request एखादा एंडपॉइंट जोडल्याने किंवा बदलल्याने तुमच्या API वरील हल्ल्यांची शक्यता वाढते. बहुतेक API सुरक्षा साधनांना तो एंडपॉइंट सुरू होऊन त्यावर रहदारी सुरू होईपर्यंत याची जाणीव होत नाही. तोपर्यंत, त्यावरचा उपाय हा कोड रिव्ह्यूमधील एका ओळीचा बदल राहत नाही, तर ती एक घटना प्रतिसाद चर्चा बनते.
एपीआय सुरक्षा म्हणजे एखादे ॲप्लिकेशन त्याचे एंडपॉइंट्स कसे उघड करते यातील धोके शोधून ते दूर करण्याची पद्धत आहे: त्यांना कोण कॉल करू शकते, ते कोणता डेटा परत करतात आणि डॉक्युमेंटेशनमध्ये सांगितल्याप्रमाणे ते काम करतात की नाही.
या समस्येसाठी तयार केलेली बहुतेक साधने, एखाद्या हल्लेखोराप्रमाणेच, रनटाइमवर बाहेरून API ची चाचणी करतात. ही पद्धत काम करते, पण ती केवळ API तैनात (deploy) झाल्यानंतरच कार्य करते. झायगेनी आधीचा मार्ग अवलंबतो: एकही विनंती एंडपॉइंटवर पोहोचण्यापूर्वी तो तुमचा सोर्स कोड आणि तुमचे API स्पेसिफिकेशन वाचतो.
एपीआय तपासण्याचे चार मार्ग, आणि प्रत्येक मार्गातून काय साध्य होते
बहुतेक प्रस्थापित प्रोग्रॅम्स यांपैकी एकापेक्षा जास्त चालवतात:
- स्थिर चाचणी डिप्लॉयमेंट करण्यापूर्वी सोर्स कोड आणि API स्पेसिफिकेशन्सचे विश्लेषण करते. "आपण नुकतेच काय उघड केले आहे?" या प्रश्नाचे उत्तर देते. हा लेख याच दृष्टिकोनावर लक्ष केंद्रित करतो.
- डायनॅमिक टेस्टिंग (DAST) चालू असलेल्या API वर प्रत्यक्ष ट्रॅफिक पाठवते आणि तो कसा प्रतिसाद देतो याचे निरीक्षण करते. यातून “सध्या प्रत्यक्षात काय पोहोचण्यायोग्य आणि शोषणीय आहे?” या प्रश्नाचे उत्तर मिळते.
- फजिंग क्रॅश आणि एज-केस फेल्युअर दर्शवण्यासाठी एंडपॉइंट्सवर चुकीच्या स्वरूपाचे किंवा अनपेक्षित इनपुट टाकते. "आम्ही अपेक्षा न केलेल्या इनपुटमुळे काय बिघडते?" या प्रश्नाचे ते उत्तर देते.
- मॅन्युअल पेनेट्रेशन टेस्टिंग स्वयंचलित साधनांना न सापडणाऱ्या तार्किक त्रुटी शोधण्यासाठी मानवी निर्णयाचा वापर केला जातो. “एक हुशार हल्लेखोर कोणत्या गोष्टींची साखळी तयार करेल?” या प्रश्नाचे उत्तर ते देते.
यांपैकी कोणीही एकमेकांची जागा घेत नाही. ते जीवनचक्राच्या वेगवेगळ्या टप्प्यांवर वेगवेगळ्या प्रश्नांची उत्तरे देतात आणि बहुतेक प्रोग्रॅम्समधील उणीव ही पहिल्या प्रश्नाचीच असते.
बहुतेक API सुरक्षा साधनांना धोका खूप उशिरा का दिसतो?
रनटाइम एपीआय सुरक्षा चाचणी एका चालू ॲप्लिकेशनवर ट्रॅफिक पाठवते आणि ते कसे प्रतिसाद देते हे पाहते. हा एक वैध आणि आवश्यक स्तर आहे. तसेच, त्याच्या रचनेनुसार, तो एक विलंबित निर्देशक आहे: रनटाइम स्कॅनरला एखाद्या एंडपॉइंटबद्दल काहीही सांगण्यापूर्वी, तो अस्तित्वात असणे, तैनात केलेला असणे आणि पोहोचण्यायोग्य असणे आवश्यक असते. स्कॅनला जे काही सापडते, ते स्कॅन पूर्ण होईपर्यंतच्या काळात आधीच असुरक्षित होते.
त्या टायमिंगच्या समस्येमागे एक दुसरी उणीव आहे. रनटाइम टूल्स फक्त त्याच गोष्टी तपासू शकतात ज्या अस्तित्वात आहेत हे त्यांना माहीत असते. जर एखाद्या एंडपॉइंटचे कधीही डॉक्युमेंटेशन झाले नसेल, किंवा कोणीतरी नवीन रूट उपलब्ध करून देताच ओपनएपी स्पेसिफिकेशन कालबाह्य झाले असेल, तर रनटाइम स्कॅनरला ते तिथे आहे हे कळण्याचा कोणताही मार्ग नसतो. ते नकाशाची चाचणी करते, प्रदेशाची नाही.
स्टॅटिक API सुरक्षा चाचणी, डिप्लॉयमेंटपूर्वी, तपासणी जिथे एंडपॉइंट परिभाषित केला आहे तिथे म्हणजेच तुमच्या कोडमध्ये आणि तुमच्या API स्पेसिफिकेशनमध्ये हलवून दोन्ही त्रुटी दूर करते. pull request जो एंडपॉइंट सादर करतो तो आहे pull request त्यामुळे त्याचा धोका समोर येतो.
स्टॅटिक एपीआय सुरक्षेचा नेमका अर्थ काय आहे
झायजेनी (Xygeni) तुमच्या एपीआयची (API) यादी दोन स्रोतांवरून तयार करते: तुमच्या ऍप्लिकेशनचा सोर्स कोड आणि तुमची एपीआय वैशिष्ट्ये, ज्यामध्ये ओपनएपीआय (OpenAPI) आणि स्वॅगर (Swagger) यांचा समावेश आहे.
केवळ स्पेसिफिकेशन्स असलेली इन्व्हेंटरी (spec-only inventory) ते एंडपॉइंट्स दाखवते ज्यांचे डॉक्युमेंटेशन (documentation) करायला कोणीतरी लक्षात ठेवले होते. केवळ कोड असलेली इन्व्हेंटरी (code-only inventory) काय अस्तित्वात आहे हे दाखवते, पण त्याचा वापर कसा करायचा होता हे दाखवतेच असे नाही. दोन्ही वाचल्याने तुम्हाला संपूर्ण चित्र मिळते: तुमच्या टीमने डॉक्युमेंटेशन केलेले एंडपॉइंट्स, आणि ज्यांचे कोणीही केले नाही ते.
ती मालमत्ता यादी हाच पाया आहे ज्यावर बाकी सर्व काही उभारले जाते:
- शोधलेल्या एकूण API ची संख्या आणि एका आधाररेषेच्या तुलनेत मोजलेली धोक्यात असलेली मालमत्ता.
- HTTP पद्धतीनुसार विभागलेले एंडपॉइंट्स
- सेवेनुसार गटबद्ध केलेल्या समस्या
- प्रत्येक एंडपॉइंट, त्याच्या मेथड, पाथ, सर्व्हिस, मॉड्यूल, ऑथेंटिकेशन स्टेट आणि रिस्क स्कोअरसह.
तुमचे इंजिनिअरिंग प्रमुख एकही तिकीट न उघडता तुमच्या API सरफेसचे स्वरूप पाहू शकतात.
Xygeni ला सापडलेला प्रत्येक एंडपॉइंट, त्याची मेथड, ऑथेंटिकेशन स्टेट आणि रिस्क स्कोअरसह, जो कोड आणि स्पेसिफिकेशन एकत्र वापरून तयार केला आहे.
Production note कोणत्याही API सुरक्षा स्क्रीनशॉटमधून AI ट्रायएज पॅनल क्रॉप करा.
OWASP API सुरक्षा टॉप 10 शी मॅप केलेले
निष्कर्ष तुमच्या सुरक्षा पथकांनी आणि लेखापरीक्षकांनी आधीच वापरत असलेल्या कार्यप्रणालीशी सुसंगत आहेत. झायजेनी (Xygeni) OWASP API सुरक्षेमधील धोके शोधते. शीर्ष ४ (२४):
एक श्रेणी हेतुपुरस्सर वगळण्यात आली आहे. API6, म्हणजेच संवेदनशील व्यावसायिक प्रवाहांमध्ये अप्रतिबंधित प्रवेश, यासाठी व्यावसायिक प्रक्रियेने नेमके काय करण्याची परवानगी द्यावी हे समजून घेणे आवश्यक आहे, आणि कोणताही स्टॅटिक ॲनालायझर ते विश्वसनीयपणे शोधू शकत नाही. याउलट दावा करणारा कोणताही विक्रेता तुम्हाला केवळ एक चेकबॉक्स विकत आहे. ही बाब तुमच्या थ्रेट मॉडेलिंग आणि पेनिट्रेशन टेस्टर्सकडेच राहते.
प्रत्येक निष्कर्ष समान नसतो: डेटाची संवेदनशीलता आणि घातक संयोग
निष्कर्षांची एक सपाट यादी अप्रमाणित हेल्थ-चेक एंडपॉइंटला, ग्राहक रेकॉर्ड्स परत करणाऱ्या अप्रमाणित एंडपॉइंटसारखेच मानते. या दोन्ही समस्या एकसारख्या नाहीत, आणि त्यांना सारखेच गुण देणारे प्राधान्यीकरण मॉडेल तुमच्या टीम्सना त्या यादीकडे दुर्लक्ष करायला शिकवते.
झायजेनी प्रत्येक एंडपॉइंट हाताळत असलेल्या डेटाचे वर्गीकरण करते, विनंती पॅरामीटर्स आणि प्रतिसादांमध्ये PII, PCI आणि PHI चिन्हांकित करते आणि त्याची एंडपॉइंटच्या प्रमाणीकरण स्थितीशी जोडणी करते.
हे एकाच एंडपॉइंटवर आढळणाऱ्या निष्कर्षांमध्ये सहसंबंध साधते आणि जेव्हा ते एकत्रित होतात तेव्हा त्यांची तीव्रता वाढवते. प्रतिसादातील PII गळती हा स्वतःच एक गंभीर निष्कर्ष आहे. प्रमाणीकरणाची आवश्यकता नसलेल्या एंडपॉइंटवरील अशीच गळती अत्यंत गंभीर असते, आणि प्लॅटफॉर्म ते कनेक्शन कोणाच्यातरी व्यक्तिगत लक्षात येण्यावर सोडून देण्याऐवजी, त्याला त्याच प्रकारे गुण देते.
झोम्बी आणि अनाथ एंडपॉइंट्स: कोड आणि स्पेकमधील तफावत
झायजेनी तुमचा कोड आणि तुमचे एपीआय स्पेसिफिकेशन एकत्र वाचत असल्यामुळे, त्यांतील मतभेद कुठे आहेत हे त्याला दिसते. हा फरक तीन ओळखण्यायोग्य पॅटर्नच्या स्वरूपात दिसून येतो:
- अनिर्दिष्ट एंडपॉइंट्स. ते कोडमध्येच आहेत आणि त्यांना कधीही स्पेकमध्ये समाविष्ट केले गेले नाही.
- झोम्बी एंडपॉइंट्स. ते अप्रचलित किंवा सेवानिवृत्त म्हणून चिन्हांकित आहेत, आणि ते अजूनही पोहोचण्यायोग्य आहेत.
- अनाथ एंडपॉइंट्स. सध्याच्या संघातील कोणाचीही त्यावर मालकी नाही.
यापैकी काहीही केवळ स्पेसिफिकेशनवर आधारित इन्व्हेंटरीमध्ये दिसत नाही, कारण नेमक्या त्याच स्पेसिफिकेशनमध्ये त्यांची कमतरता आहे.
कारवाई करता येईल असा पुरावा, चौकशीसाठी दिलेले तिकीट नव्हे.
प्रत्येक निष्कर्ष नेमक्या जबाबदार घटकाकडे निर्देश करतो: फाईल, क्लास, मेथड आणि त्रुटी निर्माण करणारी विशिष्ट ओळ, सोबत दोषपूर्ण कोडही दर्शवला जातो. या प्रत्येकासोबत त्याची तीव्रता, त्याची OWASP API Security Top 10 श्रेणी, त्याचे CWE, एंडपॉइंटची प्रमाणीकरण स्थिती आणि संबंधित डेटाचे संवेदनशीलता वर्गीकरण देखील दिलेले असते.
केवळ एंडपॉइंटचे नाव देणारी त्रुटी डेव्हलपरला काहीही दुरुस्त करण्यापूर्वीच कोडबेसमध्ये शोधाशोध करायला लावते. याउलट, ओळीचे नाव देणारी त्रुटी त्यांना थेट दुरुस्तीपर्यंत पोहोचवते.
निष्कर्ष JSON, CSV, Markdown आणि SARIF 2.1.0 स्वरूपात निर्यात केले जातात, त्यामुळे ते t मध्ये पोहोचतात.तुमची टीम आधीपासूनच वापरत असलेली साधने.
हँडलर, ओळ आणि कोड ज्यामुळे धोका निर्माण झाला. चौकशी करण्याची गरज नाही.
हे एकाच प्लॅटफॉर्मवर का चालते, दुसऱ्या कन्सोलवर का नाही
Xygeni सोबत API सुरक्षा चालवते SAST, SCA, गुप्त सुरक्षा, IaC आणि DAST एकाच प्लॅटफॉर्मच्या आत, याच्याद्वारे सहसंबंधित ASPMते स्वतःच्या स्वतंत्र साधनासह पाठवण्याऐवजी login आणि त्याचा स्वतःचा प्रलंबित कामांचा साठा.
हे महत्त्वाचे आहे कारण स्टॅटिक फाइंडिंग्ज आणि रनटाइम फाइंडिंग्ज एकाच एंडपॉइंटबद्दलच्या वेगवेगळ्या प्रश्नांची उत्तरे देतात आणि ते स्वतंत्रपणे वापरण्यापेक्षा एकत्र वापरल्यास अधिक उपयुक्त ठरतात. एखादा एंडपॉइंट कार्यान्वित होण्यापूर्वीच तो धोकादायक आहे, हे स्टॅटिक फाइंडिंग्ज सांगतात. एकदा एंडपॉइंट चालू झाल्यावर, प्रत्यक्षात काय पोहोचण्यायोग्य आणि शोषणीय आहे, याची DAST पुष्टी करते.
ते दोन कन्सोलमध्ये विभागल्यास, सहसंबंधित धोका दोन असंबंधित बॅकलॉगमध्ये विभागला जातो. कोणीही त्यांचा ताळमेळ घालत नाही, आणि जो एंडपॉइंट अनिर्दिष्ट तसेच अप्रमाणित आहे, तो दोन्हीपैकी कोणत्याही रांगेत राहत नाही.
तुमच्या API वरील हल्ल्याची खरी शक्यता पाहा. एपीआय सुरक्षा या स्वरूपात उपलब्ध आहे Enterprise Xygeni प्लॅटफॉर्मसाठी एक ॲड-ऑन, आणि तुमच्या स्वतःच्या इन्फ्रास्ट्रक्चरमधील तुमच्या स्वतःच्या रिपॉझिटरीजवर एक स्कॅन चालतो.
FAQ
कोणते एंडपॉइंट्स संवेदनशील डेटा हाताळतात हे ते सांगू शकते का?
होय. झायजेनी एंडपॉइंट पॅरामीटर्स आणि रिस्पॉन्सेसमध्ये PII, PCI आणि PHI यांना फ्लॅग करते, आणि त्या वर्गीकरणाचा वापर करून वास्तविक एक्सपोजरनुसार निष्कर्षांना रँक देते.
ते प्रत्येक गोष्टीवर चालू शकते का? pull request?
होय. इन्क्रिमेंटल स्कॅनिंग केवळ बदललेल्या एंडपॉइंट्सचे विश्लेषण करते आणि त्यातून तयार होणारा मॅनफेस्ट नंतरच्या DAST स्कॅनला त्याच एंडपॉइंट्सवर केंद्रित करू शकतो, त्यामुळे स्टॅटिक आणि रनटाइम टेस्टिंग प्रत्यक्षात बदललेल्या गोष्टींशी सुसंगत राहतात.
माझा कोड माझ्या एनवायरनमेंटच्या बाहेर जातो का?
नाही. स्कॅन तुमच्या स्वतःच्या पायाभूत सुविधांमध्ये चालतात. फक्त निकालच अपलोड केले जातात, जे प्रवासात आणि संग्रहित स्थितीत सुरक्षित असतात.
मी API सुरक्षा कशी मिळवू?
एपीआय सुरक्षा या स्वरूपात उपलब्ध आहे Enterprise अॅड-ऑन. PoC साठी विनंती करा आणि त्याची व्याप्ती तुमच्यासोबत निश्चित केली जाईल.
