Powered by CodePro Analytix and Eclipse
Severity: Medium
Summary
Enforces Applet fields to be non-private, final and non-static
Description
This audit rule violates all field declarations in Applets that are not private, final and not static. Fields that do not have all of these characteristics reduce the risk of malicious users from manipulating or gaining internal access to the Applet.
Example
The following integer would be flagged as it is public:
public final int x = 0;
Severity: High
Summary
Database queries should not be constructed from user input.
Description
This audit rule looks for places where a query is being performed that was constructed from data that might have come from user input. Malicious users can input text that will change the meaning of the query and expose data that ought not to be exposed.
Specifically, this audit rule violates the usage of the methods "execute", "executeQuery", or "executeUpdate" as defined in java.sql.Statement.
Example
The invocation of the executeQuery method below would be flagged because the argument is constructed from values that might include user input.
String query =
"SELECT userid, name FROM user_data WHERE accountnum = '"
+ req.getParameter("ACCT_NUM")
+ "'";
...
statement.executeQuery(query);
It should be replaced by something like the following:
PreparedStatement statement = connection.prepareStatement
("SELECT userid, name FROM user_data WHERE accountnum = ?");
statement.setString(1, req.getParameter("ACCT_NUM");
ResultSet results = statement.executeQuery();
Severity: Medium
Summary
String comparisons should not occur with the output from Class.getName()
Description
This audit rule looks for places where a class name is compared via the String.equals, String.equalsIgnoreCase, == or !=. By not making comparisons in this way, code is prevented from malicious users creating a class with the same name in order access the blocks of code.
Specifically, this audit rule flags the following patterns:
[class].getName().equals(*)
*.equals([class]>.getName())
[class].getName().equalsIgnoreCase(*)
*.equalsIgnoreCase(.getName())
[class].getName() == *
* == [class].getName()
[class].getName() != *
* != [class].getName()
Where [class] is any instance of java.lang.Class.
Example
The following method invocation of equals would be flagged a violation:
if("SomeClassName".equals(class.getName())) {...}Avoid Inner Classes
Severity: Medium
Summary
Avoid using inner classes.
Description
Inner classes are converted into bytecode just like parent classes. Don't depend on an inner class to keep adversaries from private fields. Remember, an inner class has bytecode separate from parent class, but still has access to private fields in the parent class.
Example
The following inner class declaration and the anonymous class declaration would both be flagged as violations:
public class OuterClass {
public class InnerClass{}
public void foo() {
Runnable runnable = new Runnable() {
public void run(){/*do nothing*/}
}
}Avoid Package Scope
Severity: Medium
Summary
Only use public, protected or private scopes.
Description
Classes, methods and fields with package scope (default scope) can be accessed from all code within the same package, including code written by adversaries. This audit flags all inner classes, constructors, methods, and fields that have a package scope.
Note: non-inner classes and interfaces cannot syntactically be declared protected or private, thus since a non-inner class/ interface isn't more secure if it has package scope instead of a public scope, this audit does not flag interfaces or non-inner classes that have a package scope.
Also note: the resolutions (fixes) for flagged instances of this audit include the insertion of the "public" modifier as well as "private" and "protected" modifiers. However, changing a modifier from package scope to a public scope does not make the code more secure, and is included only because it is expected that the public modifier is used.
Example
The following will all be flagged since they all have a package scope: the constructor "Example", the class "InnerClass", the method "some_method", and the integer "x":
class Example {
Example(){super();}
class InnerClass{}
static void some_method(){/* do nothing */}
int x;
}Deserializeability Security
Severity: Medium
Summary
Prevent non-deserializeable classes from being deserialized by adversaries.
Description
Even when a class is not serializeable, adversaries can sometimes instantiate an instance of a class with a byte array. This can be a security hazard since there is no control on the state of the new object. To prevent this, implement a readObject method:
private final void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
throw new IOException("Non-deserializable class");
}
This audit will be violated if there does not exists a method with the signature:
private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException;
Example
The following method declaration would be flagged as a violation because it does not have the required parameter:
private void readObject() throws IOException, ClassNotFoundException;
Do Not Implement Serializable
Severity: Medium
Summary
Objects and interfaces should not be declared as Serializable.
Description
When an object is serialized it is outside of the JRE and thus outside of all security measures enforced by the JRE. In many cases, packages or entire projects should not declare objects or interfaces as Serializable.
Example
The following class would be flagged:
class A implements java.io.Serializable {..}
Do Not Serialize Byte Arrays
Severity: Medium
Summary
Do not serialize byte arrays using the ObjectOutputStream.write(byte[]) method.
Description
This audit rule looks for invocations of the method ObjectOutputStream.write(byte[]). Byte arrays should not be serialized using this method because the method is not final, allowing subclasses of ObjectOutputStream to override the method and have access to internal data.
Example
Given the following field declaration:
private byte[] key;
The following invocation of the write method would be flagged:
private void writeObject(ObjectOutputStream stream)
{
stream.write(key);
}Do Not Subclass ClassLoader
Severity: Medium
Summary
Do not extend java.lang.ClassLoader
Description
Do not subclass java.lang.ClassLoader, doing so can introduce security risk. In instances where ClassLoader needs to be subclassed, use java.security.SecureClassLoader.
Example
The following class would be flagged as a violation:
class A extends ClassLoader {...}
Don't Return Mutable Types
Severity: Medium
Summary
Don't return mutable types from methods.
Description
Checks that returned types are either default immutable types like java.lang.Integer or are declared immutable in the audit rule preferences.
Example
The following method declaration would be flagged (assuming "MutableType" is not declared as immutable in the audit rule preferences):
public MutableType getData() {
return new MutableType();
}Enforce Cloneable Usage
Severity: Medium
Summary
When an Object is cloned, Object data is copied and returned, because of this secure classes must be conscious of Cloneable.
Description
This audit rule aims to prevent adversaries from accessing data by extending classes and creating clone methods. Specifically, this rule flags non-anonymous classes that:
(1) do not implement Cloneable (so that the rule doesn't flag appropriate uses of Cloneable utilities),
(2) are non-final (final classes can't be extended),
(3) do not inherit a clone method (since inserting a clone method would be unnecessarily repetitive),
(4) and do not override clone():public Object clone() throws CloneNotSupportedException;
and may enforce the following as the body of the clone method:
{
throws java.lang.CloneNotSupportedException("Type not cloneable");
}without, or with, a String input description.
Note: Even though classes that do not implement the Cloneable interface throw CloneNotSupportedException, adversaries are not prevented from extending a class, implementing the Cloneable interface, and then calling clone() to retrieve a copy of an instance of the class.
For more audit rule options concerning clone(), see Clone Method Usage and Override Clone Judiciously under Semantic Errors.
Example
The classes A, B and C below will not be flagged, but D will be.
class A {
public Object clone() {
throw new java.lang.CloneNotSupportedException();
}
}
class B extends A {}
final class C{}
class D {}Finalize Should Not Be Public
Severity: Medium
Summary
Finalize methods declared within an Applet should not be public
Description
This audit rule flags any declarations of the Object.finalize that are public and within an Applet. If the finalize method is declared properly, then the method should not need to be public. Furthermore, there are cases in which where malicious users can preform attacks on Applets using a public finalize method.
Example
The following declaration of finalize would be flagged:
class A extends java.applet.Applet {
public void finalize() {}
}Hardcoded Password
Severity: Medium
Summary
Passwords should not be hardcoded.
Description
This audit rule violates any instance where a java.util.Properties object has a password hardcoded within the source code. When a password is hardcoded, not only can other developers see the password, but the password can also be extracted from the java byte code. If a such a password is found, and it is also empty, a violation is thrown to create a password.
Example
The line "properties.setProperty("password", "somePassword");" would be flagged as "somePassword" is a hardcoded password.
Properties properties = new Properties();
properties.setProperty("user", "someUserName");
properties.setProperty("password", "somePassword");
DriverManager.getConnection(..., properties);Instance Field Security
Severity: Medium
Summary
Refrain from using non-final public instance fields.
Description
To the extent possible, refrain from using non-final public instance fields. Instead, let the interface to your instance field be through accessor methods. In this way it is possible to add centralized security checks, if required.
Example
The following field declaration would be flagged as a violation because it is both public and non-final:
public int width;
Mutability Of Arrays
Severity: Medium
Summary
Do not return internal arrays from non-private methods
Description
This audit rule flags unsafe set or get of an internal array field, this includes flagging: 1) internal array returns from a non-private method and 2) setting an internal array with parameter given through a non-private method.
With arrays it is safer to make a copy before the set or return. This way, the internal data is not manipulated outside of the class.
Example
Given the following field declaration:
int[] integerArray = ...;
public int[] getIntegerArray() {
return integerArray;
}Mutable Constant Field
Severity: Medium
Summary
Disallows public static final mutable type fields.
Description
Checks that public static final fields are either default immutable types like java.lang.Integer or are user-specified immutable types, declared through the audit rule preferences.
Example
The following would be flagged:
public static final MutableType mutableType;
Prevent Overwriting Of Externalizable Objects
Severity: Medium
Summary
Disallows Externalizable objects to be overwritten.
Description
All classes that implement java.io.Externalizable must declare the public readExternal method. Malicious users may call this method after the method has been initialized, this can potentially overwrite the internal state of the class.
This audit rule declares that every class and subclass of Externalizable must declare readExternal and that readExternal must match the following pattern:
public synchronized void readExternal(ObjectInput in) throws IOException, ClassNotFoundException {
if (! initialized) {
initialized = true;
*
} else {
throw new IllegalStateException();
}
}The boolean named "initialized", may have any valid name, and can be accessed via the this keyword, but cannot be re-assigned anywhere else within the class as such a reassignment could easily invalidate the security measures being taken.
Example
The following class would be flagged as readExternal is not declared as synchronized:
public class A implements Externalizable {
boolean initialized = false;
public void readExternal(ObjectInput in) {
if (! initialized) {
initialized = true;
// initialize the object } else {
throw new IllegalStateException();
}
}
public void writeExternal(ObjectOutput out) throws IOException {
*
}
}Serializeability Security
Severity: Medium
Summary
When an Object implements Serializeable, adversaries can sometimes serialize the Object into a byte array, because of this, secure classes must be conscious of Serializeable.
Description
This audit rule aims to prevent adversaries from accessing the state of an Object by extending classes and retrieving the Object data by calling writeObject. To prevent this hazard, implement the following in all classes that implement java.io.Serializeable:
private final void writeObject(ObjectOutputStream in) throws IOException {
new java.io.IOException("Class cannot be serialized");
}This rule flags instances of Serializable that do not contain the following method signature:
private void writeObject(ObjectOutputStream in) throws IOException;
Example
The following method declaration would be flagged as a violation because it does not have the required parameter:
private void writeObject() throws IOException;
Static Field Security
Severity: Medium
Summary
Refrain from using non-final public static fields.
Description
To the extent possible, refrain from using non-final public static fields because there is no way to check whether the code that changes such fields has appropriate permissions.
Example
The following declaration would be flagged as a violation because it is both public and non-final:
public static int minutesPerHour = 60;
Use of Random
Severity: Medium
Summary
java.util.Random is not as secure as java.security.SecureRandom
Description
This audit rule looks for any use of the java.util.Random class, including any classes declared as a subclass of Random, and any instances of Random being instantiated.
Example
The following would be flagged as a violation:
class A extends Random {}
Use Privileged Code Sparingly
Severity: Medium
Summary
Prevents the overuse of privileged code.
Description
"Privileged" code allows code access to system variables the Java API would normally not allow access to, for security purposes this code should be used sparingly.
This audit rule flags instances of java.security.PrivilegedAction and java.security.PrivilegedExceptionAction which have more than a specified number (default 0) of statements within run().
Note: When set to default value of 0, no privileged code will be allowed since the method run, see PrivilegedAction or PrivilegedExceptionAction, returns an Object, which at minimum takes one statement: "return null;".
Example
The following source would be flagged since there are statements in a run() method declared for a PrivilegedAction.
...
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
System.loadLibrary("awt");
return null;
}
});
...