Does the reflection mechanism break the security in java? Please explain

Question

I have heard that the reflection mechanism breaks the security in Java. Please can anyone explain it?

Answer 1

you can access private fields & method of Object using reflection

For example

public class Foo {

  private String privateString = null;

  public Foo(String privateString) {
    this.privateString = privateString;
  }
}

---

Foo privateObject = new Foo("The Private Value");

Field privateStringField = Foo.class.
            getDeclaredField("privateString");

privateStringField.setAccessible(true);

String fieldValue = (String) privateStringField.get(privateObject);
System.out.println("fieldValue = " + fieldValue);

Answer 2

Clearly if the reflection API obviously broke applet security, someone would have noticed by now.

Firstly we need some context. Unusually, the Java platform /can/ provide a secure environment for running untrusted code (give or take the odd bug - if you find one, do let the Oracle security response team know). However, most uses of Java ignore this.

When running securely, the reflection API limits what untrusted code can do to roughly what it can do without reflection (it checks the immediate caller in addition to some standard Java security checking - see the Secure Coding Guidelines for the Java Programming Language). For instance, untrusted code can access "package private" classes in the same package, but not those from other packages.

Why would you use reflection? Generally because it allows you do operate in same way upon an open-ended set of types on behalf of some client code. The client code will generally be in some other package, but the reflection API will limit access based on the reflection-using code. Therefore, unless the reflection-using code is competently written, the client code has access it should not be allowed. This is a rich source of vulnerabilities.

When not running securely, you can read/write files, run programs, etc., so who cares?

Answer 3

Using reflection you can do almost anything: access private variables by setting them as accessable , and modify immutable objects

A common example, is changing a String:

public static void main(String[] args) throws Exception {
    String s = "before";
    System.out.println(s);
    Field value = String.class.getDeclaredField("value");
    value.setAccessible(true);
    Field count = String.class.getDeclaredField("count");
    count.setAccessible(true);
    char[] after = {'a','f','t','e','r','\0' };
    value.set(s, after);
    count.set(s,5);
    System.out.println(s);
}

In this example - the actual string object is being changed!

Note that using reflection to change immutable objects has its own problems, as you can see in this post