Java Developer Tools

CodePro Audit Rule Set

/h1>

Security

Powered by CodePro Analytix and Eclipse


Summary

Applet Field Security
Avoid Building Queries From User Input
Avoid Comparing Classes By String Names
Avoid Inner Classes
Avoid Package Scope
Deserializeability Security
Do Not Implement Serializable
Do Not Serialize Byte Arrays
Do Not Subclass ClassLoader
Don't Return Mutable Types
Enforce Cloneable Usage
Finalize Should Not Be Public
Hardcoded Password
Instance Field Security
Mutability Of Arrays
Mutable Constant Field
Prevent Overwriting Of Externalizable Objects
Serializeability Security
Static Field Security
Use of Random
Use Privileged Code Sparingly

Details

Applet Field Security

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;

Avoid Building Queries From User Input

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();

Avoid Comparing Classes By String Names

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;
}
});
...

Authentication required

You need to be signed in with Google+ to do that.

Signing you in...

Google Developers needs your permission to do that.