Rule 01. Declarations and Initialization (DCL)

Rob and I often point out that in order to define code as vulnerable, you have to have a security policy in mind (although it can be implicit). And Java's implicit security policy is different from C.

In C, if you allow an attacker to link code against your code, we make no promises. Our security policy for C assumes the attacker only has access to an executable binary of your code; the Q being, can they crash your program, access sensitive info, or use your program for arbitrary code execution.

But Java has more stringent requirements. We assume that an attacker is allowed to link her malicious code against your 'secure' Java classes, and execute them in her own JVM (which we assume complies with the Java spec).

So to comply with our standard, your Java code (if it constitutes a complete program) must not only satisfy the C policy of preventing an attacker from crashing it, accessing sensitive info, or executing arbitrary code. Your code must also prevent crashes in itself, protect sensitive info, and prevent code execution when linked to hostile code and executed in a hostile (but standard-compliant) JVM.

We also mandate that an attacker not be able to access private or public data, or run private or public methods of your class...that is the Java implicit security policy respects the private, and protected keywords (and the implicit package access).

In the case of DCL31-J, a constant not marked final is vulnerable to hostile code changing its value. This might not require a multithreaded program, but is certainly more vulnerable in one. Thus this is a valid Java rule, but only a recommendation (DCL00-C) in C.

Dhruv, the Introduction section should make Java's security policy more explicit, since it differs from C. (For that matter, I should add a similar blurb to C++'s intro).

I wonder if there is place for ugly code such as:

class Test {
  Test() {
    test = "value2";
  }
  String test = "value1";
  // ... what is the final value of test?
}