如何限制 setAccess 只能“合法”使用?

我越了解 java.lang.reflect.AccessibleObject.setAccessible的威力,我就越惊讶于它的能力。这是根据我对这个问题的回答改编的(使用反射来更改单元测试的静态 final File.披露字符)。

import java.lang.reflect.*;


public class EverythingIsTrue {
static void setFinalStatic(Field field, Object newValue) throws Exception {
field.setAccessible(true);


Field modifiersField = Field.class.getDeclaredField("modifiers");
modifiersField.setAccessible(true);
modifiersField.setInt(field, field.getModifiers() & ~Modifier.FINAL);


field.set(null, newValue);
}
public static void main(String args[]) throws Exception {
setFinalStatic(Boolean.class.getField("FALSE"), true);


System.out.format("Everything is %s", false); // "Everything is true"
}
}

你可以做一些非常离谱的事情:

public class UltimateAnswerToEverything {
static Integer[] ultimateAnswer() {
Integer[] ret = new Integer[256];
java.util.Arrays.fill(ret, 42);
return ret;
}
public static void main(String args[]) throws Exception {
EverythingIsTrue.setFinalStatic(
Class.forName("java.lang.Integer$IntegerCache")
.getDeclaredField("cache"),
ultimateAnswer()
);
System.out.format("6 * 9 = %d", 6 * 9); // "6 * 9 = 42"
}
}

据推测,API 设计人员已经意识到 setAccessible的可滥用性,但是他们必须承认 setAccessible有合法的用途来提供它。所以我的问题是:

  • setAccessible的真正合法用途是什么?
    • Java 是否一开始就被设计成没有这种需求?
    • 这种设计的负面后果(如果有的话)是什么?
  • 你能否将 setAccessible仅限于合法用途?
    • 只能通过 SecurityManager吗?
      • 它是如何工作的? 白名单/黑名单,粒度等?
      • 在应用程序中配置它是否常见?
    • 无论 SecurityManager的配置如何,我都可以编写 setAccessible防护类吗?
      • 或者我是任由谁来管理配置?

我想还有一个更重要的问题: 我需要担心这个吗?

我的课堂上没有任何隐私可以强制执行。这项单例模式(先不考虑其是非曲直)现在已无法执行。正如我上面的片段所显示的,即使是一些关于 Java 基本原理如何工作的基本假设也远远不能得到保证。

这些问题不是真的吗?


好的,我刚刚确认: 由于 setAccessible,Java 字符串是 没有不可变的。

import java.lang.reflect.*;


public class MutableStrings {
static void mutate(String s) throws Exception {
Field value = String.class.getDeclaredField("value");
value.setAccessible(true);
value.set(s, s.toUpperCase().toCharArray());
}
public static void main(String args[]) throws Exception {
final String s = "Hello world!";
System.out.println(s); // "Hello world!"
mutate(s);
System.out.println(s); // "HELLO WORLD!"
}
}

只有我一个人认为这是个大问题吗?

20178 次浏览
  • What are the truly legitimate uses for setAccessible?

Unit testing, internals of the JVM (e.g. implementing System.setError(...)) and so on.

  • Could Java has been designed as to NOT have this need in the first place?
  • What would the negative consequences (if any) of such design be?

Lots of things would be unimplementable. For example, various Java persistence, serialization and dependency injections are reliant on reflection. And pretty much anything that relies on the JavaBeans conventions at runtime.

  • Can you restrict setAccessible to legitimate uses only?
  • Is it only through SecurityManager?

Yes.

I'm not saying that doing this through the SecurityManager and blacklists / whitelists is a good idea. I'm saying that it is (AFAIK) the only way to do this.

Also, note that Java 17 marks SecurityManager as deprecated; for removal. See JEP 411. That is a reason that this another bad idea.

  • How does it work? Whitelist/blacklist, granularity, etc?

It depends on the permission, but I believe that the permission to use setAccessible is binary. If you want granularity, you need to either use a different class loader with a different security manager for the classes that you want to restrict. I guess you could implement a custom security manager that implements finer grained logic.

  • Is it common to have to configure it in your applications?

No.

  • Can I write my classes to be setAccessible-proof regardless of SecurityManager configuration?
  • Or am I at the mercy of whoever manages the configuration?

No you cannot, and yes you are.

The other alternative is to "enforce" this via source-code analysis tools; e.g. custom pmd or findbugs rules. Or selective code review of code identified by (say) grep setAccessible ....

In response to the followup

None of my classes have any semblance of enforceable privacy what-so-ever. The singleton pattern (putting doubts about its merits aside) is now impossible to enforce.

If that worries you, then I suppose you need to worry. But really you should not be trying to force other programmers to respect your design decisions. If people are stupid enough to use reflection to gratuitously create multiple instances of your singletons (for example), they can live with the consequences.

On the other hand, if you mean "privacy" to encompass the meaning of protecting sensitive information from disclosure, you are barking up the wrong tree. The way to protect sensitive data in a Java application is not to allow untrusted code into the security sandbox that deals with sensitive data. Java access modifiers are not intended to be a security mechanism.

<String example> - Am I the only one who thinks this is a HUGE concern?

Probably not the only one :-). But IMO, this is not a concern. It is accepted fact that untrusted code should be executed in a sandbox. If you have trusted code / a trusted programmer doing things like this, then your problems are worse than unexpectedly mutable Strings. (Think logic bombs, exfiltration of data via covert channels, etcetera)

There are ways to deal with (or mitigate) the problem of a "bad actor" in your development or operations team. But they are costly and restrictive ... and overkill for most use-cases.

Reflection is indeed orthogonal to safety/security under this perspective.

How can we limit reflection?

Java has security manager and ClassLoader as foundations to its security model. In your case, I guess you need to look at java.lang.reflect.ReflectPermission.

But this does not completely solve the problem of reflection. The reflective capabilities that are available should be subject to a fine grained authorization scheme which is not the case now. E.g. to allow certain framework to use reflection (e.g. Hibernate), but no the rest of your code. Or to allow a program to reflect only in a read-only way, for debugging purpose.

One approach that may become mainstream in the future is the usage of so-called mirrors to separate reflective capabilities from classes. See Mirrors: Design Principles for Meta-level Facilities. There are however various other research that tackles this issue. But I agree that the problem is more severe for dynamic language than static languages.

Should we be worried of the superpower that reflection gives us? Yes and no.

Yes in the sense that the Java platform is supposed to be secured with Classloader and security manager. The ability to mess with reflection can be see as a breach.

No in the sense that most system are anyway not entirely secure. A lot of classes can frequently be subclassed and you could potentially already abuse the system with just that. Of course classes can be made final, or sealed so that they can not be subclassed in other jar. But only few classes are secured correctly (e.g. String) according to this.

See this answer about final class for a nice explanation. See also the blog from Sami Koivu for more java hacking around security.

The security model of Java can be seen as insufficient to some regard. Some languages such as NewSpeak take even more radical approach to modularity, where you have access only to what is explicitly given to you by dependency inversion (by default nothing).

It's also important to note that security is anyway relative. At the language level, you can for instance not prevent a module form consuming 100% of CPU or consuming all memory up to a OutOfMemoryException. Such concerns need to be addressed by other means. We will maybe see in the future Java extended with resource utilization quotas, but it's not for tomorrow :)

I could expand more on the subject, but I think I've made my point.

DO I NEED TO WORRY ABOUT THIS???

That depends entirely on what types of programs you're writing and for what kind of an architecture.

If you're distributing a software component called foo.jar to the people of the world, you're completely at their mercy anyway. They could modify the class definitions inside your .jar (through reverse engineering or direct bytecode manipulation). They could run your code in their own JVM, etc. In this case worrying will do you no good.

If you're writing a web-application that only interfaces with people and systems via HTTP and you control the application server, it's also not a concern. Sure the fellow coders at your company may create code that breaks your singleton pattern, but only if they really want to.

If your future job is writing code at Sun Microsystems/Oracle and you're tasked with writing code for the Java core or other trusted components, it's something you should be aware of. Worrying, however, will just make you lose your hair. In any case they'll probably make you read the Secure Coding Guidelines along with internal documentation.

If you're going to be writing Java applets, the security framework is something you should be aware of. You'll find that unsigned applets trying to call setAccessible will just result in a SecurityException.

setAccessible is not the only thing that goes around conventional integrity checks. There's a non-API, core Java class called sun.misc.Unsafe that can do pretty much anything at all it wants to, including accessing memory directly. Native code (JNI) can go around this kind of control as well.

In a sandboxed environment (for example Java Applets, JavaFX), each class has a set of permissions and access to Unsafe, setAccessible and defining native implementations are controlled by the SecurityManager.

"Java access modifiers are not intended to be a security mechanism."

That very much depends on where the Java code is being run. The core Java classes do use access modifiers as a security mechanism to enforce the sandbox.

What are the truly legitimate uses for setAccessible?

The Java core classes use it as an easy way to access stuff that has to remain private for security reasons. As an example, the Java Serialization framework uses it to invoke private object constructors when deserializing objects. Someone mentioned System.setErr, and it would be a good example, but curiously the System class methods setOut/setErr/setIn all use native code for setting the value of the final field.

Another obvious legitimate use are the frameworks (persistence, web frameworks, injection) that need to peek into the insides of objects.

Debuggers, in my opinion, don't fall into this category, as they normally don't run in the same JVM process, but instead the interface with the JVM using other means (JPDA).

Could Java has been designed as to NOT have this need in the first place?

That's a pretty deep question to answer well. I imagine yes, but you'd need to add some other mechanism(s) that might not be all that preferrable.

Can you restrict setAccessible to legitimate uses only?

The most straight-forward OOTB restriction you can apply is to have a SecurityManager and allow setAccessible only to code coming from certain sources. This is what Java already does - the standard Java classes that come from your JAVA_HOME are allowed to do setAccessible, while unsigned applet classes from foo.com aren't allowed to do setAccessible. As was said before, this permission is binary, in the sense that one either has it or not. There is no obvious way to allow setAccessible to modify certain fields/methods while disallowing others. Using the SecurityManager you could, however, disallow classes from referencing certain packages completely, with or without reflection.

Can I write my classes to be setAccessible-proof regardless of SecurityManager configuration? ... Or am I at the mercy of whoever manages the configuration?

You can't and you most certainly are.