SV.EXPOSE.FIELD

This error is detected when a static field in a class is not defined as final.

Vulnerability and risk

Because applets can persist after the Web browser leaves the page that contains them, it becomes important to protect applets from each other. Otherwise, an attacker's applet could deliberately sabotage a third party's applet. In many environments, it would be unacceptable for an applet to even learn of the existence of another applet.

In Netscape Navigator 3.0, AppletContext.getApplets() is careful to return handles only to applets on the same Web page as the caller. However, an applet could easily get a handle to the top-level ThreadGroup and then enumerate every thread running in the system, including threads belonging to other arbitrary applets. The Java runtime encodes the applet's class name in its thread name, so a rogue applet can now learn the names of all applets running in the system. In addition, an applet could call the stop() or setPriority() methods on threads in other applets. The SecurityManager checked only that applets could not alter the state of system threads; there were no restraints on applets altering other applet threads.

Netscape Navigator 4.0 prevents an attacker from seeing threads belonging to applets on other Web pages, in the same way it protects applets. Internet Explorer allows an applet to see those threads, but calls to stop() or setPriority() have no effect. An insidious form of this attack involves a malicious applet that lies dormant except when a particular victim applet is resident. When the victim applet is running, the malicious applet randomly mixes degradation of service attacks with attacks on the victim applet's threads. The result is that the user sees the victim applet as slow and buggy.

The attacker applet can use security vulnerabilities to modify the internal state of the victim applet, so it is important to keep the visibility of methods and fields as low as possible, avoid static fields, and use 'final' as much as possible.

Klocwork security vulnerability (SV) checkers identify calls that create potentially dangerous data; these calls are considered unsafe sources. An unsafe source can be any data provided by the user, since the user could be an attacker or has the potential for introducing human error.

Mitigation and prevention

Make non-final public or protected static fields final.

Example 1

Copy
     public static boolean debug;

SV.EXPOSE.FIELD is reported for line 9: Non-final public or protected static field 'debug' could be changed by malicious code or by accident from another package.