ऑब्जेक्ट प्रतिबिंब का सुरक्षा जोखिम क्या है?

Question

तो कुछ घंटों के कामकाज के बाद वर्तमान में Google App Engine पर प्रतिबिंब की सीमा को अक्षम कर दिया गया है, मैं सोच रहा था कि कोई मुझे समझने में मदद कर सकता है कि ऑब्जेक्ट प्रतिबिंब खतरे क्यों हो सकता है। क्या ऐसा इसलिए है क्योंकि मैं कक्षा के निजी चर का निरीक्षण कर सकता हूं या क्या कोई और गहरा कारण है?

Answer 1

1 - प्रतिबिंब (एक अवधारणा के रूप में) सुरक्षा/सुरक्षा के लिए वास्तव में ऑर्थोगोनल है।

जावा के डिजाइन में एक बड़ा जोर है कि यह एक सुरक्षित मंच बनाने के लिए, स्थिर टाइपिंग साथ था, सुरक्षा प्रबंधक, वर्ग लोडर, और कोई रास्ता नहीं संकेत पेंच के लिए/स्मृति के अनुशासित उपयोग । आप Masterminds of programming में जेम्स गोस्लिंग के साक्षात्कार को पढ़ सकते हैं, जो इसके बारे में दिलचस्प है।

लेकिन प्रतिबिंबित शक्ति आपके पास कठिन है, यह सुनिश्चित करना है कि चीजें सुरक्षित हों। प्रतिबिंब विशेष रूप से स्थैतिक टाइपिंग हार जाता है और रन-टाइम त्रुटियों का कारण बन सकता है।

लेकिन अधिक सूक्ष्म चीजें भी हो सकती हैं। उदाहरण के लिए क्लास लोडर - जिसे सिस्टम में प्रतिबिंबित हुक के रूप में माना जा सकता है - जावा के शुरुआती संस्करण में उचित रूप से डिज़ाइन नहीं किया गया था जिससे संभावित प्रकार प्रतिस्थापन हो गया। गिलद ब्राचा द्वारा आलेख Dynamic class loading in the JVM,, इस तरह के मुद्दों पर अंतर्दृष्टिपूर्ण है।

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

• strings अब और अपरिवर्तनीय नहीं हैं और बदला जा सकता है
• आप वस्तुओं की समझदार जानकारी आप
• ... अन्य कारनामों के स्वामी नहीं हैं प्रकट कर सकते हैं ...

(इस question देखें)

अंत में अन्य तंत्र हैं जो सुरक्षा को खतरे में डालते हैं, विशेष रूप से sun.misc.Unsafe जो स्मृति-पॉइंटर्स तक सीधे पहुंच प्रदान करता है।

2 - अब सवाल यह है कि क्या प्रतिबिंब (अभ्यास में) कई जोखिमों को जन्म देता है।

मैंने @dbyrne द्वारा इंगित लिंक पढ़ा है लेकिन यह ज्यादातर .NET के बारे में है। साथ ही मुझे नहीं पता कि Google ऐप के लिए क्या अक्षम है। क्या यह केवल ReflectPermission है, या सुरक्षा प्रबंधक की अन्य अनुमति है? फाइल सिस्टम और मैस के आसपास पहुंच पाने के लिए एक खतरे स्पष्ट रूप से है।

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

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

साझा/होस्ट किए गए वातावरण में, सुरक्षा संबंधित है। भाषा स्तर पर, उदाहरण के लिए आप 100% CPU का उपभोग करने वाले मॉड्यूल प्रपत्र को रोक नहीं सकते हैं या OutOfMemoryException तक सभी मेमोरी का उपभोग नहीं कर सकते हैं। इस तरह की चिंताओं को वर्चुअलाइजेशन और कोटा के साथ आमतौर पर ओएस स्तर पर अन्य माध्यमों से संबोधित करने की आवश्यकता है।

तो मेरा निजी उत्तर होगा: प्रतिबिंब एक सुरक्षा जोखिम है, लेकिन अन्य संभावित हमले वैक्टरों की तुलना में अभ्यास में इतना बड़ा नहीं है।

Answer 2

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

• पहुँच जानकारी है कि छिपा हो माना जाता है,
• पर जावा सुरक्षा सैंडबॉक्स नष्ट ताकि आप JVM में चल रहे अन्य बातों के साथ हस्तक्षेप कर सकते, पहुँच फ़ाइलें: सरलता का एक सा के साथ, इस के लिए पर्याप्त है स्थानीय मशीन, और इतने पर।

कुछ परिस्थितियों में, यह दुर्भावनापूर्ण देशी कोड के इंजेक्शन को भी अनुमति दे सकता है।

Answer 3

मेरा एक सिद्धांत यह है कि Google कुछ छिपाने की कोशिश कर रहा है। Reflection अक्षम करके Google परिवर्तनीय नाम, फ़ंक्शन कॉल और यहां तक ​​कि एक पूर्ण API को छुपा सकता है। अगर Google एपीआई की तरह कुछ छुपा रहा है, तो निश्चित रूप से वे आपको इसके बारे में बताने वाले नहीं हैं।

मुझे इस तथ्य के बारे में पता है कि प्रतिबिंब सुरक्षा परीक्षण में एक बहुत ही महत्वपूर्ण भूमिका निभाता है। उदाहरण के लिए आप प्रतिबिंब का उपयोग कर स्वचालित रूप से फ़ज़ परीक्षण उत्पन्न कर सकते हैं। AxMan सभी कक्षाओं और उनके विधि कॉल की पहचान करने के लिए टाइपलिब का उपयोग करता है जो COM ऑब्जेक्ट बनाता है। इस जानकारी का उपयोग करके एक्समैन प्रत्येक कक्षा को तुरंत चालू करेगा और लंबी विधि और बड़ी संख्या के क्रमिक क्रम के साथ प्रत्येक विधि को कॉल करेगा। इसी तरह के परीक्षण प्रतिबिंब के लिए WSDL फ़ाइल का उपयोग कर SOAP Fuzzers द्वारा आयोजित किया जाता है।

Answer 4

सबसे पहले, अगर आपने SecurityManager इंस्टॉल नहीं किया है तो आप वैसे भी सुरक्षित नहीं हैं।

दूसरे, प्रतिबिंब महत्वपूर्ण छेद को खोलने नहीं है जब तक कि setAccessible() सक्षम किया गया है, और खुद को है कि एक सुरक्षा जांच (setAccessChecksreflection permission द्वारा नियंत्रित) के अधीन है। इसके बिना, जबकि आप यह जान सकेंगे कि निजी क्षेत्र या विधि मौजूद है (हालांकि स्वयं को accessDeclaredMembersruntime permission की आवश्यकता है) आप उस ज्ञान के साथ कुछ भी नहीं कर सकते हैं। हमला करने के लिए आपकी सबसे अच्छी शर्त धारावाहिक वस्तुओं के साथ काम करना हो सकता है, लेकिन यह मोम की एक पूरी 'नोटर बॉल' है।

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

Answer 5

जीएई एक साझा होस्टिंग वातावरण है, और कई उपयोगकर्ताओं से WAR फ़ाइलों को होस्ट करता है। यह अत्यधिक संभावना है कि एक ही JVM में एकाधिक WAR फ़ाइलें होस्ट की जाती हैं, क्योंकि प्रति WAR प्रक्रिया को हास्यास्पद करना हास्यास्पद है। इसलिए, प्रत्येक युद्ध फ़ाइल को सैंडबॉक्स करने का एकमात्र तरीका प्रत्येक WAR फ़ाइल के लिए कस्टम क्लासलोडर के माध्यम से होता है।

अब, मान लीजिए कि प्रतिबिंब की अनुमति थी। आप could then walk the classloader hierarchy और अलग-अलग उपयोगकर्ताओं से संबंधित WAR फ़ाइलों से कक्षाओं/विधियों की गणना करें। जाहिर है, यह एक बड़ी चिंता है।