Naive security

April 22nd, 2004

If you believe one word from this article, you might be in deep trouble.

Make methods private as security measure? Ever used reflection?

public class Reflect { private static String indent = " "; private static String demarcation = "======="; private Reflect() { } public static void dumpAllMethods(Class clazz) { Class curr = clazz; while (curr != null) { dumpDeclaredMethods(curr); curr = curr.getSuperclass(); } } public static void dumpDeclaredMethods(Class clazz) { dumpArray("Declared methods", clazz, clazz.getDeclaredMethods()); } public static void dumpMethods(Class clazz) { dumpArray("Methods", clazz, clazz.getMethods()); } public static void dumpConstructors(Class clazz) { dumpArray("Constructors", clazz, clazz.getConstructors()); } private static void dumpArray(String subject, Class clazz, Object[] array) { System.out.println(demarcation + " " + subject + " for " + clazz + " " + demarcation); for (int i = 0, n = array.length; i

Et voila, all methods accesible to you.

Make jars sealed? Ever heard of WinZip? Do you remember crimson in it's beginning days? If you wanted to use another XML parser (or was it XSLT engine), it was standard and well-known practice to unseal the crimson.jar.

I hope these people aren't going to secure my application.

Posted by tomklaasen Filed in Java

6 Responses to “Naive security”

  1. Juha Komulainen Says:
    April 21st, 2008 at 10:17 PM Well, obviously all bets are off if you the attacker can change the original jars. Consider a server that loads code dynamically from untrusted sources: it's a good idea to seal the packages of server so that untrusted code can't pretend to belong to server's packages. Of course there are several other considerations as well, but this is certainly one of them. OTOH, with a suitably configured security policy the untrusted code can't invoke the reflection tricks to gain access to unaccessible code, so that point is moot aswell.
  2. Dan Creswell Says:
    April 21st, 2008 at 10:17 PM Yep, seen this sort of attitude before. I don't bother explaining why it's not a good idea. Instead I go back right to the top of the stack and explain what motivates an attacker, what kind of information they may be after and the techniques they tend to favour. In particular, attackers like to take the path of least resistance and hacking around with .jars is right at the bottom of the list. Finally, I explain that security is a many layered thing and time wading around in the lowest layers trying to protect your code from one of the least likely forms of attack is much better spent on layers further up the stack like preventing access to the .jars in the first place (as Juha hints).
  3. Tom Klaasen Says:
    April 21st, 2008 at 10:17 PM Juha, I'm interested in your point about the security policy. Can you give some links about disallowing reflection with security?
  4. Tom Klaasen Says:
    April 21st, 2008 at 10:17 PM Another remark: it seems that the context is a very important parameter. Could the authors tell us which context they were aiming at?
  5. Juha Komulainen Says:
    April 21st, 2008 at 10:17 PM I replied here: http://www.jroller.com/page/komu/20040423#re_naive_security
  6. my cup of java Says:
    April 21st, 2008 at 10:17 PM Re: Naive security Tom Klaasen had questions about disabling hazardous reflection with proper security-policy. I'll reply here, because I feel that my reply going to a bit long. Suppose we have the following class: package example1; public final c

Sorry, comments are closed for this article.