FindBugs : EI_EXPOSE_REP 背后的真正威胁答案

【问题标题】：FindBugs : real threat behind EI_EXPOSE_REPFindBugs : EI_EXPOSE_REP 背后的真正威胁
【发布时间】：2012-12-16 23:24:51
【问题描述】：

FindBugs 提出了一个名为 EI_EXPOSE_REP 的错误，描述如下：

EI：可能通过返回对可变对象的引用来公开内部表示

返回对存储在对象字段之一中的可变对象值的引用会公开对象的内部表示。如果实例由不受信任的代码访问，并且对可变对象的未经检查的更改会危及安全性或其他重要属性，则您将需要做一些不同的事情。在许多情况下，返回对象的新副本是更好的方法。

关于 SO 的几个问题（1、2 和 3）已经解决了如何避免此类错误，我知道这是防止修改不可变对象的开发最佳实践，但尚不清楚我为什么这样的错误属于 MALICIOUS_CODE 类别。

这背后的真正威胁是什么？

如果是恶意代码问题，攻击者几乎可以做任何他想做的事，而可变性不会是最大的问题。如果它是一个漏洞，那么只有在执行不受信任的代码时才能利用它，而且我看不到任何符合这种情况的用例。

对此有何看法？

谢谢！

【问题讨论】：

Findbugs “安全”规则基于 Sun 的老式安全指南，主要针对小程序环境。它们没有太多用处，比如 web 应用或服务器应用。
@agelastic：我认为你的评论有点误导。说“安全”规则更适用于可能运行未经批准的代码的环境可能要好得多。
Chris Lively - 那些环境是什么？在 webapp 世界中，它是小程序。其他的呢？

标签： java security immutability findbugs

【解决方案1】：

关键是，无论何时打开一个实现，您都会冒着代码造成损害的风险，无论是有意还是无意。显然，例如，恶意库用户可以通过拆解您的 jar 并以这种方式了解详细信息 - 关键是最大限度地降低暴露风险：它无法消除。

外部代码访问您的库的简单示例：

考虑一些简单的东西，比如拥有访问级别的对象。如果它是可变的，那么可以想象图书馆用户可以设置自己的访问级别。这种微不足道的事情很少会被任何合理的库公开，但它是一个内部表示何时可能被滥用的明显例子。

最重要的是，暴露的可变状态使代码难以推理，也难以保护。您的代码或其他人可能会意外或故意修改您自己的代码/库使用的某些内容。如果您的库随后更改其行为而没有考虑到这一点，您可能会引入一个微妙（或不那么微妙）的错误。

【讨论】：

确实，如果您将实现作为库或其他方式打开是可能的，但是在您自己的软件的主类中存在此类错误的真正风险是什么？
@Nibbler 不确定“在您自己的软件的主类中”是什么意思。过度暴露的可变状态允许任何代码，无论是你的还是其他人的，都可以弄乱内部表示。任何时候暴露该级别的表示，都会使代码难以保护和推理。
假设您在 Java 中使用不可变类实现了一个 FTP 服务器，但没有正确处理可变参数。它真的有风险吗？又怎么会被归类为恶意代码呢？
@Nibbler 它可以被归类为“恶意”，因为它可能您的代码或其他人的代码可以利用内部表示。我不明白你的问题是什么：它被称为“恶意”，因为它可能被恶意滥用。 FindBugs 怎么会知道它正在分析只有你会使用的代码？！从某种意义上说，可变状态使代码难以推理是有风险的。

【解决方案2】：

让对象隐藏状态并提供强大的静态接口的能力是 Java 移动代码安全性的核心。程序员将其搞砸可能会导致漏洞的多种方式。

对于值对象，请考虑String。我们相信String 的任何实例都不会改变。我们不想验证 [check] 一个特定的文件名，例如，我们不希望它在我们实际使用它时改变（注意，java.io.File 在这个意义上不能很好地工作）。此外，可变内部可能具有恶意的equals 方法（例如），由封闭类'equals 调用，但与其他封闭类实例相比，它恶意获取对其他封闭类实例的内部对象的引用。

引用类型通常是对象能力。通常，它们会削弱它们被赋予的对象的能力（通过构造函数传递）。比如说，您只能通过您有权访问的实例将文件写入特定目录，但它有一个能够写入整个文件系统的字段。

然后是 Java 2 安全模型，这绝不是一件好事。内部对象可能有在特权上下文中调用的方法，这通常不是问题。现在，恶意方将对象（可信类型）放置在该对象中，该对象执行了在该上下文中不应该执行的操作。

当然，要注意随机子类化类。他们可能会在未来的版本中获得get 方法。

话虽如此，在我看来，Findbugs 的这个警告并没有帮助。该代码可能并非有意隐藏该对象。

（有关暴露内部对象问题的详细描述，请参见 Michael Feathers Working Effectively with Legacy Code 的第 13 章（和第 14 章）。）

【讨论】：