Callbacks provide a means to register a method to be invoked (or called back) when an interesting event occurs. Java uses callbacks for applet and servlet life-cycle events, AWT and Swing event notifications such as button clicks, asynchronous reads and writes to storage, and even in
Runnable.run() wherein a new thread automatically executes the specified
In Java, callbacks are typically implemented using interfaces. The general structure of a callback is as follows:
Callback methods are often invoked without changes in privileges, which means that they may be executed in a context that has more privileges than the context in which they are declared. If these callback methods accept data from untrusted code, privilege escalation may occur.
According to Oracle's Secure Coding Guidelines [SCG 2010],
Callback methods are generally invoked from the system with full permissions. It seems reasonable to expect that malicious code needs to be on the stack in order to perform an operation, but that is not the case. Malicious code may set up objects that bridge the callback to a security checked operation. For instance, a file chooser dialog box that can manipulate the filesystem from user actions, may have events posted from malicious code. Alternatively, malicious code can disguise a file chooser as something benign while redirecting user events.
This guideline is an instance of SEC51-J. Minimize privileged code and is related to SEC01-J. Do not allow tainted variables in privileged blocks.
Noncompliant Code Example
This noncompliant code example uses a
UserLookupCallBack class that implements the
CallBack interface to look up a user's name given the user's ID. This lookup code assumes that this information lives in the
/etc/passwd file, which requires elevated privileges to open. Consequently, the
Client class invokes all callbacks with elevated privileges (within a
This code could be safely used by a client, as follows:
However, an attacker can use
CallBackAction to execute malicious code with elevated privileges by registering a
Compliant Solution (Callback-Local
According to Oracle's secure coding guidelines [SCG 2010]:
By convention, instances of
PrivilegedExceptionActionmay be made available to untrusted code, but
doPrivilegedmust not be invoked with caller-provided actions.
This compliant solution moves the invocation of
doPrivileged() out of the
CallBackAction code and into the callback itself.
This code behaves the same as before, but an attacker can no longer run malicious callback code with elevated privileges. Even though an attacker can pass a malicious callback instance using the constructor of class
CallBackAction, the code is not executed with elevated privileges because the malicious instance must contain a
doPrivileged block that cannot have the same privileges as trusted code. Additionally, class
CallBackAction cannot be subclassed to override the
perform() method as it is declared final.
Compliant Solution (Declare Callback Final)
This compliant solution declares the
final to prevent overriding of
Exposing sensitive methods through callbacks can result in misuse of privileges and arbitrary code execution.
Guideline 9-3: Safely invoke