कोड ऑडिट: 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> यह सामान्यतः ऑडिटिंग विधि है और इसका उपयोग यह पता लगाने के लिए किया जाता हैं कि क्या कोई विशिष्ट भेद्यता सम्मिलित हैं, किन्तु यह नहीं कि वे सोर्स कोड में कहाँ पर उपस्थित हैं। कुछ लोग प्रमाणित करते हैं कि अंतः चक्र लेखापरीक्षा की विधियों के कारण डेवलपर्स को अभिभूत कराया जाता हैं, इस प्रकार अंततः टीम की ज्ञात समस्याओं की लंबी सूची के साथ इसे छोड़ देते हैं, किन्तु इसमें वास्तविक सुधार बहुत कम होता है, इन स्थितियों में, विकल्पों के अनुरूप इन-लाइन ऑडिटिंग दृष्टिकोण की जाँत की जाती हैं। | सॉफ़्टवेयर को ऑडिट करते समय प्रत्येक महत्वपूर्ण घटक का अलग से पूरे कार्यक्रम के साथ ऑडिट किया जाना चाहिए। इस प्रकार पहले उच्च खतरों के [[भेद्यता (कंप्यूटिंग)]] की खोज करना और कम खतरों की भेद्यता पर कार्य करना अच्छा विचार है। उच्च खतरे और कम खतरे के बीच कमजोरियों के लिए सामान्यतः इसकी स्थिति के आधार पर सम्मिलित की जाती हैं और प्रश्नों के फलस्वरूप यह भी देखा जाता हैं कि सोर्स कोड का उपयोग कैसे किया जा रहा है। इस प्रकार एप्लिकेशन कोड के परीक्षण द्वारा एप्लिकेशन को कम करने के प्रयास में संभावित मुख्य बिंदुओं पर यथासंभव कई ज्ञात तकनीकों को लॉन्च करके सॉफ़्टवेयर में कमजोरियों की पहचान करने का प्रयास किया जाता हैं।<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> इस प्रकार यह सामान्यतः ऑडिटिंग विधि है और इसका उपयोग यह पता लगाने के लिए किया जाता हैं कि क्या कोई विशिष्ट भेद्यता सम्मिलित हैं, किन्तु यह नहीं कि वे सोर्स कोड में कहाँ पर उपस्थित हैं। कुछ लोग प्रमाणित करते हैं कि अंतः चक्र लेखापरीक्षा की विधियों के कारण डेवलपर्स को अभिभूत कराया जाता हैं, इस प्रकार अंततः टीम की ज्ञात समस्याओं की लंबी सूची के साथ इसे छोड़ देते हैं, किन्तु इसमें वास्तविक सुधार बहुत कम होता है, इन स्थितियों में, विकल्पों के अनुरूप इन-लाइन ऑडिटिंग दृष्टिकोण की जाँत की जाती हैं। | ||
=== उच्च खतरे के फलस्वरूप होने वाली भेद्यता === | === उच्च खतरे के फलस्वरूप होने वाली भेद्यता === | ||
| Line 13: | Line 13: | ||
=== कम खतरे वाली भेद्यता === | === कम खतरे वाली भेद्यता === | ||
निम्नलिखित कम | निम्नलिखित कम खतरे वाले भेद्यताओं की सूची है जो ऑडिटिंग कोड के समय पाई जानी चाहिए, किन्तु उच्च खतरा वाली स्थिति उत्पन्न नहीं करती है। | ||
* क्लाइंट-साइड कोड भेद्यताएं जो सर्वर साइड को प्रभावित नहीं करती हैं (उदाहरण के लिए, [[क्रॉस साइट स्क्रिप्टिंग]]) | * क्लाइंट-साइड कोड भेद्यताएं जो सर्वर साइड को प्रभावित नहीं करती हैं (उदाहरण के लिए, [[क्रॉस साइट स्क्रिप्टिंग]]) | ||
* उपयोगकर्ता नाम गणना | * उपयोगकर्ता नाम गणना | ||
| Line 22: | Line 22: | ||
सोर्स कोड ऑडिटिंग टूल सामान्यतः कमजोरियों की खोज करते हैं और केवल विशिष्ट [[प्रोग्रामिंग भाषा]]ओं के लिए कार्य करते हैं। इस प्रकार के स्वचालित उपकरणों का उपयोग समय बचाने के लिए किया जा सकता है, किन्तु गहन लेखापरीक्षा के लिए इस पर विश्वास नहीं किया जाना चाहिए। इस प्रकार नीति-आधारित दृष्टिकोण के घटक के रूप में ऐसे उपकरणों को लागू करने की अनुशंसा की जाती है।<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 23:04, 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
