कोड लिखते समय आप जागरूक रूप से उच्च प्रोग्राम गुणवत्ता सुनिश्चित करने के लिए प्रोग्राम को रक्षात्मक रूप से प्रोग्राम करते हैं और आपके कोड का दुर्भावनापूर्ण रूप से शोषण की संभावना से बचने के लिए, उदाहरण के लिए बफर ओवरफ्लो शोषण या कोड इंजेक्शन के माध्यम से?रक्षात्मक प्रोग्रामिंग
गुणवत्ता का "न्यूनतम" स्तर क्या है जो आप हमेशा अपने कोड पर लागू करेंगे?
काम की मेरी लाइन में, हमारा कोड शीर्ष गुणवत्ता होना चाहिए।
तो, हम दो मुख्य बातों पर ध्यान केंद्रित:
घर पैसे लाने के हैं।
मैं हमेशा इंजेक्शन हमलों जैसी चीजों को रोकने के लिए काम करता हूं। हालांकि, जब आप किसी आंतरिक इंट्रानेट साइट पर काम करते हैं, तो अधिकांश सुरक्षा सुविधाएं बर्बाद प्रयास की तरह लगती हैं। मैं अभी भी उन्हें करता हूं, शायद बस भी नहीं।
ठीक है, सुरक्षा के लिए सर्वोत्तम प्रथाओं का एक निश्चित सेट है। कम से कम, डेटाबेस अनुप्रयोगों के लिए, आपको SQL इंजेक्शन के लिए देखना होगा।
हैशिंग पासवर्ड जैसे अन्य सामान, कनेक्शन स्ट्रिंग एन्क्रिप्ट करना इत्यादि भी मानक हैं।
यहां से, यह वास्तविक एप्लिकेशन पर निर्भर करता है।
सौभाग्य से, यदि आप .NET जैसे ढांचे के साथ काम कर रहे हैं, तो बहुत सी सुरक्षा सुरक्षा अंतर्निहित होती है।
आपको हमेशा रक्षात्मक रूप से प्रोग्राम करना होगा, मैं आंतरिक ऐप्स के लिए भी कहूंगा, क्योंकि उपयोगकर्ता केवल भाग्यशाली भाग्य के माध्यम से कुछ ऐसा लिख सकते हैं जो आपके ऐप को तोड़ देता है। माना जाता है कि आपको शायद पैसे से धोखा देने की कोशिश करने की चिंता करने की ज़रूरत नहीं है लेकिन फिर भी। हमेशा रक्षात्मक रूप से प्रोग्राम करें और मान लें कि ऐप असफल हो जाएगा।
abyx के समान, टीम में मैं डेवलपर्स पर हूं हमेशा इकाई परीक्षण और कोड समीक्षा का उपयोग करता हूं। इसके अलावा, मैं यह भी सुनिश्चित करना चाहता हूं कि मैं कोड को शामिल नहीं करता हूं कि उपयोग कर सकते हैं - मैं केवल ऑब्जेक्ट के लिए आवश्यक विधियों के मूल सेट के लिए कोड लिखने के लिए कोड लिखता हूं, डी बाहर मैंने पाया है कि उन विधियों को शामिल करना जिनका उपयोग कभी नहीं किया जा सकता है, लेकिन कार्यक्षमता प्रदान करने से अनजाने में सिस्टम में "बैकडोर" या अनपेक्षित/अप्रत्याशित उपयोग शुरू हो सकता है।
बाद में वापस जाना और विधियों, विशेषताओं और गुणों को पेश करना बहुत आसान है, जिनके लिए कुछ ऐसा अनुमान लगाया जा सकता है जो कभी नहीं आ सकता है।
टेस्ट संचालित विकास का उपयोग निश्चित रूप से मदद करता है। आप एक समय में एक घटक लिखते हैं और फिर कोड लिखने से पहले इनपुट (परीक्षण के माध्यम से) के सभी संभावित मामलों की गणना करते हैं। यह सुनिश्चित करता है कि आपने सभी अड्डों को कवर किया है और कूल कोड नहीं लिखा है जो कोई भी उपयोग नहीं करेगा लेकिन टूट सकता है।
हालांकि मैं कुछ भी औपचारिक नहीं करते मैं आम तौर पर कुछ समय बिताने के प्रत्येक वर्ग के देख रही है और यह सुनिश्चित:
यह निर्भर करता है (अक्सर यह एक सफाई और फेंक है)।
यदि मैं वास्तव में अपने स्वयं के उपयोग के लिए कुछ हैकिंग कर रहा हूं तो मैं सबसे अच्छा कोड लिखूंगा जिसके बारे में मुझे नहीं सोचना है। कंपाइलर को चेतावनी आदि के लिए मेरा मित्र बनने दें, लेकिन मैं इसके नरक के लिए स्वचालित रूप से प्रकार नहीं बनाऊंगा।
कोड का उपयोग करने की अधिक संभावना है, यहां तक कि कभी-कभी, मैं चेक के स्तर को बढ़ाता हूं।
मैं एक है कि जोश बलोच द्वारा द्वारा Effective Java की वकालत की है के रूप में, रक्षात्मक प्रोग्रामिंग की एक अलग परिभाषा ले लेंगे। पुस्तक में, वह म्यूटेबल ऑब्जेक्ट्स को कैसे संभालने के बारे में बात करता है जो कॉलर आपके कोड (उदा।, सेटर्स में) पास करते हैं, और आप कॉल करने वालों को उत्परिवर्तनीय ऑब्जेक्ट्स (उदा।, गेटर्स में) पास करते हैं।
ले-होम संदेश यह सुनिश्चित करना है कि बाहरी कोड का उपयोग करने वाले किसी भी उत्परिवर्तनीय ऑब्जेक्ट्स के लिए कोई बाहरी कोड उपनाम नहीं रख सकता है, ताकि आप अपने इनवेरिएंट को बनाए रख सकें।
मैं "घटक" या ढांचे में प्रवेश करने वाले डेटा के लिए रक्षात्मक होने की अनुशंसा करता हूं। एक "घटक" या ढांचे के भीतर किसी को यह सोचना चाहिए कि डेटा "सही" है।
इस तरह सोच रहा है। सही पैरामीटर की आपूर्ति करने के लिए कॉलर पर निर्भर करता है अन्यथा सभी कार्यों और विधियों को प्रत्येक इनकमिंग पैरामीटर की जांच करनी होती है।लेकिन अगर कॉलर केवल कॉलर के लिए किया जाता है तो जांच केवल एक बार की आवश्यकता होती है। तो, एक पैरामीटर "सही" होना चाहिए और इस प्रकार निचले स्तर तक पारित किया जा सकता है।
यदि कोई बग है और किसी कॉल में गलत मान का उपयोग किया जाता है। वास्तव में सही बात क्या है? केवल एक संकेत है कि जिस प्रोग्राम पर "डेटा" प्रोग्राम काम कर रहा है वह गलत है और कुछ एसेटर्स की तरह हैं लेकिन अन्य उन्नत त्रुटि रिपोर्टिंग और संभावित त्रुटि पुनर्प्राप्ति का उपयोग करना चाहते हैं। किसी भी मामले में डेटा दोषपूर्ण पाया जाता है और कुछ मामलों में इस पर काम करना जारी रखना अच्छा होता है। (ध्यान दें कि सर्वर कम से कम मर नहीं जाते हैं)
किसी उपग्रह से भेजी गई एक छवि उन्नत त्रुटि पुनर्प्राप्ति का प्रयास करने का मामला हो सकता है ... इंटरनेट से डाउनलोड की गई छवि को त्रुटि आइकन डालने के लिए। ..
मुझे बहुत राय है कि सही प्रोग्रामिंग इन जोखिमों के खिलाफ सुरक्षा करेगी। बहिष्कृत कार्यों से बचने जैसी चीजें, जो (कम से कम माइक्रोसॉफ्ट सी ++ पुस्तकालयों में) सुरक्षा भेद्यता के कारण सामान्य रूप से बहिष्कृत होती हैं, और बाहरी सीमा पार करने वाली सभी चीज़ों को प्रमाणित करती हैं।
फ़ंक्शंस जिन्हें केवल आपके कोड से बुलाया जाता है, को अत्यधिक पैरामीटर सत्यापन की आवश्यकता नहीं होती है क्योंकि आप कॉलर को नियंत्रित करते हैं, यानी, बाहरी सीमा पार नहीं होती है। अन्य लोगों के कोड द्वारा बुलाए गए कार्यों को यह मानना चाहिए कि आने वाले पैरामीटर किसी बिंदु पर अमान्य और/या दुर्भावनापूर्ण होंगे।
उजागर कार्यों से निपटने के लिए मेरा दृष्टिकोण संभवतः एक उपयोगी संदेश के साथ, आसानी से दुर्घटनाग्रस्त होना है। यदि कॉलर सही पैरामीटर नहीं प्राप्त कर सकता है तो समस्या उनके कोड में है और उन्हें ठीक करना चाहिए, न कि आप। (स्पष्ट रूप से आपने अपने फ़ंक्शन के लिए प्रलेखन प्रदान किया है, क्योंकि इसका खुलासा किया गया है।)
कोड इंजेक्शन केवल एक समस्या है यदि आपका एप्लिकेशन वर्तमान उपयोगकर्ता को उन्नत करने में सक्षम है। यदि कोई प्रक्रिया आपके एप्लिकेशन में कोड इंजेक्ट कर सकती है तो यह आसानी से कोड को स्मृति में लिख सकती है और वैसे भी इसे निष्पादित कर सकती है। सिस्टम कोड इंजेक्शन हमलों तक पूर्ण पहुंच प्राप्त करने में सक्षम होने के बिना व्यर्थ हैं। (यही कारण है कि प्रशासकों द्वारा उपयोग किए जाने वाले अनुप्रयोगों को कम उपयोगकर्ताओं द्वारा लिखने योग्य नहीं होना चाहिए।)
मेरे अनुभव में, सकारात्मक रूप से रक्षात्मक प्रोग्रामिंग को नियोजित करने का मतलब यह नहीं है कि आप अपने कोड की गुणवत्ता में सुधार करना चाहते हैं। मुझे गलत मत समझो, आपको रक्षात्मक रूप से प्रोग्राम की ज़रूरतों को पूरा करने के लिए प्रोग्राम की आवश्यकता है, जो उपयोगकर्ता आते हैं - उपयोगकर्ताओं को यह पसंद नहीं है जब आपका प्रोग्राम उन पर दुर्घटनाग्रस्त हो जाता है - लेकिन कोड को बनाए रखने के लिए यह आसान नहीं है, परीक्षण, आदि
कई साल पहले, हमने अपने सॉफ्टवेयर के सभी स्तरों पर यह दावा करने के लिए नीति बनाई और यह - इकाई परीक्षण, कोड समीक्षा आदि के साथ-साथ हमारे मौजूदा आवेदन परीक्षण सूट - एक महत्वपूर्ण, सकारात्मक था हमारे कोड की गुणवत्ता पर प्रभाव।
मैं लोगों को कोड लिखने की सलाह देता हूं जो विकास पर्यावरण में फासीवादी है और उत्पादन में उदार है।
विकास के दौरान आप समस्याओं को रोकने के लिए जितनी जल्दी हो सके खराब डेटा/तर्क/कोड को पकड़ना चाहते हैं या तो बाद में समस्याएं होती हैं जहां मूल कारण ट्रैक करना मुश्किल होता है।
उत्पादन में हैंडल समस्याओं को यथासंभव सुंदरता में। अगर कुछ वास्तव में एक गैर-पुनर्प्राप्ति योग्य त्रुटि है तो उसे संभाल लें और उस जानकारी को उपयोगकर्ता को प्रस्तुत करें।
उदाहरण के तौर पर एक वेक्टर को सामान्यीकृत करने के लिए हमारा कोड है। यदि आप इसे विकास में खराब डेटा खिलाते हैं तो यह चिल्लाएगा, उत्पादन में यह एक सुरक्षा मूल्य देता है।
inline const Vector3 Normalize(Vector3arg vec)
{
const float len = Length(vec);
ASSERTMSG(len > 0.0f "Invalid Normalization");
return len == 0.0f ? vec : vec/len;
}
के रूप में भी जाना जाता है हम विरासत कोड पर समस्या का पता लगाने के लिए एक समान तरीके का उपयोग करते हैं। मैक्रो को जोड़ना आसान है, परीक्षण के दौरान इसका एकमात्र प्रभाव डीबग संदेशबॉक्स है। यह एक चमत्कार समाधान नहीं है, लेकिन यह "वापसी गलत" से बेहतर है; कोई भी कभी जांच नहीं करता है – paercebal
जावा, हस्ताक्षर किए गए जार और जेएएएस।
जावा बफर ओवरफ़्लो और पॉइंटर/स्टैक व्हीकिंग शोषण को रोकने के लिए।
जेएनआई का उपयोग न करें। (जावा मूल इंटरफ़ेस) यह आपको डीएलएल/साझा पुस्तकालयों के बारे में बताता है।
क्लास लोडिंग को सुरक्षा समस्या होने से रोकने के लिए जेएआर को हस्ताक्षर किया।
जेएएएस आपके आवेदन को किसी पर भरोसा नहीं कर सकता है, यहां तक कि खुद भी।
जे 2 ईई (भरोसेमंद रूप से सीमित) भूमिका आधारित सुरक्षा के लिए अंतर्निहित समर्थन है।
इनमें से कुछ के लिए कुछ ओवरहेड है लेकिन सुरक्षा छेद दूर हो जाते हैं।
सरल उत्तर: यह पर निर्भर करता है। बहुत अधिक रक्षात्मक कोडिंग प्रमुख प्रदर्शन समस्याओं का कारण बन सकता है।
जो आप वर्णन करते हैं उसे YAGNI - http://en.wikipedia.org/wiki/YAGNI – abyx