##### General

- Home
- Downloads
- Javadocs
- Mailing Lists
- Bug Tracker
- SourceForge Project
- GitHub Project

##### Running

- Ant Task Usage
- Command-Line
- Run as a Test
- Other Tools/Frameworks

##### Using

- Creating a RuleSet
- Creating a Rule
- Configuring Rules
- Starter RuleSet (All)

##### Report Types

- HTML Report
- XML Report
- Text and IDE Reports

##### Sample Reports

- Sample HTML Report
- Sample XML Report

##### Rules

- Rule Index
- Basic Rules
- Braces Rules
- Concurrency Rules
- Convention Rules
- Design Rules
- DRY Rules
- Enhanced Rules
- Exceptions Rules
- Formatting Rules
- Generic Rules
- Grails Rules
- Groovyism Rules
- Imports Rules
- JDBC Rules
- JUnit Rules
- Logging Rules
- Naming Rules
- Size/Complexity Rules
- Security Rules
- Serialization Rules
- Unnecessary Rules
- Unused Rules

##### Developing

- Developer Guide

##### Project Documentation

- Project Information
- Project Reports

## Security Rules ("rulesets/security.xml")

Also see GrailsMassAssignment.

### FileCreateTempFile Rule

New in CodeNarc 0.14

The File.createTempFile() method is insecure, and has been deprecated by the ESAPI secure coding library. It has been replaced by the ESAPI Randomizer.getRandomFilename(String) method.

For more information see the ESAPI website: http://code.google.com/p/owasp-esapi-java/ and the Randomizer Javadoc: http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Randomizer.html

### InsecureRandom Rule

New in CodeNarc 0.14

Reports usages of `java.util.Random`, which can produce very predictable results. If two instances of Random are created with the same seed and sequence of method calls, they will generate the exact same results. Use `java.security.SecureRandom` instead, which provides a cryptographically strong random number generator. SecureRandom uses PRNG, which means they are using a deterministic algorithm to produce a pseudo-random number from a true random seed. SecureRandom produces non-deterministic output.

By default, this rule ignores test classes are ignored.

For more information see: http://www.klocwork.com/products/documentation/current/Checkers:SV.RANDOM

Example of violations:

         def r1 = new Random()
         def r2 = new java.util.Random()
         Math.random()
         java.lang.Math.random()

         // this is OK
         new java.security.SecureRandom()
         new SecureRandom()

### JavaIoPackageAccess Rule

New in CodeNarc 0.14

This rule reports violations of the Enterprise JavaBeans specification by using the java.io package to access files or the file system.

The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container [1].

In this case, the program violates the following EJB guideline: "An enterprise bean must not use the java.io package to attempt to access files and directories in the file system."

A requirement that the specification justifies in the following way: "The file system APIs are not well-suited for business components to access data. Business components should use a resource manager API, such as JDBC, to store data."

REFERENCES

1. Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 576
2. The Enterprise JavaBeans 2.1 Specification Sun Microsystems

By default, this rule is not applied to tests and test cases.

Example of violations:

        FileSystem.getFileSystem()          // any method on FileSystem
        FileSystem.fileSystem.delete(aFile) // property access of FileSystem

        // shouldn't create files
        new File(name)
        new File(name, parent)

        // don't create file readers
        new FileReader(name)

        // don't create file output streams
        new FileOutputStream(name)
        new FileOutputStream(name, true)

        // don't create random access file
        new RandomAccessFile(name, parent)

### NonFinalPublicField Rule

New in CodeNarc 0.14

Finds code that violates secure coding principles for mobile code by declaring a member variable public but not final.

All public member variables in an Applet and in classes used by an Applet should be declared final to prevent an attacker from manipulating or gaining unauthorized access to the internal state of the Applet.

References:

- Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 493
- G. McGraw Securing Java. Chapter 7: Java Security Guidelines

### NonFinalSubclassOfSensitiveInterface Rule

New in CodeNarc 0.14

The permissions classes such as `java.security.Permission` and `java.security.BasicPermission` are designed to be extended. Classes that derive from these permissions classes, however, must prohibit extension. This prohibition ensures that malicious subclasses cannot change the properties of the derived class. Classes that implement sensitive interfaces such as `java.security.PrivilegedAction` and `java.security.PrivilegedActionException` must also be declared `final` for analogous reasons.

For more information see: https://www.securecoding.cert.org/confluence/display/java/SEC07-J.+Classes+that+derive+from+a+sensitive+class+or+implement+a+sensitive+interface+must+be+declared+final

Example of violations:

        class MyPermission extends java.security.Permission {
            MyPermission(String name) { super(name) }
            boolean implies(Permission permission) { true }
            boolean equals(Object obj) { true }
            int hashCode() { 0 }
            String getActions() { "action" }
        }

        class MyBasicPermission extends BasicPermission {
            MyBasicPermission(String name) { super(name) }
        }

        class MyPrivilegedAction implements PrivilegedAction {
            Object run() { 0 }
        }

        class MyPrivilegedActionException extends PrivilegedActionException {
            MyPrivilegedActionException(Exception exception) { super(exception) }
        }

### PublicFinalizeMethod Rule

New in CodeNarc 0.14

Creates a violation when the program violates secure coding principles by declaring a `finalize()` method public.

A program should never call finalize explicitly, except to call super.finalize() inside an implementation of `finalize()`. In mobile code situations, the otherwise error prone practice of manual garbage collection can become a security threat if an attacker can maliciously invoke one of your finalize() methods because it is declared with public access. If you are using `finalize()` as it was designed, there is no reason to declare `finalize()` with anything other than protected access.

References:

- Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 583
- G. McGraw Securing Java. Chapter 7: Java Security Guidelines

### ObjectFinalize Rule

New in CodeNarc 0.14

The finalize() method should only be called by the JVM after the object has been garbage collected.

While the Java Language Specification allows an object's finalize() method to be called from outside the finalizer, doing so is usually a bad idea. For example, calling finalize() explicitly means that finalize() will be called more than once: the first time will be the explicit call and the last time will be the call that is made after the object is garbage collected.

References: Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 586

### SystemExit Rule

New in CodeNarc 0.14

Web applications should never call System.exit(). A call to System.exit() is probably part of leftover debug code or code imported from a non-J2EE application.

1. Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A9 Application Denial of Service
2. Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP6080 CAT II
3. Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 382
4. Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.9

### UnsafeArrayDeclaration Rule

New in CodeNarc 0.14

Triggers a violation when an array is declared public, final, and static.

In most cases an array declared public, final and static is a bug. Because arrays are mutable objects, the final constraint requires that the array object itself be assigned only once, but makes no guarantees about the values of the array elements. Since the array is public, a malicious program can change the values stored in the array. In most situations the array should be made private.

Example of violations:

        class MyClass {
            public static final String[] myArray = init()
            public static final def myArray = [] as String[]
        }