java MALICIOUS_CODE EI_EXPOSE_REP 中
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1732789/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
MALICIOUS_CODE EI_EXPOSE_REP Medium
提问by Matt Solnit
I run findbugs against all of my code and only tackle the top stuff. I finally got the top stuff resolved and now am looking at the details. I have a simple entity, say a user:
我对我的所有代码运行 findbugs 并且只处理最重要的东西。我终于解决了最重要的问题，现在正在查看细节。我有一个简单的实体，比如一个用户：
public class User implements Serializable
{
protected Date birthDate;
public Date getBirthDate()
{return(birthDate);}
public void setBirthDate(final Date birthDate)
{this.birthDate = birthDate;}
}
This class is incomplete, so don't harp me about it missing the serialVersionUIDand other standard stuff, I am just concerned with the birthDatesecurity hole.
这门课是不完整的，所以不要抱怨我错过了serialVersionUID其他标准的东西，我只关心birthDate安全漏洞。
Now, according to the findbugs report, since I am returning a reference to a mutable object, that is a potential security risk. In practice though, how much does that really matter?
现在，根据 findbugs 报告，由于我正在返回对可变对象的引用，因此存在潜在的安全风险。但在实践中，这到底有多重要？
http://findbugs.sourceforge.net/bugDescriptions.html#EI_EXPOSE_REP
http://findbugs.sourceforge.net/bugDescriptions.html#EI_EXPOSE_REP
I suppose I still don't really see what the problem is here in this case. Should I pass in a longand set the date from that?
我想在这种情况下我仍然没有真正看到问题所在。我应该传入 along并从中设置日期吗？
Walter
沃尔特
回答by Matt Solnit
I think the key here is the if:
我认为这里的关键是if：
If instances are accessed by untrusted code, and unchecked changes to the mutable object would compromise security or other important properties, you will need to do something different.
如果实例被不受信任的代码访问，并且对可变对象的未经检查的更改会危及安全性或其他重要属性，则您需要做一些不同的事情。
So in other words, ifyou wanted an immutable object (i.e. you didn't have a setBirthdate()method), your code be incorrect, because someone could write:
所以换句话说，如果你想要一个不可变的对象（即你没有setBirthdate()方法），你的代码是不正确的，因为有人可以这样写：
Date date = user.getBirthDate();
date.setMonth(1); // mutated!
So you would probably want the following instead:
所以你可能想要以下内容：
public Date getBirthDate()
{return new Date(birthDate.getTime());} // essentially a clone
回答by bobince
Yeah, I wouldn't really call it a ‘security' issue as such... I mean, what attacker exactly is going to be writing malicious code against your objects? The real problem would be that you're quite likely yourself to trip up by accidentally calling getBirthDatethen modifying the result.
是的，我不会真正将其称为“安全”问题……我的意思是，究竟是什么攻击者会针对您的对象编写恶意代码？真正的问题是，您很可能会因不小心调用getBirthDate然后修改结果而绊倒。
For this reason, it is common to have your getter clone mutable objects like Datefor returning, when you're using them as value types.
出于这个原因，Date当您将它们用作值类型时，让您的 getter 克隆可变对象（例如返回）是很常见的。
(You could also argue that Java's Dateshouldn't have been made mutable, but there's not much can be done about that now.)
（您也可以争辩说 JavaDate不应该是可变的，但现在对此无能为力。）
回答by Wendell Pereira
Adding to the good answer of Matt Solnit, I've faced the same problem when setting a attribute, so I did the same:
除了 Matt Solnit 的好答案之外，我在设置属性时也遇到了同样的问题，所以我做了同样的事情：
public void setDataEmissaoNota (Date dataEmissaoNota)
{
this.dataEmissaoNota = new Date(dataEmissaoNota.getTime());
}
Work's fine!
工作正常！
回答by Robert Tuck
Well, I'd say that all depends. There are other non security-related reasons to return immutable objects, since it may also lead to some hard-to-find bugs in your code if the object is misused.
好吧，我想说这一切都取决于。返回不可变对象还有其他与安全无关的原因，因为如果对象被滥用，它也可能导致代码中出现一些难以发现的错误。
Is the class going to be accessed by untrusted code and/or data? If so, you need to have a clear idea of where the responsibility lies in your application with regards to validating input.
不受信任的代码和/或数据是否会访问该类？如果是这样，您需要清楚地了解您的应用程序在验证输入方面的责任所在。
Also, what is the nature of the application? If it's e.g. an externally accessible network service then the input should almost certainly be considered potentially malicious. However if it's an application run locally with no priviliges which gets input from a trusted source, then probably no need to worry.
此外，应用程序的性质是什么？如果它是例如一个外部可访问的网络服务，那么输入几乎肯定应该被认为是潜在的恶意的。但是，如果它是一个在本地运行的应用程序，没有从可信来源获取输入的特权，那么可能无需担心。
