MALICIOUS_CODE EI_EXPOSE_REP मध्यम

Question

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

public class User implements Serializable 
{ 
    protected Date birthDate; 

    public Date getBirthDate() 
    {return(birthDate);} 

    public void setBirthDate(final Date birthDate) 
    {this.birthDate = birthDate;} 
} 

इस वर्ग अधूरा है, इसलिए मुझे इसे serialVersionUID और अन्य मानक सामान लापता के बारे में वीणा नहीं है, मैं सिर्फ birthDate सुरक्षा छेद के साथ चिंतित हूँ: मैं एक साधारण इकाई है, एक उपयोगकर्ता का कहना है।

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

http://findbugs.sourceforge.net/bugDescriptions.html#EI_EXPOSE_REP

मैं मैं अभी भी वास्तव में नहीं दिख रहा है कि समस्या क्या इस मामले में यहाँ है लगता है। क्या मुझे long में पास करना चाहिए और उस तारीख को सेट करना चाहिए?

वाल्टर

Answer 1

मुझे लगता है कि यहाँ मुख्य बिंदु यदि:

उदाहरणों अविश्वस्त कोड द्वारा पहुँचा रहे हैं, और परिवर्तनशील वस्तु को अनियंत्रित परिवर्तन सुरक्षा या अन्य महत्वपूर्ण गुण समझौता चाहते हैं आप, कुछ अलग करने की आवश्यकता होगी।

दूसरे शब्दों में

तो, अगर आप एक अपरिवर्तनीय वस्तु चाहता था आपका कोड गलत हो (यानी आप एक setBirthdate() विधि नहीं था),, क्योंकि किसी ने लिख सकते हैं:

Date date = user.getBirthDate(); 
date.setMonth(1); // mutated! 

तो तुम शायद इसके बजाय निम्नलिखित चाहते हैं:

public Date getBirthDate() 
{return new Date(birthDate.getTime());} // essentially a clone 

Answer 2

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

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

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

Answer 3

हाँ, मैं वास्तव में इसे 'सुरक्षा' समस्या नहीं कहूंगा ... मेरा मतलब है, हमलावर वास्तव में आपकी वस्तुओं के विरुद्ध दुर्भावनापूर्ण कोड लिखने जा रहा है? असली समस्या यह होगी कि आप getBirthDate को गलती से कॉल करके परिणामस्वरूप संशोधन कर सकते हैं।

इस कारण से, आपके गेटर क्लोन म्यूटेबल ऑब्जेक्ट्स जैसे Date लौटने के लिए आम है, जब आप उन्हें मूल्य प्रकार के रूप में उपयोग कर रहे हैं।

(आप यह भी तर्क दे सकते हैं कि जावा का Date उत्परिवर्तनीय नहीं किया जाना चाहिए था, लेकिन अब इसके बारे में बहुत कुछ नहीं किया जा सकता है।)

Answer 4

मैट Solnit का अच्छा जवाब देने के लिए जोड़ा जा रहा है, मैं जब एक विशेषता सेटिंग एक ही समस्या का सामना करना पड़ा है, इसलिए मैं भी ऐसा ही किया:

public void setDataEmissaoNota (Date dataEmissaoNota) 
{ 
    this.dataEmissaoNota = new Date(dataEmissaoNota.getTime()); 
} 

कार्य के ठीक!