Java Developer Tools

Audit - Rules - Possible Errors

Description
This group contains audit rules that look for places where the code might contain errors.

Rules:

Details

Array Is Stored Without Copying

Summary
Storing of arrays without copying should not be used.

Description
This audit rule looks for places where arrays are stored without copying.

Security Implications
If constructors and methods receive and store arrays without copying, these arrays could be unpredictably changed from outside of the class.

Example

The following declaration of the setArray method will be marked as a violation because it does not copy its parameter:

    private String[] array;
    ....
    public void setArray( String[] newArray){
            this.array = newArray;
    }

Avoid Comparing Classes By String Names

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 using the methods String.equals or String.equalsIgnoreCase, or the == or != operators.

Specifically, this audit rule flags the following patterns:

[class].getName().equals(*)
*.equals([class].getName())
[class].getName().equalsIgnoreCase(*)
*.equalsIgnoreCase([class].getName())
[class].getName() == *
* == [class].getName()
[class].getName() != *
* != [class].getName()

Where [class] is any instance of java.lang.Class.

Security Implications
By not making comparisons in this way, code is prevented from malicious users creating a class with the same name in order to gain access to blocks of code not intended by the programmer.

Example
The following method invocation of equals would be flagged a violation:

    if ("SomeClassName".equals(class.getName())) ...

Field Might Have Null Value

Summary
You should check fields used in methods beacuse they might have null value.

Description
This audit rule looks for references to fields whose value can be null where the value of the field is not checked before being dereferenced.

Security Implications
Use checks on a null pointer because NullPointerException might be thrown.

Example
The following usage of the field date will be marked as a violation beacuse it is not checked:

    public class TestClass {
        private Date date = null;
        public void badUsage() {
            String myStr = date.toString();
        }
    }

Incompatible types stored in a collection

Summary
You should avoid incompatible casts because a ClassCastException will be thrown.

Description
This audit rule looks for places in the code that cast elements retrieved from a collection to a type that is not compatible with the type of elements being put into that very collection.

Security Implications
Incompatible cast will cause a ClassCastException to be thrown. This could be used to create a potential denial-of-service state or reveal security-sensitive parts of an application's design through the stack trace.

Example
The following invocation of the get() method will be marked as a violation because its return value is cast to a type incompatible with the one being put into collection:

    public class MyClass {
        ...
        private List testList;
        ...
        public void myMethod(MyClass obj) {
            testList.add(obj);
            Integer test = (Integer)testList.get(0);
    }

Next method invoked without hasNext method

Summary
Do not invoke the next method if you do not invoke hasNext method before that because NoSuchElementException can be thrown.

Description
This rule looks for places where the next method is invoked without or before the hasNext method.

Security Implications
If the next method is invoked without first invoking the hasNext method, in loop for example, a NoSuchElementException may be thrown.

Example
The following invocation of the next method will be flagged as a violation because the hasNext method is not invoked:

    public void myMethod(Collection myList)
    {
            .......
            Iterator iter = myList.iterator();
            for (int i = 0; i < 10; i++) {
                    iter.next();
            }
    }

Usage Of Binary Comparison

Summary
You should use short-circuit operations instead of binary operations.

Description
This rule looks for places where a binary operation is used that could be replaced by a short-circuit operator.

Security Implications
Usage of binary operation instead of short-circuit can cause unexpected situation when RuntimeException or NullPointerException can be thrown.

Example
The following code would be flagged as a violation because a binary and operator (&) is used where a conditional-and operator (&&) could be used:

    public void func(int[] a)
    {
        if (a != null & a.length() != 0) {
                doSomething();
        }
    }

Variable Has Null Value

Authentication required

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

Signing you in...

Google Developers needs your permission to do that.