582 (Weakness Variant)

Primary (Weakness exists independent of other weaknesses)

In most situations the array should be made private.

The following Java Applet code mistakenly declares an array public, final and static.

Mobile code, in this case a Java Applet, is code that is transmitted across a network and executed on a remote machine. Because mobile code developers have little if any control of the environment in which their code will execute, special security concerns become relevant. One of the biggest environmental threats results from the risk that the mobile code will run side-by-side with other, potentially malicious, mobile code. Because all of the popular web browsers execute code from multiple sources together in the same JVM, many of the security guidelines for mobile code are focused on preventing manipulation of your objects' state and behavior by adversaries who have access to the same virtual machine where your program is running.

In most cases an array declared public, final and static is a bug.

Java

481 (Weakness Variant)

Low

Pre-design: Through Build: Many IDEs and static analysis products will detect this problem.

Implementation: Place constants on the left. If one attempts to assign a constant with a variable, the compiler will of course produce an error.

This bug is generally as a result of a typo and usually should cause obvious problems with program execution. If the comparison is in an if statement, the if statement will always return the value of the right-hand side variable.

CLASP - Assigning instead of comparing

C

C++

Java

.NET

572 (Weakness Variant)

System Process

The following excerpt from a Java program mistakenly calls run() instead of start().

In most cases a direct call to a Thread object's run() method is a bug. The programmer intended to begin a new thread of control, but accidentally called run() instead of start(), so the run() method will execute in the caller's thread of control.

Java

580 (Weakness Variant)

The following two classes demonstrate a bug introduced by failing to call super.clone(). Because of the way Kibitzer implements clone(), FancyKibitzer's clone method will return an object of type Kibitzer instead of FancyKibitzer.

Java Example:

All implementations of clone() should obtain the new object by calling super.clone(). If a class fails to follow this convention, a subclass's clone() method will return an object of the wrong type.

It is also a good idea to declare your clone method as final. You may not want users inheriting your class to tamper with the clone method. In some cases, you can eliminate the clone method altogether in some cases and use copy constructors.

Java

486 (Weakness Variant)

High

Authorization: If a program relies solely on the name of an object to determine identity, it may execute the incorrect or unintended code.

Implementation: Use class equivalency to determine type. Rather than use the class name to determine if an object is of a given type, use the getClass() method, and == operator.

If the decision to trust the methods and data of an object is based on the name of a class, it is possible for malicious users to send objects of the same name as trusted classes and thereby gain the trust afforded to known classes and types.

7 Pernicious Kingdoms - Comparing Classes by Name

CLASP - Comparing classes by name

Java

493 (Weakness Variant)

Declare all public fields final when possible.

The following Java Applet code mistakenly declares a member variable public but not final.

Mobile code, in this case a Java Applet, is code that is transmitted across a network and executed on a remote machine. Because mobile code developers have little if any control of the environment in which their code will execute, special security concerns become relevant. One of the biggest environmental threats results from the risk that the mobile code will run side-by-side with other, potentially malicious, mobile code. Because all of the popular web browsers execute code from multiple sources together in the same JVM, many of the security guidelines for mobile code are focused on preventing manipulation of your objects' state and behavior by adversaries who have access to the same virtual machine where your program is running.

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.

7 Pernicious Kingdoms - Mobile Code: Non-Final Public Field

Java

396 (Weakness Base)

The following code excerpt handles three types of exceptions in an identical fashion.

At first blush, it may seem preferable to deal with these exceptions in a single catch block, as follows: try { doExchange(); } catch (Exception e) { logger.error("doExchange failed", e); } However, if doExchange() is modified to throw a new type of exception that should be handled in some different kind of way, the broad catch block will prevent the compiler from pointing out the situation. Further, the new catch block will now also handle exceptions derived from RuntimeException such as ClassCastException, and NullPointerException, which is not the programmer's intent.

Multiple catch blocks can get ugly and repetitive, but "condensing" catch blocks by catching a high-level class like Exception can obscure exceptions that deserve special treatment or that should not be caught at this point in the program. Catching an overly broad exception essentially defeats the purpose of Java's typed exceptions, and can become particularly dangerous if the program grows and begins to throw new types of exceptions. The new exception types will not receive any attention.

7 Pernicious Kingdoms - Overly-Broad Catch Block

C

C++

Java

.NET

397 (Weakness Base)

The following method throws three types of exceptions.

While it might seem tidier to write public void doExchange() throws Exception { ... } doing so hampers the caller's ability to understand and handle the exceptions that occur. Further, if a later revision of doExchange() introduces a new type of exception that should be treated differently than previous exceptions, there is no easy way to enforce this requirement.

Declaring a method to throw Exception or Throwable makes it difficult for callers to do good error handling and error recovery. Java's exception mechanism is set up to make it easy for callers to anticipate what can go wrong and write code to handle each specific exceptional circumstance. Declaring that a method throws a generic form of exception defeats this system.

7 Pernicious Kingdoms - Overly-Broad Throws Declaration

C

C++

Java

.NET

111 (Weakness Base)

Primary (Weakness exists independent of other weaknesses)

Explicit (This is an explicit weakness resulting from behavior of the developer)

The following code defines a class named Echo. The class declares one native method (defined below), which uses C to echo commands entered on the console back to the user. class Echo { public native void runEcho(); static { System.loadLibrary("echo"); } public static void main(String[] args) { new Echo().runEcho(); } } The following C code defines the native method implemented in the Echo class:

Java Example:

Because the example is implemented in Java, it may appear that it is immune to memory issues like buffer overflow vulnerabilities. Although Java does do a good job of making memory operations safe, this protection does not extend to vulnerabilities occurring in source code written in other languages that are accessed using the Java Native Interface. Despite the memory protections offered in Java, the C code in this example is vulnerable to a buffer overflow because it makes use of gets(), which does not perform any bounds checking on its input. The Sun Java(TM) Tutorial provides the following description of JNI [See Reference]: The JNI framework lets your native method utilize Java objects in the same way that Java code uses these objects. A native method can create Java objects, including arrays and strings, and then inspect and use these objects to perform its tasks. A native method can also inspect and use objects created by Java application code. A native method can even update Java objects that it created or that were passed to it, and these updated objects are available to the Java application. Thus, both the native language side and the Java side of an application can create, update, and access Java objects and then share these objects between them. The vulnerability in the example above could easily be detected through a source code audit of the native method implementation. This may not be practical or possible depending on the availability of the C source code and the way the project is built, but in many cases it may suffice. However, the ability to share objects between Java and native methods expands the potential risk to much more insidious cases where improper data handling in Java may lead to unexpected vulnerabilities in native code or unsafe operations in native code corrupt data structures in Java. Vulnerabilities in native code accessed through a Java application are typically exploited in the same manner as they are in applications written in the native language. The only challenge to such an attack is for the attacker to identify that the Java application uses native code to perform certain operations. This can be accomplished in a variety of ways, including identifying specific behaviors that are often implemented with native code or by exploiting a system information leak in the Java application that exposes its use of JNI [See Reference].

Native code is unprotected by the security features enforced by the runtime environment, such as strong typing and array bounds checking. Many safety features that programmers may take for granted simply do not apply for native code, so you must carefully review all such code for potential problems. Other programming languages that may be more susceptible to buffer overflows and other attacks, such as C or C++, usually implement native code. Language-based encapsulation is broken.

7 Pernicious Kingdoms - Unsafe JNI

Java

609 (Weakness Base)

While double-checked locking can be achieved in some languages, it is inherently flawed in Java before 1.5, and cannot be achieved without compromising platform independence. Before Java 1.5, only use of the synchronized keyword is known to work. Beginning in Java 1.5, use of the "volatile" keyword allows double-checked locking to work successfully, although there is some debate as to whether it achieves sufficient performance gains. See references.

It may seem that the following bit of code achieves thread safety while avoiding unnecessary synchronization...

Java Example:

The programmer wants to guarantee that only one <code>Helper()</code> object is ever allocated, but does not want to pay the cost of synchronization every time this code is called.

Let's say helper is not initialized. Then, thread A comes along, sees that helper==null, and enters the synchronized block and begins to execute:

If a second thread, thread B, takes over in the middle of this call and helper has not finished running the constructor, then thread B may make calls on helper while its fields hold incorrect values.

Anonymous Tool Vendor (under NDA) -

Java

Implementation

494 (Weakness Variant)

Medium

Implementation: Avoid doing this without proper cryptographic safeguards.

Java Example:

This is an unsafe practice and should not be performed unless one can use some type of cryptographic protection to assure that the mobile code has not been altered.

CLASP - Invoking untrusted mobile code

Java

575 (Weakness Variant)

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. In this case, the program violates the following EJB guideline: "An enterprise bean must not use the AWT functionality to attempt to output information to a display, or to input information from a keyboard." A requirement that the specification justifies in the following way: "Most servers do not allow direct interaction between an application program and a keyboard/display attached to the server system."

Java

578 (Weakness Variant)

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. In this case, the program violates the following EJB guideline: "The enterprise bean must not attempt to create a class loader; obtain the current class loader; set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams." A requirement that the specification justifies in the following way: "These functions are reserved for the EJB container. Allowing the enterprise bean to use these functions could compromise security and decrease the container's ability to properly manage the runtime environment."

Java

576 (Weakness Variant)

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. 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." The specification justifies this requirement 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."

Java

577 (Weakness Variant)

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. In this case, the program violates the following EJB guideline: "An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast." A requirement that the specification justifies in the following way: "The EJB architecture allows an enterprise bean instance to be a network socket client, but it does not allow it to be a network server. Allowing the instance to become a network server would conflict with the basic function of the enterprise bean-- to serve the EJB clients."

Java

574 (Weakness Variant)

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. In this case, the program violates the following EJB guideline: "An enterprise bean must not use thread synchronization primitives to synchronize execution of multiple instances." A requirement that the specification justifies in the following way: "This rule is required to ensure consistent runtime semantics because while some EJB containers may use a single JVM to execute all enterprise bean's instances, others may distribute the instances across multiple JVMs."

Java

585 (Weakness Variant)

Synchronization in Java can be tricky. An empty synchronized block is often a sign that a programmer is wrestling with synchronization but has not yet achieved the result they intend.

Java

586 (Weakness Variant)

The following code fragment calls finalize() explicitly:

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.

Java

478 (Weakness Variant)

Undefined: Depending on the logical circumstances involved, any consequences may result: e.g., issues of confidentiality, authentication, authorization, availability, integrity, accountability, or non-repudiation.

Implementation: Ensure that there are no unaccounted for cases, when adjusting flow or values based on the value of a given variable. In switch statements, this can be accomplished through the use of the default label.

In general, a safe switch statement has this form:

This is because the assumption cannot be made that all possible cases are accounted for. A good practice is to reserve the default case for error handling.

This flaw represents a common problem in software development, in which not all possible values for a variable are considered or handled by a given process. Because of this, further decisions are made based on poor information, and cascading failure results. This cascading failure may result in any number of security issues, and constitutes a significant failure in the system. In the case of switch style statements, the very simple act of creating a default case can mitigate this situation, if done correctly. Often however, the default cause is used simply to represent an assumed option, as opposed to working as a sanity check. This is poor practice and in some cases is as bad as omitting a default case entirely.

CLASP - Failure to account for default case in switch

C

C++

Java

.NET

568 (Weakness Variant)

The following method omits the call to super.finalize().

Java Example:

The Java Language Specification states that it is a good practice for a finalize() method to call super.finalize()

Java

460 (Weakness Variant)

Medium

Implementation: The code could be left in a bad state.

Implementation: If one breaks from a loop or function by throwing an exception, make sure that cleanup happens or that you should exit the program. Use throwing exceptions sparsely.

C++/Java Example:

In this case, you may leave a thread locked accidentally.

Often, when functions or loops become complicated, some level of cleanup in the beginning to the end is needed. Often, since exceptions can disturb the flow of the code, one can leave a code block in a bad state.

CLASP - Improper cleanup on thrown exception

C

C++

Java

.NET

498 (Weakness Variant)

Medium

Confidentiality: A class which can be cloned can be produced without executing the constructor.

Implementation: Make classes uncloneable by defining a clone function like: public final void clone() throws java.lang.CloneNotSupportedException { throw new java.lang.CloneNotSupportedException(); }

Implementation: If you do make your classes clonable, ensure that your clone method is final and throw super.clone().

Java Example:

Classes which do no explicitly deny cloning can be cloned by any other class without running the constructor. This is, of course, dangerous since numerous checks and security aspects of an object are often taken care of in the constructor.

CLASP - Information leak through class cloning

C++

Java

.NET