कोड ऑडिट: Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
 
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Short description|Comprehensive analysis of software source code}}
{{Short description|Comprehensive analysis of software source code}}
एक सॉफ्टवेयर कोड ऑडिट [[कंप्यूटर प्रोग्रामिंग]] प्रोजेक्ट में बग, सुरक्षा उल्लंघनों या प्रोग्रामिंग सम्मेलनों के उल्लंघन की खोज के इरादे से स्रोत कोड का एक व्यापक विश्लेषण है। यह [[रक्षात्मक प्रोग्रामिंग]] प्रतिमान का एक अभिन्न अंग है, जो सॉफ़्टवेयर जारी होने से पहले त्रुटियों को कम करने का प्रयास करता है। सी और सी ++ स्रोत कोड ऑडिट करने के लिए सबसे आम कोड है क्योंकि कई उच्च-स्तरीय भाषाओं, जैसे कि पायथन, में कम संभावित कमजोर कार्य हैं (उदाहरण के लिए, कार्य जो सीमा की जांच नहीं करते हैं).
सॉफ्टवेयर '''कोड ऑडिट''' मुख्य रूप से [[कंप्यूटर प्रोग्रामिंग]] में बनाये जाने वाले प्रोजेक्ट में बग की जाँच करने सुरक्षा उल्लंघनों तथा प्रोग्रामिंग संयोजन के उल्लंघन की खोज के फलस्वरूप सोर्स कोड का व्यापक विश्लेषण है। यह [[रक्षात्मक प्रोग्रामिंग]] प्रतिमान का अभिन्न अंग है, जो सॉफ़्टवेयर प्रस्तुत होने से पहले त्रुटियों को कम करने का प्रयास करता है। सी और सी ++ सोर्स कोड ऑडिट करने के लिए सबसे सरल कोड है क्योंकि कई उच्च-स्तरीय भाषाओं में जैसे पायथन में कम संभावित कार्य होते हैं, उदाहरण के लिए किसी कार्य की सीमा की जांच नहीं की जाती हैं।


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


=== उच्च जोखिम भेद्यता ===
=== उच्च खतरे के फलस्वरूप होने वाली भेद्यता ===
इसके उपयोग के कारण कुछ सामान्य उच्च-जोखिम भेद्यताएं मौजूद हो सकती हैं:
इसके उपयोग के कारण कुछ सामान्य उच्च-खतरा भेद्यताएं सम्मिलित हो सकती हैं:
* नॉन-बाउंड्स-चेकिंग फ़ंक्शंस (जैसे, [[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"/>* निष्पादन (), निष्पादन पाइप, सिस्टम () और इसी तरह की चीजों की तरह कॉल, खासकर जब गैर-स्थैतिक तर्कों के साथ कहा जाता है <ref name="guidelines-for-c-source-code-auditing"/>* इनपुट सत्यापन, उदा। (एसक्यूएल में): <code>statement := "SELECT * FROM users WHERE name = '" + userName + "';"</code> SQL इंजेक्शन भेद्यता का एक उदाहरण है
* बफ़र्स का सूचक के परिवर्तन होने के बाद की सीमा की जाँच में हस्तक्षेप कर सकता है, जैसे: <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>
सोर्स कोड ऑडिटिंग टूल सामान्यतः कमजोरियों की खोज करते हैं और केवल विशिष्ट [[प्रोग्रामिंग भाषा]]ओं के लिए कार्य करते हैं। इस प्रकार के स्वचालित उपकरणों का उपयोग समय बचाने के लिए किया जा सकता है, किन्तु गहन लेखापरीक्षा के लिए इस पर विश्वास नहीं किया जाना चाहिए। इस प्रकार नीति-आधारित दृष्टिकोण के घटक के रूप में ऐसे उपकरणों को लागू करने की अनुशंसा की जाती है।<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>
== आवश्यकताओं पर निर्भरता ==
== आवश्यकताओं पर निर्भरता ==
यदि निम्न सीमा पर सेट किया जाता है, तो अधिकांश सॉफ़्टवेयर ऑडिटिंग टूल बहुत सारी कमजोरियों का पता लगाते हैं, खासकर यदि कोड का पहले ऑडिट नहीं किया गया हो। हालाँकि इन अलर्ट का वास्तविक महत्व इस बात पर भी निर्भर करता है कि एप्लिकेशन का उपयोग कैसे किया जाता है। लाइब्रेरी जो दुर्भावनापूर्ण कोड से जुड़ी हो सकती है (और इसके खिलाफ प्रतिरक्षा होनी चाहिए) में सभी लौटाए गए डेटा संरचनाओं को क्लोन करने जैसी सख्त आवश्यकताएं हैं, क्योंकि सिस्टम को तोड़ने के जानबूझकर प्रयासों की अपेक्षा की जाती है। प्रोग्राम जो केवल दुर्भावनापूर्ण इनपुट (जैसे वेब सर्वर बैकएंड) के संपर्क में आ सकता है, उसे पहले इस इनपुट (बफर ओवररन, एसक्यूएल इंजेक्शन, आदि) की परवाह करनी चाहिए। इस तरह के हमले उस प्रोग्राम के लिए कभी नहीं हो सकते हैं जो केवल संरक्षित बुनियादी ढांचे में अधिकृत उपयोगकर्ताओं द्वारा आंतरिक रूप से उपयोग किया जाता है।
यदि निम्न सीमा पर सेट किया जाता है, तो अधिकांश सॉफ़्टवेयर ऑडिटिंग टूल बहुत सारी कमजोरियों का पता लगाते हैं, मुख्य रूप से यदि कोड का पहले ऑडिट नहीं किया गया हो। चूंकि इन अलर्ट का वास्तविक महत्व इस बात पर भी निर्भर करता है कि एप्लिकेशन का उपयोग कैसे किया जाता है। लाइब्रेरी जो दुर्भावनापूर्ण कोड से जुड़ी हो सकती है (और इसके विरुद्ध प्रतिरक्षा होनी चाहिए) में सभी लौटाए गए डेटा संरचनाओं को क्लोन करने जैसी सख्त आवश्यकताएं हैं, क्योंकि सिस्टम को तोड़ने के लिए किये जाने वाले प्रयासों की समीक्षा की जाती है। इस प्रकार वे प्रोग्राम जो केवल दुर्भावनापूर्ण इनपुट (जैसे वेब सर्वर बैकएंड) के संपर्क में आ जाते हैं, उसे पहले इस इनपुट (बफर ओवररन, एसक्यूएल इंजेक्शन, आदि) के बारे में सोचना चाहिए। इस प्रकार के हमले इन प्रोग्राम्स के लिए कभी नहीं हो सकते हैं जो केवल संरक्षित मौलिक ढांचे में अधिकृत उपयोगकर्ताओं द्वारा आंतरिक रूप से उपयोग किया जाता है।


== यह भी देखें ==
== यह भी देखें ==
Line 34: Line 34:
== संदर्भ ==
== संदर्भ ==
{{reflist}}
{{reflist}}
[[Category: सूचना प्रौद्योगिकी लेखा परीक्षा]]


[[Category: Machine Translated Page]]
[[Category:Created On 02/03/2023]]
[[Category:Created On 02/03/2023]]
[[Category:Lua-based templates]]
[[Category:Machine Translated Page]]
[[Category:Pages with script errors]]
[[Category:Short description with empty Wikidata description]]
[[Category:Templates Vigyan Ready]]
[[Category:Templates that add a tracking category]]
[[Category:Templates that generate short descriptions]]
[[Category:Templates using TemplateData]]
[[Category:Webarchive template wayback links]]
[[Category:सूचना प्रौद्योगिकी लेखा परीक्षा]]

Latest revision as of 18:08, 15 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]

आवश्यकताओं पर निर्भरता

यदि निम्न सीमा पर सेट किया जाता है, तो अधिकांश सॉफ़्टवेयर ऑडिटिंग टूल बहुत सारी कमजोरियों का पता लगाते हैं, मुख्य रूप से यदि कोड का पहले ऑडिट नहीं किया गया हो। चूंकि इन अलर्ट का वास्तविक महत्व इस बात पर भी निर्भर करता है कि एप्लिकेशन का उपयोग कैसे किया जाता है। लाइब्रेरी जो दुर्भावनापूर्ण कोड से जुड़ी हो सकती है (और इसके विरुद्ध प्रतिरक्षा होनी चाहिए) में सभी लौटाए गए डेटा संरचनाओं को क्लोन करने जैसी सख्त आवश्यकताएं हैं, क्योंकि सिस्टम को तोड़ने के लिए किये जाने वाले प्रयासों की समीक्षा की जाती है। इस प्रकार वे प्रोग्राम जो केवल दुर्भावनापूर्ण इनपुट (जैसे वेब सर्वर बैकएंड) के संपर्क में आ जाते हैं, उसे पहले इस इनपुट (बफर ओवररन, एसक्यूएल इंजेक्शन, आदि) के बारे में सोचना चाहिए। इस प्रकार के हमले इन प्रोग्राम्स के लिए कभी नहीं हो सकते हैं जो केवल संरक्षित मौलिक ढांचे में अधिकृत उपयोगकर्ताओं द्वारा आंतरिक रूप से उपयोग किया जाता है।

यह भी देखें

संदर्भ

  1. ↑ "सोर्स कोड ऑडिट - एफएक्यू". Archived from the original on 2009-02-10. Retrieved 2008-02-12.
  2. ↑ 2.0 2.1 2.2 "सी सोर्स कोड ऑडिटिंग के लिए दिशानिर्देश". Archived from the original on 2008-03-28. Retrieved 2008-02-12.
  3. ↑ "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
Retrieved from ‘https://www.vigyanwiki.in/index.php?title=कोड_ऑडिट&oldid=108982’