कोड ऑडिट: Difference between revisions
(Created page with "{{Short description|Comprehensive analysis of software source code}} एक सॉफ्टवेयर कोड ऑडिट कंप्यूटर प्रोग्र...") |
No edit summary |
||
| Line 1: | Line 1: | ||
{{Short description|Comprehensive analysis of software source code}} | {{Short description|Comprehensive analysis of software source code}} | ||
एक सॉफ्टवेयर कोड ऑडिट [[कंप्यूटर प्रोग्रामिंग]] प्रोजेक्ट में बग, सुरक्षा उल्लंघनों या प्रोग्रामिंग सम्मेलनों के उल्लंघन की खोज के इरादे से स्रोत कोड का एक व्यापक विश्लेषण है। यह [[रक्षात्मक प्रोग्रामिंग]] प्रतिमान का एक अभिन्न अंग है, जो सॉफ़्टवेयर जारी होने से पहले त्रुटियों को कम करने का प्रयास करता है। सी और सी ++ स्रोत कोड ऑडिट करने के लिए सबसे आम कोड है क्योंकि कई उच्च-स्तरीय भाषाओं, जैसे कि पायथन, में कम संभावित कमजोर कार्य हैं (उदाहरण के लिए, कार्य जो सीमा की जांच नहीं करते हैं) | एक सॉफ्टवेयर कोड ऑडिट [[कंप्यूटर प्रोग्रामिंग]] प्रोजेक्ट में बग, सुरक्षा उल्लंघनों या प्रोग्रामिंग सम्मेलनों के उल्लंघन की खोज के इरादे से स्रोत कोड का एक व्यापक विश्लेषण है। यह [[रक्षात्मक प्रोग्रामिंग]] प्रतिमान का एक अभिन्न अंग है, जो सॉफ़्टवेयर जारी होने से पहले त्रुटियों को कम करने का प्रयास करता है। सी और सी ++ स्रोत कोड ऑडिट करने के लिए सबसे आम कोड है क्योंकि कई उच्च-स्तरीय भाषाओं, जैसे कि पायथन, में कम संभावित कमजोर कार्य हैं (उदाहरण के लिए, कार्य जो सीमा की जांच नहीं करते हैं). | ||
== दिशानिर्देश == | == दिशानिर्देश == | ||
| Line 21: | Line 21: | ||
== उपकरण == | == उपकरण == | ||
सोर्स कोड ऑडिटिंग टूल आम तौर पर सामान्य कमजोरियों की तलाश करते हैं और केवल विशिष्ट [[प्रोग्रामिंग भाषा]]ओं के लिए काम करते हैं। इस तरह के स्वचालित उपकरणों का उपयोग समय बचाने के लिए किया जा सकता है, लेकिन गहन लेखापरीक्षा के लिए इस पर भरोसा नहीं किया जाना चाहिए। नीति-आधारित दृष्टिकोण के भाग के रूप में ऐसे उपकरणों को लागू करने की अनुशंसा की जाती है।<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> | सोर्स कोड ऑडिटिंग टूल आम तौर पर सामान्य कमजोरियों की तलाश करते हैं और केवल विशिष्ट [[प्रोग्रामिंग भाषा]]ओं के लिए काम करते हैं। इस तरह के स्वचालित उपकरणों का उपयोग समय बचाने के लिए किया जा सकता है, लेकिन गहन लेखापरीक्षा के लिए इस पर भरोसा नहीं किया जाना चाहिए। नीति-आधारित दृष्टिकोण के भाग के रूप में ऐसे उपकरणों को लागू करने की अनुशंसा की जाती है।<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 20:06, 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
