कोड ऑडिट: Difference between revisions
No edit summary |
No edit summary |
||
| Line 3: | Line 3: | ||
== दिशानिर्देश == | == दिशानिर्देश == | ||
सॉफ़्टवेयर का ऑडिट करते समय, प्रत्येक महत्वपूर्ण घटक का अलग से और पूरे कार्यक्रम के साथ ऑडिट किया जाना चाहिए। पहले उच्च- | सॉफ़्टवेयर का ऑडिट करते समय, प्रत्येक महत्वपूर्ण घटक का अलग से और पूरे कार्यक्रम के साथ ऑडिट किया जाना चाहिए। पहले उच्च-खतरा [[भेद्यता (कंप्यूटिंग)]] की खोज करना और कम-खतरा भेद्यता पर काम करना एक अच्छा विचार है। उच्च-खतरा और कम-खतरा के बीच कमजोरियां सामान्यतः स्थिति के आधार पर सम्मिलित होती हैं और प्रश्न में स्रोत कोड का उपयोग कैसे किया जा रहा है। एप्लिकेशन पैठ परीक्षण एप्लिकेशन को कम करने के प्रयास में संभावित पहुंच बिंदुओं पर यथासंभव कई ज्ञात आक्रमण तकनीकों को लॉन्च करके सॉफ़्टवेयर में कमजोरियों की पहचान करने का प्रयास करता है।<ref name="source-code-audit-faq">{{cite web|title=सोर्स कोड ऑडिट - एफएक्यू|url=http://www.ouncelabs.com/resources/code-audit-faq.asp|access-date=2008-02-12|archive-url=https://web.archive.org/web/20090210113645/http://www.ouncelabs.com/resources/code-audit-faq.asp|archive-date=2009-02-10|url-status=dead}}</ref> यह एक सामान्य ऑडिटिंग विधि है और इसका उपयोग यह पता लगाने के लिए किया जा सकता है कि क्या कोई विशिष्ट भेद्यता सम्मिलित है, किन्तु यह नहीं कि वे स्रोत कोड में कहाँ हैं। कुछ लोग प्रमाणित करते हैं कि अंत-चक्र लेखापरीक्षा के तरीके डेवलपर्स को अभिभूत करते हैं, अंततः टीम को ज्ञात समस्याओं की एक लंबी सूची के साथ छोड़ देते हैं, किन्तु वास्तविक सुधार बहुत कम होता है; इन मामलों में, एक विकल्प के रूप में एक इन-लाइन ऑडिटिंग दृष्टिकोण की सिफारिश की जाती है। | ||
=== उच्च | === उच्च खतरा भेद्यता === | ||
इसके उपयोग के कारण कुछ सामान्य उच्च- | इसके उपयोग के कारण कुछ सामान्य उच्च-खतरा भेद्यताएं सम्मिलित हो सकती हैं: | ||
* नॉन-बाउंड्स-चेकिंग फ़ंक्शंस (जैसे, [[strcpy]], [[sprintf]], vsprintf, और [[sscanf]]) जो [[बफ़र अधिकता]] भेद्यता का कारण बन सकते हैं <ref name="guidelines-for-c-source-code-auditing">{{cite web|title=सी सोर्स कोड ऑडिटिंग के लिए दिशानिर्देश|url=http://mixter.void.ru/vulns.html|access-date=2008-02-12|archive-url=https://web.archive.org/web/20080328073833/http://mixter.void.ru/vulns.html|archive-date=2008-03-28|url-status=dead}}</ref> | * नॉन-बाउंड्स-चेकिंग फ़ंक्शंस (जैसे, [[strcpy]], [[sprintf]], vsprintf, और [[sscanf]]) जो [[बफ़र अधिकता]] भेद्यता का कारण बन सकते हैं <ref name="guidelines-for-c-source-code-auditing">{{cite web|title=सी सोर्स कोड ऑडिटिंग के लिए दिशानिर्देश|url=http://mixter.void.ru/vulns.html|access-date=2008-02-12|archive-url=https://web.archive.org/web/20080328073833/http://mixter.void.ru/vulns.html|archive-date=2008-03-28|url-status=dead}}</ref> | ||
* बफ़र्स का सूचक हेरफेर जो बाद की सीमा जाँच में हस्तक्षेप कर सकता है, जैसे: <code>if ((bytesread = net_read(buf,len)) > 0) buf += bytesread;</code> <ref name="guidelines-for-c-source-code-auditing"/>* निष्पादन (), निष्पादन पाइप, सिस्टम () और इसी | * बफ़र्स का सूचक हेरफेर जो बाद की सीमा जाँच में हस्तक्षेप कर सकता है, जैसे: <code>if ((bytesread = net_read(buf,len)) > 0) buf += bytesread;</code> <ref name="guidelines-for-c-source-code-auditing"/>* निष्पादन (), निष्पादन पाइप, सिस्टम () और इसी प्रकार की चीजों की प्रकार कॉल, खासकर जब गैर-स्थैतिक तर्कों के साथ कहा जाता है <ref name="guidelines-for-c-source-code-auditing"/>* इनपुट सत्यापन, उदा। (एसक्यूएल में): <code>statement := "SELECT * FROM users WHERE name = '" + userName + "';"</code> SQL इंजेक्शन भेद्यता का एक उदाहरण है | ||
* फ़ाइल समावेशन कार्य, उदा। (PHP में): <code>include($page . '.php');</code> [[दूरस्थ फ़ाइल समावेशन]] भेद्यता का एक उदाहरण है | * फ़ाइल समावेशन कार्य, उदा। (PHP में): <code>include($page . '.php');</code> [[दूरस्थ फ़ाइल समावेशन]] भेद्यता का एक उदाहरण है | ||
* उन | * उन लाइब्रेरीज के लिए जो दुर्भावनापूर्ण कोड से जुड़े हो सकते हैं, आंतरिक परिवर्तनीय डेटा संरचना (रिकॉर्ड, सरणी) के संदर्भ को वापस कर रहे हैं। दुर्भावनापूर्ण कोड संरचना को संशोधित करने या भविष्य के परिवर्तनों को देखने के लिए संदर्भ को बनाए रखने का प्रयास कर सकता है। | ||
=== कम | === कम खतरा वाली भेद्यता === | ||
निम्नलिखित कम- | निम्नलिखित कम-खतरा भेद्यता की एक सूची है जो ऑडिटिंग कोड के समय पाई जानी चाहिए, किन्तु उच्च खतरा वाली स्थिति उत्पन्न नहीं करती है। | ||
* क्लाइंट-साइड कोड भेद्यताएं जो सर्वर साइड को प्रभावित नहीं करती हैं (उदाहरण के लिए, [[क्रॉस साइट स्क्रिप्टिंग]]) | * क्लाइंट-साइड कोड भेद्यताएं जो सर्वर साइड को प्रभावित नहीं करती हैं (उदाहरण के लिए, [[क्रॉस साइट स्क्रिप्टिंग]]) | ||
* उपयोगकर्ता नाम गणना | * उपयोगकर्ता नाम गणना | ||
| Line 20: | Line 20: | ||
== उपकरण == | == उपकरण == | ||
सोर्स कोड ऑडिटिंग टूल | सोर्स कोड ऑडिटिंग टूल सामान्यतः सामान्य कमजोरियों की तलाश करते हैं और केवल विशिष्ट [[प्रोग्रामिंग भाषा]]ओं के लिए काम करते हैं। इस प्रकार के स्वचालित उपकरणों का उपयोग समय बचाने के लिए किया जा सकता है, किन्तु गहन लेखापरीक्षा के लिए इस पर भरोसा नहीं किया जाना चाहिए। नीति-आधारित दृष्टिकोण के भाग के रूप में ऐसे उपकरणों को लागू करने की अनुशंसा की जाती है।<ref>"[http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1331438,00.html Static analysis at the end of the SDLC doesn't work] {{Webarchive|url=https://web.archive.org/web/20101015045541/http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1331438,00.html |date=2010-10-15 }}" by Wayne Ariola, SearchSoftwareQuality.com, September 22, 2008</ref> | ||
== आवश्यकताओं पर निर्भरता == | == आवश्यकताओं पर निर्भरता == | ||
यदि निम्न सीमा पर सेट किया जाता है, तो अधिकांश सॉफ़्टवेयर ऑडिटिंग टूल बहुत सारी कमजोरियों का पता लगाते हैं, खासकर यदि कोड का पहले ऑडिट नहीं किया गया हो। | यदि निम्न सीमा पर सेट किया जाता है, तो अधिकांश सॉफ़्टवेयर ऑडिटिंग टूल बहुत सारी कमजोरियों का पता लगाते हैं, खासकर यदि कोड का पहले ऑडिट नहीं किया गया हो। चूंकि इन अलर्ट का वास्तविक महत्व इस बात पर भी निर्भर करता है कि एप्लिकेशन का उपयोग कैसे किया जाता है। लाइब्रेरी जो दुर्भावनापूर्ण कोड से जुड़ी हो सकती है (और इसके विरुद्ध प्रतिरक्षा होनी चाहिए) में सभी लौटाए गए डेटा संरचनाओं को क्लोन करने जैसी सख्त आवश्यकताएं हैं, क्योंकि सिस्टम को तोड़ने के जानबूझकर प्रयासों की अपेक्षा की जाती है। प्रोग्राम जो केवल दुर्भावनापूर्ण इनपुट (जैसे वेब सर्वर बैकएंड) के संपर्क में आ सकता है, उसे पहले इस इनपुट (बफर ओवररन, एसक्यूएल इंजेक्शन, आदि) की परवाह करनी चाहिए। इस प्रकार के हमले उस प्रोग्राम के लिए कभी नहीं हो सकते हैं जो केवल संरक्षित बुनियादी ढांचे में अधिकृत उपयोगकर्ताओं द्वारा आंतरिक रूप से उपयोग किया जाता है। | ||
== यह भी देखें == | == यह भी देखें == | ||
Revision as of 21:01, 10 March 2023
एक सॉफ्टवेयर कोड ऑडिट कंप्यूटर प्रोग्रामिंग प्रोजेक्ट में बग, सुरक्षा उल्लंघनों या प्रोग्रामिंग सम्मेलनों के उल्लंघन की खोज के इरादे से स्रोत कोड का एक व्यापक विश्लेषण है। यह रक्षात्मक प्रोग्रामिंग प्रतिमान का एक अभिन्न अंग है, जो सॉफ़्टवेयर जारी होने से पहले त्रुटियों को कम करने का प्रयास करता है। सी और सी ++ स्रोत कोड ऑडिट करने के लिए सबसे आम कोड है क्योंकि कई उच्च-स्तरीय भाषाओं, जैसे कि पायथन, में कम संभावित कमजोर कार्य हैं (उदाहरण के लिए, कार्य जो सीमा की जांच नहीं करते हैं).
दिशानिर्देश
सॉफ़्टवेयर का ऑडिट करते समय, प्रत्येक महत्वपूर्ण घटक का अलग से और पूरे कार्यक्रम के साथ ऑडिट किया जाना चाहिए। पहले उच्च-खतरा भेद्यता (कंप्यूटिंग) की खोज करना और कम-खतरा भेद्यता पर काम करना एक अच्छा विचार है। उच्च-खतरा और कम-खतरा के बीच कमजोरियां सामान्यतः स्थिति के आधार पर सम्मिलित होती हैं और प्रश्न में स्रोत कोड का उपयोग कैसे किया जा रहा है। एप्लिकेशन पैठ परीक्षण एप्लिकेशन को कम करने के प्रयास में संभावित पहुंच बिंदुओं पर यथासंभव कई ज्ञात आक्रमण तकनीकों को लॉन्च करके सॉफ़्टवेयर में कमजोरियों की पहचान करने का प्रयास करता है।[1] यह एक सामान्य ऑडिटिंग विधि है और इसका उपयोग यह पता लगाने के लिए किया जा सकता है कि क्या कोई विशिष्ट भेद्यता सम्मिलित है, किन्तु यह नहीं कि वे स्रोत कोड में कहाँ हैं। कुछ लोग प्रमाणित करते हैं कि अंत-चक्र लेखापरीक्षा के तरीके डेवलपर्स को अभिभूत करते हैं, अंततः टीम को ज्ञात समस्याओं की एक लंबी सूची के साथ छोड़ देते हैं, किन्तु वास्तविक सुधार बहुत कम होता है; इन मामलों में, एक विकल्प के रूप में एक इन-लाइन ऑडिटिंग दृष्टिकोण की सिफारिश की जाती है।
उच्च खतरा भेद्यता
इसके उपयोग के कारण कुछ सामान्य उच्च-खतरा भेद्यताएं सम्मिलित हो सकती हैं:
- नॉन-बाउंड्स-चेकिंग फ़ंक्शंस (जैसे, strcpy, sprintf, vsprintf, और sscanf) जो बफ़र अधिकता भेद्यता का कारण बन सकते हैं [2]
- बफ़र्स का सूचक हेरफेर जो बाद की सीमा जाँच में हस्तक्षेप कर सकता है, जैसे:
if ((bytesread = net_read(buf,len)) > 0) buf += bytesread;[2]* निष्पादन (), निष्पादन पाइप, सिस्टम () और इसी प्रकार की चीजों की प्रकार कॉल, खासकर जब गैर-स्थैतिक तर्कों के साथ कहा जाता है [2]* इनपुट सत्यापन, उदा। (एसक्यूएल में):statement := "SELECT * FROM users WHERE name = '" + userName + "';"SQL इंजेक्शन भेद्यता का एक उदाहरण है - फ़ाइल समावेशन कार्य, उदा। (PHP में):
include($page . '.php');दूरस्थ फ़ाइल समावेशन भेद्यता का एक उदाहरण है - उन लाइब्रेरीज के लिए जो दुर्भावनापूर्ण कोड से जुड़े हो सकते हैं, आंतरिक परिवर्तनीय डेटा संरचना (रिकॉर्ड, सरणी) के संदर्भ को वापस कर रहे हैं। दुर्भावनापूर्ण कोड संरचना को संशोधित करने या भविष्य के परिवर्तनों को देखने के लिए संदर्भ को बनाए रखने का प्रयास कर सकता है।
कम खतरा वाली भेद्यता
निम्नलिखित कम-खतरा भेद्यता की एक सूची है जो ऑडिटिंग कोड के समय पाई जानी चाहिए, किन्तु उच्च खतरा वाली स्थिति उत्पन्न नहीं करती है।
- क्लाइंट-साइड कोड भेद्यताएं जो सर्वर साइड को प्रभावित नहीं करती हैं (उदाहरण के लिए, क्रॉस साइट स्क्रिप्टिंग)
- उपयोगकर्ता नाम गणना
- निर्देशिका ट्रैवर्सल
- संवेदनशील एपीआई कुंजी
उपकरण
सोर्स कोड ऑडिटिंग टूल सामान्यतः सामान्य कमजोरियों की तलाश करते हैं और केवल विशिष्ट प्रोग्रामिंग भाषाओं के लिए काम करते हैं। इस प्रकार के स्वचालित उपकरणों का उपयोग समय बचाने के लिए किया जा सकता है, किन्तु गहन लेखापरीक्षा के लिए इस पर भरोसा नहीं किया जाना चाहिए। नीति-आधारित दृष्टिकोण के भाग के रूप में ऐसे उपकरणों को लागू करने की अनुशंसा की जाती है।[3]
आवश्यकताओं पर निर्भरता
यदि निम्न सीमा पर सेट किया जाता है, तो अधिकांश सॉफ़्टवेयर ऑडिटिंग टूल बहुत सारी कमजोरियों का पता लगाते हैं, खासकर यदि कोड का पहले ऑडिट नहीं किया गया हो। चूंकि इन अलर्ट का वास्तविक महत्व इस बात पर भी निर्भर करता है कि एप्लिकेशन का उपयोग कैसे किया जाता है। लाइब्रेरी जो दुर्भावनापूर्ण कोड से जुड़ी हो सकती है (और इसके विरुद्ध प्रतिरक्षा होनी चाहिए) में सभी लौटाए गए डेटा संरचनाओं को क्लोन करने जैसी सख्त आवश्यकताएं हैं, क्योंकि सिस्टम को तोड़ने के जानबूझकर प्रयासों की अपेक्षा की जाती है। प्रोग्राम जो केवल दुर्भावनापूर्ण इनपुट (जैसे वेब सर्वर बैकएंड) के संपर्क में आ सकता है, उसे पहले इस इनपुट (बफर ओवररन, एसक्यूएल इंजेक्शन, आदि) की परवाह करनी चाहिए। इस प्रकार के हमले उस प्रोग्राम के लिए कभी नहीं हो सकते हैं जो केवल संरक्षित बुनियादी ढांचे में अधिकृत उपयोगकर्ताओं द्वारा आंतरिक रूप से उपयोग किया जाता है।
यह भी देखें
- सूचना प्रौद्योगिकी लेखा परीक्षा
- रक्षात्मक प्रोग्रामिंग
- दूरस्थ फ़ाइल समावेशन
- एसक्यूएल इंजेक्षन
- बफ़र अधिकता
- स्थैतिक कोड विश्लेषण के लिए उपकरणों की सूची
संदर्भ
- ↑ "सोर्स कोड ऑडिट - एफएक्यू". Archived from the original on 2009-02-10. Retrieved 2008-02-12.
- ↑ 2.0 2.1 2.2 "सी सोर्स कोड ऑडिटिंग के लिए दिशानिर्देश". Archived from the original on 2008-03-28. Retrieved 2008-02-12.
- ↑ "Static analysis at the end of the SDLC doesn't work Archived 2010-10-15 at the Wayback Machine" by Wayne Ariola, SearchSoftwareQuality.com, September 22, 2008
