Val's Blog
Lots of stuff for Web 2.0 freaks and Java addicts
Feeds RSS | Atom | RDF
 
 
Albert Einstein: "Intellectuals solve problems: geniuses prevent them."
[ Login ]

May 2004
SunMonTueWedThuFriSat
       1 
 2  3  4  5  6  7  8 
 9  10  11  12  13  14  15 
 16  17  18  19  20  21  22 
 23  24  25  26  27  28  29 
 30  31      
Apr  |  Today  |  Jun
XML Feeds   Subscribe with Bloglines

Javaranch Sheriff   My LinkedIn Profile
Drop me a line or two   Bloglines Blogroll
JavaRSS   Referers
How cool are you?   My Reviews

Next trips...
SpringOne 2008 (Jun 11-12, 08)
Ajax Exp. 2008 (Sep 29-Oct 1, 08)
Top 10 entries (#hits)
(As of Nov 30, 2007)


Top 10 entries (#hits/day)
Come Back (5.032)
(As of Nov 30, 2007)
Recent Blog Entries
Recent Blog Comments
Re: Review of "Marketing Management 12th"
i know marketing management by kotler is good book but the problem is that the management part of this book is totally missing as fare as i know managemet is complete different subject and it should not be mixed i am student of MBA i was looking at ass...

Re: Review of "Pro Spring"
Using simple POJOs + factories without Spring for "echo" and "counter" would be a lot more easier. No need to write those XML files... So, in this case using Spring makes me write a lot more code... (OK, you can generate everything with the help of And...

pls urgent
Hi I am trying to generate the word doc but i m not understanding wats happening any one pls figure it out /* * WordAPI.java * * Created on May 30, 2006, 10:50 AM * * To change this template, choose Tools | Template Manager * and open the te...
Archives (# entries)
Links
Other Blogs
Other Blogs

Reviewing
Reading
Locations of visitors to this page
What they once said...
 

Ever wondered what evil power can be unleashed when using reflection? Do you think private methods are really only accessible from within the declaring class? Do you think that a private field can only be modified from within the declaring class? No? That's what I thought!! In this blog, I will try to demonstrate that it is always important to correctly set the security properties of your applications. For instance, let's look at the following example where we successfully retrieve a private password from another class:

1.  class A {
2.    private static String getPassword() {
3.      return "someHighlyPreciousPassword";
4.    }
5.  }
6.
7. public class Test {
8.   public static void main(String[] args) throws Exception {
9.     Class cl = Class.forName("A");
10.    java.lang.reflect.Method[] m = cl.getDeclaredMethods();
11.    m[0].setAccessible(true);
12.    String password = (String) m[0].invoke(null, null);
13.    System.out.println("I got it:" + password);
14.  }	
15.}
  
Output:
 I got it: someHighlyPreciousPassword
 

Ok, the example is not really sexy. Let's mess up a class that implements the Singleton pattern. In the normal case, a singleton object is supposed to be the only instance of a given class. To achieve this, we usually declare the class constructor private, so that no one can invoke it. Well, as demonstrated below, with reflection we can bypass this restriction and create a second "singleton object".

1.  class A {
2.    public static final A singleton = new A("I'm the only instance of class A");
3.    private String name; 
4.    private A(String name) {
5.      this.name = name;
6.    }
7.    public String toString() {
8.      return this.name;
9.    }
10. }
11.
12. public class Test {
13.   public static void main(String[] args) throws Exception {
14.     Class cl = Class.forName("A");
15.     java.lang.reflect.Constructor[] c = cl.getDeclaredConstructors();
16.     c[0].setAccessible(true);
17.     A anotherA  = (A) c[0].newInstance(new Object[]{"Not anymore!!"});
18.     System.out.println(A.singleton);
19.     System.out.println(anotherA);
20.   }	
21. }
  
Output:
 I'm the only instance of class A
 Not anymore!!
 

Using this technique, you can create an instance of any non-abstract class, even if all its constructors are declared private. For instance, below we create an instance of the Math class even though it is useless since the Math class has no instance method. Still, it is possible to do it.

1.  public class Test {
2.  public static void main(String[] args) throws Exception {
3.      Class cl = Class.forName("java.lang.Math");
4.      java.lang.reflect.Constructor[] c = cl.getDeclaredConstructors();
5.      c[0].setAccessible(true);
6.      Math mathInstance = (Math) c[0].newInstance(null);
7.      System.out.println(mathInstance);
8.    }
9.  }
  
Output:
 java.lang.Math@1cde100
 

Finally, let's mess with the Runtime class which has one private static field for storing the current Runtime instance. This is another example of a badly implemented singleton class. Let's look at the code below. We first retrieve the current runtime object and display it (3-4). Then, we set the Runtime.currentRuntime static field to null, which means that all successive calls to Runtime.getRuntime() will yield null (6-9) since currentRuntime is initialized at class loading time. We then get the currentRuntime field again and display its value (11-12). And finally, we try to use the current runtime to execute a command for displaying the content of the current directory (14). The output talks for itself.

1.  public class Test {
2.    public static void main(String[] args) throws Exception {
3.      Runtime r = Runtime.getRuntime();
4.      System.out.println("Before: Runtime.getRuntime() yields " + r);
5.
6.      Class cl = Class.forName("java.lang.Runtime");
7.      java.lang.reflect.Field f = cl.getDeclaredField("currentRuntime");
8.      f.setAccessible(true);
9.      f.set(null, null);
10.
11.     r = Runtime.getRuntime();
12.     System.out.println("After: Runtime.getRuntime() yields " + r);
13.
14.     r.exec("dir"); //raises NullPointerException!!
15.   }
16. }
  
Output:
 Before: Runtime.getRuntime() yields java.lang.Runtime@cac268
 After: Runtime.getRuntime() yields null
 Exception in thread "main" java.lang.NullPointerException
       at Test.main(Test.java:59)
 

All this could have been avoided if the currentRuntime field had been declared final. Nothing prevents setAccessible(true) to be called on the field (8) but when the set(null, null) method is called, IllegalAccessException is thrown with the message "Field is final".

I'm pretty sure that there is a huge amount of code out there that could be broken this way. Watch out!!
Bottom line: singleton fields should always be declared private static final!!! Moreover, make sure you never grant ReflectPermission and RuntimePermission.accessDeclaredMembers in the java.policy file of your production code.

I have just finished reading "Secure XML - The New Syntax for Signatures and Encryption" by Donald E. Eastlake and Kitty Niles. I'm pretty much happy with what I have read in this book. It wouldn't have hurt to see the presented standards applied on concrete case studies, though. This is what cost the book two horseshoes. No big deal!!

My review follows (also available at Javaranch.com):

When looking back, it is safe to say that using XML has become one of the most preferred ways of transferring data across the web. With the rise of web services and given the way the Internet is organized and governed, this ubiquity raises the fundamental issue of how to effectively protect the content of an XML transmission at the application level.

This book presents the efforts of two well-known consortia (IETF and W3C) working on the XML Digital Signature, XML Encryption and XML Key Management System standards. This book is meant to be within anybody's range as prerequisite knowledge in neither XML nor cryptography is required. Consequently, this means that about a third of this 500 pages book is dedicated to introducing both topics.

The authors do an outstanding job of presenting the technical details and cover areas such as, XML basics, digital cryptography fundamentals, XML canonicalization techniques, XML encryption, and key management. This is one of the most comprehensive resources on the subject currently available in store. I really enjoyed reading it and I would recommend it to any developer in need of a solid understanding of how XML communications can be protected against undesirable intrusions.

On the downside, even though the authors have presented two concrete applications of XML digital signatures (i.e., P3P XMLDSIG and SOAP XMLDSIG profiles), I would have much appreciated to see a case study about a plausible application of the technologies presented and how they fit into the big picture.

 
About this Blog