क्या परावर्तन एक नुकसान है क्योंकि निजी चर को प्रतिबंधित नहीं किया जा सकता है?

Question

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

Comments

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

— कोडइन्चौस

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

— कोडइन्चौस

Google यह, बहुत सारे डुप्लिकेट हैं: stackoverflow.com/questions/7566626/… , stackoverflow.com/questions/29246028/… , stackoverflow.com/questions/18619754/java-preventing-reflection ...

— dagnelies

उपयोगकर्ता जो कुछ भी चाहते हैं, उसे करने के लिए बस अपना कोड पैच कर सकते हैं। DRM के लिए आंशिक अपवाद के साथ (जो स्थायी सुरक्षा प्रदान करने के लिए पर्याप्त शक्तिशाली नहीं है), कोई भी व्यक्ति जिसके पास आपके एप्लिकेशन (बायनेरी या स्रोत कोड) तक पहुंच है, इसके साथ कुछ भी कर सकता है।

— ब्रायन

क्या यह भाषा का विशिष्ट प्रश्न नहीं है? प्रतिबिंब विभिन्न भाषाओं में अलग ढंग से संचालित होता है। मैं सोच रहा था कि क्या इस सवाल में जावा या कुछ और के लिए एक टैग होना चाहिए।

— वेन कॉनराड

Answer 1

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

Comments

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

— ब्रायन

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

— जिमीजैम्स

@ ब्रायन यह 100% सही नहीं है - कुछ प्रतिबिंब संचालन हैं जो आप आंशिक रूप से विश्वसनीय कोड में कर सकते हैं; यह आपको निजी क्षेत्रों तक पहुँचने जैसे काम करने की अनुमति नहीं देता है।

— लुअन

@Brian जब तक किसी को एक भेद्यता या सामाजिक इंजीनियरिंग नहीं मिलती है जो उन्हें प्रतिबंधों को बायपास करने की अनुमति देता है। उन्हें उस तरह से इस्तेमाल करने की कोशिश करने का कोई मतलब नहीं है। यह उनका प्राथमिक उद्देश्य नहीं है।

— jpmc26

Answer 2

वर्ग अभिगम अधिकारों पर हर्ब सटर को उद्धृत करने के लिए :

"यहाँ मुद्दा मर्फी के खिलाफ की रक्षा करना है। मैकियावेली के खिलाफ की रक्षा करना ... यानी, आकस्मिक दुरुपयोग (जो भाषा बहुत अच्छा करती है) के खिलाफ रक्षा करना। बनाम जानबूझकर दुरुपयोग (जो प्रभावी रूप से असंभव है) के खिलाफ रक्षा करना। अंत में, यदि एक प्रोग्रामर बुरी तरह से सिस्टम को अलग करना चाहता है, वह एक रास्ता ढूंढेगा "

Comments

ऐसे समय होते हैं जब आपको अविश्वास कोड को सैंडबॉक्स करने की आवश्यकता होती है, लेकिन यह एक कठिन काम है। त्रुटि (मर्फी) से बचाव कहीं अधिक सामान्य मामला है।

— पॉल ड्रेपर

#define private public(इस बात को नज़रअंदाज़ करते हुए कि यह वास्तव में अपरिभाषित व्यवहार है) और वोइला मैं बाहर से आपकी कक्षाओं के प्रतिबंधित हिस्से तक पूरी पहुँच रखता है।

— बोल्व

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

— MarkJ

@MarkJ। हर्ब सटर की टिप्पणी डेवलपर द्वारा जानबूझकर दुरुपयोग के बारे में है जिसने पहली जगह में क्लास लिखा था और शायद उनकी टीम के साथी। मुझे नहीं लगता कि भाषा सुविधाओं द्वारा उस तरह के दुरुपयोग को रोकने का कोई तरीका है।

— निमन्जा ट्राइफुनोविक

@ मुझे लगता है कि स्टंट भाषा पर निर्भर है जो मुझे लगता है। हालांकि C / C ++ प्रीप्रोसेसर शायद आपको इससे दूर कर देंगे, लेकिन उनके बिना कुछ भी शायद "#define" में "आरक्षित शब्दों का उपयोग नहीं कर सकता है"।

— दान

Answer 3

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

Comments

दूसरे शब्दों में, यह एक संभावित टूटी हुई एपीआई को दरकिनार करने का एक तरीका है - चाहे अपूर्ण आवश्यकताओं या अपूर्ण कार्यान्वयन के कारण।

— मोनिका से

Answer 4

आप एक से अधिक स्तर तक पहुंच को प्रतिबंधित करते हैं: निष्पादन वातावरण।

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

जावा में ऐसा करने के बारे में अधिक जानकारी: प्रतिबिंब सुरक्षा

Answer 5

आप किस प्रतिबिंब के बारे में बात कर रहे हैं?

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

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

Answer 6

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

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

ध्यान दें कि यह, जाहिर है, सुरक्षा मुद्दे बनाता है जहां एक तृतीय-पक्ष आपके डेटा तक पहुंच सकता है ; कुछ जो एक स्ट्रिंग और समान डेटा संरचनाओं के एन्क्रिप्टेड वेरिएंट की ओर जाता है । लेकिन इस तरह के उपयोग से अपने कोड की रक्षा करना अधिक संबंधित OS और कोड-स्तरीय एक्सेस प्रतिबंध है , और इसका प्रति चिंतन से कोई लेना-देना नहीं है।

Comments

ध्यान दें कि C # में, केवल पूरी तरह से विश्वसनीय कोड निजी सदस्यों को प्रतिबिंबित कर सकता है। मेमोरी को प्रोसेस करने के लिए सीधे लिखना अभी भी काम करता है, लेकिन मूल कोड की तुलना में कठिन है।

— लुआन