रक्षात्मक प्रोग्रामिंग: Difference between revisions

From Vigyanwiki
(Created page with "{{Short description|Software development methodology}} {{Use American English|date=November 2020}} {{howto|date=March 2012}} रक्षात्मक प्रोग्र...")
 
No edit summary
 
(7 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{Short description|Software development methodology}}
{{Short description|Software development methodology}}
{{Use American English|date=November 2020}}
{{Use American English|date=November 2020}}
{{howto|date=March 2012}}
रक्षात्मक प्रोग्रामिंग [[रक्षात्मक डिजाइन]] का एक रूप है जिसका उद्देश्य उन कार्यक्रमों को विकसित करना है जो संभावित सुरक्षा असामान्यताओं का पता लगाने और पूर्व निर्धारित प्रतिक्रिया देने में सक्षम हैं।<ref>{{Citation |last=Boulanger |first=Jean-Louis |title=6 - Technique to Manage Software Safety |date=2016-01-01 |url=https://www.sciencedirect.com/science/article/pii/B9781785481178500064 |work=Certifiable Software Applications 1 |pages=125–156 |editor-last=Boulanger |editor-first=Jean-Louis |publisher=Elsevier |language=en |isbn=978-1-78548-117-8 |access-date=2022-09-02}}</ref> यह अप्रत्याशित परिस्थितियों में सॉफ्टवेयर के एक टुकड़े के निरंतर कार्य को सुनिश्चित करता है। रक्षात्मक प्रोग्रामिंग प्रथाओं का अक्सर उपयोग किया जाता है जहां [[उच्च उपलब्धता]], [[सुरक्षा]] या [[कंप्यूटर सुरक्षा]] की आवश्यकता होती है।


रक्षात्मक प्रोग्रामिंग सॉफ्टवेयर और स्रोत कोड को बेहतर बनाने के लिए एक दृष्टिकोण है:
'''रक्षात्मक प्रोग्रामिंग''' उन [[रक्षात्मक डिजाइन]] का एक रूप है जिसका उद्देश्य उन कार्यक्रमों को विकसित करना है जो संभावित सुरक्षा असामान्यताओं का पता लगाने और पूर्व निर्धारित प्रतिक्रियाएं करने में सक्षम हैं।<ref>{{Citation |last=Boulanger |first=Jean-Louis |title=6 - Technique to Manage Software Safety |date=2016-01-01 |url=https://www.sciencedirect.com/science/article/pii/B9781785481178500064 |work=Certifiable Software Applications 1 |pages=125–156 |editor-last=Boulanger |editor-first=Jean-Louis |publisher=Elsevier |language=en |isbn=978-1-78548-117-8 |access-date=2022-09-02}}</ref> यह अप्रत्याशित परिस्थितियों में सॉफ्टवेयर के एक भाग के निरंतर कार्य को सुनिश्चित करता है। रक्षात्मक प्रोग्रामिंग प्रथाओं का उपयोग प्रायः किया जाता है जहां [[उच्च उपलब्धता]], [[सुरक्षा]] या सुरक्षा की आवश्यकता होती है।
* सामान्य गुणवत्ता - [[सॉफ्टवेयर बग]] और समस्याओं की संख्या कम करना।
* स्रोत कोड को बोधगम्य बनाना - स्रोत कोड को पठनीय और समझने योग्य होना चाहिए ताकि इसे [[कोड ऑडिट]] में अनुमोदित किया जा सके।
* अनपेक्षित इनपुट या उपयोगकर्ता क्रियाओं के बावजूद [[सॉफ़्टवेयर]] को पूर्वानुमेय तरीके से व्यवहार करना।


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


== सुरक्षित प्रोग्रामिंग ==
== सुरक्षित प्रोग्रामिंग ==
{{main|Secure coding}}
{{main|सुरक्षित कोडिंग}}
सुरक्षित प्रोग्रामिंग कंप्यूटर सुरक्षा से संबंधित रक्षात्मक प्रोग्रामिंग का सबसेट है। सुरक्षा चिंता का विषय है, जरूरी नहीं कि सुरक्षा या उपलब्धता (सॉफ़्टवेयर को कुछ तरीकों से विफल होने की अनुमति दी जा सकती है)। जैसा कि सभी प्रकार की रक्षात्मक प्रोग्रामिंग के साथ होता है, बग से बचना एक प्राथमिक उद्देश्य है; हालाँकि, प्रेरणा सामान्य ऑपरेशन में विफलता की संभावना को कम करने के लिए उतनी नहीं है (जैसे कि सुरक्षा चिंता थी), लेकिन हमले की सतह को कम करने के लिए - प्रोग्रामर को यह मान लेना चाहिए कि बग को प्रकट करने के लिए सॉफ़्टवेयर का सक्रिय रूप से दुरुपयोग किया जा सकता है, और वह बगों का दुर्भावना से शोषण किया जा सकता है।
 
सुरक्षित प्रोग्रामिंग, कंप्यूटर सुरक्षा से संबंधित रक्षात्मक प्रोग्रामिंग का एक उपसमुच्चय है। सुरक्षा एक चिंता का विषय है, आवश्यक रूप से सुरक्षा या उपलब्धता नहीं (सॉफ़्टवेयर को कुछ तरीकों से विफल होने की अनुमति दी जा सकती है)। रक्षात्मक प्रोग्रामिंग के सभी रूपों के साथ, बग से बचना एक प्राथमिक उद्देश्य है; हालांकि, प्रेरणा सामान्य ऑपरेशन में विफलता की संभावना को कम करने के लिए इतनी अधिक नहीं है (जैसे कि वह एक सुरक्षा चिंता थी), लेकिन हमले की सतह को कम करने के लिए - प्रोग्रामर को यह मान लेना चाहिए कि सॉफ्टवेयर बग को प्रकट करने में सक्षम होगा। के लिए डिजाइन किया जाएगा। इसका सक्रिय रूप से दुरुपयोग किया जा सकता है और बग का दुर्भावनापूर्ण तरीके से उपयोग किया जा सकता है।


<syntaxhighlight lang= c >int risky_programming(char *input) {
<syntaxhighlight lang="c">int risky_programming(char *input) {
   चार str [1000];
   char str[1000];  
    
    
   // ...
   // ...
    
    
   strcpy (एसटीआर, इनपुट); // कॉपी इनपुट।
   strcpy(str, input); // Copy input.
    
    
   // ...
   // ...
}</syntaxhighlight>
}</syntaxhighlight>
1000 वर्णों से अधिक इनपुट होने पर फ़ंक्शन अपरिभाषित व्यवहार का परिणाम देगा। कुछ प्रोग्रामर यह महसूस नहीं कर सकते हैं कि यह एक समस्या है, यह मानते हुए कि कोई भी उपयोगकर्ता इतने लंबे इनपुट में प्रवेश नहीं करेगा। यह विशेष बग एक भेद्यता प्रदर्शित करता है जो [[बफ़र अधिकता]] [[शोषण (कंप्यूटर सुरक्षा)]] को सक्षम करता है। यहाँ इस उदाहरण का समाधान है:
फ़ंक्शन को अपरिभाषित व्यवहार में परिणाम होगा जब इनपुट 1000 से अधिक वर्णों का है। कुछ प्रोग्रामर यह महसूस नहीं कर सकते हैं कि यह एक समस्या है, यह मानते हुए कि कोई भी उपयोगकर्ता इतने लंबे इनपुट में प्रवेश नहीं करेगा। यह विशेष बग एक भेद्यता को प्रदर्शित करता है जो '''बफर ओवरफ्लो एक्सप्लॉइट्स''' को सक्षम करता है। यहाँ इस उदाहरण का समाधान है:


<syntaxhighlight lang= c>int Secure_programming(char *input) {
<syntaxhighlight lang="c">int secure_programming(char *input) {
   चार str [1000 + 1]; // अशक्त चरित्र के लिए एक और।
   char str[1000+1]; // One more for the null character.


   // ...
   // ...


   // गंतव्य की लंबाई को पार किए बिना इनपुट कॉपी करें।
   // Copy input without exceeding the length of the destination.
   strncpy (एसटीआर, इनपुट, आकार (एसटीआर));
   strncpy(str, input, sizeof(str));


   // यदि strlen(input) >= sizeof(str) तो strncpy समाप्त नहीं होगा।
   // If strlen(input) >= sizeof(str) then strncpy won't null terminate.
   // हम हमेशा एनयूएल के लिए बफर में अंतिम वर्ण सेट करके इसका मुकाबला करते हैं,
   // We counter this by always setting the last character in the buffer to NUL,
   // प्रभावी ढंग से स्ट्रिंग को अधिकतम लंबाई तक क्रॉप करना जिसे हम संभाल सकते हैं।
   // effectively cropping the string to the maximum length we can handle.
   // अगर कोई स्ट्रेलन (इनपुट) है तो प्रोग्राम को स्पष्ट रूप से निरस्त करने का निर्णय भी ले सकता है
   // One can also decide to explicitly abort the program if strlen(input) is
   // बहुत लंबा।
   // too long.
   str[sizeof(str) - 1] = '\0';
   str[sizeof(str) - 1] = '\0';


Line 44: Line 46:
}</syntaxhighlight>
}</syntaxhighlight>


== आक्रामक प्रोग्रामिंग ==
== आक्रामक प्रोग्रामिंग (ओफ्फेंसिव प्रोग्रामिंग) ==
{{main|Offensive programming}}
{{main|ओफ्फेंसिव प्रोग्रामिंग }}
आपत्तिजनक प्रोग्रामिंग रक्षात्मक प्रोग्रामिंग की एक श्रेणी है, जिसमें इस बात पर जोर दिया गया है कि कुछ त्रुटियां सुंदर गिरावट नहीं होनी चाहिए। इस अभ्यास में, केवल प्रोग्राम के नियंत्रण के बाहर की त्रुटियों को नियंत्रित किया जाता है (जैसे कि उपयोगकर्ता इनपुट); इस [[कार्यप्रणाली]] में स्वयं सॉफ्टवेयर, साथ ही कार्यक्रम की रक्षा पंक्ति के भीतर के डेटा पर भरोसा किया जाना चाहिए।
 
आक्रामक प्रोग्रामिंग रक्षात्मक प्रोग्रामिंग की एक श्रेणी है, इस जोर के साथ कि कुछ त्रुटियों को रक्षात्मक रूप से संभाला नहीं जाना चाहिए। इस अभ्यास में, कार्यक्रम के नियंत्रण के बाहर से केवल त्रुटियों को संभाला जाना है (जैसे उपयोगकर्ता इनपुट); सॉफ्टवेयर, साथ ही साथ कार्यक्रम की रक्षा की लाइन के भीतर से डेटा, इस पद्धति में भरोसा किया जाना है।
 
=== आंतरिक डेटा वैधता पर विश्वास करना ===
'''अत्यधिक रक्षात्मक प्रोग्रामिंग'''
 
<syntaxhighlight lang="c">const char* trafficlight_colorname(enum traffic_light_color c) {
 
   switch (c) {
 
       case TRAFFICLIGHT_RED:    return "red";
 
       case TRAFFICLIGHT_YELLOW: return "yellow";
 
       case TRAFFICLIGHT_GREEN:  return "green";
 
   }
 
   return "black"; // To be handled as a dead traffic light.
 
   // Warning: This last 'return' statement will be dropped by an optimizing
 
   // compiler if all possible values of 'traffic_light_color' are listed in
 
   // the previous 'switch' statement...


=== आंतरिक डेटा वैधता पर भरोसा ===
}</syntaxhighlight>


अत्यधिक रक्षात्मक प्रोग्रामिंग
'''ओफ्फेंसिव प्रोग्रामिंग'''
<वाक्यविन्यास प्रकाश लैंग = सी>
const char* trafficlight_colorname(enum traffic_light_color c) {
    स्विच (सी) {
        मामला TRAFFICLIGHT_RED: वापसी लाल;
        मामला TRAFFICLIGHT_YELLOW: पीला लौटें;
        केस TRAFFICLIGHT_GREEN: रिटर्न ग्रीन;
    }
    काला लौटें; // एक मृत ट्रैफिक लाइट के रूप में संभाला जाना।
    // चेतावनी: यह अंतिम 'वापसी' कथन एक अनुकूलन द्वारा हटा दिया जाएगा
    // कंपाइलर यदि 'traffic_light_color' के सभी संभावित मान सूचीबद्ध हैं
    // पिछला 'स्विच' स्टेटमेंट ...
}
</वाक्यविन्यास हाइलाइट>


आक्रामक प्रोग्रामिंग
<syntaxhighlight lang="c">const char* trafficlight_colorname(enum traffic_light_color c) {
<वाक्यविन्यास प्रकाश लैंग = सी>
const char* trafficlight_colorname(enum traffic_light_color c) {
    स्विच (सी) {
        मामला TRAFFICLIGHT_RED: वापसी लाल;
        मामला TRAFFICLIGHT_YELLOW: पीला लौटें;
        केस TRAFFICLIGHT_GREEN: रिटर्न ग्रीन;
    }
    मुखर (0); // जोर दें कि यह खंड पहुंच योग्य नहीं है।
    // चेतावनी: यह 'जोर' फ़ंक्शन कॉल एक अनुकूलन द्वारा हटा दी जाएगी
    // कंपाइलर यदि 'traffic_light_color' के सभी संभावित मान सूचीबद्ध हैं
    // पिछला 'स्विच' स्टेटमेंट ...
}
</वाक्यविन्यास हाइलाइट>


=== सॉफ्टवेयर घटकों पर भरोसा करना ===
   switch (c) {


अत्यधिक रक्षात्मक प्रोग्रामिंग
       case TRAFFICLIGHT_RED:    return "red";
<वाक्यविन्यास प्रकाश लैंग = सी>
अगर (is_legacy_संगत (user_config)) {
    // रणनीति: विश्वास न करें कि नया कोड वही व्यवहार करता है
    पुराना_कोड (user_config);
} अन्य {
    // फ़ॉलबैक: विश्वास न करें कि नया कोड समान मामलों को संभालता है
    अगर (new_code (user_config)! = ठीक है) {
        पुराना_कोड (user_config);
    }
}
</वाक्यविन्यास हाइलाइट>


आक्रामक प्रोग्रामिंग
       case TRAFFICLIGHT_YELLOW: return "yellow";
<वाक्यविन्यास प्रकाश लैंग = सी>
// अपेक्षा करें कि नए कोड में कोई नई बग नहीं है
अगर (new_code (user_config)! = ठीक है) {
    // जोर से रिपोर्ट करें और उचित ध्यान पाने के लिए कार्यक्रम को अचानक समाप्त कर दें
    रिपोर्ट_त्रुटि (कुछ बहुत गलत हो गया);
    बाहर निकलें (-1);
}
</वाक्यविन्यास हाइलाइट>


       case TRAFFICLIGHT_GREEN:  return "green";
   }
   assert(0); // Assert that this section is unreachable.
   // Warning: This 'assert' function call will be dropped by an optimizing
   // compiler if all possible values of 'traffic_light_color' are listed in
   // the previous 'switch' statement...
}</syntaxhighlight>
=== सॉफ्टवेयर घटकों पर विश्वास करना ===
'''अत्यधिक रक्षात्मक प्रोग्रामिंग'''
if (is_legacy_compatible(user_config)) {
  // Strategy: Don't trust that the new code behaves the same
  old_code(user_config);
} else {
  // Fallback: Don't trust that the new code handles the same cases
  if (new_code(user_config)n!= OK) {
  old_code(user_config);
  }
}
'''आक्रामक प्रोग्रामिंग'''
  // Expect that the new code has no new bugs
if (new_code(user_config))!= OK) {
  // Loudly report and abruptly terminate program to get proper attention
  report_error("Something went very wrong");
  exit(-1);
}
== तकनीक ==
== तकनीक ==
यहाँ कुछ रक्षात्मक प्रोग्रामिंग तकनीकें हैं:
यहाँ कुछ रक्षात्मक प्रोग्रामिंग तकनीकें हैं:


=== बुद्धिमान स्रोत कोड पुन: उपयोग ===
=== इंटेलिजेंट सोर्स कोड का पुन: उपयोग ===
यदि मौजूदा कोड का परीक्षण किया गया है और काम करने के लिए जाना जाता है, तो इसका पुन: उपयोग करने से बग्स के पेश होने की संभावना कम हो सकती है।
यदि मौजूदा कोड का परीक्षण किया गया है और काम करने के लिए जाना जाता है, तो इसका पुन: उपयोग करने से बग्स के पेश होने की संभावना कम हो सकती है।


हालाँकि, कोड का पुन: उपयोग करना हमेशा अच्छा अभ्यास नहीं होता है। मौजूदा कोड का पुन: उपयोग, विशेष रूप से जब व्यापक रूप से वितरित किया जाता है, ऐसे शोषण के लिए अनुमति दे सकता है जो अन्यथा संभव से अधिक व्यापक दर्शकों को लक्षित करता है और पुन: उपयोग किए गए कोड की सभी सुरक्षा और कमजोरियों को अपने साथ लाता है।
हालाँकि, कोड का पुन: उपयोग करना हमेशा अच्छा अभ्यास नहीं होता है। मौजूदा कोड का पुन: उपयोग, विशेष रूप से जब व्यापक रूप से वितरित किया जाता है, ऐसे उपयोग के लिए अनुमति दे सकता है जो अन्यथा संभव से अधिक व्यापक दर्शकों को लक्षित करता है और पुन: उपयोग किए गए कोड की सभी सुरक्षा और कमजोरियों को अपने साथ लाता है।


मौजूदा स्रोत कोड का उपयोग करने पर विचार करते समय, मॉड्यूल की त्वरित समीक्षा (वर्ग या कार्यों जैसे उप-वर्ग) डेवलपर को किसी भी संभावित कमजोरियों से अवगत कराने या जागरूक करने में मदद करेगा और यह सुनिश्चित करेगा कि यह परियोजना में उपयोग करने के लिए उपयुक्त है। {{Citation needed|reason=Cannot find source, Was from a video viewed~April 2015|date=November 2021}}
मौजूदा स्रोत कोड का उपयोग करने पर विचार करते समय, मॉड्यूल की त्वरित समीक्षा (वर्ग या कार्यों जैसे उप-वर्ग) डेवलपर को किसी भी संभावित कमजोरियों से अवगत कराने या जागरूक करने में मदद करेगा और यह सुनिश्चित करेगा कि यह परियोजना में उपयोग करने के लिए उपयुक्त है। {{Citation needed|reason=Cannot find source, Was from a video viewed~April 2015|date=November 2021}}
 
==== लिगेसी समस्याएं ====
 
==== विरासत की समस्याएं ====
पुराने स्रोत कोड, पुस्तकालयों, एपीआई, कॉन्फ़िगरेशन आदि का पुन: उपयोग करने से पहले, यह विचार किया जाना चाहिए कि क्या पुराना कार्य पुन: उपयोग के लिए मान्य है, या यदि यह विरासत प्रणाली की समस्याओं से ग्रस्त होने की संभावना है।
पुराने स्रोत कोड, पुस्तकालयों, एपीआई, कॉन्फ़िगरेशन आदि का पुन: उपयोग करने से पहले, यह विचार किया जाना चाहिए कि क्या पुराना कार्य पुन: उपयोग के लिए मान्य है, या यदि यह विरासत प्रणाली की समस्याओं से ग्रस्त होने की संभावना है।


Line 124: Line 136:
* [[लीगेसी कोड]] एक रक्षात्मक प्रोग्रामिंग पहल के तहत डिज़ाइन नहीं किया गया हो सकता है, और इसलिए नए डिज़ाइन किए गए स्रोत कोड की तुलना में बहुत कम गुणवत्ता वाला हो सकता है।
* [[लीगेसी कोड]] एक रक्षात्मक प्रोग्रामिंग पहल के तहत डिज़ाइन नहीं किया गया हो सकता है, और इसलिए नए डिज़ाइन किए गए स्रोत कोड की तुलना में बहुत कम गुणवत्ता वाला हो सकता है।
* लीगेसी कोड को उन शर्तों के तहत लिखा और परखा जा सकता है जो अब लागू नहीं होती हैं। पुराने गुणवत्ता आश्वासन परीक्षणों की अब कोई वैधता नहीं हो सकती है।
* लीगेसी कोड को उन शर्तों के तहत लिखा और परखा जा सकता है जो अब लागू नहीं होती हैं। पुराने गुणवत्ता आश्वासन परीक्षणों की अब कोई वैधता नहीं हो सकती है।
** उदाहरण 1: पुराने कोड को ASCII इनपुट के लिए डिज़ाइन किया गया हो सकता है लेकिन अब इनपुट UTF-8 है।
** '''उदाहरण 1:''' पुराने कोड को एएससीआईआई इनपुट के लिए डिज़ाइन किया गया हो सकता है लेकिन अब इनपुट यूटीएफ-8 है।
** उदाहरण 2: 32-बिट आर्किटेक्चर पर लीगेसी कोड संकलित और परीक्षण किया जा सकता है, लेकिन जब 64-बिट आर्किटेक्चर पर संकलित किया जाता है, तो नई अंकगणितीय समस्याएं हो सकती हैं (जैसे, अमान्य हस्ताक्षर परीक्षण, अमान्य टाइप कास्ट, आदि)।
** '''उदाहरण 2:''' 32-बिट आर्किटेक्चर पर लीगेसी कोड संकलित और परीक्षण किया जा सकता है, लेकिन जब 64-बिट आर्किटेक्चर पर संकलित किया जाता है, तो नई अंकगणितीय समस्याएं हो सकती हैं (जैसे, अमान्य हस्ताक्षर परीक्षण, अमान्य टाइप कास्ट, आदि)।
** उदाहरण 3: लीगेसी कोड को ऑफ़लाइन मशीनों के लिए लक्षित किया जा सकता है, लेकिन नेटवर्क कनेक्टिविटी जुड़ जाने के बाद यह असुरक्षित हो जाता है।
** '''उदाहरण 3:''' लीगेसी कोड को ऑफ़लाइन मशीनों के लिए लक्षित किया जा सकता है, लेकिन नेटवर्क कनेक्टिविटी जुड़ जाने के बाद यह असुरक्षित हो जाता है।
* लिगेसी कोड नई समस्याओं को ध्यान में रखकर नहीं लिखा गया है। उदाहरण के लिए, 1990 में लिखे गए स्रोत कोड में कई [[कोड इंजेक्शन]] भेद्यता होने की संभावना है, क्योंकि उस समय ऐसी अधिकांश समस्याओं को व्यापक रूप से समझा नहीं गया था।
* लिगेसी कोड नई समस्याओं को ध्यान में रखकर नहीं लिखा गया है। उदाहरण के लिए, 1990 में लिखे गए स्रोत कोड में कई [[कोड इंजेक्शन]] भेद्यता होने की संभावना है, क्योंकि उस समय ऐसी अधिकांश समस्याओं को व्यापक रूप से समझा नहीं गया था।


विरासत की समस्या के उल्लेखनीय उदाहरण:
लिगेसी की समस्या के उल्लेखनीय उदाहरण:
* [[BIND]], पॉल विक्सी और डेविड कॉनराड द्वारा BINDv9 के रूप में प्रस्तुत किया गया एक [[पुनर्लेखन (प्रोग्रामिंग)]] है, डिजाइन में सुरक्षा एक महत्वपूर्ण विचार था,<ref>{{Cite web|url=http://impressive.net/archives/fogo/20001005080818.O15286@impressive.net|title=fogo archive: Paul Vixie and David Conrad on BINDv9 and Internet Security by Gerald Oskoboiny <gerald@impressive.net>|website=impressive.net|access-date=2018-10-27}}</ref> पुरानी विरासत कोड को फिर से लिखने के लिए प्रमुख चिंताओं के रूप में नामकरण सुरक्षा, मजबूती, मापनीयता और नए प्रोटोकॉल।
* बाइंड ([[BIND]]) 9, पॉल विक्सी और डेविड कॉनराड द्वारा "बाइंडv9 एक पूर्ण पुनर्लेखन है" के रूप में प्रस्तुत किया गया, "डिजाइन में सुरक्षा एक महत्वपूर्ण विचार था",<ref>{{Cite web|url=http://impressive.net/archives/fogo/20001005080818.O15286@impressive.net|title=fogo archive: Paul Vixie and David Conrad on BINDv9 and Internet Security by Gerald Oskoboiny <gerald@impressive.net>|website=impressive.net|access-date=2018-10-27}}</ref> नामकरण सुरक्षा, मजबूती, मापनीयता और नए प्रोटोकॉल पुराने विरासत कोड को फिर से लिखने के लिए प्रमुख चिंताएं हैं।
* [[Microsoft Windows]] को Windows मेटाफ़ाइल भेद्यता और WMF प्रारूप से संबंधित अन्य कारनामों का सामना करना पड़ा। Microsoft सुरक्षा प्रतिक्रिया केंद्र WMF-सुविधाओं का वर्णन इस प्रकार करता है 1990 के आसपास, WMF समर्थन जोड़ा गया था... सुरक्षा परिदृश्य में यह एक अलग समय था... सभी पूरी तरह से विश्वसनीय थे,<ref>{{Cite news|url=http://blogs.technet.com/msrc/archive/2006/01/13/417431.aspx|title=Looking at the WMF issue, how did it get there?|work=MSRC|access-date=2018-10-27|language=en-US|archive-url=https://web.archive.org/web/20060324152626/http://blogs.technet.com/msrc/archive/2006/01/13/417431.aspx|archive-date=2006-03-24|url-status=dead}}</ref> Microsoft में सुरक्षा पहल के तहत विकसित नहीं किया जा रहा है।
*[[Microsoft Windows|माइक्रोसॉफ़्ट विंडोज़]] विंडोज़ मेटाफ़ाइल भेद्यता और डब्ल्यूएमएफ प्रारूप से संबंधित दूसरा पराक्रम से त्रस्त था। माइक्रोसॉफ़्ट सुरक्षा प्रतिक्रिया केंद्र डब्ल्यूएमएफ-विशेषताओं का वर्णन इस प्रकार करता है "1990 के आसपास, डब्ल्यूएमएफ समर्थन जोड़ा गया था...सुरक्षा परिदृश्य में यह एक अलग समय था... सभी पूरी तरह से भरोसेमंद थे",<ref>{{Cite news|url=http://blogs.technet.com/msrc/archive/2006/01/13/417431.aspx|title=Looking at the WMF issue, how did it get there?|work=MSRC|access-date=2018-10-27|language=en-US|archive-url=https://web.archive.org/web/20060324152626/http://blogs.technet.com/msrc/archive/2006/01/13/417431.aspx|archive-date=2006-03-24|url-status=dead}}</ref> माइक्रोसॉफ्ट में सुरक्षा पहल के तहत विकसित नहीं किया जा रहा था।
* [[Oracle Corporation]] पुरानी समस्याओं का मुकाबला कर रहा है, जैसे SQL इंजेक्शन और [[विशेषाधिकार वृद्धि]] की चिंताओं को संबोधित किए बिना लिखा गया पुराना स्रोत कोड, जिसके परिणामस्वरूप कई सुरक्षा भेद्यताएँ हैं जिन्हें ठीक करने में समय लगा है और अधूरे सुधार भी उत्पन्न हुए हैं। इसने [[डेविड लीचफील्ड]], [[अलेक्जेंडर कोर्नब्रस्ट]], [[सीज़र सेरुडो]] जैसे सुरक्षा विशेषज्ञों की भारी आलोचना को जन्म दिया है।<ref>{{Cite web|url=http://seclists.org/lists/bugtraq/2006/May/0039.html|title=Bugtraq: Oracle, where are the patches???|last=Litchfield|first=David|website=seclists.org|access-date=2018-10-27}}</ref><ref>{{Cite web|url=http://seclists.org/lists/bugtraq/2006/May/0045.html|title=Bugtraq: RE: Oracle, where are the patches???|last=Alexander|first=Kornbrust|website=seclists.org|access-date=2018-10-27}}</ref><ref>{{Cite web|url=http://seclists.org/lists/bugtraq/2006/May/0083.html|title=Bugtraq: Re: [Full-disclosure] RE: Oracle, where are the patches???|last=Cerrudo|first=Cesar|website=seclists.org|access-date=2018-10-27}}</ref> एक अतिरिक्त आलोचना यह है कि डिफ़ॉल्ट इंस्टॉलेशन (ज्यादातर पुराने संस्करणों की विरासत) उनकी अपनी सुरक्षा अनुशंसाओं के अनुरूप नहीं हैं, जैसे कि [http://www.oracle.com/technology/deploy/security/database-security/pdf/twp_security_checklist_database .pdf Oracle डेटाबेस सुरक्षा चेकलिस्ट], जिसमें संशोधन करना कठिन है क्योंकि कई अनुप्रयोगों को ठीक से काम करने के लिए कम सुरक्षित लीगेसी सेटिंग्स की आवश्यकता होती है।
*[[Oracle Corporation|ओरेकल]] पुरानी समस्याओं का मुकाबला कर रहा है, जैसे एसक्यूएल इंजेक्शन और विशेषाधिकार वृद्धि की चिंताओं को दूर किए बिना लिखे गए पुराने स्रोत कोड, जिसके परिणामस्वरूप कई सुरक्षा भेद्यताएं हैं जिन्हें ठीक करने में समय लगा है और अपूर्ण सुधार भी उत्पन्न हुए हैं। इसने [[डेविड लीचफील्ड]], [[अलेक्जेंडर कोर्नब्रस्ट]], [[सीज़र सेरुडो]] जैसे सुरक्षा विशेषज्ञों की भारी आलोचना को जन्म दिया है।<ref>{{Cite web|url=http://seclists.org/lists/bugtraq/2006/May/0039.html|title=Bugtraq: Oracle, where are the patches???|last=Litchfield|first=David|website=seclists.org|access-date=2018-10-27}}</ref><ref>{{Cite web|url=http://seclists.org/lists/bugtraq/2006/May/0045.html|title=Bugtraq: RE: Oracle, where are the patches???|last=Alexander|first=Kornbrust|website=seclists.org|access-date=2018-10-27}}</ref><ref>{{Cite web|url=http://seclists.org/lists/bugtraq/2006/May/0083.html|title=Bugtraq: Re: [Full-disclosure] RE: Oracle, where are the patches???|last=Cerrudo|first=Cesar|website=seclists.org|access-date=2018-10-27}}</ref> एक अतिरिक्त आलोचना यह है कि डिफ़ॉल्ट स्थापनाएं (ज्यादातर पुराने संस्करणों से एक विरासत) उनकी अपनी सुरक्षा अनुशंसाओं के साथ संरेखित नहीं हैं, जैसे कि ओरेकल डाटाबेस सुरक्षा चेकलिस्ट, जिसमें संशोधन करना कठिन है क्योंकि कई अनुप्रयोगों को ठीक से काम करने के लिए कम सुरक्षित विरासत सेटिंग्स की आवश्यकता होती है।


=== कैननिकलाइज़ेशन ===
=== कैनोनिकलाइजेशन ===
दुर्भावनापूर्ण उपयोगकर्ता गलत डेटा के नए प्रकार के प्रतिनिधित्व का आविष्कार कर सकते हैं। उदाहरण के लिए, यदि कोई प्रोग्राम /etc/Passwd (फ़ाइल) फ़ाइल तक पहुँचने को अस्वीकार करने का प्रयास करता है, तो एक क्रैकर इस फ़ाइल नाम का दूसरा संस्करण पास कर सकता है, जैसे /etc/./passwd। गैर-[[कानूनी फॉर्म]] इनपुट के कारण बग से बचने के लिए [[कैनॉनिकलाइज़ेशन]] लाइब्रेरी को नियोजित किया जा सकता है।
दुर्भावनापूर्ण उपयोगकर्ता गलत डेटा के नए प्रकार के प्रतिनिधित्व का आविष्कार कर सकते हैं। उदाहरण के लिए, यदि कोई प्रोग्राम "/etc/passwd" फ़ाइल तक पहुँचने को अस्वीकार करने का प्रयास करता है, तो एक क्रैकर इस फ़ाइल नाम का एक और संस्करण पास कर सकता है, जैसे "/etc/./passwd"। गैर-कैनोनिकल इनपुट के कारण बग से बचने के लिए [[कैनॉनिकलाइज़ेशन|कैनोनिकलाइज़ेशन]] लाइब्रेरी को नियोजित किया जा सकता है।


=== संभावित बग के खिलाफ कम सहनशीलता ===
=== "संभावित" बग के प्रति कम सहिष्णुता ===
मान लें कि कोड निर्माण जो समस्या प्रवण प्रतीत होते हैं (ज्ञात कमजोरियों के समान, आदि) बग और संभावित सुरक्षा दोष हैं। बुनियादी नियम यह है: मुझे सभी प्रकार के सुरक्षा कारनामों की जानकारी नहीं है। मुझे उन लोगों से बचाव करना चाहिए जिनके बारे में मैं जानता हूं और फिर मुझे सक्रिय होना चाहिए! .
मान लें कि कोड निर्माण जो समस्या प्रवण प्रतीत होते हैं (ज्ञात कमजोरियों के समान, आदि) बग और संभावित सुरक्षा दोष हैं। बुनियादी नियम यह है: मुझे सभी प्रकार के सुरक्षा कारनामों की जानकारी नहीं है। मुझे उन लोगों से बचाव करना चाहिए जिनके बारे में मैं जानता हूं और फिर मुझे सक्रिय होना चाहिए ! .


===अपना कोड सुरक्षित करने के लिए अन्य टिप्स===
===अपना कोड सुरक्षित करने के लिए और टिप्स===
* सबसे आम समस्याओं में से एक है डायनेमिक-साइज़ डेटा के लिए निरंतर-आकार या पूर्व-आवंटित संरचनाओं का अनियंत्रित उपयोग, जैसे कि प्रोग्राम में इनपुट (बफ़र ओवरफ़्लो समस्या)। यह [[सी (प्रोग्रामिंग भाषा)]] में [[स्ट्रिंग (कंप्यूटर प्रोग्रामिंग)]] डेटा के लिए विशेष रूप से आम है। सी पुस्तकालय कार्य करता है <code>gets</code> इनपुट बफर का अधिकतम आकार तर्क के रूप में पारित नहीं होने के बाद से कभी भी उपयोग नहीं किया जाना चाहिए। सी पुस्तकालय कार्य करता है <code>scanf</code> सुरक्षित रूप से उपयोग किया जा सकता है, लेकिन प्रोग्रामर को उपयोग करने से पहले इसे साफ करके, सुरक्षित प्रारूप स्ट्रिंग्स के चयन पर ध्यान देने की आवश्यकता होती है।
* सबसे साधारण समस्याओं में से एक है डायनेमिक-साइज़ डेटा के लिए निरंतर-आकार या पूर्व-आवंटित संरचनाओं का अनियंत्रित उपयोग, जैसे कि प्रोग्राम में इनपुट (बफ़र ओवरफ़्लो समस्या)। यह [[सी (प्रोग्रामिंग भाषा)]] में [[स्ट्रिंग (कंप्यूटर प्रोग्रामिंग)]] डेटा के लिए विशेष रूप से साधारण है। सी पुस्तकालय कार्य करता है <code>gets</code> इनपुट बफर का अधिकतम आकार तर्क के रूप में पारित नहीं होने के बाद से कभी भी उपयोग नहीं किया जाना चाहिए। सी पुस्तकालय कार्य करता है <code>scanf</code> सुरक्षित रूप से उपयोग किया जा सकता है, लेकिन प्रोग्रामर को उपयोग करने से पहले इसे साफ करके, सुरक्षित प्रारूप स्ट्रिंग्स के चयन पर ध्यान देने की आवश्यकता होती है।
* नेटवर्क पर प्रसारित सभी महत्वपूर्ण डेटा को एन्क्रिप्ट/प्रमाणित करें। अपनी स्वयं की एन्क्रिप्शन योजना को लागू करने का प्रयास न करें, इसके बजाय [[क्रिप्टोग्राफी मानक]]ों का उपयोग करें। [[चक्रीय अतिरिक्तता जांच]] या इसी तरह की तकनीक के साथ मैसेज चेकिंग भी नेटवर्क पर भेजे गए डेटा को सुरक्षित रखने में मदद करेगी।
* नेटवर्क पर प्रसारित सभी महत्वपूर्ण डेटा को एन्क्रिप्ट/प्रमाणित करें। अपनी स्वयं की एन्क्रिप्शन योजना को लागू करने का प्रयास न करें, इसके बजाय [[क्रिप्टोग्राफी मानक]] का उपयोग करें। [[चक्रीय अतिरिक्तता जांच]] या इसी तरह की तकनीक के साथ मैसेज चेकिंग भी नेटवर्क पर भेजे गए डेटा को सुरक्षित रखने में मदद करेगी।


==== [[आंकड़े]] सुरक्षा के 3 नियम ====
==== डेटा सुरक्षा के 3 कानून ====
   * अन्यथा सिद्ध होने तक सभी डेटा महत्वपूर्ण हैं।
   * अन्यथा सिद्ध होने तक सभी डेटा महत्वपूर्ण हैं।
   * अन्यथा सिद्ध होने तक सभी डेटा दूषित हैं।
   * अन्यथा सिद्ध होने तक सभी डेटा दूषित हैं।
   * अन्यथा साबित होने तक सभी कोड असुरक्षित हैं।
   * अन्यथा साबित होने तक सभी कोड असुरक्षित हैं।


** आप [[यूजरलैंड (कंप्यूटिंग)]] में किसी भी कोड की सुरक्षा को साबित नहीं कर सकते हैं, या, जिसे आमतौर पर क्लाइंट पर कभी भरोसा नहीं किया जाता है।
*आप [[यूजरलैंड (कंप्यूटिंग)|यूजरलैंड]] में किसी भी कोड की सुरक्षा को साबित नहीं कर सकते, या, जिसे सामान्यतः "क्लाइंट पर कभी भरोसा नहीं" के रूप में जाना जाता है।
डेटा सुरक्षा के बारे में ये तीन नियम बताते हैं कि आंतरिक या बाह्य रूप से किसी भी डेटा को कैसे संभालना है:
डेटा सुरक्षा के बारे में ये तीन नियम बताते हैं कि आंतरिक या बाह्य रूप से किसी भी डेटा को कैसे संभालना है:


'अन्यथा सिद्ध होने तक सभी डेटा महत्वपूर्ण हैं' - इसका अर्थ है कि नष्ट होने से पहले सभी डेटा को कचरा के रूप में सत्यापित किया जाना चाहिए।
'''<nowiki/>'अन्यथा सिद्ध होने तक सभी डेटा महत्वपूर्ण हैं'''' - इसका अर्थ है कि नष्ट होने से पहले सभी डेटा को कचरा के रूप में सत्यापित किया जाना चाहिए।


'अन्यथा सिद्ध होने तक सभी डेटा दागी हैं' - इसका मतलब है कि सभी डेटा को इस तरह से संभाला जाना चाहिए जो अखंडता को सत्यापित किए बिना शेष रनटाइम वातावरण को उजागर न करे।
'''<nowiki/>'अन्यथा सिद्ध होने तक सभी डेटा दागी हैं'''' - इसका मतलब है कि सभी डेटा को इस तरह से संभाला जाना चाहिए जो अखंडता को सत्यापित किए बिना शेष रनटाइम वातावरण को उजागर न करे।


'अन्यथा सिद्ध होने तक सभी कोड असुरक्षित हैं' - जबकि एक मामूली मिथ्या नाम, एक अच्छा काम करता है जो हमें यह याद दिलाता है कि हमारा कोड कभी सुरक्षित नहीं है क्योंकि बग या [[अपरिभाषित व्यवहार]] प्रोजेक्ट या सिस्टम को सामान्य SQL इंजेक्शन हमलों जैसे हमलों के लिए उजागर कर सकते हैं।
'''<nowiki/>'अन्यथा सिद्ध होने तक सभी कोड असुरक्षित हैं'''' - जबकि एक मामूली मिथ्या नाम, एक अच्छा काम करता है जो हमें यह याद दिलाता है कि हमारा कोड कभी सुरक्षित नहीं है क्योंकि बग या [[अपरिभाषित व्यवहार]] प्रोजेक्ट या सिस्टम को सामान्य SQL इंजेक्शन हमलों जैसे हमलों के लिए उजागर कर सकते हैं।


==== अधिक जानकारी ====
==== अधिक जानकारी ====
Line 163: Line 175:
* [[अभिकथन (कंप्यूटिंग)]] (जिसे मुखर प्रोग्रामिंग भी कहा जाता है)
* [[अभिकथन (कंप्यूटिंग)]] (जिसे मुखर प्रोग्रामिंग भी कहा जाता है)
* कोड वापस करने के लिए एक्सेप्शन हैंडलिंग को प्राथमिकता दें
* कोड वापस करने के लिए एक्सेप्शन हैंडलिंग को प्राथमिकता दें
** सामान्यतया, अपवाद संदेशों को फेंकना बेहतर होता है जो आपके [[अप्लिकेशन प्रोग्रामिंग अंतरफलक]] के हिस्से को अनुबंध द्वारा डिज़ाइन करते हैं और त्रुटि कोड मानों को वापस करने के बजाय डेवलपर को मार्गदर्शन करते हैं जो यह इंगित नहीं करते हैं कि अपवाद कहाँ हुआ या प्रोग्राम स्टैक क्या पसंद आया, डेवलपर तनाव को कम करते हुए बेहतर लॉगिंग और अपवाद हैंडलिंग आपके सॉफ़्टवेयर की मजबूती और सुरक्षा को बढ़ाएगी।
** सामान्यतः, अपवाद संदेशों को फेंकना बेहतर होता है जो आपके एपीआई अनुबंध के हिस्से को लागू करते हैं और त्रुटि कोड मानों को वापस करने के बजाय डेवलपर को मार्गदर्शन करते हैं जो यह इंगित नहीं करते हैं कि अपवाद कहां हुआ या प्रोग्राम स्टैक क्या विकल्प आया, डेवलपर तनाव को कम करते हुए, बेहतर लॉगिंग और अपवाद हैंडलिंग आपके सॉफ़्टवेयर की मजबूती और सुरक्षा में वृद्धि करेगी।


== यह भी देखें ==
== यह भी देखें ==
Line 171: Line 183:
== संदर्भ ==
== संदर्भ ==
<references />
<references />
==बाहरी संबंध==
==बाहरी संबंध==
* [https://www.securecoding.cert.org/confluence/display/seccode/SEI+CERT+Coding+Standards CERT Secure Coding Standards]
* [https://www.securecoding.cert.org/confluence/display/seccode/SEI+CERT+Coding+Standards CERT Secure Coding Standards]
[[Category: प्रोग्रामिंग प्रतिमान]] [[Category: प्रोग्रामिंग सिद्धांत]]


[[Category: Machine Translated Page]]
[[Category:All Wikipedia articles written in American English]]
[[Category:All articles with unsourced statements]]
[[Category:Articles with hatnote templates targeting a nonexistent page]]
[[Category:Articles with unsourced statements from November 2021]]
[[Category:CS1 English-language sources (en)]]
[[Category:Created On 19/02/2023]]
[[Category:Created On 19/02/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:Use American English from November 2020]]
[[Category:प्रोग्रामिंग प्रतिमान]]
[[Category:प्रोग्रामिंग सिद्धांत]]

Latest revision as of 17:15, 4 September 2023

रक्षात्मक प्रोग्रामिंग उन रक्षात्मक डिजाइन का एक रूप है जिसका उद्देश्य उन कार्यक्रमों को विकसित करना है जो संभावित सुरक्षा असामान्यताओं का पता लगाने और पूर्व निर्धारित प्रतिक्रियाएं करने में सक्षम हैं।[1] यह अप्रत्याशित परिस्थितियों में सॉफ्टवेयर के एक भाग के निरंतर कार्य को सुनिश्चित करता है। रक्षात्मक प्रोग्रामिंग प्रथाओं का उपयोग प्रायः किया जाता है जहां उच्च उपलब्धता, सुरक्षा या सुरक्षा की आवश्यकता होती है।

रक्षात्मक प्रोग्रामिंग सॉफ्टवेयर और सोर्स कोड में सुधार के लिए एक दृष्टिकोण है:

  • सामान्य गुणवत्ता - सॉफ्टवेयर बग और समस्याओं की संख्या को कम करना है।
  • स्रोत कोड को समझ में आता है - स्रोत कोड पठनीय और समझ में आता है इसलिए इसे कोड ऑडिट में अनुमोदित किया जाता है।
  • अप्रत्याशित इनपुट या उपयोगकर्ता कार्यों के बावजूद सॉफ़्टवेयर को एक अनुमानित तरीके से व्यवहार करना है।

अत्यधिक रक्षात्मक प्रोग्रामिंग, हालांकि, उन त्रुटियों के खिलाफ सुरक्षा कर सकते हैं जो कभी भी सामना नहीं करेंगे, इस प्रकार रन-टाइम और रखरखाव की लागत को बढ़ाते हैं। एक जोखिम यह भी है कि कोड ट्रैप बहुत अधिक अपवाद हैंडलिंग को रोकता है, जिसके परिणामस्वरूप संभावित रूप से अनजान, गलत परिणाम होते हैं।

सुरक्षित प्रोग्रामिंग

Main article: सुरक्षित कोडिंग

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

int risky_programming(char *input) {
  char str[1000]; 
  
  // ...
  
  strcpy(str, input);  // Copy input.
  
  // ...
}

फ़ंक्शन को अपरिभाषित व्यवहार में परिणाम होगा जब इनपुट 1000 से अधिक वर्णों का है। कुछ प्रोग्रामर यह महसूस नहीं कर सकते हैं कि यह एक समस्या है, यह मानते हुए कि कोई भी उपयोगकर्ता इतने लंबे इनपुट में प्रवेश नहीं करेगा। यह विशेष बग एक भेद्यता को प्रदर्शित करता है जो बफर ओवरफ्लो एक्सप्लॉइट्स को सक्षम करता है। यहाँ इस उदाहरण का समाधान है: 

int secure_programming(char *input) {
  char str[1000+1];  // One more for the null character.

  // ...

  // Copy input without exceeding the length of the destination.
  strncpy(str, input, sizeof(str));

  // If strlen(input) >= sizeof(str) then strncpy won't null terminate. 
  // We counter this by always setting the last character in the buffer to NUL,
  // effectively cropping the string to the maximum length we can handle.
  // One can also decide to explicitly abort the program if strlen(input) is 
  // too long.
  str[sizeof(str) - 1] = '\0';

  // ...
}

आक्रामक प्रोग्रामिंग (ओफ्फेंसिव प्रोग्रामिंग)

Main article: ओफ्फेंसिव प्रोग्रामिंग

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

आंतरिक डेटा वैधता पर विश्वास करना

अत्यधिक रक्षात्मक प्रोग्रामिंग 

const char* trafficlight_colorname(enum traffic_light_color c) {

   switch (c) {

       case TRAFFICLIGHT_RED:    return "red";

       case TRAFFICLIGHT_YELLOW: return "yellow";

       case TRAFFICLIGHT_GREEN:  return "green";

   }

   return "black"; // To be handled as a dead traffic light.

   // Warning: This last 'return' statement will be dropped by an optimizing

   // compiler if all possible values of 'traffic_light_color' are listed in

   // the previous 'switch' statement...

}

ओफ्फेंसिव प्रोग्रामिंग 

const char* trafficlight_colorname(enum traffic_light_color c) {

   switch (c) {

       case TRAFFICLIGHT_RED:    return "red";

       case TRAFFICLIGHT_YELLOW: return "yellow";

       case TRAFFICLIGHT_GREEN:  return "green";

   }

   assert(0); // Assert that this section is unreachable.

   // Warning: This 'assert' function call will be dropped by an optimizing

   // compiler if all possible values of 'traffic_light_color' are listed in

   // the previous 'switch' statement...

}

सॉफ्टवेयर घटकों पर विश्वास करना

अत्यधिक रक्षात्मक प्रोग्रामिंग 

if (is_legacy_compatible(user_config)) {
 // Strategy: Don't trust that the new code behaves the same
 old_code(user_config);
} else {
 // Fallback: Don't trust that the new code handles the same cases
 if (new_code(user_config)n!= OK) {
 old_code(user_config);
 }
}

आक्रामक प्रोग्रामिंग 

 // Expect that the new code has no new bugs
if (new_code(user_config))!= OK) {
 // Loudly report and abruptly terminate program to get proper attention
 report_error("Something went very wrong");
 exit(-1);
}

तकनीक

यहाँ कुछ रक्षात्मक प्रोग्रामिंग तकनीकें हैं:

इंटेलिजेंट सोर्स कोड का पुन: उपयोग

यदि मौजूदा कोड का परीक्षण किया गया है और काम करने के लिए जाना जाता है, तो इसका पुन: उपयोग करने से बग्स के पेश होने की संभावना कम हो सकती है।

हालाँकि, कोड का पुन: उपयोग करना हमेशा अच्छा अभ्यास नहीं होता है। मौजूदा कोड का पुन: उपयोग, विशेष रूप से जब व्यापक रूप से वितरित किया जाता है, ऐसे उपयोग के लिए अनुमति दे सकता है जो अन्यथा संभव से अधिक व्यापक दर्शकों को लक्षित करता है और पुन: उपयोग किए गए कोड की सभी सुरक्षा और कमजोरियों को अपने साथ लाता है।

मौजूदा स्रोत कोड का उपयोग करने पर विचार करते समय, मॉड्यूल की त्वरित समीक्षा (वर्ग या कार्यों जैसे उप-वर्ग) डेवलपर को किसी भी संभावित कमजोरियों से अवगत कराने या जागरूक करने में मदद करेगा और यह सुनिश्चित करेगा कि यह परियोजना में उपयोग करने के लिए उपयुक्त है।[citation needed]

लिगेसी समस्याएं

पुराने स्रोत कोड, पुस्तकालयों, एपीआई, कॉन्फ़िगरेशन आदि का पुन: उपयोग करने से पहले, यह विचार किया जाना चाहिए कि क्या पुराना कार्य पुन: उपयोग के लिए मान्य है, या यदि यह विरासत प्रणाली की समस्याओं से ग्रस्त होने की संभावना है।

विरासत की समस्याएं अंतर्निहित समस्याएं हैं जब पुराने डिजाइनों से आज की आवश्यकताओं के साथ काम करने की उम्मीद की जाती है, खासकर जब पुराने डिजाइनों को उन आवश्यकताओं को ध्यान में रखते हुए विकसित या परीक्षण नहीं किया गया था।

कई सॉफ्टवेयर उत्पादों में पुराने विरासत स्रोत कोड के साथ समस्याओं का अनुभव हुआ है; उदाहरण के लिए:

  • लीगेसी कोड एक रक्षात्मक प्रोग्रामिंग पहल के तहत डिज़ाइन नहीं किया गया हो सकता है, और इसलिए नए डिज़ाइन किए गए स्रोत कोड की तुलना में बहुत कम गुणवत्ता वाला हो सकता है।
  • लीगेसी कोड को उन शर्तों के तहत लिखा और परखा जा सकता है जो अब लागू नहीं होती हैं। पुराने गुणवत्ता आश्वासन परीक्षणों की अब कोई वैधता नहीं हो सकती है।
    • उदाहरण 1: पुराने कोड को एएससीआईआई इनपुट के लिए डिज़ाइन किया गया हो सकता है लेकिन अब इनपुट यूटीएफ-8 है।
    • उदाहरण 2: 32-बिट आर्किटेक्चर पर लीगेसी कोड संकलित और परीक्षण किया जा सकता है, लेकिन जब 64-बिट आर्किटेक्चर पर संकलित किया जाता है, तो नई अंकगणितीय समस्याएं हो सकती हैं (जैसे, अमान्य हस्ताक्षर परीक्षण, अमान्य टाइप कास्ट, आदि)।
    • उदाहरण 3: लीगेसी कोड को ऑफ़लाइन मशीनों के लिए लक्षित किया जा सकता है, लेकिन नेटवर्क कनेक्टिविटी जुड़ जाने के बाद यह असुरक्षित हो जाता है।
  • लिगेसी कोड नई समस्याओं को ध्यान में रखकर नहीं लिखा गया है। उदाहरण के लिए, 1990 में लिखे गए स्रोत कोड में कई कोड इंजेक्शन भेद्यता होने की संभावना है, क्योंकि उस समय ऐसी अधिकांश समस्याओं को व्यापक रूप से समझा नहीं गया था।

लिगेसी की समस्या के उल्लेखनीय उदाहरण:

  • बाइंड (BIND) 9, पॉल विक्सी और डेविड कॉनराड द्वारा "बाइंडv9 एक पूर्ण पुनर्लेखन है" के रूप में प्रस्तुत किया गया, "डिजाइन में सुरक्षा एक महत्वपूर्ण विचार था",[2] नामकरण सुरक्षा, मजबूती, मापनीयता और नए प्रोटोकॉल पुराने विरासत कोड को फिर से लिखने के लिए प्रमुख चिंताएं हैं।
  • माइक्रोसॉफ़्ट विंडोज़ विंडोज़ मेटाफ़ाइल भेद्यता और डब्ल्यूएमएफ प्रारूप से संबंधित दूसरा पराक्रम से त्रस्त था। माइक्रोसॉफ़्ट सुरक्षा प्रतिक्रिया केंद्र डब्ल्यूएमएफ-विशेषताओं का वर्णन इस प्रकार करता है "1990 के आसपास, डब्ल्यूएमएफ समर्थन जोड़ा गया था...सुरक्षा परिदृश्य में यह एक अलग समय था... सभी पूरी तरह से भरोसेमंद थे",[3] माइक्रोसॉफ्ट में सुरक्षा पहल के तहत विकसित नहीं किया जा रहा था।
  • ओरेकल पुरानी समस्याओं का मुकाबला कर रहा है, जैसे एसक्यूएल इंजेक्शन और विशेषाधिकार वृद्धि की चिंताओं को दूर किए बिना लिखे गए पुराने स्रोत कोड, जिसके परिणामस्वरूप कई सुरक्षा भेद्यताएं हैं जिन्हें ठीक करने में समय लगा है और अपूर्ण सुधार भी उत्पन्न हुए हैं। इसने डेविड लीचफील्ड, अलेक्जेंडर कोर्नब्रस्ट, सीज़र सेरुडो जैसे सुरक्षा विशेषज्ञों की भारी आलोचना को जन्म दिया है।[4][5][6] एक अतिरिक्त आलोचना यह है कि डिफ़ॉल्ट स्थापनाएं (ज्यादातर पुराने संस्करणों से एक विरासत) उनकी अपनी सुरक्षा अनुशंसाओं के साथ संरेखित नहीं हैं, जैसे कि ओरेकल डाटाबेस सुरक्षा चेकलिस्ट, जिसमें संशोधन करना कठिन है क्योंकि कई अनुप्रयोगों को ठीक से काम करने के लिए कम सुरक्षित विरासत सेटिंग्स की आवश्यकता होती है।

कैनोनिकलाइजेशन

दुर्भावनापूर्ण उपयोगकर्ता गलत डेटा के नए प्रकार के प्रतिनिधित्व का आविष्कार कर सकते हैं। उदाहरण के लिए, यदि कोई प्रोग्राम "/etc/passwd" फ़ाइल तक पहुँचने को अस्वीकार करने का प्रयास करता है, तो एक क्रैकर इस फ़ाइल नाम का एक और संस्करण पास कर सकता है, जैसे "/etc/./passwd"। गैर-कैनोनिकल इनपुट के कारण बग से बचने के लिए कैनोनिकलाइज़ेशन लाइब्रेरी को नियोजित किया जा सकता है।

"संभावित" बग के प्रति कम सहिष्णुता

मान लें कि कोड निर्माण जो समस्या प्रवण प्रतीत होते हैं (ज्ञात कमजोरियों के समान, आदि) बग और संभावित सुरक्षा दोष हैं। बुनियादी नियम यह है: मुझे सभी प्रकार के सुरक्षा कारनामों की जानकारी नहीं है। मुझे उन लोगों से बचाव करना चाहिए जिनके बारे में मैं जानता हूं और फिर मुझे सक्रिय होना चाहिए ! .

अपना कोड सुरक्षित करने के लिए और टिप्स

  • सबसे साधारण समस्याओं में से एक है डायनेमिक-साइज़ डेटा के लिए निरंतर-आकार या पूर्व-आवंटित संरचनाओं का अनियंत्रित उपयोग, जैसे कि प्रोग्राम में इनपुट (बफ़र ओवरफ़्लो समस्या)। यह सी (प्रोग्रामिंग भाषा) में स्ट्रिंग (कंप्यूटर प्रोग्रामिंग) डेटा के लिए विशेष रूप से साधारण है। सी पुस्तकालय कार्य करता है gets इनपुट बफर का अधिकतम आकार तर्क के रूप में पारित नहीं होने के बाद से कभी भी उपयोग नहीं किया जाना चाहिए। सी पुस्तकालय कार्य करता है scanf सुरक्षित रूप से उपयोग किया जा सकता है, लेकिन प्रोग्रामर को उपयोग करने से पहले इसे साफ करके, सुरक्षित प्रारूप स्ट्रिंग्स के चयन पर ध्यान देने की आवश्यकता होती है।
  • नेटवर्क पर प्रसारित सभी महत्वपूर्ण डेटा को एन्क्रिप्ट/प्रमाणित करें। अपनी स्वयं की एन्क्रिप्शन योजना को लागू करने का प्रयास न करें, इसके बजाय क्रिप्टोग्राफी मानक का उपयोग करें। चक्रीय अतिरिक्तता जांच या इसी तरह की तकनीक के साथ मैसेज चेकिंग भी नेटवर्क पर भेजे गए डेटा को सुरक्षित रखने में मदद करेगी।

डेटा सुरक्षा के 3 कानून

 * अन्यथा सिद्ध होने तक सभी डेटा महत्वपूर्ण हैं।
 * अन्यथा सिद्ध होने तक सभी डेटा दूषित हैं।
 * अन्यथा साबित होने तक सभी कोड असुरक्षित हैं।
  • आप यूजरलैंड में किसी भी कोड की सुरक्षा को साबित नहीं कर सकते, या, जिसे सामान्यतः "क्लाइंट पर कभी भरोसा नहीं" के रूप में जाना जाता है।

डेटा सुरक्षा के बारे में ये तीन नियम बताते हैं कि आंतरिक या बाह्य रूप से किसी भी डेटा को कैसे संभालना है:

'अन्यथा सिद्ध होने तक सभी डेटा महत्वपूर्ण हैं' - इसका अर्थ है कि नष्ट होने से पहले सभी डेटा को कचरा के रूप में सत्यापित किया जाना चाहिए।

'अन्यथा सिद्ध होने तक सभी डेटा दागी हैं' - इसका मतलब है कि सभी डेटा को इस तरह से संभाला जाना चाहिए जो अखंडता को सत्यापित किए बिना शेष रनटाइम वातावरण को उजागर न करे।

'अन्यथा सिद्ध होने तक सभी कोड असुरक्षित हैं' - जबकि एक मामूली मिथ्या नाम, एक अच्छा काम करता है जो हमें यह याद दिलाता है कि हमारा कोड कभी सुरक्षित नहीं है क्योंकि बग या अपरिभाषित व्यवहार प्रोजेक्ट या सिस्टम को सामान्य SQL इंजेक्शन हमलों जैसे हमलों के लिए उजागर कर सकते हैं।

अधिक जानकारी

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

यह भी देखें

  • कंप्यूटर सुरक्षा
  • प्रतिरक्षा-जागरूक प्रोग्रामिंग

संदर्भ

  1. ↑ Boulanger, Jean-Louis (2016-01-01), Boulanger, Jean-Louis (ed.), "6 - Technique to Manage Software Safety", Certifiable Software Applications 1 (in English), Elsevier, pp. 125–156, ISBN 978-1-78548-117-8, retrieved 2022-09-02
  2. ↑ "fogo archive: Paul Vixie and David Conrad on BINDv9 and Internet Security by Gerald Oskoboiny <gerald@impressive.net>". impressive.net. Retrieved 2018-10-27.
  3. ↑ "Looking at the WMF issue, how did it get there?". MSRC (in English). Archived from the original on 2006-03-24. Retrieved 2018-10-27.
  4. ↑ Litchfield, David. "Bugtraq: Oracle, where are the patches???". seclists.org. Retrieved 2018-10-27.
  5. ↑ Alexander, Kornbrust. "Bugtraq: RE: Oracle, where are the patches???". seclists.org. Retrieved 2018-10-27.
  6. ↑ Cerrudo, Cesar. "Bugtraq: Re: [Full-disclosure] RE: Oracle, where are the patches???". seclists.org. Retrieved 2018-10-27.

बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=रक्षात्मक_प्रोग्रामिंग&oldid=255477’