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

कोड लिखते समय आप जागरूक रूप से उच्च प्रोग्राम गुणवत्ता सुनिश्चित करने के लिए प्रोग्राम को रक्षात्मक रूप से प्रोग्राम करते हैं और आपके कोड का दुर्भावनापूर्ण रूप से शोषण की संभावना से बचने के लिए, उदाहरण के लिए बफर ओवरफ्लो शोषण या कोड इंजेक्शन के माध्यम से?

गुणवत्ता का "न्यूनतम" स्तर क्या है जो आप हमेशा अपने कोड पर लागू करेंगे?

0
ro fr bn

13 उत्तर

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

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

ले-होम संदेश यह सुनिश्चित करना है कि बाहरी कोड का उपयोग करने वाले किसी भी उत्परिवर्तनीय ऑब्जेक्ट्स के लिए कोई बाहरी कोड उपनाम नहीं रख सकता है, ताकि आप अपने इनवेरिएंट को बनाए रख सकें।

0
जोड़ा

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

0
जोड़ा

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

हैशिंग पासवर्ड जैसे अन्य सामान, कनेक्शन स्ट्रिंग एन्क्रिप्ट करना इत्यादि भी मानक हैं।

यहां से, यह वास्तविक एप्लिकेशन पर निर्भर करता है।

सौभाग्य से, यदि आप .NET जैसे ढांचे के साथ काम कर रहे हैं, तो बहुत सी सुरक्षा सुरक्षा अंतर्निहित होती है।

0
जोड़ा

टेस्ट संचालित विकास का उपयोग निश्चित रूप से मदद करता है। आप एक समय में एक घटक लिखते हैं और फिर कोड लिखने से पहले इनपुट (परीक्षण के माध्यम से) के सभी संभावित मामलों की गणना करते हैं। यह सुनिश्चित करता है कि आपने सभी अड्डों को कवर किया है और आपने कोई भी cool कोड नहीं लिखा है जो कोई भी उपयोग नहीं करेगा लेकिन टूट सकता है।

हालांकि मैं औपचारिक कुछ नहीं करता हूं, लेकिन आम तौर पर प्रत्येक कक्षा को देखने में कुछ समय लगता है और यह सुनिश्चित करता हूं कि:

  1. यदि वे एक वैध स्थिति में हैं कि वे एक वैध स्थिति में रहते हैं
  2. उन्हें अमान्य स्थिति में बनाने का कोई तरीका नहीं है
  3. असाधारण परिस्थितियों में वे जितना संभव हो उतना गहराई से असफल हो जाएंगे (अक्सर यह एक सफाई और फेंकना है)
0
जोड़ा

आपको हमेशा रक्षात्मक रूप से प्रोग्राम करना होगा, मैं आंतरिक ऐप्स के लिए भी कहूंगा, क्योंकि उपयोगकर्ता केवल भाग्यशाली भाग्य के माध्यम से कुछ ऐसा लिख ​​सकते हैं जो आपके ऐप को तोड़ देता है। माना जाता है कि आपको शायद पैसे से धोखा देने की कोशिश करने की चिंता करने की ज़रूरत नहीं है लेकिन फिर भी। हमेशा रक्षात्मक रूप से प्रोग्राम करें और मान लें कि ऐप असफल हो जाएगा।

0
जोड़ा

काम की मेरी लाइन में, हमारे कोड को शीर्ष गुणवत्ता होना चाहिए।
तो, हम दो मुख्य चीजों पर ध्यान केंद्रित करते हैं:

  1. परीक्षण
  2. कोड समीक्षा

वे पैसे घर लाते हैं।

0
जोड़ा

निर्भर करता है।

अगर मैं अपने स्वयं के उपयोग के लिए वास्तव में कुछ हैकिंग कर रहा हूं तो मैं सबसे अच्छा कोड लिखूंगा जिसके बारे में मुझे सोचना नहीं है। कंपाइलर को चेतावनी आदि के लिए मेरा मित्र बनने दें, लेकिन मैं इसके नरक के लिए स्वचालित रूप से प्रकार नहीं बनाऊंगा।

कोड का उपयोग करने की अधिक संभावना है, यहां तक ​​कि कभी-कभी, मैं चेक के स्तर को बढ़ाता हूं।

  • minimal magic numbers
  • better variable names
  • fully checked & defined array/string lengths
  • programming by contract assertions
  • null value checks
  • exceptions (depending upon context of the code)
  • basic explanatory comments
  • accessible usage documentation (if perl etc.)
0
जोड़ा

मैं लोगों को कोड लिखने की सलाह देता हूं जो विकास पर्यावरण में फासीवादी है और उत्पादन में उदार है।

विकास के दौरान आप समस्याओं को रोकने के लिए जितनी जल्दी हो सके खराब डेटा / तर्क / कोड को पकड़ना चाहते हैं या तो बाद में समस्याएं होती हैं जहां मूल कारण ट्रैक करना मुश्किल होता है।

उत्पादन में संभावित रूप से यथासंभव संभालती है। अगर कुछ वास्तव में एक गैर-पुनर्प्राप्ति योग्य त्रुटि है तो उसे संभाल लें और उस जानकारी को उपयोगकर्ता को प्रस्तुत करें।

उदाहरण के तौर पर एक वेक्टर को सामान्यीकृत करने के लिए हमारा कोड है। यदि आप इसे विकास में खराब डेटा खिलाते हैं तो यह चिल्लाएगा, उत्पादन में यह एक सुरक्षा मूल्य देता है।

inline const Vector3 Normalize( Vector3arg vec )
{
    const float len = Length(vec);
    ASSERTMSG(len > 0.0f "Invalid Normalization");
    return len == 0.0f ? vec : vec / len;
}
0
जोड़ा
हम विरासत कोड पर समस्या का पता लगाने "को बढ़ाने" के समान तरीके का उपयोग करते हैं। मैक्रो को जोड़ना आसान है, परीक्षण के दौरान इसका एकमात्र प्रभाव डीबग संदेशबॉक्स है। यह एक चमत्कार समाधान नहीं है, लेकिन यह "वापसी गलत" से बेहतर है; कोई भी कभी जांच नहीं करता है
जोड़ा लेखक paercebal, स्रोत

मुझे बहुत राय है कि सही प्रोग्रामिंग इन जोखिमों के खिलाफ सुरक्षा करेगी। बहिष्कृत कार्यों से बचने जैसी चीजें, जो (कम से कम माइक्रोसॉफ्ट सी ++ पुस्तकालयों में) सुरक्षा भेद्यता के कारण सामान्य रूप से बहिष्कृत होती हैं, और बाहरी सीमा पार करने वाली सभी चीज़ों को प्रमाणित करती हैं।

फ़ंक्शंस जिन्हें केवल आपके कोड से बुलाया जाता है, उन्हें अत्यधिक पैरामीटर सत्यापन की आवश्यकता नहीं होती है क्योंकि आप कॉलर को नियंत्रित करते हैं, यानी, बाहरी सीमा पार नहीं होती है। अन्य लोगों के कोड द्वारा बुलाए गए कार्यों को यह मानना ​​चाहिए कि आने वाले पैरामीटर किसी बिंदु पर अमान्य और / या दुर्भावनापूर्ण होंगे।

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

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

0
जोड़ा

मैं "घटक" या ढांचे में प्रवेश करने वाले डेटा के लिए रक्षात्मक होने की अनुशंसा करता हूं। एक "घटक" या ढांचे के भीतर किसी को यह सोचना चाहिए कि डेटा "सही" है।

इस तरह सोच रहा है। सही पैरामीटर की आपूर्ति करने के लिए कॉलर पर निर्भर करता है अन्यथा सभी कार्यों और विधियों को प्रत्येक इनकमिंग पैरामीटर की जांच करनी होती है। लेकिन अगर कॉलर केवल कॉलर के लिए किया जाता है तो जांच केवल एक बार की आवश्यकता होती है। तो, एक पैरामीटर "सही" होना चाहिए और इस प्रकार निचले स्तर तक पारित किया जा सकता है।

  1. बाहरी स्रोतों, उपयोगकर्ताओं आदि से डेटा हमेशा जांचें
  2. एक "घटक" या ढांचे को हमेशा इनकमिंग कॉल की जांच करनी चाहिए।

यदि कोई बग है और किसी कॉल में गलत मान का उपयोग किया जाता है। वास्तव में सही बात क्या है? केवल एक संकेत है कि जिस प्रोग्राम पर "डेटा" प्रोग्राम काम कर रहा है वह गलत है और कुछ एसेटर्स की तरह हैं लेकिन अन्य उन्नत त्रुटि रिपोर्टिंग और संभावित त्रुटि पुनर्प्राप्ति का उपयोग करना चाहते हैं। किसी भी मामले में डेटा दोषपूर्ण पाया जाता है और कुछ मामलों में इस पर काम करना जारी रखना अच्छा होता है। (ध्यान दें कि सर्वर कम से कम मर नहीं जाता है तो यह अच्छा है)

एक उपग्रह से भेजी गई एक छवि उन्नत त्रुटि वसूली का प्रयास करने का मामला हो सकता है ... इंटरनेट से डाउनलोड की गई एक छवि के लिए त्रुटि आइकन डालने के लिए ...

0
जोड़ा

जावा, हस्ताक्षर किए गए जार और जेएएएस।

बफर ओवरफ्लो और पॉइंटर / स्टैक व्हीकिंग शोषण को रोकने के लिए जावा।

जेएनआई का प्रयोग न करें। (जावा मूल इंटरफ़ेस) यह आपको डीएलएल / साझा पुस्तकालयों के बारे में बताता है।

क्लास लोडिंग को सुरक्षा समस्या होने से रोकने के लिए जार की हस्ताक्षर की गई।

जेएएएस आपके आवेदन को किसी भी पर भरोसा नहीं कर सकता है, यहां तक ​​कि खुद भी।

जे 2 ईई (भरोसेमंद रूप से सीमित) भूमिका आधारित सुरक्षा के लिए अंतर्निहित समर्थन है।

इनमें से कुछ के लिए कुछ ओवरहेड है लेकिन सुरक्षा छेद दूर हो जाते हैं।

0
जोड़ा

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

बाद में वापस जाना और विधियों, विशेषताओं और गुणों को पेश करना बहुत आसान है, जिनके लिए कुछ ऐसा अनुमान लगाया जाता है जो कभी नहीं आ सकता है।

0
जोड़ा
आप जो वर्णन करते हैं उसे YAGNI के रूप में भी जाना जाता है - en.wikipedia.org/wiki/YAGNI
जोड़ा लेखक abyx, स्रोत

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

कई साल पहले, हमने अपने सॉफ़्टवेयर के सभी स्तरों पर दावाों का उपयोग करने की नीति बनाई और यह - यूनिट परीक्षण, कोड समीक्षा आदि के साथ-साथ हमारे मौजूदा एप्लिकेशन टेस्ट सूट - हमारे कोड की गुणवत्ता पर एक महत्वपूर्ण, सकारात्मक प्रभाव पड़ा।

0
जोड़ा