गुणवत्ता कोड: डेटा सत्यापन आवश्यक है

-555 बेसिन के बारे में पोस्ट पर टिप्पणियों में जो चर्चा हुई, वह इंगित करती है कि उपयोगकर्ता से प्राप्त गलत डेटा पर प्रतिक्रिया कैसे करें, यह सभी के लिए स्पष्ट नहीं है।





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



इस विषय पर विशेष साहित्य में अक्सर और बड़े पैमाने पर चर्चा की जाती है, उदाहरण के लिए, एस। मैककोनेल (कोड पूरा), अध्याय 8, "रक्षात्मक प्रोग्रामिंग" द्वारा "परफेक्ट कोड" देखें।



मैं इस पुस्तक से एक छोटा उद्धरण दूंगा (यदि किसी ने इसे नहीं पढ़ा है, तो मैं इसकी सलाह देता हूं):

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

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

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

8.1। प्रोग्राम को गलत इनपुट डेटा से सुरक्षित रखना।

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



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



इनपुट जंक डेटा को संसाधित करने के तीन मुख्य तरीके हैं, जो नीचे सूचीबद्ध हैं।



बाहरी स्रोतों से सभी डेटा की जाँच करें

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



विधि के सभी इनपुट मापदंडों के मूल्य की जांच करें

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



तय करें कि गलत इनपुट को कैसे संभालना है।

यदि आप गलत पैरामीटर पाते हैं तो क्या होगा? स्थिति के आधार पर, आप धारा 8.3 में विस्तार से वर्णित एक दर्जन दृष्टिकोणों में से एक का चयन कर सकते हैं।



सुरक्षात्मक प्रोग्रामिंग इस पुस्तक में वर्णित कार्यक्रमों की गुणवत्ता में सुधार करने के अन्य तरीकों के लिए एक उपयोगी अतिरिक्त है। सुरक्षित रूप से सांकेतिक शब्दों में बदलना करने का सबसे अच्छा तरीका शुरू में गलतियाँ करना नहीं है। Iterative डिज़ाइन, कोडिंग से पहले छद्म कोड और परीक्षण लिखना, और परियोजना के अनुपालन का निम्न-स्तरीय सत्यापन यह सब है जो दोषों को जोड़ने से बचने में मदद करता है। ...

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



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

उसे शायद सील कर दिया गया था, शायद किसी तरह के कुल्हक ने जाँच की कि यहाँ सब कुछ कैसे काम करता है, और शायद यह इंटरफ़ेस में एक गलती है।

किसी भी मामले में, यदि डेटा प्रविष्टि के दौरान कोई त्रुटि होती है, तो प्रोग्राम को स्थगित करना और उपयोगकर्ता को सूचित करना तर्कसंगत है कि दर्ज किया गया डेटा गलत है। (स्वाभाविक रूप से, हम उन संदेशों के बारे में बात कर रहे हैं जो उपयोगकर्ता के लिए समझने योग्य हैं, उदाहरण के लिए, "http / 500, UE फेंक ... गलत ज़िप ... कक्षा N पर" के बजाय "इस तरह के सूचकांक के साथ कोई समझौता नहीं है"।



यह माना जाता है कि इससे इंटरफ़ेस की "मित्रता" कम हो जाएगी। ऐसा नहीं है। इसके विपरीत, सॉफ्टवेयर उपयोगकर्ता के लिए और डेवलपर दोनों के लिए अधिक समझने योग्य, अनुमानित और सुरक्षित हो जाएगा। व्यवहार में यह सत्यापित करना आसान है: लॉग में ऐसी त्रुटियों को लिखना पर्याप्त है, और बाद में इसकी सामग्री का विश्लेषण करें।



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