Security - Java Coding Guidelines - page 80

class CallBackAction {
private CallBack callback;
public CallBackAction(CallBack callback) {
this.callback = callback;
}
public void perform() {
callback.callMethod();
}
}
class Client {
public static void main(String[] args) {
CallBackAction action =
new CallBackAction(new CallBackImpl());
// ...
action.perform(); // Prints "CallBack invoked"
}
}
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 escala-
tion 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 anoperation, butthat is notthe case. Malicious code may set upobjects that
bridge the callback to a security checked operation. For instance, a file chooser dia-
log box that can manipulate the filesystem from user actions, may have events pos-
ted from malicious code. Alternatively, malicious code can disguise a file chooser as
something benign while redirecting user events.
This guideline is an instance of Guideline 17 , “ Minimize privileged code ,” and is re-
latedto The CERT ® Oracle ® Secure Coding Standard for Java ™ [Long2012],“SEC01-J.
Do not allow tainted variables in privileged blocks.”