Twelve rules for developing more secure Java code-Rule 11

Rule 11: Don't compare classes by name

 Sometimes you want to compare the classes of two objects to see whether they are the same; or you want to see whether an object has a particular class. When you do this, be aware that there can be multiple classes with the same name in a JVM. It is a mistake to compare classes by name since different classes can have the same name. A better method is to compare class objects for equality directly. For example, given two objects, A and B, if you want to see whether they are the same class, use this code:

if(a.getClass() == b.getClass()){

        // objects have the same class

}else{

        // objects have different classes

}

You should also be on the lookout for cases of less direct by-name

comparisons. Suppose, for example, you want to see whether an object

has the class "Foo." Here is the wrong way to do it:

if(obj.getClass().getName().equals("Foo"))   // Wrong!

        // objects class is named Foo

}else{

        // object's class has some other name

}

Here's a better way to do it:

if(obj.getClass() == this.getClassLoader().loadClass("Foo")){

        // object's class is equal to the class that this class calls "Foo"

}else{

        // object's class is not equal to the class that

   // this class calls "Foo"

}

 Do note the legalistic comments in the last example. Whenever you use class names, you open yourself up to mix-and-match attacks, as described in Rule 7. You should also know that the Java language forces you to use class names all the time: in variable declarations, instanceof expressions, and exception-catching blocks. Only the designers of Java can prevent mix-and-match attacks, but you can avoid making the problem worse by avoiding by-name class comparisons.

Twelve rules for developing more secure Java code-Rule 10

Rule 10: Make your classes nondeserializeable

This rule is even more important than the previous one. Even if your class isn't serializeable, it may still be deserializeable. An adversary can create a sequence of bytes that happens to deserialize to an instance of your class. This is dangerous, since you do not have control over what state the deserialized object is in. You can think of deserialization as another kind of public constructor for your object; unfortunately it's a kind of constructor that is difficult for you to control.

You can prevent this kind of attack by making it impossible to deserialize a byte stream into an instance of your class. You can do this by declaring the readObject method:

private final void readObject(ObjectInputStream in)

throws java.io.IOException {

        throw new java.io.IOException("Class cannot be deserialized");

}

  

As above, this method is declared final to prevent the adversary from overriding it.

Twelve rules for developing more secure Java code-Rule 9

Rule 9: Make your classes nonserializeable

Serialization is dangerous because it allows adversaries to get their hands on the internal state of your objects. An adversary can serialize one of your objects into a byte array that can be read. This allows the adversary to inspect the full internal state of your object, including any fields you marked private, and including the internal state of any objects you reference.

To prevent this, you can make your object impossible to serialize. To achieve this goal, declare the writeObject method: 

private final void writeObject(ObjectOutputStream out)

throws java.io.IOException {

        throw new java.io.IOException("Object cannot be serialized");

}

 This method is declared final so that a subclass defined by the adversary cannot override it.

Twelve rules for developing more secure Java code-Rule 8

Rule 8: Make your classes noncloneable

Java's object cloning mechanism can allow an attacker to manufacture new instances of classes you define, without executing any of your constructors. If your class isn't cloneable, the attacker can define a subclass of your class, and make the subclass implement java.lang.Cloneable. This lets an attacker create new instances of your class. The new instances are made by copying the memory images of existing objects; though this is sometimes an acceptable way to make a new object, it often is not.

Rather than worry about this, you're better off making your objects noncloneable. You can do this by defining the following method in each of your classes:

public final void clone() throws java.lang.CloneNotSupportedException {

        throw new java.lang.CloneNotSupportedException();

}

If you want your class to be cloneable, and you've considered the

consequences of that choice, then you can still protect yourself. If you're

defining a clone method yourself, make it final. If you're relying on a

nonfinal clone method in one of your superclasses, then define this

method:

public final void clone() throws java.lang.CloneNotSupportedException {

        super.clone();

}

 This prevents an attacker from redefining your clone method.

Twelve rules for developing more secure Java code-Rule 6

Rule 6: Avoid signing your code

 Code that isn't signed will run without any special privileges. And code with no special privileges is much less likely to do damage.

Of course, some of your code might have to acquire and use privileges to perform some dangerous operation. Work hard to minimize the amount of privileged code, and audit the privileged code more carefully than the rest.