२६२-०००१७७-००१ API सुरक्षेसाठी OWASP टॉप १०

उत्पादन माहिती

तपशील

  • उत्पादनाचे नाव: २०२३ च्या API साठी OWASP टॉप १० साठी डेव्हलपर मार्गदर्शक
    सुरक्षा
  • आशय: API सुरक्षा चीट शीट, व्याख्या आणि तपशीलवार
    २०२३ च्या OWASP टॉप १० साठी API सुरक्षेसाठी मार्गदर्शक

उत्पादन वापर सूचना

एपीआय सुरक्षेचा परिचय

डेव्हलपर मार्गदर्शक यावर व्यापक माहिती प्रदान करते
२०२३ OWASP API सुरक्षेसाठी टॉप १०, सामान्य सुरक्षिततेवर प्रकाश टाकणारे
API सह अनुप्रयोग विकसित करताना जोखीम.

API सुरक्षा फसवणूक पत्रक

चीट शीटमध्ये API सुरक्षेच्या खालील श्रेणी सूचीबद्ध आहेत:
जोखीम:

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

विकसक मार्गदर्शक संपलाview

मार्गदर्शक प्रत्येक API सुरक्षा जोखीम श्रेणीमध्ये खोलवर जातो, प्रदान करतो
कसे सोडवायचे आणि कसे कमी करायचे याबद्दल तपशीलवार स्पष्टीकरण आणि मार्गदर्शन
हे धोके प्रभावीपणे टाळता येतील.

वारंवार विचारले जाणारे प्रश्न (FAQ)

प्रश्न: API सुरक्षा का महत्त्वाची आहे?

अ: एपीआय सुरक्षा अत्यंत महत्त्वाची आहे कारण एपीआय अनेकदा संवेदनशील डेटा उघड करतात.
आणि अनुप्रयोग तर्कशास्त्र, ज्यामुळे ते हल्लेखोरांचे प्रमुख लक्ष्य बनतात.
डेटा उल्लंघन रोखण्यासाठी API सुरक्षित करणे आवश्यक आहे आणि
एकूण प्रणाली सुरक्षा सुनिश्चित करणे.

प्रश्न: मी सुरक्षित API कसे लागू करू शकतो?

अ: सुरक्षित एपीआय अंमलात आणण्यासाठी, सर्वोत्तम पद्धतींचे अनुसरण करा जसे की
योग्य प्रमाणीकरण, अधिकृतता यंत्रणा, इनपुट प्रमाणीकरण,
संवेदनशील डेटाचे एन्क्रिप्शन, आणि नियमित सुरक्षा मूल्यांकन आणि
अद्यतने

"`

पांढरा कागद
API सुरक्षेसाठी २०२३ च्या OWASP टॉप १० साठी डेव्हलपर मार्गदर्शक

सामग्री

API सुरक्षा चीट शीट

5

व्याख्या

5

API1:2023–तुटलेली ऑब्जेक्ट लेव्हल ऑथोरायझेशन

7

API2:2023–तुटलेले प्रमाणीकरण

8

API3:2023–ब्रोकन ऑब्जेक्ट प्रॉपर्टी लेव्हल ऑथोरायझेशन

9

API4:2023–अप्रतिबंधित संसाधन वापर

11

API5:2023–तुटलेली फंक्शन लेव्हल ऑथोरायझेशन

13

API6:2023–संवेदनशील व्यवसाय प्रवाहांना अप्रतिबंधित प्रवेश

14

API7:2023–सर्व्हर साइड रिक्वेस्ट फोर्जरी

16

API8:2023–सुरक्षा चुकीची कॉन्फिगरेशन

18

API9:2023–अयोग्य इन्व्हेंटरी व्यवस्थापन

19

API10:2023–API चा असुरक्षित वापर

21

एपीआय सिक्युरिटी टॉप-१० पुरेसे नाही!

23

निष्कर्ष

23

API सुरक्षेसाठी २०२३ च्या OWASP टॉप १० साठी डेव्हलपर मार्गदर्शक

2/23

कंपन्यांनी क्लाउड-नेटिव्ह पायाभूत सुविधा आणि डेव्हऑप-शैलीच्या पद्धती स्वीकारल्या असल्याने, web अॅप्लिकेशन प्रोग्रामिंग इंटरफेस किंवा एपीआय वाढले आहेत. काही सर्वात लोकप्रिय सार्वजनिक एपीआयमध्ये असे समाविष्ट आहे जे डेव्हलपर्सना गुगल सर्च अॅक्सेस करण्यास, टिकटॉकवरून डेटा स्क्रॅप करण्यास, वाहनांचा मागोवा घेण्यास, स्पोर्ट्स स्कोअर गोळा करण्यास आणि लोकप्रिय साइट्सवरून इमेज डाउनलोडवर डेटा गोळा करण्यास अनुमती देतात. १. २०२३ मध्ये, एपीआय-संबंधित ट्रॅफिक सर्व डायनॅमिक - नॉन-कॅशेबल - ट्रॅफिकपैकी ५८ टक्के आहे, जे २०२१ च्या अखेरीस ५४ टक्के होते. २.
एंटरप्राइझ अॅप्लिकेशन्सना एकमेकांशी संवाद साधण्यासाठी आणि एकत्रित करण्यासाठी API हे एक मार्ग बनले आहेत. कंपन्या त्यांच्या अॅप्लिकेशन्सपैकी सुमारे दोन-तृतीयांश API (64%) भागीदारांशी जोडण्यासाठी वापरतात, तर सुमारे अर्धे (51%) मायक्रोसर्व्हिसेससाठी अॅक्सेस पॉइंट्स असतात. एकूणच, तीन-चतुर्थांश पेक्षा जास्त कंपन्या प्रत्येक अॅप्लिकेशनसाठी सरासरी किमान 25 API वापरतात.3
API-आधारित अनुप्रयोग पायाभूत सुविधांचा अवलंब करणे आश्चर्यकारक नाही: तृतीय-पक्ष विकासकांना आकर्षित करण्यासाठी आणि परिसंस्था तयार करण्यासाठी API स्वीकारणाऱ्या कंपन्यांची वाढ दिसून येते. चॅपमन विद्यापीठ आणि बोस्टन विद्यापीठातील संशोधकांनी २०२२ मध्ये केलेल्या एका पेपरनुसार, तंत्रज्ञानाभोवती अडथळे निर्माण करण्याच्या आणि काही क्षमता आणि डेटामध्ये खुल्या प्रवेशाची परवानगी देण्याच्या पारंपारिक संकल्पनांना उलटे करून, या "उलट्या कंपन्या" - तथाकथित कारण त्या API स्वीकारल्या नाहीत अशा कंपन्यांच्या तुलनेत दोन वर्षांत जवळजवळ १३ टक्के आणि १६ वर्षांत ३९ टक्के वाढल्या. ४
तथापि, मायक्रोसर्व्हिसेस, कंटेनरायझेशन आणि एपीआयचा अवलंब केल्याने असुरक्षित सॉफ्टवेअर घटक, खराब व्यवसाय तर्कशास्त्र आणि सदोष डेटा सुरक्षा असे विविध धोके येतात. दहापैकी नऊ संस्था (९२%) असुरक्षित एपीआयशी संबंधित किमान एक सुरक्षा घटना घडली आहे.५ मोठ्या कंपन्यांमध्ये सामान्यतः हजारो एपीआय असतात आणि त्या सिस्टीमवरील हल्ल्यांमुळे सुमारे २० टक्के सुरक्षा घटना घडतात, तर लहान कंपन्यांमध्ये शेकडो एपीआय असतात ज्यांच्या लहान हल्ल्याच्या पृष्ठभागावर सुरक्षा घटनांमध्ये पाच टक्के घटना घडतात.६ मार्श मॅकलेननच्या अंदाजानुसार, एपीआय भेद्यतेमुळे होणाऱ्या उल्लंघनांमुळे होणारे वार्षिक नुकसान जागतिक स्तरावर $४० अब्जपेक्षा जास्त आहे.७
१ अरेलानो, केली. टॉप ५० सर्वात लोकप्रिय एपीआय. रॅपिडएपीआय ब्लॉग. रॅपिडएपीआय. Web पान १६ मार्च २०२३.
२ ट्रेमांटे, मायकेल, आणि इतर. अनुप्रयोग सुरक्षा अहवाल: Q2 2. क्लाउडफ्लेअर ब्लॉग. क्लाउडफ्लेअर. ब्लॉग पोस्ट. २१ ऑगस्ट २०२३.
३ मार्क्स, मेलिंडा. एपीआय अटॅक सरफेस सुरक्षित करणे. एंटरप्राइझ स्ट्रॅटेजी ग्रुप. पालो अल्टो नेटवर्क्स द्वारे प्रायोजित. पीडीएफ रिपोर्ट, पृष्ठ १०. २३ मे २०२३.
४ बेंझेल, सेथ जी., इत्यादी. एपीआय फर्मला उलटे करून वाढ कशी निर्माण करतात. सोशल सायन्स रिसर्च नेटवर्क. रिसर्च पेपर. सुधारित: ३० डिसेंबर २०२२.
५ एपीआय अटॅक पृष्ठभाग सुरक्षित करणे. एंटरप्राइझ स्ट्रॅटेजी ग्रुप, पृष्ठ १४. ६ लेमोस, रॉबर्ट. एपीआय सुरक्षेमुळे एकूण अब्जावधींचे नुकसान झाले, परंतु ते गुंतागुंतीचे आहे. गडद वाचन.
बातमी लेख. ३० जून २०२२. ७ मार्श मॅकलेनन. एपीआय असुरक्षिततेच्या किंमतीचे प्रमाण निश्चित करणे. इम्पर्वा द्वारे प्रायोजित.
पीडीएफ अहवाल. २२ जून २०२२.

API सुरक्षेसाठी २०२३ च्या OWASP टॉप १० साठी डेव्हलपर मार्गदर्शक

3/23

२०२३ च्या एपीआय सिक्युरिटी टॉप-१० यादीमध्ये एपीआय उघड करणारे किंवा वापरणारे अॅप्लिकेशन विकसित करताना निर्माण होणारे दहा सर्वात सामान्य आणि गंभीर सुरक्षा धोके अधोरेखित केले आहेत.

ही समस्या इतकी गंभीर आहे की यूएस नॅशनल सिक्युरिटी एजन्सीने ऑस्ट्रेलियन सायबर सिक्युरिटी सेंटर (ACSC) आणि यूएस सायबरसुरक्षा आणि पायाभूत सुविधा सुरक्षा एजन्सी (CISA) सोबत मिळून API सुरक्षा समस्यांवर मार्गदर्शन केले, विशेषतः सर्वात सामान्य, ज्याला असुरक्षित डायरेक्ट ऑब्जेक्ट रेफरन्स (IDOR) भेद्यता म्हणून ओळखले जाते.8
आश्चर्याची गोष्ट नाही की, वाढत्या सुरक्षा चिंतेच्या पार्श्वभूमीवर, ओपन वर्ल्डवाइड अॅप्लिकेशन सिक्युरिटी प्रोजेक्ट (OWASP) ने त्यांच्या API सिक्युरिटी टॉप-१० यादीचे अपडेट जारी केले. २०१९ च्या पहिल्या यादीला रिफ्रेश करत, २०२३ च्या API सिक्युरिटी टॉप-१० यादीमध्ये API उघड करणारे किंवा वापरणारे अॅप्लिकेशन विकसित करताना निर्माण होणारे दहा सर्वात सामान्य आणि गंभीर सुरक्षा धोके हायलाइट केले आहेत. ब्रोकन ऑब्जेक्ट-लेव्हल ऑथोरायझेशन, एक सुपरसेट ज्यामध्ये IDOR भेद्यता समाविष्ट आहे, सारखे मुद्दे मागील यादीपेक्षा सारखेच आहेत. तरीही, नवीन श्रेणी - किंवा पुनर्गठित श्रेणी - आता सर्व्हर-साइड रिक्वेस्ट फोर्जरी (API10:2019) आणि संवेदनशील व्यवसाय प्रवाहांमध्ये अप्रतिबंधित प्रवेश (API2023:10) सारख्या भूतकाळात दुर्लक्षित केलेल्या समस्यांवर प्रकाश टाकतात.
"स्वभावाने, APIs अॅप्लिकेशन लॉजिक आणि वैयक्तिकरित्या ओळखण्यायोग्य माहिती (PII) सारख्या संवेदनशील डेटाचा पर्दाफाश करतात आणि यामुळे, APIs हल्लेखोरांचे लक्ष्य बनत आहेत," OWASP गटाने त्यांच्या घोषणेत म्हटले आहे.9 "सुरक्षित APIs शिवाय, जलद नवोपक्रम अशक्य होईल."

८ नवीन सायबरसुरक्षा सल्लागारांबद्दल चेतावणी देते Web अर्जातील भेद्यता. राष्ट्रीय सुरक्षा संस्था. प्रेस रिलीज. २७ जुलै २०२३.
९ ओपन वर्ल्डवाइड अॅप्लिकेशन सिक्युरिटी प्रोजेक्ट. OWASP API सिक्युरिटी टॉप १०: फॉरवर्ड. OWASP.org. Web पान ३ जुलै २०२३.

API सुरक्षेसाठी २०२३ च्या OWASP टॉप १० साठी डेव्हलपर मार्गदर्शक

4/23

API सुरक्षा चीट शीट

OWASP टॉप १० श्रेणी १. ब्रोकन ऑब्जेक्ट लेव्हल ऑथोरायझेशन २. ब्रोकन ऑथेंटिकेशन ३. ब्रोकन ऑब्जेक्ट प्रॉपर्टी लेव्हल ऑथोरायझेशन ४. अप्रतिबंधित संसाधन वापर ५. ब्रोकन फंक्शन लेव्हल ऑथोरायझेशन ६. संवेदनशील व्यवसाय प्रवाहांना अप्रतिबंधित प्रवेश ७. सर्व्हर साइड रिक्वेस्ट फोर्जरी ८. सुरक्षा चुकीचे कॉन्फिगरेशन ९. अयोग्य इन्व्हेंटरी व्यवस्थापन १०. API चा असुरक्षित वापर

सायबर सुरक्षा उपाय SAST SAST, DAST SAST, DAST SAST, DAST, Secure API व्यवस्थापक SAST DAST DAST SAST, DAST सुरक्षित API व्यवस्थापक SCA, SAST

व्याख्या
एपीआय एंडपॉइंट - दोन सिस्टीममधील संवादाचा बिंदू, सामान्यतः ए URL मायक्रोसर्व्हिस चालवणाऱ्या कंटेनर किंवा सर्व्हरचा. वापरणे URL, एखादा अॅप्लिकेशन किंवा डेव्हलपर सर्व्हरकडून माहिती मागू शकतो किंवा API सर्व्हर किंवा मायक्रोसर्व्हिसवर कृती करू शकतो.
API-संबंधित रहदारी - इंटरनेट ट्रॅफिक ज्यामध्ये HTTP किंवा HTTPS विनंती असते आणि XML किंवा JSON ची प्रतिसाद सामग्री असते, जी दर्शवते की डेटा अनुप्रयोगाकडे पाठवला जात आहे, सामान्यतः SOAP, WSDL, REST API किंवा gRPC द्वारे (खाली पहा).
डायनॅमिक अॅप्लिकेशन सिक्युरिटी टेस्टिंग (DAST) – इंटरफेस वापरून अॅप्लिकेशन किंवा API सर्व्हरचे विश्लेषण करण्याची प्रक्रिया, अॅप्लिकेशनसाठी वापरकर्ता इंटरफेस असो, web साठी पुढचा भाग web अर्ज, किंवा URLAPI एंडपॉइंट्ससाठी s. ब्लॅक-बॉक्स चाचणीच्या प्रकारात, हा दृष्टिकोन एखाद्या अ‍ॅप्लिकेशनवर आक्रमणकर्त्याप्रमाणेच हल्ला करून "बाहेरून आत" अ‍ॅप्लिकेशनचे मूल्यांकन करतो, सहसा अंतर्गत प्रक्रियांची माहिती नसताना.
स्टॅटिक अॅप्लिकेशन सिक्युरिटी टेस्टिंग (SAST) – अॅप्लिकेशन सिक्युरिटीचा एक दृष्टिकोन जो त्रुटी किंवा भेद्यतांच्या ओळखल्या जाणाऱ्या नमुन्यांसाठी स्त्रोत, बायनरी किंवा बाइट कोड स्कॅन करतो. कधीकधी व्हाईट-बॉक्स टेस्टिंग म्हणून ओळखले जाणारे, SAST "आत-बाहेर" दृष्टिकोन वापरते जे संभाव्य भेद्यता आणि त्रुटी ओळखते ज्या बाह्य आक्रमणकर्त्याद्वारे शोषण करण्यायोग्य असू शकतात किंवा नसू शकतात. हलके स्थिर साधने त्यांच्या IDE मधील विकासकांना रिअल-टाइम अभिप्राय प्रदान करू शकतात.

API सुरक्षेसाठी २०२३ च्या OWASP टॉप १० साठी डेव्हलपर मार्गदर्शक

5/23

ब्रोकन ऑब्जेक्ट लेव्हल ऑथोरायझेशन ही एक व्यापक आणि सहजपणे वापरता येणारी समस्या आहे web अनुप्रयोग कारण API कॉलमध्ये स्थिती माहिती असते. जर अनुप्रयोग वापरकर्त्याला API मध्ये एक ओळखकर्ता निर्दिष्ट करून कृती करण्याची परवानगी देतात तर ते असुरक्षित असतात, त्यांना त्या कृती करण्याची परवानगी आहे की नाही हे तपासल्याशिवाय.

SOAP/WSDL - तयार करण्यासाठी एक XML-आधारित प्रोटोकॉल Web API. SOAP हा प्रोटोकॉल स्वतः आहे आणि WSDL (Web (सेवा परिभाषा भाषा) ही सेवांचे औपचारिक वर्णन करण्यासाठी वापरली जाणारी स्वरूप आहे. जास्त ओव्हरहेडमुळे, ही API शैली नवीन विकासांसाठी अलोकप्रिय झाली आहे.
विश्रांती-अ Web HTTP च्या अर्थशास्त्राचा वापर करून, HTTP वरून थेट संदेशांची देवाणघेवाण करणारी API शैली. URLs आणि क्रियापदे, अतिरिक्त "लिफाफा" न वापरता. सामग्री सहसा JSON म्हणून एन्कोड केली जाते, जरी काही प्रकरणांमध्ये ती XML असते.
GraphQL – API मध्ये वापरण्यासाठी डिझाइन केलेली एक क्वेरी भाषा (JSON मध्ये विनंत्या आणि प्रतिसादांसह), या क्वेरी कार्यान्वित करण्यासाठी सर्व्हर-साइड रनटाइमसह. हे क्लायंटना आवश्यक असलेल्या डेटाची रचना परिभाषित करण्यास आणि नंतर त्या स्वरूपात सर्व्हरकडून प्राप्त करण्यास अनुमती देते.
gRPC – एक API प्रोटोकॉल जो REST पेक्षा जास्त कामगिरी करतो. तो HTTP/2 आणि कार्यप्रदर्शन अॅडव्हान्स वापरतो.tagHTTP/1.1 वर ऑफर करणारे es. वैयक्तिक संदेशांचे स्वरूप सहसा बायनरी असते आणि ProtoBuf वर आधारित असते, ज्यामुळे पुन्हा कार्यप्रदर्शन अॅडव्हान्स तयार होतेtagREST आणि SOAP पेक्षा जास्त आहे.

२०२३ API सुरक्षा टॉप १०

अॅनालॉगस २०१९ एपीआय सुरक्षा नोंद

API1:2023–तुटलेली ऑब्जेक्ट लेव्हल ऑथोरायझेशन

API1:2019–तुटलेली ऑब्जेक्ट लेव्हल ऑथोरायझेशन

API2:2023–तुटलेले प्रमाणीकरण

API2:2019–तुटलेले वापरकर्ता प्रमाणीकरण

API3:2023–ब्रोकन ऑब्जेक्ट प्रॉपर्टी लेव्हल ऑथोरायझेशन

API3:2019–अति डेटा एक्सपोजर, API6:2019–मास असाइनमेंट

API4:2023–अप्रतिबंधित संसाधन वापर

API4:2019–संसाधनांचा अभाव आणि दर मर्यादा

API5:2023–तुटलेली फंक्शन लेव्हल ऑथोरायझेशन

API5:2019–तुटलेली फंक्शन लेव्हल ऑथोरायझेशन

API6:2023–संवेदनशील व्यवसाय प्रवाहांना अप्रतिबंधित प्रवेश

API7:2023–सर्व्हर साइड रिक्वेस्ट फोर्जरी

API8:2023–सुरक्षा चुकीचे कॉन्फिगरेशन API7:2019–सुरक्षा चुकीचे कॉन्फिगरेशन

API9:2023–अयोग्य इन्व्हेंटरी व्यवस्थापन

API9:2019–अयोग्य मालमत्ता व्यवस्थापन

API10:2023–API चा असुरक्षित वापर

API8:2019–इंजेक्शन, API10:2019–अपुरा लॉगिंग आणि देखरेख

Source: https://owasp.org/API-Security/editions/2023/en/0x11-t10/ Source: https://owasp.org/API-Security/editions/2019/en/0x11-t10/

API सुरक्षेसाठी २०२३ च्या OWASP टॉप १० साठी डेव्हलपर मार्गदर्शक

6/23

डेव्हलपर्स आणि अॅप्लिकेशन-सुरक्षा टीमनी प्रमाणीकरणाद्वारे वापरकर्त्याची ओळख तपासण्यासाठी क्षमता योग्यरित्या अंमलात आणल्या पाहिजेत.

API1:2023–तुटलेली ऑब्जेक्ट लेव्हल ऑथोरायझेशन
ते काय आहे?
एपीआय प्रमाणित वापरून सेवा आणि डेटामध्ये प्रवेश करण्यास अनुमती देतात web विनंत्या. जेव्हा त्या मालमत्ता चांगल्या प्रकारे संरक्षित नसतात किंवा अधिकृतता नियंत्रणे खराबपणे अंमलात आणली जातात किंवा अनुपस्थित असतात तेव्हा कंपन्या त्यांच्या पायाभूत सुविधा आणि डेटा असुरक्षित थेट प्रवेशासाठी उघड करतात. ब्रोकन ऑब्जेक्ट लेव्हल ऑथोरायझेशन - ज्याला असुरक्षित डायरेक्ट ऑब्जेक्ट रेफरन्स (IDOR) असेही म्हणतात - डेटा प्रकटीकरणापासून ते संपूर्ण खाते ताब्यात घेण्यापर्यंत विविध धोके निर्माण करू शकते.
एखाद्या अॅप्लिकेशनला असुरक्षित कशामुळे बनवले जाते?
ही एक व्यापक आणि सहजपणे वापरता येणारी समस्या आहे web अनुप्रयोग. जर अनुप्रयोग वापरकर्त्याला API मध्ये आयडेंटिफायर निर्दिष्ट करून कृती करण्याची परवानगी देतात तर त्यांना त्या कृती करण्याची परवानगी आहे की नाही हे तपासल्याशिवाय ते असुरक्षित असतात.
माजी मध्येampOWASP द्वारे सविस्तर माहितीनुसार, ऑनलाइन स्टोअर्ससाठी एक प्लॅटफॉर्म एका साध्या कॉलचा वापर करून दुकानाच्या डेटामध्ये प्रवेश देऊ शकतो:
/ दुकाने/{ दुकानाचे नाव}/ महसूल _ डेटा.जेसन
हे असुरक्षित आहे कारण कोणताही वापरकर्ता shopName दुसऱ्या वापरकर्त्याच्या स्टोअरच्या नावाने बदलू शकतो, ज्यामुळे त्यांच्याकडे नसलेल्या डेटामध्ये प्रवेश मिळू शकतो.
हल्ला माजीampलेस
२०२१ मध्ये, एका सुरक्षा संशोधकाला असे आढळून आले की web-पेलोटन व्यायाम बाईकना डेटा प्रदान करणारे अॅप्लिकेशन आणि बॅक-एंड सर्व्हरमध्ये अनेक API एंडपॉइंट्स होते जे अनधिकृत वापरकर्त्यांना खाजगी डेटामध्ये प्रवेश करण्याची परवानगी देतात. फेब्रुवारी २०२१ मध्ये, पेलोटनने समस्येसाठी आंशिक निराकरण लागू केले, प्रमाणित वापरकर्त्यांसाठी API प्रवेश मर्यादित केला, परंतु तरीही त्या वापरकर्त्यांना इतर सदस्यांसाठी कोणताही खाजगी डेटा प्रवेश करण्याची परवानगी दिली. मे २०२१ मध्ये पूर्ण निराकरण झाले.१०
विकासक म्हणून ते कसे रोखायचे?
डेव्हलपर्स कडक नियंत्रणे लागू करून, खात्यांची गणना रोखण्यासाठी अप्रत्याशित वापरकर्ता ओळखकर्ता नियुक्त करून आणि डेटा स्रोतामध्ये प्रवेश करणाऱ्या प्रत्येक फंक्शनसाठी ऑब्जेक्ट-लेव्हल ऑथोरायझेशन तपासून ऑब्जेक्ट्समध्ये असुरक्षित प्रवेश रोखतात. अनवधानाने झालेल्या चुकांमुळे सुरक्षितता बिघडू शकते ही शक्यता दूर करण्यासाठी डेव्हलपर्सनी अशा तपासण्यांचा समावेश केला पाहिजे, विशेषतः जर ते वापरकर्त्याच्या इनपुटवर आधारित असतील. अॅप्लिकेशन-सुरक्षा आणि ऑपरेशन्स व्यावसायिकांना डेटा बॅकएंड करण्यासाठी प्रत्येक विनंतीसाठी अधिकृतता तपासणीची आवश्यकता असावी.
ओपनटेक्स्ट कशी मदत करू शकते?
OpenTextTM स्टॅटिक अॅप्लिकेशन सिक्युरिटी टेस्टिंग (SAST) आणि OpenTextTM डायनॅमिक अॅप्लिकेशन सिक्युरिटी टेस्टिंग (DAST) हे असुरक्षित डायरेक्ट ऑब्जेक्ट रेफरन्स (IDOR) श्रेणीमध्ये विविध प्रकारच्या भेद्यता शोधू शकतात. IDOR मध्ये डायरेक्टरी ट्रॅव्हर्सल सारख्या भेद्यता समाविष्ट असू शकतात, File अपलोड करा, आणि File समावेश. अधिक सामान्यतः, IDOR मध्ये भेद्यतेचे वर्ग देखील समाविष्ट असतात जिथे ओळखकर्ता
१० मास्टर्स, जानेवारी. टूर डी पेलोटन: वापरकर्ता डेटा उघडकीस आला. पेन टेस्ट पार्टनर्स ब्लॉग. पेन टेस्ट पार्टनर्स. Web पान ५ मे २०२१.

API सुरक्षेसाठी २०२३ च्या OWASP टॉप १० साठी डेव्हलपर मार्गदर्शक

7/23

डेव्हलपर्स आणि अॅप्लिकेशन-सुरक्षा टीमनी प्रमाणीकरणाद्वारे वापरकर्त्याची ओळख तपासण्यासाठी क्षमता योग्यरित्या अंमलात आणल्या पाहिजेत.

द्वारे सुधारित केले जाऊ शकते URL, बॉडी, किंवा हेडर मॅनिपुलेशन. ही प्रणाली डेव्हलपर्सना अशा प्रकरणांमध्ये सतर्क करेल जिथे वापरकर्ता डेटाबेस किंवा स्टोरेज कंटेनरसाठी API विनंतीमध्ये प्राथमिक की थेट निवडू शकतो, ही एक समस्या आहे जी बहुतेकदा या वर्गाच्या भेद्यतेकडे नेते. अपेक्षित अधिकृतता तपासणी गहाळ झाल्यास सिस्टम देखील चेतावणी देईल.
API2:2023–तुटलेले प्रमाणीकरण
ते काय आहे?
अधिकृतता तपासणी विशिष्ट भूमिका किंवा वापरकर्त्यांवर आधारित डेटावर प्रवेश मर्यादित करते, परंतु त्या मर्यादा सिस्टम, डेटा आणि सेवांचे संरक्षण करण्यासाठी पुरेशा नाहीत. डेव्हलपर्स आणि अॅप्लिकेशन-सुरक्षा संघांनी प्रमाणीकरणाद्वारे वापरकर्ता ओळख तपासण्यासाठी क्षमता योग्यरित्या अंमलात आणल्या पाहिजेत. प्रमाणीकरणाचे गंभीर स्वरूप असूनही, घटक बहुतेकदा खराबपणे अंमलात आणले जातात किंवा अयोग्यरित्या वापरले जातात - तुटलेल्या वापरकर्ता प्रमाणीकरणाचे मूळ कारण. तुटलेल्या वापरकर्ता प्रमाणीकरणामुळे हल्लेखोरांना असुरक्षित प्रमाणीकरण टोकनचा वापर करून किंवा अंमलबजावणीतील त्रुटींशी तडजोड करून इतर वापरकर्त्यांची ओळख तात्पुरती किंवा कायमची गृहीत धरण्याची क्षमता मिळते.
एखाद्या अॅप्लिकेशनला असुरक्षित कशामुळे बनवले जाते?
ही सामान्य आणि सहज वापरता येणारी समस्या उद्भवते कारण प्रमाणीकरण ही एक जटिल प्रक्रिया आहे जी गोंधळात टाकणारी असू शकते आणि व्याख्येनुसार, लोकांसमोर येते. डेव्हलपरच्या चुका आणि अॅप्लिकेशनच्या चुकीच्या कॉन्फिगरेशनमुळे आवश्यक तपासणीचा अभाव होऊ शकतो ज्यामुळे हल्लेखोरांना प्रमाणीकरण टाळता येते. जे डेव्हलपर विशिष्ट एंडपॉइंटसाठी प्रमाणीकरण लागू करण्यात अयशस्वी होतात किंवा कमकुवत प्रमाणीकरण यंत्रणेला परवानगी देतात ते अॅप्लिकेशन्सना क्रेडेन्शियल स्टफिंग, टोकन रिप्ले किंवा पासवर्ड स्निफिंग सारख्या विविध हल्ल्यांना सामोरे जातात.
हल्ला माजीampलेस
फेब्रुवारी ते जून २०२३ दरम्यान, क्रेडेन्शियल स्टफिंग हल्ल्यांनी कपड्यांचे विक्रेता हॉट टॉपिकला लक्ष्य केले, ज्याने त्यांच्या ग्राहकांना अज्ञात संख्येने खाती हॅक झाल्याचे सूचित केले. अज्ञात स्त्रोतांकडून मिळवलेल्या क्रेडेन्शियल्सचा वापर करून हल्लेखोर ग्राहकांची नावे, ईमेल पत्ते, ऑर्डर इतिहास, फोन नंबर आणि जन्माचे महिने आणि दिवस यासारख्या संवेदनशील वैयक्तिक डेटामध्ये प्रवेश करू शकले.११
फेब्रुवारी २०२२ मध्ये, चुकीच्या पद्धतीने कॉन्फिगर केलेल्या क्लाउड स्टोरेज बकेटमुळे ईमेल मार्केटिंग सेवा बीटल आय कडून १ जीबी संवेदनशील डेटा पासवर्ड संरक्षण किंवा एन्क्रिप्शनशिवाय राहिला. डेटामध्ये विविध पर्यटन संस्था आणि यूएस राज्यांनी गोळा केलेली संपर्क माहिती आणि पर्यटनाशी संबंधित माहिती समाविष्ट होती. १२ चुकीच्या पद्धतीने कॉन्फिगर केलेल्या प्रमाणीकरण यंत्रणेला ब्रोकन युजर ऑथेंटिकेशन श्रेणीचा एक प्रकार मानले जाते.
विकासक म्हणून ते कसे रोखायचे?
११ टॉलास, बिल. रिटेल चेन हॉट टॉपिकने क्रेडेन्शियल-स्टफिंग हल्ल्यांच्या लाटेचा खुलासा केला. ब्लीपिंग कॉम्प्युटर. बातमी लेख. १ ऑगस्ट २०२३.
१२ नायर, प्रजीत. यूएस मार्केटिंग प्लॅटफॉर्मद्वारे ७ दशलक्ष लोकांचा डेटा उघडकीस आला. आज डेटा उल्लंघन. आयएसएमजी नेटवर्क. ११ फेब्रुवारी २०२२.

API सुरक्षेसाठी २०२३ च्या OWASP टॉप १० साठी डेव्हलपर मार्गदर्शक

8/23

प्रमाणीकरणासाठी मानकीकरण हा तुमचा मित्र आहे. DevSecOps टीम्सनी अनुप्रयोगांसाठी एक किंवा मर्यादित संख्येने प्रमाणीकरण पद्धती तयार कराव्यात आणि डेव्हलपर्स सर्व मायक्रोसर्व्हिसेस आणि API मध्ये एकसमानपणे यंत्रणा अंमलात आणतील याची खात्री करावी.

प्रमाणीकरणासाठी मानकीकरण हा तुमचा मित्र आहे. DevSecOps टीम्सनी अनुप्रयोगांसाठी एक किंवा मर्यादित संख्येने प्रमाणीकरण पद्धती तयार कराव्यात आणि डेव्हलपर्स सर्व मायक्रोसर्व्हिसेस आणि API मध्ये एकसमानपणे यंत्रणा अंमलात आणतील याची खात्री करावी. कोणत्याही प्रमाणीकरण अंमलबजावणीचे पुन्हा पुनरावलोकन केले पाहिजे.viewअंमलबजावणी आणि संबंधित सुरक्षा नियंत्रणांची शुद्धता सुनिश्चित करण्यासाठी सध्या आवृत्ती ४,१३ वर असलेल्या OWASP अॅप्लिकेशन सिक्युरिटी व्हेरिफिकेशन स्टँडर्ड (ASVS) च्या संदर्भात संपादित. मानकांमधील कोणतेही विचलन - विशेषतः अनधिकृत एंडपॉइंट्सचे जाणूनबुजून केलेले प्रदर्शन - सुरक्षा पथकाने मूल्यांकन केले पाहिजे आणि केवळ मजबूत व्यवसाय आवश्यकता पूर्ण करण्यासाठीच परवानगी दिली पाहिजे.
ओपनटेक्स्ट कशी मदत करू शकते?
OAuth आणि JWT हे API अंमलात आणण्यासाठी वापरल्या जाणाऱ्या प्रमाणीकरणाचे दोन सर्वात सामान्य प्रकार आहेत आणि OpenText डायनॅमिक अॅप्लिकेशन सिक्युरिटी टेस्टिंगमध्ये अॅप्लिकेशन्समध्ये दोन्ही मानकांच्या कमकुवत अंमलबजावणीची तपासणी केली जाते, तसेच कस्टम ऑथेंटिकेशन अंमलबजावणीमध्ये येणाऱ्या चुकीच्या कॉन्फिगरेशन आणि CSRF आणि सेशन फिक्सेशन सारख्या असुरक्षित नमुन्यांची तपासणी केली जाते. OpenText द्वारे डायनॅमिक अॅप्लिकेशन सिक्युरिटी टूल (DAST) स्कॅनिंग हे प्रमाणीकरण भेद्यता शोधण्याचा एक उत्तम मार्ग आहे, विशेषतः API मध्ये.
ओपनटेक्स्ट स्टॅटिक अॅप्लिकेशन सिक्युरिटी टेस्टिंगमुळे खराब प्रमाणीकरणाशी संबंधित विस्तृत तपासणी देखील करता येते. स्टॅटिक अॅनालिसिस टूलमध्ये क्रेडेन्शियल लीकेजसारख्या सामान्य समस्यांसाठी शोध तसेच JWT टोकनमध्ये गहाळ संरक्षण दावे किंवा JWT हेडरमध्ये होणारे दावे यासारख्या अत्यंत API-विशिष्ट समस्यांचा समावेश आहे.
API3:2023–ब्रोकन ऑब्जेक्ट प्रॉपर्टी लेव्हल ऑथोरायझेशन
ते काय आहे?
ब्रोकन ऑब्जेक्ट प्रॉपर्टी लेव्हल ऑथोरायझेशन ही २०२३ च्या OWASP यादीतील एक नवीन श्रेणी आहे जी मागील यादीतील दोन श्रेणी एकत्र करते: एक्सेक्झिव्ह डेटा एक्सपोजर (API2023:3) आणि मास असाइनमेंट (API2019:6). ही समस्या वापरकर्त्याच्या अधिकृततेचे प्रमाणीकरण नसल्यामुळे - किंवा ऑब्जेक्ट-प्रॉपर्टी स्तरावर वापरकर्त्याच्या अयोग्य अधिकृततेमुळे - उद्भवते. API एंडपॉइंट्सने हे प्रमाणित केले पाहिजे की प्रत्येक वापरकर्त्याला ते प्रवेश करण्याचा किंवा बदलण्याचा प्रयत्न करत असलेल्या प्रत्येक मालमत्तेसाठी अधिकृतता आहे. समस्येचा गैरफायदा घेतल्याने अनधिकृत पक्षांकडून माहिती उघड होऊ शकते किंवा डेटामध्ये फेरफार होऊ शकतो.
एखाद्या अॅप्लिकेशनला असुरक्षित कशामुळे बनवले जाते?
सामान्य आणि वापरण्यास सोपी समस्या तेव्हा उद्भवते जेव्हा वापरकर्त्याला एखाद्या विशिष्ट ऑब्जेक्टच्या काही गुणधर्मांमध्ये प्रवेश करण्याची परवानगी असू शकते, जसे की ट्रॅव्हल अॅप्लिकेशनमध्ये खोली आरक्षित करणे, परंतु इतर नाही, जसे की खोलीची किंमत. जेव्हा वापरकर्ता API द्वारे एखाद्या ऑब्जेक्टच्या गुणधर्मांमध्ये प्रवेश करतो, तेव्हा अनुप्रयोगाने हे तपासले पाहिजे की वापरकर्ता:
· वस्तूच्या विशिष्ट गुणधर्मात प्रवेश मिळवण्यास सक्षम असावे.
१३ OWASP अॅप्लिकेशन सिक्युरिटी व्हेरिफिकेशन स्टँडर्ड. OWASP. गिटहब पेज. शेवटचा अ‍ॅक्सेस: १७ नोव्हेंबर २०२३.

API सुरक्षेसाठी २०२३ च्या OWASP टॉप १० साठी डेव्हलपर मार्गदर्शक

9/23

ब्रोकन ऑब्जेक्ट प्रॉपर्टी लेव्हल ऑथोरायझेशन ही २०२३ च्या OWASP यादीतील एक नवीन श्रेणी आहे जी मागील यादीतील दोन श्रेणी एकत्र करते: एक्सेक्झिव्ह डेटा एक्सपोजर (API2023:3) आणि मास असाइनमेंट (API2019:6).
ओपनटेक्स्ट™ स्टॅटिक अॅप्लिकेशन सिक्युरिटी टेस्टिंग डेटा फ्लो विश्लेषणाद्वारे जास्त डेटा एक्सपोजर आणि मास असाइनमेंट दोन्ही टाळण्यास मदत करते. ही प्रणाली खाजगी डेटाचे अनेक स्रोत हायलाइट करेल, जसे की व्हेरिएबल्सच्या नावांवर किंवा विशिष्ट API कॉलवर आधारित, आणि मास असाइनमेंटला परवानगी देणाऱ्या वस्तू ओळखेल.

(उल्लंघनांना पूर्वी अतिरेकी डेटा एक्सपोजर म्हणून ओळखले जात असे), आणि/किंवा
· ऑब्जेक्टचा विशिष्ट गुणधर्म बदलण्याची परवानगी आहे (काही अनुप्रयोग हे तपासण्यात अयशस्वी होतात कारण ते स्वयंचलितपणे मॅप करण्यासाठी फ्रेमवर्क वापरतात) web ऑब्जेक्ट फील्डसाठी पॅरामीटर्सची विनंती करा, ही समस्या मास असाइनमेंट म्हणून ओळखली जाते).
OWASP माजी मध्येampम्हणजे, ऑनलाइन व्हिडिओ प्लॅटफॉर्म वापरकर्त्याला व्हिडिओचे वर्णन बदलण्याची परवानगी देतो, अगदी ब्लॉक केलेल्या व्हिडिओचे देखील, परंतु वापरकर्त्याला 'ब्लॉक केलेले' गुणधर्म बदलण्याची परवानगी देऊ नये.
/api/व्हिडिओ/अपडेट _ व्हिडिओ ठेवा
{
"वर्णन": "मांजरींबद्दल एक मजेदार व्हिडिओ",
"ब्लॉक केलेले": खोटे
}
हल्ला माजीampलेस
जानेवारी २०२२ मध्ये, एका बग बाउंटी प्रोग्रामने ट्विटरमध्ये एक त्रुटी शोधून काढली ज्यामुळे वापरकर्त्याला ट्विटरच्या सिस्टममध्ये ईमेल पत्ता किंवा फोन नंबर सबमिट करण्याची परवानगी मिळाली, ज्यामुळे नंतर माहिती ज्या खात्याशी संबंधित होती ते नाव परत येईल.१४ एका अज्ञात हल्लेखोराने फोन नंबर आणि ईमेल पत्त्यांशी जोडलेल्या लाखो वापरकर्ता खात्यांची यादी तयार करण्यासाठी या त्रुटीचा वापर केला. कोणालाही दोन गुणधर्मांशी जोडण्याची परवानगी देऊन, ट्विटरने अनवधानाने छद्म नाव असलेल्या वापरकर्त्यांना अधिक विशिष्टपणे ओळखण्याची परवानगी दिली.
विकासक म्हणून ते कसे रोखायचे?
विशिष्ट ऑब्जेक्ट प्रॉपर्टीजमध्ये प्रवेश करण्याच्या किंवा बदलण्याच्या क्षमतेवर डेव्हलपर्सनी नेहमीच योग्य नियंत्रणे लागू केली पाहिजेत. प्रत्येक प्रॉपर्टीसह सामान्य डेटा स्ट्रक्चर परत करण्याऐवजी - जे बहुतेकदा to_json() आणि to_string() सारख्या सामान्य पद्धतींसह घडते - प्रोग्रामरने कोणती माहिती परत करावी याबद्दल खूप विशिष्ट असले पाहिजे. सुरक्षेचा अतिरिक्त उपाय म्हणून, अनुप्रयोगांनी स्कीमा-आधारित प्रतिसाद प्रमाणीकरण लागू केले पाहिजे जे API पद्धतींद्वारे परत केलेल्या सर्व डेटावर सुरक्षा नियंत्रणे लागू करते. प्रवेश किमान विशेषाधिकार तत्त्वांचे पालन केला पाहिजे, जर अगदी आवश्यक असेल तरच प्रवेशास परवानगी दिली पाहिजे.
ओपनटेक्स्ट कशी मदत करू शकते?
ओपनटेक्स्ट™ स्टॅटिक अॅप्लिकेशन सिक्युरिटी टेस्टिंग डेटा फ्लो विश्लेषणाद्वारे जास्त डेटा एक्सपोजर आणि मास असाइनमेंट दोन्ही टाळण्यास मदत करते. ही प्रणाली खाजगी डेटाचे अनेक स्रोत हायलाइट करेल, जसे की व्हेरिएबल्सच्या नावांवर किंवा विशिष्ट एपीआय कॉलवर आधारित, आणि मास असाइनमेंटला परवानगी देणाऱ्या वस्तू ओळखेल. वापरकर्ते त्यांचे स्वतःचे स्रोत देखील परिभाषित करू शकतात, प्रोग्रामद्वारे डेटा ट्रॅक करू शकतात आणि जर ते अयोग्य ठिकाणी संपले तर, विकासक किंवा ऑपरेटरला जोखीमची सूचना देऊ शकतात.

१४ ट्विटरवरील काही खाती आणि खाजगी माहितीवर परिणाम करणारी घटना. ट्विटर प्रायव्हसी सेंटर. ट्विटर. Web पान ५ ऑगस्ट २०२२.

API सुरक्षेसाठी २०२३ च्या OWASP टॉप १० साठी डेव्हलपर मार्गदर्शक

10/23

विनंती पूर्ण करण्यासाठी नियुक्त केलेल्या संसाधनांवर मर्यादा न घालणारे अनुप्रयोग असुरक्षित असू शकतात, ज्यामध्ये वाटप करण्यायोग्य मेमरी, संख्या प्रतिबंधित करण्यात अयशस्वी होणारे अनुप्रयोग समाविष्ट आहेत. fileइतर गुणधर्मांसह, प्रवेश केलेल्या प्रक्रिया किंवा विनंत्यांची अनुमत दर.

याव्यतिरिक्त, ओपनटेक्स्ट SAST ला सर्वात महत्त्वाच्या JSON आणि XML सिरीयलायझेशन आणि डिसीरियलायझेशन यंत्रणेचे ज्ञान आहे. याचा वापर करून, हे टूल डोमेन ट्रान्सफर ऑब्जेक्ट्स (DTOs) योग्यरित्या डिसीरियलायझेशन न करणारा कोड शोधू शकते, ज्यामुळे त्याच्या गुणधर्मांचे मोठ्या प्रमाणात असाइनमेंट होऊ शकते. ओपनटेक्स्ट डायनॅमिक अॅप्लिकेशन सिक्युरिटी टेस्टिंग वापरून माहिती एक्सपोजर आणि मास असाइनमेंटची काही प्रकरणे देखील शोधली जाऊ शकतात. शेवटी, नियम जोडून काही प्रतिकारक उपाय लागू केले जाऊ शकतात. web अॅप्लिकेशन फायरवॉल (WAF).
API4:2023–अप्रतिबंधित संसाधन वापर
ते काय आहे?
API अनेक उपयुक्त व्यवसाय कार्ये उघड करतात. हे करण्यासाठी, ते डेटाबेस सर्व्हर सारख्या संगणकीय संसाधनांचा वापर करतात किंवा ऑपरेशनल तंत्रज्ञानाद्वारे भौतिक घटकांमध्ये प्रवेश करू शकतात. API कॉलला प्रतिसाद देण्यासाठी सिस्टमकडे मर्यादित संसाधनांचा संच असल्याने, हल्लेखोर विशेषतः अशा परिस्थिती निर्माण करण्यासाठी विनंत्या तयार करू शकतात ज्यामुळे संसाधनांचा थकवा, सेवा नाकारणे किंवा व्यवसाय खर्च वाढतो. बर्‍याच प्रकरणांमध्ये, हल्लेखोर API विनंत्या पाठवू शकतात ज्या महत्त्वपूर्ण संसाधनांना बांधतात, मशीन किंवा बँडविड्थ संसाधनांना जास्त प्रमाणात व्यापतात आणि परिणामी सेवा नाकारण्याचा हल्ला होतो. वेगवेगळ्या IP पत्त्यांवरून किंवा क्लाउड उदाहरणांवरून वारंवार विनंत्या पाठवून, हल्लेखोर वापरात संशयास्पद स्पाइक्स शोधण्यासाठी डिझाइन केलेल्या संरक्षणांना बायपास करू शकतात.
एखाद्या अॅप्लिकेशनला असुरक्षित कशामुळे बनवले जाते?
API विनंत्या प्रतिसादांना ट्रिगर करतात. त्या प्रतिसादांमध्ये डेटाबेसमध्ये प्रवेश करणे, I/O करणे, गणना चालवणे किंवा (वाढत्या प्रमाणात) मशीन-लर्निंग मॉडेलमधून आउटपुट जनरेट करणे समाविष्ट असले तरीही, API संगणकीय, नेटवर्क आणि मेमरी संसाधने वापरतात. आक्रमणकर्ता सेवा नाकारण्याच्या (DoS) हल्ल्याचा भाग म्हणून एंडपॉइंटवर API विनंत्या पाठवू शकतो जो बँडविड्थ - व्हॉल्यूमेट्रिक DoS हल्ल्याचे ध्येय - वर जाण्याऐवजी CPU, मेमरी आणि क्लाउड संसाधने संपवतो. विनंती पूर्ण करण्यासाठी नियुक्त केलेल्या संसाधनांना मर्यादित न करणारे अनुप्रयोग असुरक्षित असू शकतात, ज्यामध्ये वाटप करण्यायोग्य मेमरी प्रतिबंधित करण्यात अयशस्वी होणारे अनुप्रयोग, संख्या fileइतर गुणधर्मांसह, प्रवेश केलेल्या प्रक्रिया किंवा विनंत्यांची अनुमत दर.
मेमरी आणि वर्कलोडचे जास्त वाटप, API-ट्रिगर केलेल्या ऑपरेशन्ससाठी जास्त विनंत्या किंवा खर्च मर्यादा नसलेल्या तृतीय-पक्ष सेवेसाठी जास्त शुल्क टाळण्यासाठी सर्व्हर प्रोसेसिंग API मध्ये मर्यादा असणे आवश्यक आहे.
एक सामान्य हल्ला म्हणजे API एंडपॉइंटला पाठवलेले युक्तिवाद सुधारणे, जसे की प्रतिसादाचा आकार वाढवणे आणि पहिल्या दहा नोंदींऐवजी लाखो डेटाबेस नोंदींची विनंती करणे:
/एपीआय/वापरकर्ते?पृष्ठ=१&आकार=१००००००
याव्यतिरिक्त, जर हल्लेखोर वापरासाठी शुल्क आकारणाऱ्या बॅकएंड सेवेमध्ये प्रवेश करू शकत असेल, तर अनुप्रयोग मालकासाठी शुल्क वाढविण्यासाठी संसाधन वापर हल्ल्यांचा वापर केला जाऊ शकतो. आणखी एक OWASP माजीampले एका रिसेट-पासवर्ड वैशिष्ट्याकडे निर्देश करते जे ओळख पडताळण्यासाठी एसएमएस मजकूर संदेश वापरते आणि ज्याला हजारो वेळा कॉल करून पीडितेचा खर्च वाढवता येतो.

API सुरक्षेसाठी २०२३ च्या OWASP टॉप १० साठी डेव्हलपर मार्गदर्शक

11/23

नेटवर्कच्या काठावर कंटेंट डिलिव्हरी नेटवर्क्स (CDNs) वापरून फिल्टरिंग करणे web अॅप्लिकेशन फायरवॉल (WAFs) वैयक्तिक वापरकर्त्यांवर होणारा परिणाम कमीत कमी करताना ट्रॅफिक फ्लड कमी करू शकतात.

पोस्ट /एसएमएस /पाठवा _ रीसेट _ पास _ कोड
होस्ट: willyo.net {
“फोन _ नंबर”: “६५०१११३४३४” }
हल्ला माजीampलेस
संसाधन-वापराचे हल्ले बहुतेकदा कामगिरी आणि उपलब्धतेच्या समस्यांसह एकत्रित केले जात असल्याने, लक्ष्यित कंपन्या त्यांना व्यवसाय करण्याच्या खर्चाचा भाग म्हणून मानतात, ज्या घटनांची तक्रार करणे आवश्यक आहे त्याऐवजी, ज्यामुळे धोक्यात दृश्यमानता कमी होते. २०२२ मध्ये, अॅप्लिकेशन-लेयर डिस्ट्रिब्युटेड-डिनायलऑफ-सर्व्हिस (DDoS) हल्ले, API संसाधन वापर हल्ल्यांचा एक सुपरसेट, सर्व हल्ल्यांच्या वाट्याला कमी झाले, परंतु २०२२ च्या चौथ्या तिमाहीत मागील वर्षीच्या त्याच तिमाहीपेक्षा ७९% जास्त हल्ले झाले.१५
२०१५ मध्ये वर्णन केलेल्या एका हल्ल्यात, एका डेव्हलपरला एक अँड्रॉइड क्लायंट आढळला जो त्यांच्या साइटच्या Web यादृच्छिकपणे जनरेट केलेल्या API कीसह API, ज्यामुळे सेवा नाकारण्याचा हल्ला होतो. डेव्हलपरने असा अंदाज लावला की Android डिव्हाइसवर स्थापित केलेला एक दुर्भावनापूर्ण अनुप्रयोग 64-बिट API कीचा अंदाज घेण्याचा प्रयत्न करत आहे.16
विकासक म्हणून ते कसे रोखायचे?
दर मर्यादा आणि थ्रेशोल्ड वापरून, बहुतेक संसाधनांच्या वापराचे हल्ले कमी केले जाऊ शकतात, जरी कायदेशीर रहदारी खराब बांधलेल्या संरक्षणामुळे देखील प्रभावित होऊ शकते. विशिष्ट मर्यादा यावर सेट केल्या पाहिजेत:
· मेमरी वाटप
· प्रक्रिया
· क्लाउड उदाहरणे
· अपलोड केले file वर्णनकर्ते आणि file आकार
· रेकॉर्ड परत केले
· तृतीय-पक्ष सेवांना केलेल्या सशुल्क व्यवहारांची संख्या
· येणारे सर्व पॅरामीटर्स (उदा., स्ट्रिंग लांबी, अ‍ॅरे लांबी, इ.)
· विशिष्ट वेळेत प्रति क्लायंट API परस्परसंवादांची संख्या
नेटवर्कच्या काठावर कंटेंट डिलिव्हरी नेटवर्क्स (CDNs) वापरून फिल्टरिंग करणे web अॅप्लिकेशन फायरवॉल (WAFs) ट्रॅफिक फ्लड कमी करू शकतात आणि वैयक्तिक वापरकर्त्यांवर होणारा परिणाम कमी करू शकतात. अॅप्लिकेशन डिलिव्हरी प्लॅटफॉर्म मेमरी, CPU आणि प्रक्रियांवरील मर्यादांसह सोपे फिल्टरिंग करण्यास अनुमती देतात.
१५ योआचिमिक, ओमर. २०२२ च्या चौथ्या तिमाहीसाठी क्लाउडफ्लेअर डीडीओएस धोक्याचा अहवाल. क्लाउडफ्लेअर ब्लॉग. Web पान १० जानेवारी २०२३.
१६ वर हॅक/डॉस हल्ला कसा थांबवायचा web एपीआय. स्टॅकओव्हरफ्लो. Web पान. १५ सप्टेंबर २०१५.

API सुरक्षेसाठी २०२३ च्या OWASP टॉप १० साठी डेव्हलपर मार्गदर्शक

12/23

ओपनटेक्स्ट डायनॅमिक अॅप्लिकेशन सिक्युरिटी टेस्टिंग सेवेवर परिणाम न करता डिनायल ऑफ-सर्व्हिस हल्ल्याच्या भेद्यतेसाठी सर्व्हर आणि एपीआय फंक्शन्सची चाचणी करू शकते. याव्यतिरिक्त, DAST स्कॅन चालवण्याची कृती संभाव्य संसाधन-वापर कमकुवतपणा दर्शविण्याइतपत वातावरणाची चाचणी करू शकते.

ओपनटेक्स्ट कशी मदत करू शकते?
ओपनटेक्स्ट SAST आणि ओपनटेक्स्ट डायनॅमिक अॅप्लिकेशन सिक्युरिटी टेस्टिंगसह, DevSecOps टीम्स रिसोर्स एक्झॉशन हल्ल्यांसाठी त्यांच्या कोड आणि पायाभूत सुविधांची लवचिकता तपासू शकतात. ओपनटेक्स्ट SAST अनेक क्षेत्रे शोधू शकते जिथे हल्लेखोर अत्यधिक रिसोर्स वापर निर्माण करण्यासाठी अॅप्लिकेशन लॉजिकचा गैरवापर करू शकतो.
अनुप्रयोगातील या समस्येचे निराकरण करण्यासाठी कोड-स्तरीय सुरक्षा पुरेशी नाही. संसाधन थकवा आणि दर मर्यादा हे सेवा नाकारण्याच्या हल्ल्यांचे विशिष्ट उप-विभाग आहेत जे रनटाइमवर कमी केले पाहिजेत. ओपनटेक्स्ट डायनॅमिक अनुप्रयोग सुरक्षा चाचणी सेवेवर परिणाम न करता सेवा नाकारण्याच्या हल्ल्याच्या असुरक्षिततेसाठी सर्व्हर आणि API फंक्शन्सची चाचणी करू शकते. याव्यतिरिक्त, DAST स्कॅन चालवण्याची कृती संभाव्य संसाधन-वापर कमकुवतपणा दर्शविण्याइतपत वातावरणाची चाचणी करू शकते.
API5:2023–तुटलेली फंक्शन लेव्हल ऑथोरायझेशन
ते काय आहे?
आधुनिक अॅप्लिकेशनमध्ये डेटा अॅक्सेस करणे, तयार करणे, हाताळणे, हटवणे आणि व्यवस्थापित करणे अशी अनेक वेगवेगळी फंक्शन्स आहेत. प्रत्येक अॅप्लिकेशन वापरकर्त्याला प्रत्येक फंक्शन किंवा सर्व डेटा अॅक्सेस करण्याची आवश्यकता नसते आणि कमीत कमी विशेषाधिकाराच्या तत्त्वानुसार त्याला परवानगी दिली जाऊ नये. प्रत्येक API एंडपॉइंटमध्ये एक उद्देशित प्रेक्षक असतो ज्यामध्ये अनामिक, नियमित गैर-विशेषाधिकारित आणि विशेषाधिकारित वापरकर्ते समाविष्ट असू शकतात. प्रशासकीय आणि व्यवस्थापन फंक्शन्सना विशेषाधिकारित अधिकृतता आवश्यक असते, परंतु कधीकधी ते गैर-अधिकृत वापरकर्त्याकडून कायदेशीर API कॉलद्वारे प्रवेशयोग्य असतात - ब्रोकन फंक्शन लेव्हल ऑथोरायझेशनचे मूळ. वेगवेगळ्या पदानुक्रमांमुळे, गटांमुळे आणि भूमिकांमुळे अॅक्सेस नियंत्रणांमध्ये गुंतागुंत निर्माण होते, अॅप्लिकेशन फंक्शन्सना त्यांना कोण कॉल करू शकते यावर योग्य निर्बंध नसू शकतात.
एखाद्या अॅप्लिकेशनला असुरक्षित कशामुळे बनवले जाते?
विशिष्ट फंक्शन्सना प्रशासकीय कामे करण्यास अनुमती देणारे अॅप्लिकेशन्स सुरक्षित पद्धतीने त्या फंक्शन्समध्ये प्रवेश प्रतिबंधित करू शकत नाहीत. अशा फंक्शन्सना थेट मॅप करणारे API त्या कमकुवतपणाचा गैरफायदा घेतील. अॅप्लिकेशनच्या प्रमाणीकरण आणि अधिकृतता यंत्रणेचा वापर न करणारी फंक्शन्स संभाव्य सुरक्षा कमकुवतपणा मानली पाहिजेत.
माजी मध्येampOWASP द्वारे उद्धृत केलेल्या माहितीनुसार, आक्रमणकर्त्याला नवीन मोबाइल अनुप्रयोगात आमंत्रित वापरकर्त्याला जोडण्यासाठी API विनंत्यांमध्ये प्रवेश मिळतो, कारण आमंत्रणात आमंत्रित व्यक्तीच्या भूमिकेबद्दल माहिती असते. कमकुवतपणाचा फायदा घेत, आक्रमणकर्त्याने नवीन आमंत्रण पाठवले:
पोस्ट /एपीआय/आमंत्रणे/नवीन
{
“ईमेल”: “attacker@somehost.com”,
“भूमिका”:”प्रशासक”
} यामुळे त्यांना सिस्टमवर प्रशासकीय विशेषाधिकार मिळू शकतात.

API सुरक्षेसाठी २०२३ च्या OWASP टॉप १० साठी डेव्हलपर मार्गदर्शक

13/23

DevSecOps टीम्सनी अधिकृतता आणि प्रमाणीकरणासाठी एक मानक दृष्टिकोन तयार केला पाहिजे जो डीफॉल्टनुसार विनंत्यांना प्रवेश प्रतिबंधित करतो, "सर्व नाकारा" ची डीफॉल्ट अंमलबजावणी करतो.
अॅप्लिकेशन कंट्रोल आणि लॉजिक फ्लो हे कोणत्याही ऑनलाइन व्यवसायाचे हृदय असते आणि कंपन्या त्यांचे अधिकाधिक ऑपरेशन्स क्लाउडवर हलवतात तेव्हा ते फ्लो उघड होऊ शकतात आणि त्यांचा गैरफायदा घेतला जाऊ शकतो. या अतिरेकी अॅक्सेसमुळे व्यवसायाला हानी पोहोचू शकते.

हल्ला माजीampलेस
२०२२ मध्ये, टेक्सास विमा विभागाने जनतेला सूचित केले की कामगार भरपाई अर्जाच्या एका भागाद्वारे सुमारे दोन दशलक्ष टेक्सासवासीयांची माहिती उघडकीस आली आहे ज्यामुळे अनवधानाने जनतेच्या सदस्यांना संरक्षित डेटामध्ये प्रवेश मिळाला. १७ २०२२ मध्ये दुसऱ्या घटनेत, ऑस्ट्रेलियन टेलिकम्युनिकेशन फर्म ऑप्टसने कबूल केले की सुमारे १ कोटी ऑस्ट्रेलियन लोकांची वैयक्तिक आणि खाते माहिती एका API द्वारे उघडकीस आली होती ज्याला कोणत्याही प्रमाणीकरणाची किंवा अधिकृततेची आवश्यकता नव्हती. ऑप्टसने या हल्ल्याला "अत्याधुनिक" म्हटले असले तरी, हल्ल्याच्या तपशीलांशी परिचित असलेल्या एका सुरक्षा संशोधकाने ते "क्षुल्लक" म्हणून वर्णन केले. १८
विकासक म्हणून ते कसे रोखायचे?
DevSecOps टीम्सनी प्रमाणीकरण आणि अधिकृततेसाठी एक मानक दृष्टिकोन तयार केला पाहिजे जो डीफॉल्टनुसार विनंत्यांमध्ये प्रवेश रोखतो, "सर्व नाकारा" चे डीफॉल्ट लागू करतो. या डीफॉल्टवरून, भूमिका/गट/वापरकर्त्यांसाठी प्रवेश निश्चित करताना नेहमीच किमान विशेषाधिकाराचे तत्व लागू करा. विकासकांनी प्रत्येक API एंडपॉइंटशी संबंधित सर्व संबंधित HTTP क्रियापद/पद्धतींसाठी (उदा., POST, GET, PUT, PATCH, DELETE) प्रमाणीकरण आणि अधिकृतता योग्य आहे याची खात्री करावी. असंबद्ध क्रियापदांना परवानगी नाकारली पाहिजे. याव्यतिरिक्त, विकासकांनी प्रशासकीय प्रवेश आणि व्यवस्थापनासाठी बेस क्लास लागू करावा, क्लास इनहेरिटन्स वापरून खात्री करावी की अधिकृतता नियंत्रणे प्रवेश देण्यापूर्वी वापरकर्त्याची भूमिका तपासतात. सर्व गंभीर प्रशासकीय कार्यांनी विशेषाधिकार वाढ रोखण्यासाठी अधिकृतता यंत्रणा वापरावी.
ओपनटेक्स्ट कशी मदत करू शकते?
ओपनटेक्स्टटीएम स्टॅटिक अ‍ॅप्लिकेशन सिक्युरिटी टेस्टिंगच्या स्टॅटिक कोड आणि एपीआय विश्लेषण वैशिष्ट्यांना ओपनटेक्स्ट डायनॅमिक अ‍ॅप्लिकेशन सिक्युरिटी टेस्टिंग (डीएएसटी) सूटच्या रनटाइम तपासणीसह एकत्रित करून, डेव्हसेकऑप्स टीम्स त्यांच्या तुटलेल्या फंक्शन-लेव्हल ऑथोरायझेशन समस्यांसाठी अनुप्रयोगाचे मूल्यांकन करू शकतात आणि तैनात करण्यापूर्वी सुरक्षा कमकुवतपणासाठी उत्पादन कोडची सतत चाचणी करू शकतात. ब्रोकन ऑब्जेक्ट फंक्शन ऑथोरायझेशन समस्या शोधण्यासाठी, ओपनटेक्स्टटीएम स्टॅटिक अ‍ॅप्लिकेशन सिक्युरिटी टेस्टिंग विशिष्ट प्रोग्रामिंग भाषा आणि फ्रेमवर्कमध्ये अधिकृतता तपासणी कधी अपेक्षित असेल आणि अशा तपासणीची अनुपस्थिती कधी नोंदवली जाईल हे निर्दिष्ट करणारे नियम वापरते.
API6:2023–संवेदनशील व्यवसाय प्रवाहांना अप्रतिबंधित प्रवेश
ते काय आहे?
स्नीकरबॉट्सपासून ते तिकीट बॉट्सपर्यंत, ऑनलाइन किरकोळ विक्रेत्यांच्या API द्वारे त्यांच्या इन्व्हेंटरीवर होणारे हल्ले ई-कॉमर्स साइट्ससाठी एक महत्त्वाची समस्या बनली आहे. व्यवसाय मॉडेल आणि अनुप्रयोग तर्क समजून घेऊन, हल्लेखोर API कॉलची मालिका तयार करू शकतो जे स्वयंचलितपणे आरक्षित किंवा खरेदी करू शकतात.
१७ बीफरमन, जेसन. विमा विभागाच्या दाव्यांसह १.८ दशलक्ष टेक्सासवासीयांची वैयक्तिक माहिती वर्षानुवर्षे उघड झाली होती, असे ऑडिटमध्ये म्हटले आहे. द टेक्सास ट्रिब्यून. १७ मे २०२२.
१८ टेलर, जोश. ऑप्टस डेटा उल्लंघन: काय घडले याबद्दल आम्हाला आतापर्यंत माहित असलेली प्रत्येक गोष्ट. द गार्डियन. २८ सप्टेंबर २०२२.

API सुरक्षेसाठी २०२३ च्या OWASP टॉप १० साठी डेव्हलपर मार्गदर्शक

14/23

संवेदनशील व्यवसाय प्रवाहांना अनिर्बंध प्रवेश रोखणे हे अनुप्रयोग सुरक्षेसाठी समग्र दृष्टिकोनाबद्दल अधिक आहे आणि विशिष्ट तंत्रज्ञान शोधण्याबद्दल कमी आहे.

इन्व्हेंटरी, अशा प्रकारे इतर, कायदेशीर ग्राहकांना व्यवसायांच्या उत्पादनांमध्ये किंवा सेवांमध्ये प्रवेश मिळविण्यापासून रोखते. व्यवसाय प्रक्रियेत प्रवेश करण्यास अनुमती देणारे कोणतेही API आक्रमणकर्त्याद्वारे व्यवसायावर परिणाम करण्यासाठी वापरले जाऊ शकते आणि ते संवेदनशील व्यवसाय प्रवाहांमध्ये अप्रतिबंधित प्रवेशाच्या व्याख्येत येते.
एखाद्या अॅप्लिकेशनला असुरक्षित कशामुळे बनवले जाते?
अॅप्लिकेशन कंट्रोल आणि लॉजिक फ्लो हे कोणत्याही ऑनलाइन व्यवसायाचे हृदय असते आणि कंपन्या त्यांचे अधिकाधिक ऑपरेशन्स क्लाउडवर हलवतात तेव्हा ते फ्लो उघड होऊ शकतात आणि त्यांचा गैरफायदा घेतला जाऊ शकतो. जेव्हा हल्लेखोर उत्पादनांची खरेदी स्वयंचलित करतात, टिप्पण्या देण्यासाठी बॉट्स तयार करतात आणि पुन्हा वापरतात तेव्हा या अत्यधिक प्रवेशामुळे व्यवसायाला हानी पोहोचू शकते.views, किंवा वस्तू किंवा सेवांचे आरक्षण स्वयंचलित करा.
जर एखादा अॅप्लिकेशन असा एंडपॉइंट देत असेल ज्याला एंडपॉइंटमागील व्यवसाय ऑपरेशन्समध्ये प्रवेश मर्यादित न करता कंपनीच्या व्यवसाय प्रवाहात प्रवेश असेल, तर तो अॅप्लिकेशन असुरक्षित असेल. संरक्षणांमध्ये फिंगरप्रिंटिंगद्वारे एकाच डिव्हाइसवरून प्रवेश प्रयत्नांची संख्या मर्यादित करणे, क्रियाकलाप मानवी अभिनेत्याकडून उद्भवतो की नाही हे शोधणे आणि ऑटोमेशनचा समावेश आहे की नाही हे शोधणे समाविष्ट आहे.
हल्ला माजीampलेस
नोव्हेंबर २०२२ मध्ये जेव्हा टेलर स्विफ्टची तिकिटे तिकीटमास्टरवर विक्रीसाठी आली तेव्हा १.५ दशलक्ष ग्राहकांनी पूर्व-नोंदणी केली होती, परंतु १.४ कोटींहून अधिक विनंत्या होत्या - ज्यात बॉट ट्रॅफिकच्या तिप्पट समावेश होता - swampतिकीट विक्री सुरू होताच खरेदी लिंक्स आणि API डाउनलोड केले. साइट क्रॅश झाली, ज्यामुळे अनेक ग्राहकांना तिकीट खरेदी करता आले नाही.19
पुनर्विक्रेता बॉट्सचा हल्ला नोव्हेंबर २०२० मध्ये प्लेस्टेशन ५ च्या लाँचिंगला उद्ध्वस्त करणाऱ्यांसारखाच होता. नवीनतम सोनी गेमिंग कन्सोल लाँच होण्यापूर्वी पुरवठा-साखळीच्या समस्यांमुळे आधीच पुरवठा मर्यादित होता, परंतु स्वयंचलित बॉट्समुळे उपलब्ध युनिट्स शोधणे आणखी कठीण झाले आणि त्यामुळे पुनर्विक्रीच्या किमती प्रचंड वाढल्या. एका ई-कॉमर्स साइटच्या बाबतीत, "कार्टमध्ये जोडा" व्यवहारांची संख्या प्रति तास सरासरी १५,००० विनंत्यांवरून २७ दशलक्षांहून अधिक झाली, स्टोअरच्या API चा वापर करून SKU क्रमांकाद्वारे थेट उत्पादनांची विनंती केली.२०
विकासक म्हणून ते कसे रोखायचे?
बिझनेस-फ्लोमध्ये संभाव्य दुर्भावनापूर्ण प्रवेशाच्या समस्या सोडवण्यासाठी डेव्हलपर्सनी बिझनेस-ऑपरेशन आणि इंजिनिअरिंग टीम्ससोबत काम करावे. बिझनेस टीम्स एपीआयद्वारे कोणते फ्लो उघड होतात हे ओळखू शकतात आणि हल्लेखोर त्या एंडपॉइंट्सचा कसा गैरवापर करू शकतात हे ठरवण्यासाठी धोक्याचे विश्लेषण करू शकतात. दरम्यान, डेव्हलपर्सनी डेव्हऑप्स टीमचा भाग म्हणून इंजिनिअरिंग ऑपरेशन्ससोबत काम करावे जेणेकरून ऑटोमेटेड ब्राउझर इंस्टन्सना जबरदस्त होण्यापासून रोखण्यासाठी डिव्हाइस फिंगरप्रिंटिंग वापरणे आणि मानवी आणि मशीन अ‍ॅक्टर्समध्ये फरक करणाऱ्या वर्तनातील नमुने ओळखणे यासारखे अतिरिक्त तांत्रिक संरक्षणात्मक उपाय स्थापित करता येतील.
१९ स्टील, बिली. तिकीटमास्टरला माहित आहे की त्यात बॉटची समस्या आहे, पण काँग्रेसने ती दुरुस्त करावी अशी त्याची इच्छा आहे. एनगॅजेट. बातम्यांचा लेख. २४ जानेवारी २०२३.
२० मुवंडी, तफारा आणि वॉरबर्टन, डेव्हिड. बॉट्सने लाखो गेमर्ससाठी प्लेस्टेशन ५ लाँच कसे उद्ध्वस्त केले. F20 लॅब्स ब्लॉग. F5. Web पान १६ मार्च २०२३.

API सुरक्षेसाठी २०२३ च्या OWASP टॉप १० साठी डेव्हलपर मार्गदर्शक

15/23

सर्वात प्रसिद्ध माजीampSSRF च्या हल्ल्यात एका माजी Amazonमेझॉनचा समावेश होता Web चुकीच्या पद्धतीने कॉन्फिगर केलेल्या व्यक्तीचे शोषण करणारा सेवा (AWS) अभियंता web अॅप्लिकेशन फायरवॉल (WAF) वापरून नंतर वित्तीय दिग्गज कॅपिटल वनच्या सर्व्हर इंस्टन्समधून डेटा गोळा करण्यासाठी SSRF दोषाचा वापर केला.

ऑपरेशन टीमनी देखील पुन्हा विचार करावाview इतर मशीन्सद्वारे वापरण्यासाठी डिझाइन केलेले कोणतेही API, जसे की B2B वापराच्या प्रकरणांमध्ये, आणि हल्लेखोरांना मशीन-टू-मशीन परस्परसंवादाचा गैरफायदा घेण्यापासून रोखण्यासाठी काही संरक्षण उपलब्ध असल्याची खात्री करा.
ओपनटेक्स्ट कशी मदत करू शकते?
असुरक्षित आणि संवेदनशील व्यवसाय प्रवाह पकडणे हे बहुतेकदा मूलभूत गोष्टी करण्यावर अवलंबून असते. कंपन्यांना त्यांच्या सर्व कार्यरत API चे दस्तऐवजीकरण आणि ट्रॅक करणे आवश्यक आहे आणि कोणते API संवेदनशील प्रक्रिया आणि डेटा संभाव्य हल्लेखोरांना उघड करतात हे निर्धारित करणे आवश्यक आहे. हल्लेखोरांकडून शोषण होऊ शकणाऱ्या लॉजिक त्रुटींसाठी अॅप्लिकेशन लॉजिकचे विश्लेषण करणे देखील आवश्यक आहे.
एकंदरीत, संवेदनशील व्यवसाय प्रवाहांना अप्रतिबंधित प्रवेश रोखणे हे अनुप्रयोग सुरक्षेसाठी समग्र दृष्टिकोनाबद्दल अधिक आहे आणि विशिष्ट तंत्रज्ञान शोधण्याबद्दल कमी आहे.
API7:2023–सर्व्हर साइड रिक्वेस्ट फोर्जरी
ते काय आहे?
बॅकएंड सर्व्हर API एंडपॉइंट्सद्वारे केलेल्या विनंत्या हाताळतात. सर्व्हर-साइड रिक्वेस्ट फोर्जरी (SSRF) ही एक भेद्यता आहे जी आक्रमणकर्त्याला सर्व्हरला त्यांच्या वतीने आणि सर्व्हरच्या विशेषाधिकार पातळीसह विनंत्या पाठवण्यास प्रवृत्त करण्यास अनुमती देते. अनेकदा हल्ला बाह्य आक्रमणकर्ता आणि अंतर्गत नेटवर्कमधील अंतर भरण्यासाठी सर्व्हरचा वापर करतो. मूलभूत SSRF हल्ल्यांमुळे आक्रमणकर्त्याला प्रतिसाद परत मिळतो, जो ब्लाइंड SSRF हल्ल्यांपेक्षा खूपच सोपा परिस्थिती आहे, जिथे कोणताही प्रतिसाद परत मिळत नाही, ज्यामुळे आक्रमणकर्त्याला हल्ला यशस्वी झाला की नाही याची पुष्टी मिळत नाही.
एखाद्या अॅप्लिकेशनला असुरक्षित कशामुळे बनवले जाते?
सर्व्हर-साइड रिक्वेस्ट फोर्जरी (SSRF) मधील त्रुटी मूलतः वापरकर्त्याने पुरवलेल्या इनपुटची पडताळणी न झाल्यामुळे उद्भवतात. हल्लेखोर विनंत्या तयार करू शकतात आणि लक्ष्यित अनुप्रयोगात प्रवेश प्रदान करणारा URI समाविष्ट करू शकतात.
अनुप्रयोग विकासातील आधुनिक संकल्पना, जसे की webOWASP नुसार, हुक आणि प्रमाणित अनुप्रयोग फ्रेमवर्क, SSRF ला अधिक सामान्य आणि अधिक धोकादायक बनवतात.
माजी मध्येampवापरकर्त्यांना प्रो अपलोड करण्याची परवानगी देणारे सोशल नेटवर्क, OWASP द्वारे उद्धृत केलेलेfile जर सर्व्हरने अॅप्लिकेशनला पाठवलेले युक्तिवाद सत्यापित केले नाहीत तर चित्रे SSRF साठी असुरक्षित असू शकतात. त्याऐवजी URL एखाद्या प्रतिमेकडे निर्देश करणे, जसे की:
पोस्ट /एपीआय/प्रोfile/चित्र अपलोड करा _
{
"चित्र _" url": "http://example.com/profile _ चित्र.jpg”
}
एखादा हल्लेखोर खालील API कॉल वापरून विशिष्ट पोर्ट उघडा आहे की नाही हे निर्धारित करणारा URI पाठवू शकतो:
{ "चित्र _" url": "लोकलहोस्ट:८०८०"
}

API सुरक्षेसाठी २०२३ च्या OWASP टॉप १० साठी डेव्हलपर मार्गदर्शक

16/23

सुरक्षा चुकीच्या कॉन्फिगरेशनमध्ये असुरक्षित डीफॉल्ट कॉन्फिगरेशनसह अनुप्रयोग सेट करणे, संवेदनशील फंक्शन्स आणि डेटामध्ये अत्यधिक परवानगी देणे आणि तपशीलवार त्रुटी संदेशांद्वारे अनुप्रयोग माहिती सार्वजनिकपणे उघड करणे समाविष्ट आहे.

ब्लाइंड SSRF प्रकरणातही, हल्लेखोर प्रतिसाद मिळण्यासाठी लागणारा वेळ मोजून पोर्ट उघडे आहे की नाही हे शोधू शकतो.
हल्ला माजीampलेस
सर्वात प्रसिद्ध माजीampSSRF च्या हल्ल्यात एका माजी Amazonमेझॉनचा समावेश होता Web चुकीच्या पद्धतीने कॉन्फिगर केलेल्या व्यक्तीचे शोषण करणारा सेवा (AWS) अभियंता web अॅप्लिकेशन फायरवॉल (WAF) नंतर आर्थिक दिग्गज कॅपिटल वनच्या सर्व्हर इंस्टन्समधून डेटा गोळा करण्यासाठी SSRF दोष वापरतो. जुलै २०१९ मध्ये घडलेल्या या घटनेमुळे अंदाजे १०० दशलक्ष अमेरिकन नागरिक आणि सहा दशलक्ष कॅनेडियन नागरिकांचा डेटा चोरीला गेला.२१ अमेझॉन SSRF दोषापेक्षा चुकीच्या कॉन्फिगरेशनला तडजोडीचे स्रोत मानते.२२
ऑक्टोबर २०२२ मध्ये, एका क्लाउड सिक्युरिटी फर्मने मायक्रोसॉफ्टला कंपनीच्या प्रमुख अझूर क्लाउड प्लॅटफॉर्ममधील चार SSRF भेद्यतांबद्दल सूचित केले. प्रत्येक भेद्यतेचा अझूर मशीन लर्निंग सेवा आणि अझूर API व्यवस्थापन सेवा यासह वेगवेगळ्या अझूर सेवेवर परिणाम झाला.२३
विकासक म्हणून ते कसे रोखायचे?
डेव्हलपर्सनी त्यांच्या कोडमध्ये रिसोर्स-फेचिंग मेकॅनिझम एन्कॅप्स्युलेट करावेत, फीचर वेगळे करावेत आणि कोणत्याही विनंत्यांची पडताळणी करण्यासाठी अॅडिशन प्रोटेक्शन्स लेयर करावेत. कारण अशी फीचर्स सामान्यतः रिमोट रिसोर्सेस मिळवण्यासाठी वापरली जातात आणि अंतर्गत फीचर्स नाहीत, त्यामुळे डेव्हलपर्सनी परवानगी असलेल्या रिमोट रिसोर्सेसची यादी वापरण्यासाठी आणि अंतर्गत रिसोर्सेसमध्ये प्रवेश करण्याचे प्रयत्न ब्लॉक करण्यासाठी एन्कॅप्स्युलेटेड फीचर्स कॉन्फिगर करावेत. रिसोर्स-फेचिंग फंक्शन्स आणि दुर्भावनापूर्ण कोडसाठी पार्स केलेल्या कोणत्याही विनंत्यांसाठी HTTP रीडायरेक्शन अक्षम केले पाहिजे.
SSRF च्या कमकुवतपणाचा धोका नेहमीच पूर्णपणे काढून टाकता येत नाही, म्हणून कंपन्यांनी बाह्य संसाधनांवर कॉल वापरण्याच्या जोखमीचा बारकाईने विचार केला पाहिजे.
ओपनटेक्स्ट कशी मदत करू शकते?
ओपनटेक्स्ट डायनॅमिक अॅप्लिकेशन सिक्युरिटी टेस्टिंगमुळे डेव्हसेकऑप्स टीम नियमितपणे सर्व्हर-साइड रिक्वेस्ट फोर्जरीची चाचणी करू शकतात. ओपनटेक्स्ट™ डायनॅमिक अॅप्लिकेशन सिक्युरिटी टेस्टिंग कॉन्फिगर केलेल्या वातावरणात अॅप्लिकेशन सर्व्हर स्कॅन करते जेणेकरून सर्व घटक - अॅप्लिकेशन, सर्व्हर आणि नेटवर्क - तपासता येतील, ज्यामुळे डायनॅमिक अॅनालिसिस प्लॅटफॉर्मला एक व्यापक view सर्व्हर विनंत्यांचा परिणाम.
ओपनटेक्स्ट SAST डाग विश्लेषणाद्वारे SSRF चे अनेक प्रकरण शोधू शकते - उदाहरणार्थampजर अनुप्रयोगाने अप्रमाणित वापरकर्ता इनपुट वापरला तर URL ते नंतर आणले जाईल. हे टूल अप्रतिबंधित वापरकर्ता इनपुटचा वापर दर्शवेल.

२१ कॅपिटल वन सायबर घटनेची माहिती. कॅपिटल वन सल्लागार. Web पृष्ठ. २२ एप्रिल २०२२ रोजी अपडेट केले.
२२ एनजी, अल्फ्रेड. कॅपिटल वन उल्लंघनासाठी अमेझॉनने सिनेटरना दोषी ठरवले नाही. सीएनईटी न्यूज. कॉम. बातम्यांचा लेख. २१ नोव्हेंबर २०१९.
२३ शिट्रिट, लिडोर बेन. ऑर्काला चार वेगवेगळ्या अझूर सेवांमध्ये सर्व्हर-साइड रिक्वेस्ट फोर्जरी (SSRF) भेद्यता कशा आढळल्या. ऑर्का सिक्युरिटी ब्लॉग. Web पान १० जानेवारी २०२३.

API सुरक्षेसाठी २०२३ च्या OWASP टॉप १० साठी डेव्हलपर मार्गदर्शक

17/23

कोड म्हणून सुरक्षा कॉन्फिगरेशन पुनरावृत्ती करण्यायोग्य बनवून आणि अनुप्रयोग-सुरक्षा संघांना विशिष्ट अनुप्रयोग घटकांसाठी मानक कॉन्फिगरेशन संच सेट करण्याची क्षमता देऊन मदत करू शकते.

API8:2023–सुरक्षा चुकीची कॉन्फिगरेशन
ते काय आहे?
डेव्हलपर्स अनेकदा त्यांचे अॅप्लिकेशन चुकीचे कॉन्फिगर करतात, डेव्हलपमेंट अॅसेट्स उत्पादन अॅसेट्सपासून वेगळे करण्यात अयशस्वी होतात, संवेदनशील fileअशा प्रकारची संरचना fileत्यांच्या सार्वजनिक भांडारांमध्ये प्रवेश करणे आणि डीफॉल्ट कॉन्फिगरेशन बदलण्यात अयशस्वी होणे. सुरक्षा चुकीच्या कॉन्फिगरेशनमध्ये असुरक्षित डीफॉल्ट कॉन्फिगरेशनसह अनुप्रयोग सेट करणे, संवेदनशील फंक्शन्स आणि डेटामध्ये अत्यधिक परवानगी देणे आणि तपशीलवार त्रुटी संदेशांद्वारे अनुप्रयोग माहिती सार्वजनिकपणे उघड करणे समाविष्ट आहे.
एखाद्या अॅप्लिकेशनला असुरक्षित कशामुळे बनवले जाते?
डीफॉल्ट अॅप्लिकेशन कॉन्फिगरेशन बहुतेकदा जास्त परवानगी देणारे असतात, सुरक्षा कडकपणाचा अभाव असतो आणि क्लाउड स्टोरेज उदाहरणे लोकांसाठी खुली ठेवतात. बऱ्याचदा, web ज्या फ्रेमवर्कवर अनुप्रयोग आधारित आहेत त्यामध्ये अनेक अनुप्रयोग वैशिष्ट्ये समाविष्ट आहेत जी आवश्यक नाहीत आणि ज्यांचा समावेश सुरक्षा कमी करतो.
माजी मध्येample द्वारे तपशीलवार माहिती दिली आहे OWASP, एक सोशल नेटवर्क जे डायरेक्ट मेसेजिंग फीचर देते जे वापरकर्त्यांच्या गोपनीयतेचे रक्षण करते, परंतु खालील उदाहरण वापरून विशिष्ट संभाषण पुनर्प्राप्त करण्यासाठी API विनंती देतेampAPI विनंती:
/dm/user _ updates.json?conversation _ id=1234567&cursor=GRlFp7LCUAAAA मिळवा
API एंडपॉइंट कॅशेमध्ये साठवलेल्या डेटावर मर्यादा घालत नाही, परिणामी खाजगी संभाषणे कॅशे केली जातात web ब्राउझर. हल्लेखोर ब्राउझरमधून माहिती मिळवू शकत होते, ज्यामुळे पीडिताचे खाजगी संदेश उघड होऊ शकत होते.
हल्ला माजीampलेस
मे २०२१ मध्ये, एका क्लाउड सिक्युरिटी फर्मने मायक्रोसॉफ्टला सूचित केले की किमान ४७ वेगवेगळ्या ग्राहकांनी त्यांच्या मायक्रोसॉफ्ट पॉवर अॅप्सच्या उदाहरणांचे डीफॉल्ट कॉन्फिगरेशन बदलले नाही. प्रभावित संस्थांमध्ये अमेरिकन एअरलाइन्स आणि मायक्रोसॉफ्ट सारख्या कंपन्या आणि इंडियाना आणि मेरीलँड सारख्या राज्य सरकारांचा समावेश होता आणि पॉवर अॅप्स पोर्टलवर ३८ दशलक्ष रेकॉर्ड संभाव्य तडजोडीसाठी उघड केले.२४
२०२२ मध्ये, एका भेद्यता व्यवस्थापन फर्मला आढळले की Amazon वर १२,००० क्लाउड प्रकरणे होस्ट केली गेली आहेत. Web २०२२ च्या अहवालानुसार, Azure वर होस्ट केलेल्या सेवा आणि १०,५०० सेवांमुळे टेलनेट, एक रिमोट अॅक्सेस प्रोटोकॉल, जो "आज कोणत्याही इंटरनेट-आधारित वापरासाठी अयोग्य" मानला जातो, तो उघड होत राहिला.२५ अनावश्यक आणि असुरक्षित वैशिष्ट्यांचा समावेश API आणि अनुप्रयोगांच्या या सुरक्षिततेला कमकुवत करतो.

२४ अपगार्ड रिसर्च. डिझाइननुसार: मायक्रोसॉफ्ट पॉवर अॅप्सवरील डीफॉल्ट परवानग्या लाखो लोकांना कसे धोक्यात आणतात. अपगार्ड रिसर्च ब्लॉग. Web पान ५ ऑगस्ट २०२२.
२५ बियर्डस्ली, टॉड. २०२२ क्लाउड मिसकॉन्फिगरेशन रिपोर्ट. रॅपिड७. पीडीएफ रिपोर्ट. पृष्ठ १२. २० एप्रिल २०२२.

API सुरक्षेसाठी २०२३ च्या OWASP टॉप १० साठी डेव्हलपर मार्गदर्शक

18/23

जेव्हा API चा उद्देश, कार्यप्रणाली आणि आवृत्तीचे तपशील अस्पष्ट असतात तेव्हा दस्तऐवजीकरण ब्लाइंडस्पॉट म्हणजे या महत्त्वाच्या गुणधर्मांचे तपशीलवार दस्तऐवजीकरण नसल्यामुळे.

डेव्हलपरने ते कसे रोखायचे?
DevSecOps टीमना त्यांच्या अनुप्रयोगांसाठी सुरक्षित कॉन्फिगरेशन तयार करण्यासाठी आवश्यक असलेले टप्पे समजून घेणे आवश्यक आहे आणि कॉन्फिगरेशन तपासण्यासाठी स्वयंचलित विकास पाइपलाइन वापरणे आवश्यक आहे. fileकॉन्फिगरेशन त्रुटी किंवा सुरक्षा समस्यांसाठी सॉफ्टवेअर सतत तपासण्यासाठी नियमित युनिट चाचण्या आणि रनटाइम तपासणीसह तैनातीपूर्वीच्या तपासण्या. कॉन्फिगरेशन पुनरावृत्ती करण्यायोग्य बनवून आणि अनुप्रयोग-सुरक्षा संघांना विशिष्ट अनुप्रयोग घटकांसाठी मानक कॉन्फिगरेशन संच सेट करण्याची क्षमता देऊन सुरक्षा-अ‍ॅज-कोड मदत करू शकते.
त्यांच्या सुरक्षित विकास जीवनचक्राचा भाग म्हणून, विकासक आणि ऑपरेशन टीमनी हे करावे:
· सुरक्षित अनुप्रयोग वातावरणाची पुनरावृत्ती करण्यायोग्य निर्मिती आणि देखभाल सुलभ करणारी एक कठोर प्रक्रिया स्थापित करा,
. पुन्हाview आणि नवीन मानक सातत्याने समाविष्ट करण्यासाठी API स्टॅकवरील सर्व कॉन्फिगरेशन अपडेट करा, आणि
· सर्व वातावरणात कॉन्फिगरेशन सेटिंग्जच्या प्रभावीतेचे मूल्यांकन स्वयंचलित करा.
ओपनटेक्स्ट कशी मदत करू शकते?
ओपनटेक्स्ट स्टॅटिक अॅप्लिकेशन सिक्युरिटी टेस्टिंग डेव्हलपमेंट प्रक्रियेदरम्यान कॉन्फिगरेशन तपासू शकते आणि अनेक प्रकारच्या कमकुवतपणा शोधू शकते. अॅप्लिकेशन-कोड स्तरावर आणि पायाभूत सुविधा स्तरावर सुरक्षा चुकीच्या कॉन्फिगरेशनमुळे, चुकीच्या कॉन्फिगरेशन पकडण्यासाठी वेगवेगळ्या ओपनटेक्स्ट उत्पादनांचा वापर केला जाऊ शकतो.
ओपनटेक्स्ट स्टॅटिक अॅप्लिकेशन सिक्युरिटी टेस्टिंग स्कॅन चुकीच्या कॉन्फिगरेशन समस्यांसाठी अॅप्लिकेशन कोड तपासू शकतात. स्टॅटिक अॅनालिसिस तपासणी दरम्यान, ओपनटेक्स्ट SAST कॉन्फिगरेशनचे मूल्यांकन करू शकते. fileसुरक्षा त्रुटींसाठी s, ज्यामध्ये डॉकर, कुबर्नेट्स, अँसिबल, अमेझॉन यांचा समावेश आहे. Web सेवा, क्लाउडफॉर्मेशन, टेराफॉर्म आणि अझ्युर रिसोर्स मॅनेजर टेम्पलेट्स.
रनटाइम दरम्यान कॉन्फिगरेशन त्रुटी देखील आढळू शकतात. ओपनटेक्स्ट डायनॅमिक अॅप्लिकेशन सिक्युरिटी टेस्टिंगमुळे DevSecOps टीमना सामान्य सुरक्षा चुकीच्या कॉन्फिगरेशनसाठी नियमितपणे चाचणी करण्याची परवानगी मिळते. DAST स्कॅनिंगची सर्वात मोठी ताकद म्हणजे ते अॅप्लिकेशन सर्व्हरवर कॉन्फिगर केलेल्या वातावरणात चालते, याचा अर्थ असा की संपूर्ण वातावरण - अॅप्लिकेशन, सर्व्हर आणि नेटवर्क - एकाच वेळी तपासले जातात, ज्यामुळे डायनॅमिक अॅनालिसिस प्लॅटफॉर्मला एक व्यापक view उत्पादन वातावरणाचे कॉन्फिगरेशन केले आहे.
API9:2023–अयोग्य इन्व्हेंटरी व्यवस्थापन
ते काय आहे?
बहुतेक सॉफ्टवेअर मालमत्तेप्रमाणे, API चे एक जीवनचक्र असते, जुन्या आवृत्त्या अधिक सुरक्षित आणि कार्यक्षम API ने बदलल्या जातात किंवा वाढत्या प्रमाणात, तृतीय-पक्ष सेवांशी कनेक्ट केलेले API वापरतात. DevSecOps टीम जे त्यांच्या API आवृत्त्या आणि दस्तऐवजीकरण राखत नाहीत ते जुन्या, सदोष API आवृत्त्या वापरत राहिल्यास भेद्यता आणू शकतात - ही कमकुवतपणा अयोग्य इन्व्हेंटरी मॅनेजमेंट म्हणून ओळखली जाते. इन्व्हेंटरी व्यवस्थापनासाठी सर्वोत्तम पद्धतींमध्ये ट्रॅकिंग आवश्यक आहे

API सुरक्षेसाठी २०२३ च्या OWASP टॉप १० साठी डेव्हलपर मार्गदर्शक

19/23

सुरक्षा भेद्यतेचा प्रसार रोखण्यासाठी API आवृत्त्या, एकात्मिक सेवांचे नियमित मूल्यांकन आणि इन्व्हेंटरींग आणि लेगसी आवृत्त्यांचे नियमित नापसंती.
एखाद्या अॅप्लिकेशनला असुरक्षित कशामुळे बनवले जाते?
API वर अवलंबून असलेल्या सॉफ्टवेअर आर्किटेक्चर्स - विशेषतः जे मायक्रोसर्व्हिस आर्किटेक्चर वापरतात - पारंपारिक पेक्षा जास्त एंडपॉइंट्स उघड करतात. web अनुप्रयोग. API च्या अनेक आवृत्त्या एकाच वेळी अस्तित्वात असण्याची शक्यता असलेल्या API एंडपॉइंट्सची भरपूरता, वाढत्या हल्ल्याच्या पृष्ठभागास प्रतिबंध करण्यासाठी API प्रदात्याकडून अतिरिक्त व्यवस्थापन संसाधनांची आवश्यकता असते. OWASP DevSecOps संघांना त्यांच्या API पायाभूत सुविधांबद्दल असू शकणारे दोन प्रमुख ब्लाइंडस्पॉट्स ओळखते.
प्रथम, जेव्हा API चा उद्देश, कार्यप्रणाली आणि आवृत्तीचे तपशील अस्पष्ट असतात तेव्हा दस्तऐवजीकरण ब्लाइंडस्पॉट म्हणजे या महत्त्वाच्या गुणधर्मांचे तपशीलवार दस्तऐवजीकरण नसल्यामुळे.
दुसरे म्हणजे, डेटा-फ्लो ब्लाइंडस्पॉट तेव्हा होतो जेव्हा एपीआयचा वापर स्पष्टतेचा अभाव असलेल्या पद्धतीने केला जातो, ज्यामुळे अशा क्षमता निर्माण होतात ज्या मजबूत व्यावसायिक औचित्याशिवाय परवानगी देऊ नयेत. सुरक्षिततेच्या हमीशिवाय तृतीय पक्षासह संवेदनशील डेटा शेअर करणे, डेटा फ्लोच्या अंतिम परिणामाची दृश्यमानता नसणे आणि साखळी केलेल्या एपीआयमध्ये सर्व डेटा फ्लो मॅप करण्यात अयशस्वी होणे हे सर्व ब्लाइंडस्पॉट आहेत.
माजी म्हणूनampतसेच, OWASP अहवालात एका काल्पनिक सोशल नेटवर्कचा उल्लेख आहे जो तृतीय-पक्ष स्वतंत्र अनुप्रयोगांसह एकत्रीकरण करण्यास अनुमती देतो. अंतिम वापरकर्त्याची संमती आवश्यक असली तरी, सोशल नेटवर्क डेटा प्रवाहात पुरेशी दृश्यमानता राखत नाही जेणेकरून डाउनस्ट्रीम पक्षांना डेटामध्ये प्रवेश करण्यापासून रोखता येईल, जसे की केवळ वापरकर्त्याच्याच नव्हे तर त्यांच्या मित्रांच्या क्रियाकलापांचे निरीक्षण करणे.
हल्ला माजीampलेस
२०१३ आणि २०१४ मध्ये, फेसबुक प्लॅटफॉर्मवर सुमारे ३,००,००० लोकांनी ऑनलाइन मानसशास्त्रीय प्रश्नमंजुषा घेतली. या प्रश्नमंजुषामागील कंपनी, केंब्रिज अॅनालिटिका, ने केवळ त्या वापरकर्त्यांचीच माहिती गोळा केली नाही तर त्यांच्याशी जोडलेल्या मित्रांचीही माहिती गोळा केली - एकूण लोकसंख्या ८७ दशलक्ष इतकी होती, ज्यापैकी बहुतेकांनी त्यांची माहिती गोळा करण्याची परवानगी दिली नव्हती. त्यानंतर कंपनीने या माहितीचा वापर त्यांच्या क्लायंटच्या वतीने त्या लोकांना जाहिराती आणि संदेश पाठवण्यासाठी केला, ज्यामध्ये ट्रम्प सरकारला पाठिंबा देणाऱ्या राजकीय जाहिराती पाठवणे समाविष्ट होते.amp२०१६ च्या निवडणुकीत विजय.२६ फेसबुकने त्यांच्या प्लॅटफॉर्मवरून मिळवलेल्या माहितीचा वापर तृतीय पक्षांनी कसा केला याबद्दल दृश्यमानतेचा अभाव हा एक माजीampअयोग्य इन्व्हेंटरी व्यवस्थापनाचा दोष.
विकासक म्हणून ते कसे रोखायचे?
DevSecOps टीमनी सर्व API होस्टचे दस्तऐवजीकरण करावे आणि API आणि तृतीय-पक्ष सेवांमधील डेटा प्रवाहात दृश्यमानता राखण्यावर लक्ष केंद्रित करावे. अयोग्य इन्व्हेंटरी व्यवस्थापन रोखण्याचा प्राथमिक मार्ग म्हणजे सर्व API सेवा आणि होस्टच्या महत्त्वाच्या पैलूंचे तपशीलवार दस्तऐवजीकरण करणे, ज्यामध्ये ते कोणता डेटा हाताळतात, होस्ट आणि डेटामध्ये कोणाचा प्रवेश आहे याची माहिती समाविष्ट आहे,
२६ रोझेनबर्ग, मॅथ्यू आणि डान्स, गॅब्रिएल. ``तुम्हीच उत्पादन आहात'': फेसबुकवर केंब्रिज अॅनालिटिकाने लक्ष्य केले. द न्यू यॉर्क टाईम्स. बातमी लेख. ८ एप्रिल २०१८.

API सुरक्षेसाठी २०२३ च्या OWASP टॉप १० साठी डेव्हलपर मार्गदर्शक

20/23

ओपनटेक्स्ट सिक्योर एपीआय मॅनेजर बाय ओपनटेक्स्ट वापरून संस्था त्यांच्या एपीआय वापराचे व्यवस्थापन, निरीक्षण, सुरक्षितता आणि दस्तऐवजीकरण करू शकतात, जे अॅप्लिकेशन सिक्युरिटी टीमना एपीआय मालमत्तेची अद्ययावत इन्व्हेंटरी राखण्यास अनुमती देते.

आणि प्रत्येक होस्टच्या विशिष्ट API आवृत्त्या. दस्तऐवजीकरण केलेल्या तांत्रिक तपशीलांमध्ये प्रमाणीकरण अंमलबजावणी, त्रुटी हाताळणी, दर मर्यादा संरक्षण, क्रॉस-ओरिजिन रिसोर्स शेअरिंग (CORS) धोरण आणि प्रत्येक एंडपॉइंटचे तपशील समाविष्ट आहेत.
दस्तऐवजीकरणाचे महत्त्वपूर्ण प्रमाण मॅन्युअली व्यवस्थापित करणे कठीण आहे, म्हणून सतत एकत्रीकरण प्रक्रियेद्वारे आणि खुल्या मानकांचा वापर करून दस्तऐवजीकरण तयार करण्याची शिफारस केली जाते. API दस्तऐवजीकरणाचा प्रवेश API वापरण्यास अधिकृत असलेल्या विकासकांपर्यंत मर्यादित असावा.
अनुप्रयोग तयार करण्याच्या आणि चाचणीच्या टप्प्यांदरम्यान, विकासकांनी विकास किंवा वापरावर उत्पादन डेटा वापरणे टाळावे.tagडेटा लीक टाळण्यासाठी अॅप्लिकेशनच्या समर्थित आवृत्त्या. जेव्हा API च्या नवीन आवृत्त्या रिलीज केल्या जातात, तेव्हा DevSecOps टीमने अॅप्लिकेशन्स अपग्रेड करण्यासाठी सर्वोत्तम दृष्टिकोन निश्चित करण्यासाठी जोखीम विश्लेषण करावे.tagवाढीव सुरक्षिततेचा.
ओपनटेक्स्ट कशी मदत करू शकते?
संस्था OpenTextTM सिक्योर API मॅनेजर वापरून त्यांच्या API वापराचे व्यवस्थापन, निरीक्षण, सुरक्षितता आणि दस्तऐवजीकरण करू शकतात, जे अॅप्लिकेशन-सुरक्षा टीमना API मालमत्तेची अद्ययावत यादी राखण्यास अनुमती देते. OpenText Secure API मॅनेजर एक अधिकृत रिपॉझिटरी प्रदान करते जिथे तुमची DevSecOps टीम संस्थेद्वारे वापरल्या जाणाऱ्या सर्व API संग्रहित आणि व्यवस्थापित करू शकते, ज्यामुळे API विकासापासून सेवानिवृत्तीपर्यंतचे जीवन चक्र व्यवस्थापित करणे सोपे होते. हे सॉफ्टवेअर तपशीलवार विश्लेषणांना परवानगी देऊन नियमांचे आणि परवान्याचे पालन सुधारण्यास मदत करते.
API10:2023–API चा असुरक्षित वापर
ते काय आहे?
अनुप्रयोग तयार करण्यासाठी स्थानिक क्लाउड इन्फ्रास्ट्रक्चरच्या वाढत्या वापरामुळे, API हे अनुप्रयोग घटकांमधील एकात्मतेचे बिंदू बनले आहेत. तथापि, API द्वारे प्रवेश केलेल्या तृतीय-पक्ष सेवांची सुरक्षा स्थिती क्वचितच स्पष्ट आहे, ज्यामुळे हल्लेखोरांना अनुप्रयोग कोणत्या सेवांवर अवलंबून आहे आणि त्यापैकी कोणत्याही सेवांमध्ये सुरक्षा कमकुवतपणा आहे की नाही हे निर्धारित करण्याची परवानगी मिळते. विकसक बाह्य किंवा तृतीय-पक्ष API ची पडताळणी न करता त्यांचा अनुप्रयोग कोणत्या अंतिम बिंदूंवर संवाद साधतो यावर विश्वास ठेवतात. API च्या या असुरक्षित वापरामुळे अनुप्रयोग अनेकदा कमकुवत सुरक्षा आवश्यकता असलेल्या किंवा इनपुट प्रमाणीकरणासारख्या मूलभूत सुरक्षा कडकपणा नसलेल्या सेवांवर अवलंबून राहतो.
एखाद्या अॅप्लिकेशनला असुरक्षित कशामुळे बनवले जाते?
डेव्हलपर्स वापरकर्त्याच्या इनपुटपेक्षा थर्ड-पार्टी एपीआय कडून मिळालेल्या डेटावर जास्त विश्वास ठेवतात, जरी हे दोन्ही स्रोत मूलतः प्रेरित आक्रमणकर्त्यासाठी समान आहेत. या चुकीच्या विश्वासामुळे, इनपुट व्हॅलिडेशन आणि सॅनिटायझेशनच्या अभावामुळे डेव्हलपर्स मूलतः कमकुवत सुरक्षा मानकांवर अवलंबून राहतात.
जर अनुप्रयोग:
· अनएनक्रिप्टेड कम्युनिकेशन्स वापरून इतर API वापरतो किंवा वापरतो,
· इतर API किंवा सेवांमधील डेटा सत्यापित आणि निर्जंतुक करण्यात अयशस्वी झाल्यास,
· कोणत्याही सुरक्षा तपासणीशिवाय पुनर्निर्देशन करण्यास अनुमती देते, किंवा

API सुरक्षेसाठी २०२३ च्या OWASP टॉप १० साठी डेव्हलपर मार्गदर्शक

21/23

जर डेव्हलपरने API एंडपॉइंटद्वारे परत आलेल्या कोणत्याही डेटाची पडताळणी करण्यासाठी त्यांच्या अॅप्लिकेशनमध्ये सुरक्षा तपासणी कोड केली नाही, तर त्यांचे अॅप्लिकेशन रीडायरेक्टचे अनुसरण करेल आणि हल्लेखोराला संवेदनशील वैद्यकीय माहिती पाठवेल.
क्लाउड-नेटिव्ह डेव्हलपर्सना API बनवण्यासाठी OWASP API सिक्युरिटी टॉप-१० हे महत्त्वाचे आहे. तरीही, SQL इंजेक्शन, डेटा एक्सपोजर आणि सुरक्षा चुकीची कॉन्फिगरेशन यासारख्या सामान्य अॅप्लिकेशन भेद्यता दूर करण्यास प्राधान्य दिले पाहिजे, कारण सायबर धोक्यांद्वारे त्यांचा वारंवार गैरफायदा घेतला जातो. API सिक्युरिटी टॉप-१० हा सुरक्षित सॉफ्टवेअर डेव्हलपमेंटचा एक आवश्यक भाग आहे परंतु सामान्य अॅप्लिकेशन भेद्यता दूर करण्यासाठी तो दुय्यम असावा.

· थ्रेशोल्ड आणि टाइमआउट वापरून संसाधनांचा वापर मर्यादित करण्यात अयशस्वी.
माजी मध्येampOWASP अहवालानुसार, संवेदनशील वापरकर्ता वैद्यकीय माहिती संग्रहित करण्यासाठी तृतीय-पक्ष सेवा प्रदात्यासह एकत्रित होणारे API API एंडपॉइंटद्वारे खाजगी डेटा पाठवू शकते. हल्लेखोर 308 स्थायी पुनर्निर्देशन: HTTP/1.1 308 स्थायी पुनर्निर्देशन वापरून भविष्यातील विनंत्यांना प्रतिसाद देण्यासाठी तृतीय-पक्ष API होस्टशी तडजोड करू शकतात.
स्थान: https://attacker.com/
जर डेव्हलपरने API एंडपॉइंटद्वारे परत आलेल्या कोणत्याही डेटाची पडताळणी करण्यासाठी त्यांच्या अॅप्लिकेशनमध्ये सुरक्षा तपासणी कोड केली नाही, तर त्यांचे अॅप्लिकेशन रीडायरेक्टचे अनुसरण करेल आणि हल्लेखोराला संवेदनशील वैद्यकीय माहिती पाठवेल.
हल्ला माजीampलेस
डिसेंबर २०२१ मध्ये, सामान्यतः वापरल्या जाणाऱ्या ओपन-सोर्स सॉफ्टवेअर घटक, Log2021J मधील भेद्यतांच्या संचामुळे हल्लेखोराला एन्कोडेड स्क्रिप्टसारखे अस्वच्छ इनपुट प्रदान करण्याची आणि सर्व्हरवर स्क्रिप्ट कार्यान्वित करण्यासाठी Log4J च्या असुरक्षित आवृत्त्या वापरण्याची परवानगी मिळाली. Log4J भेद्यतेमागील समस्या इनपुट प्रमाणीकरणाच्या अभावामुळे उद्भवली, विशेषतः डीसीरियलाइज्ड वापरकर्त्याने पुरवलेल्या डेटावर सुरक्षा तपासणी करण्यात अयशस्वी होणे. अनुक्रमित दुर्भावनापूर्ण कोड पाठवून, हल्लेखोर भेद्यतेचा फायदा घेऊ शकतात आणि भेद्यता असलेल्या सर्व्हरवर हल्ला करू शकतात. विकासकांनी तृतीय-पक्ष API आणि इतर बाह्य स्रोतांद्वारे प्रदान केलेले सर्व इनपुट तपासले पाहिजेत.4
डेव्हलपरने ते कसे रोखायचे?
सेवा प्रदात्यांच्या मूल्यांकनात, त्यांच्या API सुरक्षा स्थितीचे मूल्यांकन करताना आणि कडक सुरक्षा नियंत्रणे लागू करताना विकासकांनी योग्य ती काळजी घेतली पाहिजे. याव्यतिरिक्त, विकासकांनी याची पुष्टी करावी की तृतीय पक्ष API आणि तृतीय पक्षांकडून संस्थेच्या API कडे जाणारे सर्व संप्रेषण गुप्तहेर आणि पुन्हा खेळण्याचे हल्ले रोखण्यासाठी सुरक्षित संप्रेषण चॅनेल वापरतात.
बाह्य वापरकर्ते आणि मशीन्सकडून डेटा प्राप्त करताना, कोडची अनवधानाने अंमलबजावणी टाळण्यासाठी इनपुट नेहमीच निर्जंतुक केले पाहिजेत. शेवटी, API द्वारे एकत्रित केलेल्या क्लाउड सेवांसाठी, कोणत्याही IP पत्त्याला अनुप्रयोगाच्या API वर कॉल करण्याची परवानगी देण्याऐवजी, एकात्मिक सोल्यूशनचा पत्ता लॉक करण्यासाठी परवानगी सूची वापरल्या पाहिजेत.
ओपनटेक्स्ट कशी मदत करू शकते?
ओपनटेक्स्ट स्टॅटिक अॅप्लिकेशन सिक्युरिटी टेस्टिंगच्या स्टॅटिक कोड आणि API विश्लेषण वैशिष्ट्यांना ओपनटेक्स्ट डायनॅमिक अॅप्लिकेशन सिक्युरिटी टेस्टिंग (DAST) सूटच्या रनटाइम तपासणीसह एकत्रित करून, DevSecOps टीम त्यांच्या अॅप्लिकेशनद्वारे थर्ड-पार्टी API चा वापर तपासू शकतात आणि सामान्य हल्ल्याच्या प्रकारांची चाचणी करू शकतात. असुरक्षित API शोधण्यासाठी, OpenText Secure API मॅनेजर सिस्टमद्वारे कॉल केलेल्या सर्व API चे तसेच कोणते बाह्य अॅप्लिकेशन तुमच्या अॅप्लिकेशनचे API वापरू शकतात याचे रिपॉझिटरी तयार करू शकते.
२७ मायक्रोसॉफ्ट थ्रेट इंटेलिजेंस. Log27j २ च्या भेद्यतेचा गैरवापर रोखण्यासाठी, शोधण्यासाठी आणि शोधण्यासाठी मार्गदर्शन. मायक्रोसॉफ्ट. Web पृष्ठ. अपडेट: १० जानेवारी २०२२.

API सुरक्षेसाठी २०२३ च्या OWASP टॉप १० साठी डेव्हलपर मार्गदर्शक

22/23

पुढे कुठे जायचे
या दस्तऐवजात नमूद केलेली उत्पादने येथे आहेत: ओपनटेक्स्ट अॅप्लिकेशन सुरक्षा >
ओपनटेक्स्ट स्टॅटिक अॅप्लिकेशन सुरक्षा चाचणी >
ओपनटेक्स्ट डायनॅमिक अॅप्लिकेशन सुरक्षा चाचणी >
ओपनटेक्स्ट सिक्युअर एपीआय मॅनेजर >
अतिरिक्त संसाधने OWASP टॉप १० API सुरक्षा धोके–२०२३ >
अॅप्लिकेशन सुरक्षा चाचणीसाठी गार्टनर मॅजिक क्वाड्रंट >
OpenText ऍप्लिकेशन सुरक्षा Webइनार मालिका >

एपीआय सिक्युरिटी टॉप-१० पुरेसे नाही!
क्लाउड-नेटिव्ह डेव्हलपर्ससाठी जे विशेषतः अनुप्रयोगाच्या इतर भागांना, अंतर्गत वापरकर्त्यांना किंवा जागतिक वापरासाठी सेवा देण्यासाठी API तयार करण्यावर लक्ष केंद्रित करतात, त्यांच्यासाठी OWASP API सुरक्षा टॉप १० यादी वाचण्यासाठी आणि समजून घेण्यासाठी एक महत्त्वाचा दस्तऐवज आहे.
तथापि, OWASP API सुरक्षा टॉप १० हा एक स्वतंत्र दस्तऐवज नाही. विकासकांना हे देखील सुनिश्चित करावे लागेल की ते त्यांच्या सध्याच्या अनुप्रयोग आणि आर्किटेक्चरशी संबंधित OWASP टॉप १० सारख्या सर्वोत्तम पद्धतींच्या इतर स्रोतांचा वापर करतात. सामान्य अनुप्रयोग भेद्यता - SQL इंजेक्शन, डेटा एक्सपोजर आणि सुरक्षा चुकीचे कॉन्फिगरेशन - हे सायबर धोका गट कॉर्पोरेट पायाभूत सुविधांना तडजोड करू शकतात आणि त्यांचे त्वरीत निराकरण केले पाहिजे. याव्यतिरिक्त, काही API-आधारित अनुप्रयोग, जसे की मोबाइल अॅप्स, यांना स्वतंत्र अनुप्रयोगांपेक्षा वेगळ्या अॅप्सेक कठोर चरणांची आवश्यकता असते. web-अ‍ॅप, आणि कनेक्ट आणि आयओटी डिव्हाइसेससाठी आवश्यक असलेल्यापेक्षा वेगळे. एकंदरीत, एपीआय सिक्युरिटी टॉप १० यादी महत्त्वाची आहे, परंतु ती एकूण सुरक्षित सॉफ्टवेअर डेव्हलपमेंट लाइफसायकलचा फक्त एक पैलू आहे. ही यादी आणि ओडब्ल्यूएएसपी टॉप १० यादी, विश्लेषणाधीन उपायासाठी आवश्यक असलेल्या इतर कोणत्याही संबंधित मानके आणि सर्वोत्तम पद्धतींसह वापरली पाहिजे.
निष्कर्ष
क्लाउड इन्फ्रास्ट्रक्चरवर अॅप्लिकेशन्स अधिकाधिक अवलंबून असल्याने, web अ‍ॅप्लिकेशन प्रोग्रामिंग इंटरफेस (एपीआय) हे इंटरनेटचा पाया बनले आहेत. कंपन्यांच्या वातावरणात सामान्यतः शेकडो, जर हजारो नसतील तर एपीआय एंडपॉइंट्स असतात, ज्यामुळे त्यांचा हल्ला पृष्ठभाग नाटकीयरित्या वाढतो आणि अ‍ॅप्लिकेशन्सना विविध कमकुवतपणाचा सामना करावा लागतो.
२०२३ च्या OWASP API सुरक्षा टॉप १० यादीचे प्रकाशन हे कंपन्या आणि विकासकांसाठी API-आधारित पायाभूत सुविधांच्या जोखमींबद्दल स्वतःला शिक्षित करण्यासाठी आणि त्यांच्या स्वतःच्या अनुप्रयोगांचे मूल्यांकन करण्यासाठी एक चांगला प्रारंभिक बिंदू आहे. अधिक प्रसिद्ध अनुप्रयोग सुरक्षा टॉप-१० यादीसह, रँकिंगची जोडी DevSecOps संघांना त्यांच्या अनुप्रयोगांच्या एकूण सुरक्षिततेसाठी एक समग्र दृष्टिकोन विकसित करण्यास मदत करू शकते.
DevSecOps टीमना API च्या सुरक्षिततेचे परिणाम, अंमलबजावणीच्या भेद्यता आणि सुरक्षा कमकुवतपणा कशा कमी करायच्या आणि त्यांच्या विकास पाइपलाइन आणि परिणामी API सर्व्हरला कसे कडक करायचे याबद्दल जागरूक असणे आवश्यक आहे जेणेकरून हल्लेखोरांना त्याच्या API द्वारे अनुप्रयोगाशी तडजोड करणे अधिक कठीण होईल.

कॉपीराइट © 2025 खुला मजकूर · 04.25 | 262-000177-001

कागदपत्रे / संसाधने

ओपनटेक्स्ट २६२-०००१७७-००१ ओडब्ल्यूएएसपी एपीआय सुरक्षेसाठी टॉप १० [pdf] वापरकर्ता मॅन्युअल
२६२-०००१७७-००१, २६२-०००१७७-००१ ओडब्ल्यूएएसपी टॉप १० फॉर एपीआय सिक्युरिटी, २६२-०००१७७-००१, ओडब्ल्यूएएसपी टॉप १० फॉर एपीआय सिक्युरिटी, फॉर एपीआय सिक्युरिटी, सेक्युरिटी

संदर्भ

एक टिप्पणी द्या

तुमचा ईमेल पत्ता प्रकाशित केला जाणार नाही. आवश्यक फील्ड चिन्हांकित आहेत *