java - 对象反射的安全风险是什么？

Question

因此，经过几个小时的解决方法，目前在 Google App Engine 上禁用了反射的限制，我想知道是否有人可以帮助我理解为什么对象反射可能是一种威胁。是因为我可以检查一个类的私有(private)变量还是有其他更深层次的原因？

Answer 1

1 - 反射(作为一个概念)确实与安全/安保正交。

Java 的设计非常重视使其成为一个安全的平台，具有静态类型、安全管理器、类加载器，并且没有办法拧指针/内存。您可以在 Masterminds of programming 中阅读 James Gosling 的采访。 ，这很有趣。

但是，您拥有的 反射 能力越强，就越难以确保事情的安全。反射会明显击败静态类型，并可能导致运行时错误。

但更微妙的事情也可能发生。例如，类加载器——可以被认为是系统中的 reflective 钩子(Hook)——在 Java 的早期版本中没有正确设计，从而导致潜在的类型替换。文章Dynamic class loading in the JVM, Gilad Bracha 对这些问题很有见地。

反射不能完全关闭；总是可以反射(reflection)自己的公共(public)领域/方法。但是，可以禁用使用 AccessibleObject.setAccessible 对私有(private)结构的反射，因为它破坏了 封装。通过访问私有(private)字段等，可以检查和修改内部数据。它可能导致各种恶意攻击，例如

• strings 不再是不可变的，可以更改(参见 question)
• 您可以透露不属于您的元素的敏感信息
• ...其他漏洞利用...

最后还有其他将安全置于危险境地的机制，特别是 sun.misc.Unsafe，它可以直接访问内存——指针又回来了。

2 - 现在，问题是反射(reflection)(在实践中)是否会导致这么多风险。

我已阅读 @dbyrne 指向的链接但主要是关于.net。此外，我不确切知道 Google App 禁用了什么。是ReflectPermission仅，还是安全管理员的其他许可？一种危险显然是访问文件系统并搞乱。

在实践中可以争论访问私有(private)数据和破坏封装的问题。编写安全代码确实非常困难，即使不更改访问修饰符，您也可以以不适当的方式对类进行子类化——除非它们是 final，或者更好的是，密封的——并传递它们。例如 defensive copying尽量防止。

由于向下转换，类型安全无论如何也受到运行时错误的威胁，所以这一点也可以争论。

在共享/托管环境中，安全性是相对的。例如，在语言级别，您可以不阻止模块形式消耗 100% 的 CPU 或消耗所有内存，直至 OutOfMemoryException。此类问题需要通过其他方式解决，通常在操作系统级别，包括虚拟化和配额。

所以我个人的回答是:反射是一种安全风险，但与其他潜在的攻击媒介相比，在实践中并没有那么大。