जावा सुरक्षित कोडिंग क्यों महत्वपूर्ण है?

Question

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

Answer 1

प्रोग्रामिंग कठिन है।

यदि आप सख्त एपीआई परिभाषित करते हैं, तो वे उन चरों का पर्दाफाश नहीं करते हैं जिन्हें प्रकट नहीं किया जाना चाहिए (हम इसे encapsulation पर कॉल करना चाहते हैं), आप अपने एपीआई के उपयोगकर्ताओं की मदद करते हैं, और इस प्रकार प्रोग्रामिंग को आसान बनाते हैं। यह एक अच्छी बात माना जाता है।

कारणों नहीं मुख्य रूप से "सुरक्षा", जितना स्पष्टता, सरलता, और understandability गुप्त गुप्त बातें रखते हुए, के रूप में कर रहे हैं।

एक बोनस के रूप में, यह चीजों को सही ढंग से काम करता है, तो आप पता कर सकते हैं कि एपीआई के उपयोगकर्ता नहीं बदल रहा है अपनी पीठ के पीछे "अपने" चर, निश्चित रूप से बनाने के लिए काफी आसान है।

Answer 2

यह "सुरक्षित" है जिसका अर्थ यह है कि जो कोई भी इसका उपयोग करता है, उसके लिए एक कक्षा आंतरिक कार्य छुपा रहता है।

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

अपने उदाहरण ले रहा है:

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

Answer 3

बस क्या दूसरों को पहले से ही कहा है में जोड़ने के लिए। यदि मैं सदस्य private बनाता हूं तो मैं इसे दूसरों तक पहुंचने के लिए "असंभव" बना देता हूं (यह संभव है, लेकिन यह यहां बिंदु के अलावा है), लेकिन अधिक महत्वपूर्ण बात यह है कि मैं उपयोगकर्ताओं को बताता हूं कि यह एक कार्यान्वयन विस्तार है, कि उन्हें भरोसा नहीं करना चाहिए ।

Answer 4

यहां दो मुद्दे हैं।

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

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

उदाहरण के लिए, यदि आपके पास संरक्षित फ़ंक्शन getArea() के साथ क्लास स्क्वायर है, तो आप एक वर्ग के क्षेत्र को वापस करने की उम्मीद करते हैं। हालांकि, वर्ग आयताकार वर्ग को विस्तारित करता है, एक नई कक्षा बनाई जा सकती है जो वर्ग को बढ़ाती है। अब rectange getArea() को ओवरराइड कर सकता है, लेकिन यह अभी भी प्रकार का वर्ग है, जो कुछ तोड़ सकता है जो वर्ग की उस कार्यक्षमता पर निर्भर करता है। अपनी कक्षा को अंतिम बनाकर आप जोर दे रहे हैं कि यह आपके सिस्टम में कभी नहीं हो सकता है।

इस प्रकार का "सुरक्षित कोडिंग" किसी को आपके स्रोत कोड को देखने से नहीं रोकेगा, लेकिन यह भविष्य में आपके कोड को अधिक विश्वसनीय और उपयोग करने में मदद करता है।

Answer 5

जावा object-oriented programming लैंगेज है, और ऑब्जेक्ट उन्मुख प्रोग्रामिंग में महत्वपूर्ण अवधारणाओं में से एक encapsulation है।

encapsulation के पीछे विचार आंतरिक चर के रूप में कार्यान्वयन विवरण जैसे "ऑब्जेक्ट की स्थिति और एल्गोरिदम जैसे आंतरिक कार्यकलापों को" छिपाना "है, और केवल एक इंटरफ़ेस प्रदान करना है जो अन्य ऑब्जेक्ट्स प्रदर्शन करने के लिए उपयोग कर सकते हैं वस्तु के साथ काम करता है।

उस अवधारणा का उपयोग करके, अन्य वस्तुओं को सीधे आंतरिक राज्यों को प्रभावित करने से रोकने के लिए private चर का उपयोग कर आंतरिक राज्यों को छिपाना चाहेंगे। जावा में, वस्तुओं के साथ काम करने के लिए गेटर्स और सेटर्स (उदा। getColor और setColor) देखना आम बात है।

इसके अलावा, encapsulation कोड की मजबूती भी बढ़ा सकता है।

उदाहरण के लिए, आंतरिक राज्यों तक पहुंच प्रतिबंधित करके, ऑब्जेक्ट को बदलने से पहले कुछ सैनिटी चेक करना संभव होगा।

एक ठोस उदाहरण के रूप में कहते हैं कि एक Score वस्तु 0 और 100 जो percent मूल्य के लिए किया गया है कि नहीं था। setPercent(int) विधि प्रदान करके जो मान्य करता है कि निर्दिष्ट मान अनुमत सीमा के भीतर था, यह Score ऑब्जेक्ट को अस्वीकार्य स्थिति में सेट करने से रोक देगा।

तो, सीधे score.percent = 150 की तरह एक बयान लिख कर आंतरिक स्थिति में हेरफेर करने की कोशिश कर रोका जा सकता है, setPercent विधि एक त्रुटि का कारण बनता है या एक Exception फेंकता है तो निर्धारित मूल्य से अस्वीकार्य है अगर।

Answer 6

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

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

संक्षेप में, आप एक विशाल समस्या में हैं, और डिबगिंग आप के बाद से एक बुरा सपना नहीं जानता कि जब डेटा chagned गया था, जो धागा किया है, इसलिए इससे जहां आदि happend

बस एक के परिदृश्य से क्या हो रहा है अगर आप encapsulate नहीं है ...

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

Answer 7

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

• Secure Coding Guidelines for the Java Programming Language, version 2.0. दो साल पहले अपडेट किया गया है, और एक अद्यतन की जरूरत होती:

  जावा के लिए वहाँ दो उल्लेखनीय मार्गदर्शक हैं।

• The CERT Sun Microsystems Secure Coding Standard for Java. एक नया विकि दोनों CERT और सूर्य जो कुछ भी आपको लगता है कि महत्वपूर्ण है के साथ अद्यतन किया जा सकता है जिसके द्वारा समर्थित। यह सूर्य दिशानिर्देशों की तुलना में बहुत व्यापक दृश्य लेता है। उदाहरण के लिए, सूर्य दिशानिर्देश वास्तव में पूर्णांक ओवरफ़्लो से संबंधित नहीं हैं क्योंकि सभी सरणी सीमाएं चेक की जाती हैं, लेकिन विकी ऐसा इसलिए करती है क्योंकि यह अभी भी प्रोग्राम त्रुटियों का कारण बन सकती है।

जावा में सुरक्षित कोडिंग के दो अलग-अलग तरीके हैं।

एक आप कोड सभी विशेषाधिकार है कि आपके कोड करता है नहीं हो सकता है कि साथ काम कर रहे में

। उदाहरण के लिए यदि आप लाइब्रेरी लिख रहे हैं या कोड पर हस्ताक्षर कर रहे हैं तो आपको यह करने की ज़रूरत है। दुर्भावनापूर्ण कोड के लिए अनजान तरीकों से आपकी अनुमतियों का लाभ उठाना असंभव होना चाहिए। यह कठिन है!

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

कुछ ओवरलैप है। उदाहरण के लिए दुभाषिया दुभाषिया कोड की अनुमतियों के साथ चलते हैं और काफी "शक्तिशाली" हो सकते हैं।