CWE-492: Use of Inner Class Containing Sensitive Data
Use of Inner Class Containing Sensitive Data
Weakness ID: 492 (Weakness Variant)
Status: Draft
Description
Description Summary
Inner classes are translated into classes that are accessible
at package scope and may expose code that the programmer intended to keep
private to attackers.
Time of Introduction
Implementation
Applicable Platforms
Languages
Java
Common Consequences
Scope
Effect
Confidentiality
"Inner Classes" data confidentiality aspects can often be
overcome.
Likelihood of Exploit
Medium
Demonstrative Examples
Example 1
The following Java Applet code mistakenly makes use of an inner
class.
(Bad Code)
Java
public final class urlTool extends Applet {
private final class urlHelper {
...
}
...
}
Potential Mitigations
Phase
Description
Implementation
Using sealed classes protects object-oriented encapsulation paradigms
and therefore protects code from being extended in unforeseen
ways.
Implementation
Inner Classes do not provide security. Warning: Never reduce the
security of the object from an outer class, going to an inner class. If
your outer class is final or private, ensure that your inner class is
private as well.
Other Notes
Inner classes quietly introduce several security concerns because of the
way they are translated into Java bytecode. In Java source code, it appears
that an inner class can be declared to be accessible only by the enclosing
class, but Java bytecode has no concept of an inner class, so the compiler
must transform an inner class declaration into a peer class with package
level access to the original outer class. More insidiously, since an inner
class can access private fields in their enclosing class, once an inner
class becomes a peer class in bytecode, the compiler converts private fields
accessed by the inner class into protected fields.
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.
Description
