2010-11-01 14 views
7

मैं जावा कोड में deserialization के साथ समस्याओं को खोजने में सक्षम होना चाहूंगा। मुझे क्या खोजना चाहिए? उदाहरण के लिए, कोई कैसे निर्धारित करेगा कि कुछ जावा कोड "java calendar bug" का फायदा उठाने का प्रयास करता है या नहीं? ध्यान दें कि मैं जावा प्रोग्रामर नहीं हूं, लेकिन मैं धारावाहिकता और ओओपी जुर्माना के पीछे अवधारणाओं को समझता हूं। मैं कुछ सुरक्षा जांच को लागू करने की कोशिश कर रहा हूं (कुछ संकलक चेतावनी उपकरण की तरह)।जावा deserialization मुद्दों को कैसे स्पॉट करें?

संपादित करें: टिप्पणियां मैं सवाल थोड़ा परिवर्तन करना चाहते हैं के आधार पर: मैं विचार सभी कोड का विश्लेषण किया "अविश्वसनीय", वहाँ एक रास्ता संभावित खतरा रेट करने के लिए कैसे है? मेरा मतलब है, क्या मैं बता सकता हूं कि कोड ए deserialization बग के संबंध में बी से अधिक खतरनाक है? मुझे क्या खोजना चाहिए?

उत्तर

5

सबसे पहले आपको सुरक्षा खतरों को निर्धारित करने के लिए अपने संदर्भ को समझने की आवश्यकता है। (जब मैं "ट्रस्ट" के बारे में बात करता हूं, तो मैं थोड़ा छोटा कटौती कर रहा हूं। मैं जानबूझकर दुर्भावनापूर्ण बात कर रहा हूं।)

यदि धारावाहिक डेटा बनाया गया था, उसी ट्रस्ट के साथ रखा और पढ़ा गया था, तो कोई भी नहीं है वास्तविक समस्या (मानक बग के अलावा)। ध्यान दें कि यदि आप कोई संवेदनशील जानकारी लिखते हैं, तो धारावाहिक डेटा भी संवेदनशील है (यह स्पष्ट प्रतीत होता है, लेकिन वहाँ एक उचित मात्रा में संकेत है)।

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

आप जो कम विश्वसनीय कोड द्वारा किया जाता है पुस्तकालय कोड लिख रहे हैं, तो चीजें और दिलचस्प हो जाता:

"कैलेंडर बग" (और इसी तरह) के मामले में, जो दुर्भावनापूर्ण साथ एक मनमाना धारा deserialising के बारे में है डेटा और दुर्भावनापूर्ण कोड। जावा सिक्योर कोडिंग दिशानिर्देश कस्टम readObject विधियों के भीतर सुरक्षा जांच ("जावा 2 सुरक्षा मॉडल" का उपयोग करके) करने का सुझाव देते हैं, जिसका अर्थ है कि आपको कोड और डेटा की तुलना में अधिक विश्वास के साथ deserialisation को कॉल नहीं करना चाहिए।

deserialisable वस्तुओं के पक्ष से, चीजें अधिक मुश्किल हैं। ObjectInputStream द्वारा readObject, readUnshared, defaultReadObject, readFields या केवल डिफ़ॉल्ट deserialisation द्वारा दुर्भावनापूर्ण कोड द्वारा कब्जा कर लिया गया संदर्भ हो सकता है, या गैर-अंतिम कक्षाओं के लिए, दुर्भावनापूर्ण subclassed हो सकता है। आंशिक रूप से प्रारंभ होने पर, एक वस्तु का उपयोग deserialisation के दौरान भी किया जा सकता है। Deserialisation deserialised वर्ग के एक "वास्तविक" कन्स्ट्रक्टर का आह्वान नहीं करता है (readObject/readObjectNoData एक प्रकार का psuedo-constructor है, जो final एस सेट नहीं कर सकता है)। यह सब एक दुःस्वप्न है, इसलिए आप शायद अपने संवेदनशील वर्गों को क्रमबद्ध नहीं बनाना चाहते हैं।

क्रमबद्धरण और deserialisation के कार्यान्वयन में कई भेद्यताएं रही हैं। आपको इसके बारे में चिंता करने की ज़रूरत नहीं है, जब तक कि आप इसे स्वयं लागू नहीं कर लेते।

+0

एक पूरी तरह से पूर्ण जवाब +1 –

2

हम्म ... आपका प्रश्न थोड़ा सामान्य है। क्या आपने this आलेख पर एक नज़र डाली? यह जावा के सीरियलाइजेशन एल्गोरिदम के बारे में है, लेकिन Google के कैश से क्योंकि मुख्य पृष्ठ इस समय नीचे दिख रहा है।

+0

लेख के लिए धन्यवाद, मैं इसके माध्यम से जाऊंगा। मुझे पता है कि मेरा प्रश्न थोड़ा सामान्य है, लेकिन मैं इस मुद्दे को सामान्य तरीके से कवर करना चाहता हूं। – PeterK

1

मैंने सोचा होगा कि जावा में ज्ञात सुरक्षा छेद का उपयोग करने वाले कोड को हराने का सबसे अच्छा तरीका जावा संस्करण में अपग्रेड करना है जो बग को हल करता है। और अगला सबसे अच्छा तरीका (धारावाहिक संबंधित बग से निपटने के लिए) सभी धारावाहिक डेटा को अज्ञात/असत्यापित/असुरक्षित स्रोतों से संदिग्ध माना जाता है।

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

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

+0

अच्छा बिंदु! जवाब के लिए धन्यवाद। कृपया संपादित प्रश्न देखें, मैंने इसे थोड़ा सा बदल दिया, शायद वह कहीं भी नेतृत्व करेगा। – PeterK

+0

@ पीटरके - ईमानदारी से, मुझे नहीं पता कि क्या देखना है। लेकिन एक बार फिर, यदि देखने के लिए ज्ञात चीजें थीं, तो आप उम्मीद करेंगे कि सूर्य और दूसरों को पहले ही देखा होगा। उदाहरण के लिए, मुझे लगता है कि कैलेंडर छेद की खोज ने आंतरिक कोड समीक्षाओं की झुकाव को प्रेरित किया। –

+0

आप दोनों को करने से बेहतर हैं। सभी धारावाहिक डेटा को अविश्वसनीय रूप से अपग्रेड करें और उनका इलाज करें। – Antimony

1

आप अपने जावा वस्तु को क्रमानुसार तो एक अलग पर स्थानांतरित करना आवेदन, अनुप्रयोगों के बीच साझा की गई कुंजी के साथ ऑब्जेक्ट पर हस्ताक्षर करने पर विचार क्यों नहीं करें? यह मनुष्यों के बीच में हमले से खुद को बचाने के लिए पर्याप्त होना चाहिए।

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

संबंधित मुद्दे