DonÕt rely on package Scope
It is important not to rely on package protection to secure your code. It is a common misconception to think that only classes in your package, as you define your package can access protected methods and variables. There are a number of very simple ways to workaround this protection. This is a security hole that may be caused by a lapse in attention, any variables or methods that are not designated with either public or private are automatically designated as protected at compile time.[6] A variable or method designated as protected means that any class within the package can access it. It can be executed or modified by any class within the package. This seems like a reasonable option because it allow the classes of your application to call methods and manipulate variables, but prevents classes that are not within your application from access. It is a feature created for internal communication within an application.
The problem with this is a shortcoming of Java. It is impossible to absolutely define what classes are members of your package. There is no way to seal your package without the possibility of another class being added to it. If another class is added then the new class would have access to all of the protected variables and methods in the package. Because of this, it is essential to make sure that all protected variables and methods are not ones that could compromise the security of your application. It is especially important to scan for this security hole because of JavaÕs default designation of ÒprotectedÓ to untagged variables and methods. If the programmer forgets to designate a variable the program will run normally and the missing designation will not be caught at compile time it will be tagged as Òprotected.Ó This missing designation could cause a serious vulnerability in the application. [6]
There are two easy ways to access protected members of a class. The use of these two options depends upon the precautions the author of the code takes. If they simply distribute the code in a JAR file without sealing it, it is simply a matter of defining a new class with an identical package declaration to the package you wish to gain access to. For example if you are trying to gain access to edu.colby.JSS you simply need to declare a new class with the header Òpackage edu.colby.JSS.Ò You then must modify the CLASSPATH in the .bat file so it includes the directory where your additional class is stored before it loads the original JAR file. [6]
If the package is distributed as a sealed then the process involves one more trivial step. A sealed package sets the precedent that all classes that are loaded must come from the same JAR file, making the technique previously described ineffective. However, unsealing a file is easier than adding a new class. To unseal the file you simply have to modify the JARÕs manifest file and change the Boolean value of the Sealed attribute, or extract the JAR and recompile it with the new class in the same directory as the other classes.
An example of such flawed code is as follows:
public class Course {
Vector students = new Vector();
É
public addStudent(Student o) {
students.addElement(o);
}
}
In this class the students in a particular course are stored in a vector labeled Òstudents.Ó This variable is designated as protected since there is not explicitly designated as protected, public or private. With its protected designation the vector is available to any class in the package, or any class later added to the package. This unrestricted access would allow any other class to access or modify the vector. Whether this is due to the implementation of the class or because the author simply forgot to specify it makes the variable ÒstudentsÓ accessible to all other classes with the same package heading. As we have seen before having the same package heading does not insure that it is a trusted class.