Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Reflection is indeed orthogonal to safety/security under this perspective. </p> <p><strong>How can we limit reflection?</strong></p> <p>Java has security manager and <code>ClassLoader</code> as foundations to its security model. In your case, I guess you need to look at <a href="http://java.sun.com/j2se/1.4.2/docs/guide/security/permissions.html#ReflectPermission" rel="nofollow noreferrer"><code>java.lang.reflect.ReflectPermission</code></a>. </p> <p>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. </p> <p>One approach that may become mainstream in the future is the usage of so-called <em>mirrors</em> to separate reflective capabilities from classes. See <a href="http://bracha.org/mirrors.pdf" rel="nofollow noreferrer">Mirrors: Design Principles for Meta-level Facilities</a>. There are however various <a href="http://www.inria.fr/travailler/mrted/en/eng/details.html?nPostingId=4074&amp;nPostingTargetId=8668" rel="nofollow noreferrer">other research</a> that tackles this issue. But I agree that the problem is more severe for dynamic language than static languages.</p> <p><strong>Should we be worried of the superpower that reflection gives us?</strong> Yes and no. </p> <p><em>Yes</em> in the sense that the Java platform is supposed to be secured with <code>Classloader</code> and security manager. The ability to mess with reflection can be see as a breach. </p> <p><em>No</em> 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 <code>final</code>, or <a href="http://java.sun.com/docs/books/tutorial/deployment/jar/sealman.html" rel="nofollow noreferrer">sealed</a> so that they can not be subclassed in other jar. But only few classes are secured correctly (e.g. String) according to this. </p> <p>See this <a href="https://stackoverflow.com/questions/2478846/why-is-string-a-sealed-class-in-c/2478877#2478877">answer about final class</a> for a nice explanation. See also the blog from <a href="http://slightlyrandombrokenthoughts.blogspot.com/" rel="nofollow noreferrer">Sami Koivu</a> for more java hacking around security. </p> <p>The security model of Java can be seen as insufficient to some regard. Some languages such as <a href="http://bracha.org/newspeak.pdf" rel="nofollow noreferrer">NewSpeak</a> 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).</p> <p>It's also important to note that security is anyway <em>relative</em>. At the language level, you can for instance not prevent a module form consuming 100% of CPU or consuming all memory up to a <code>OutOfMemoryException</code>. 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 :)</p> <p>I could expand more on the subject, but I think I've made my point.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload