10

I am going through this link , OBJ10-J. Do not use public static nonfinal fields and it says that ,

Client code can trivially access public static fields because access to such fields are not checked by a security manager.

what do they actually mean by that? i.e what do they mean by escaping from security manager?

If they simply meant it because field being non-final and public , then how come non-final , public instance fields different than their static counterparts? ( as far as code security is concerned )

I have been through this question and have not seen any mention in terms of security , Why are static variables considered evil

public class's public static fields would be accessible from anywhere and so public instance fields too, so where is the difference? Why non-final public instance fields not a security issue but being static is?

Community
  • 1
  • 1
Sabir Khan
  • 9,826
  • 7
  • 45
  • 98

2 Answers2

5

Why non-final public instance fields not a security issue but being static is?

If you want to access an instance field you need the reference to that object instance. If you don't have a reference you can't access it.

So your code can control to which objects a refernce is passed. If malicious code tries to hijack one of your objects using reflection to get a reference you can install a security manager to prevent this.

On the other side a public static field can be accessed from everybody that has access to the class, because the Class object is accessible. So malicious code might only use

YourClass.PUBLIC_INSTANCE_FIELD = someValue;

or the reflection way

Class clazz = Class.forName("YourClass");
Field publicStaticField = clazz.getDeclaredField("PUBLIC_INSTANCE_FIELD");
publicStaticField.set(null, someValue);
René Link
  • 48,224
  • 13
  • 108
  • 140
  • so is there no way to apply access restrictions on `Class Object`? Eventually, that is an Object too but not kept in heap, right? – Sabir Khan Jan 11 '16 at 09:32
  • @SabirKhan I don't know what you mean with "apply access restrictions on Class Object". Do you want to protect the main memory (RAM) from being hijacked? – René Link Jan 11 '16 at 09:53
  • What I meant to ask is , is class name in your example `YourClass` an instance of `java.lang.Class`? so if `YourClass` is simply a reference of type `java.lang.Class` then I can apply security manager on it too ( like suggested for heap objects ) or security manager can't be applied to **jvm** created `Class` Objects? – Sabir Khan Jan 11 '16 at 10:18
  • @SabirKhan Yes, `YourClass` is the class object and I think you can apply a security manager as well. http://stackoverflow.com/questions/5486797/how-to-prevent-public-methods-from-being-called-from-specific-classes – René Link Jan 11 '16 at 11:15
4

That's because the case of non-static fields is already covered by OBJ01-J. Limit accessibility of fields

public instance field are covered by OBJ01-J for slightly different reasons. For one, you need to have a reference to an instance before you can change public instance fields, while public static fields can be accessed directly at class level. But both are against the CERT rules.

Erwin Bolwidt
  • 30,799
  • 15
  • 56
  • 79
  • so that sentence (that public instance fields escape security manager) applicable here too, right ? What I understand by that is `public` fields are intended to be accessed from anywhere and disabling **refelction** etc will not have any impact or there is no way to include these accesses in security manager. – Sabir Khan Jan 11 '16 at 09:28
  • @SabirKhan Yes that's correct, public fields cannot be controlled by a SecurityManager. Non-public fields that you normally cannot access can be accessed through reflection, but you can use the SecurityManager to disable or control access through reflection. – Erwin Bolwidt Jan 11 '16 at 12:44